Guia de operação.

1. Abra a calculadora e copie a consulta SQL de inventário.
2. Execute a consulta em cada instância SQL Server que deseja analisar e exporte o resultado em CSV.
3. Se houver várias instâncias, consolide os CSVs mantendo server_name, instance_name e as demais colunas originais. Adicione environment_name para identificar Produção, Homologação etc.
4. Importe o CSV consolidado. Revise os volumes, preencha os espaços livres que vierem em branco e informe o crescimento mensal esperado de cada arquivo.
5. Calcule a projeção, avalie os cenários, riscos, plano de ação e, se aplicável, o diagnóstico AlwaysOn.
6. Exporte os relatórios e valide as recomendações com a equipe DBA e infraestrutura antes de qualquer mudança.

Escopo da consulta

• Inclui bancos de usuário ONLINE, não snapshots, e acessíveis ao login que executa a consulta.
• Não inclui bancos de sistema, offline, restoring ou arquivos FILESTREAM. A calculadora modela arquivos DATA (ROWS) e LOG.
• Coleta servidor, instância, banco, arquivo, caminho físico, volume, tamanho alocado, espaço utilizado DATA, FILEGROWTH, MAXSIZE e espaço livre reportado pelo sistema operacional.
• O inventário é somente leitura. A ferramenta não abre conexão com SQL Server e não executa a consulta por conta própria.
• O importador reconhece CSV delimitado por vírgula, ponto e vírgula ou tabulação e interpreta números com vírgula decimal em formatos usuais do Excel em português.

Permissões e qualidade da coleta

O login precisa ter acesso aos metadados dos bancos incluídos e as permissões de estado do servidor exigidas pela versão do SQL Server para as DMVs utilizadas. Em geral, SQL Server 2019 e anteriores usam VIEW SERVER STATE; SQL Server 2022 e posteriores podem exigir VIEW SERVER PERFORMANCE STATE. Confirme a permissão específica na documentação da versão instalada.

Se volume_mount_point ou available_gb não vierem preenchidos, a ferramenta não presume espaço livre igual a zero: deixa o campo em branco para revisão manual. Em SQL Server no Linux, volume_mount_point pode retornar NULL, exigindo a identificação manual do volume. Quando o ponto de montagem não é identificado, cada caminho físico é isolado para evitar somar o mesmo espaço livre várias vezes. Confirme o volume real e consolide manualmente os arquivos que compartilham o mesmo volume antes de projetar capacidade.

Azure SQL Database, Elastic Pools e Managed Instance

A consulta pronta desta página foi desenhada para SQL Server com arquivos associados a volumes do sistema operacional. Não a utilize como coleta automática de espaço físico para Azure SQL Database ou Elastic Pools: esses serviços expõem métricas próprias de armazenamento e recursos, em escopo de banco e pool. Para Azure SQL Database, consulte sys.resource_stats no banco virtual master para histórico de armazenamento e recursos, e sys.dm_db_resource_stats no banco de usuário para métricas granulares recentes; para Managed Instance, avalie sys.server_resource_stats. Em Elastic Pools, as porcentagens de recurso são relativas aos limites configurados para o pool. Esses dados não devem ser confundidos com espaço livre de uma unidade física. A calculadora pode receber dados manuais, mas a consulta de inventário desta página não substitui uma coleta específica do Azure.

Referências: sys.dm_os_volume_stats · sys.resource_stats (Azure SQL Database) · sys.server_resource_stats (Managed Instance) · sys.dm_db_resource_stats.

Quando um mesmo volume aparece em várias linhas do CSV, a calculadora utiliza o menor espaço livre informado na coleta, como critério conservador.

DATA (MDF/NDF)

Informe o crescimento mensal esperado do espaço utilizado, não o aumento do tamanho alocado. A projeção consome primeiro a folga interna do arquivo; somente quando a necessidade supera o tamanho alocado é considerada a expansão física por FILEGROWTH.

LOG (LDF)

Informe o aumento físico líquido mensal do arquivo de log. Não use o volume bruto de transações geradas. Considere o recovery model, backups de log, transações longas, sessões abertas, reutilização do log e comportamento real do workload.

FILEGROWTH e MAXSIZE

• FILEGROWTH fixo pode ser informado em MB ou GB; em percentual, o incremento é recalculado sobre o tamanho atual a cada evento simulado.
• FILEGROWTH igual a zero representa autogrowth desativado. Se houver demanda de expansão, o arquivo será sinalizado como bloqueado.
• MAXSIZE limita a alocação projetada. Um arquivo que atinge MAXSIZE pode deixar de crescer, mas isso não significa que a demanda da aplicação desapareceu: trate o bloqueio como risco operacional.
• Use taxas mensais baseadas em medições comparáveis. Uma única coleta não permite inferir crescimento histórico.

As projeções por arquivo consideram crescimento linear e os incrementos FILEGROWTH informados. A visão de infraestrutura consolida a necessidade adicional por volume e por instância em 12, 24 e 36 meses, descontando o espaço livre atual e aplicando a margem de segurança configurada.

Os cenários otimista, provável e pessimista aplicam fatores às taxas mensais. Eles são simulações de sensibilidade, não previsões estatísticas. Revise os percentuais de cenário e a margem de segurança para refletir a política da organização.

O planejamento financeiro multiplica a capacidade adicional estimada pelo preço informado por GB ou TB. A conversão utilizada é 1 TB = 1.024 GB. Preço igual a zero significa valor não informado e não será tratado como storage gratuito; sem preço positivo, o orçamento não é calculado. O valor não representa cotação de fornecedor nem inclui automaticamente impostos, suporte, licenciamento, IOPS, throughput, replicação, backup, câmbio, migração ou descontos.

• O histórico de inventário é armazenado no armazenamento local do navegador e limitado a 30 coletas. Não é sincronizado entre dispositivos ou navegadores.
• Após corrigir manualmente espaço livre, volume ou dados de arquivo, use Salvar coleta atual no histórico para registrar a versão revisada. Coletas com menos de 24 horas não entram no cálculo de taxa mensal.
• A comparação entre coletas usa variação de espaço utilizado para DATA e variação do tamanho alocado para LOG. São necessárias pelo menos 24 horas entre coletas para aplicar taxas mensais.
• A análise de aceleração exige cinco coletas, correspondentes a quatro intervalos válidos. Ela compara o último período com a referência dos períodos anteriores e aplica critérios heurísticos.
• O histórico de Capacity Planning é separado do histórico de inventários. Salve snapshots manualmente na seção correspondente para comparar fechamentos ao longo do tempo.
• Se o armazenamento local for apagado, bloqueado ou estiver sem espaço, o histórico poderá ser perdido ou não ser atualizado. Exporte os relatórios importantes para arquivamento externo.

Para uma visão consolidada das réplicas, execute a consulta AlwaysOn na instância que hospeda a réplica primária. A DMV sys.dm_hadr_availability_replica_states consultada na secundária retorna somente o escopo local; use a coleta secundária como validação complementar, sem concatenar resultados duplicados.

As filas log_send_queue_size e redo_queue_size são reportadas em KB; as taxas log_send_rate e redo_rate em KB/s. O ETA é uma divisão simples entre fila e taxa observada, assumindo que a taxa se mantenha. É uma aproximação, não um SLA ou previsão garantida.

• Uma réplica em SYNCHRONIZING com HEALTHY pode ser normal em ASYNCHRONOUS_COMMIT.
• Em modo SYNCHRONOUS_COMMIT, o estado SYNCHRONIZING recebe atenção para revisão até a réplica ficar sincronizada.
• Estados ausentes/desconhecidos, réplica desconectada, suspensão, falha operacional e filas elevadas recebem classificação heurística. Ajuste os limiares conforme RPO, RTO e workload.
• A correlação com o inventário é nominal por ambiente, servidor, instância e banco; não prova que a fila AlwaysOn causou o crescimento do storage.

• Não substitui monitoramento contínuo, alertas, análise de workload, capacity review ou validação do DBA.
• Não modela sazonalidade, picos, compressão, shrink, reservas do sistema operacional, snapshots, thin provisioning, RAID, deduplicação, limites de IOPS/throughput ou políticas específicas de storage/cloud.
• Não executa comandos SQL, não altera arquivos, não solicita expansão e não aplica mudanças em AlwaysOn.
• Diagnósticos, scores, alertas e planos de ação são regras determinísticas baseadas nas entradas. São hipóteses para investigação, não análise de causa raiz por IA.
• Resultados dependem da qualidade do CSV, da identificação correta dos volumes e das taxas de crescimento informadas. Valide com telemetria e histórico real antes de comprometer orçamento ou janela de mudança.

• CSV atualizado de todas as instâncias e ambientes relevantes.
• Volumes identificados e espaço livre confirmado; caminhos sem mount point reconciliados manualmente.
• FILESTREAM excluído ou analisado por processo separado.
• Taxas DATA e LOG revisadas e coerentes com o período observado.
• FILEGROWTH e MAXSIZE conferidos com a configuração real dos arquivos.
• Riscos de volume e arquivos bloqueados validados com infraestrutura e responsáveis pelos bancos.
• Premissas, margem de segurança, cenários e preço do storage documentados.
• Relatórios CSV exportados e recomendações aprovadas antes de qualquer alteração.