Estimar o crescimento projetado do banco de dados

Recentemente, comecei a trabalhar com o SQL Server 2008 como trainee de DBA. Preciso calcular o tamanho do banco de dados, mas também estimar seu crescimento nos últimos meses e o crescimento previsto para os próximos 12 meses.

Posso usar a instrução sp_spaceused para calcular o tamanho real, mas como faço para calcular todo o resto?

As outras respostas são tecnicamente corretas, mas não no mundo real. Aqui está o que você precisa perguntar à empresa:

Em que horizonte de tempo estou buscando? No seu caso, você está procurando um número de 12 meses.

Durante esse período, arquivaremos ou manteremos todos os dados? Em algumas empresas, você pode (ou precisa) manter apenas uma certa quantidade de dados, como nos últimos 12 meses. Nesse caso, você precisará descobrir o crescimento dos dados (que as perguntas subsequentes responderão), mas depois voltar aos últimos 12 meses consecutivos. Você não pode simplesmente dizer: "No momento, a quantidade de dados é de 100 GB", porque se o volume de dados estiver aumentando, os últimos 12 meses também aumentarão. A quantidade de tempo pode ser constante, mas os dados não são.

Vamos adicionar usuários adicionais? Por exemplo, os negócios podem estar crescendo em novos territórios ou adquirindo novos clientes. Se eles dobrarem a base de usuários, em alguns casos, os dados também começarão a dobrar.

Esperamos que o volume de negócios cresça? Se você estiver acompanhando as vendas em um site, por exemplo, e começar a exibir anúncios do Super Bowl ou da Copa do Mundo, seu volume de dados poderá atingir a curva de crescimento do taco de hóquei.

Adicionaremos funcionalidades adicionais no aplicativo? Se o aplicativo começar a armazenar imagens de repente, isso afetará drasticamente o tamanho do banco de dados.

Adicionaremos dados de outra fonte ou registraremos novos dados? Se você começar a capturar cliques no site ou em um data warehouse, adicionando fontes adicionais, o volume de dados aumentará.

Os desenvolvedores ou DBAs serão índices de ajuste de desempenho? Se você permitir que as pessoas criem índices, poderá dobrar (ou triplicar ou quadruplicar) o tamanho dos seus dados, dependendo de quão zelosos eles ficam.

E enquanto você estiver fazendo essas perguntas, também pergunte se o desempenho deve permanecer o mesmo, degradar ou melhorar. Gosto de mapear o crescimento projetado em um gráfico de linhas e depois comparar os investimentos em treinamento de hardware e equipe durante o mesmo cronograma.

Você não pode projetar com precisão o crescimento futuro sem um histórico de crescimento anterior. No entanto, você pode trapacear e obter uma tendência aproximada usando o histórico de backup, conforme detalhado por Erin Stellato em Trending Growth Database from Backups .

Plote a saída da seguinte consulta no Excel:

SELECT
    [Database] = [database_name]
    , [Month] = DATEPART(month,[backup_start_date])
    , [Backup Size MB] = AVG([backup_size]/1024/1024)
    , [Compressed Backup Size MB] = AVG([compressed_backup_size]/1024/1024)
    , [Compression Ratio] = AVG([backup_size]/[compressed_backup_size])
FROM 
    msdb.dbo.backupset
WHERE 
    [database_name] = N'YourDatabaseName'
AND [type] = 'D'
GROUP BY 
    [database_name]
    , DATEPART(mm, [backup_start_date]);

Existem várias maneiras de como você pode fazer o planejamento da capacidade do banco de dados.

histórico de backup do msdb, se for aparado regularmente, você não terá muitos dados restantes para análise

Como Mark apontou, isso pode ser feito usando o método descrito por Erin - tendências do crescimento do banco de dados a partir do backup.

Você pode até usar o PIVOT para descobrir o crescimento do banco de dados por um período de 12 meses a partir do histórico de backup, como abaixo:

DECLARE @startDate DATETIME;

SET @startDate = GetDate();

SELECT PVT.DatabaseName
    ,PVT.[0]
    ,PVT.[-1]
    ,PVT.[-2]
    ,PVT.[-3]
    ,PVT.[-4]
    ,PVT.[-5]
    ,PVT.[-6]
    ,PVT.[-7]
    ,PVT.[-8]
    ,PVT.[-9]
    ,PVT.[-10]
    ,PVT.[-11]
    ,PVT.[-12]
FROM (
    SELECT BS.database_name AS DatabaseName
        ,DATEDIFF(mm, @startDate, BS.backup_start_date) AS MonthsAgo
        ,CONVERT(NUMERIC(10, 1), AVG(BF.file_size / 1048576.0)) AS AvgSizeMB
    FROM msdb.dbo.backupset AS BS
    INNER JOIN msdb.dbo.backupfile AS BF ON BS.backup_set_id = BF.backup_set_id
    WHERE BS.database_name NOT IN (
            'master'
            ,'msdb'
            ,'model'
            ,'tempdb'
            )
        AND BS.database_name IN (
            SELECT db_name(database_id)
            FROM master.SYS.DATABASES
            WHERE state_desc = 'ONLINE'
            )
        AND BF.[file_type] = 'D'
        AND BS.backup_start_date BETWEEN DATEADD(yy, - 1, @startDate)
            AND @startDate
    GROUP BY BS.database_name
        ,DATEDIFF(mm, @startDate, BS.backup_start_date)
    ) AS BCKSTAT
PIVOT(SUM(BCKSTAT.AvgSizeMB) FOR BCKSTAT.MonthsAgo IN (
            [0]
            ,[-1]
            ,[-2]
            ,[-3]
            ,[-4]
            ,[-5]
            ,[-6]
            ,[-7]
            ,[-8]
            ,[-9]
            ,[-10]
            ,[-11]
            ,[-12]
            )) AS PVT
ORDER BY PVT.DatabaseName;

Há outra maneira que você achará realmente útil, conforme descrito excelentemente por Chad Miller no SSC - Database Space Capacity Planning . Ele também se concentra no days remainingque é muito útil.

Existe outro método que envolve cálculos matemáticos e isso daria resultados precisos. Como os backups já apontados, seria melhor consultar o crescimento de dados, pois você disse que precisava calcular e prever o tamanho do banco de dados abaixo dos links da Microsoft.

Estimar o tamanho do banco de dados

Tamanho estimado do índice agrupado

Estimar o tamanho da pilha

Tamanho estimado da tabela

Espero que este código ajude:

Funciona com base no histórico do tamanho do backup (em MB), fornece mês a mês min MB, média de MB, max MB e diferença de outro mês em MB.

Lista todos os bancos de dados com backups, exceto os bancos de dados do sistema.

-- T-SQL script - Analyses database growth using backup information (Last (12) months in that case
-- Looks only to FULL backups information
-- Parameters: Date GetDate() and nr of months to analyse

SET NOCOUNT ON
DECLARE @endDate datetime, @months smallint; 
SET @endDate = GetDate();  -- Data atual
SET @months = 12;          -- Nr. de meses a analisar

;WITH HIST AS 
   (SELECT BS.database_name AS DatabaseName 
          ,YEAR(BS.backup_start_date) * 100 
           + MONTH(BS.backup_start_date) AS YearMonth 
          ,CONVERT(numeric(10, 1), MIN(BS.backup_size / 1048576.0)) AS MinSizeMB 
          ,CONVERT(numeric(10, 1), MAX(BS.backup_size / 1048576.0)) AS MaxSizeMB 
          ,CONVERT(numeric(10, 1), AVG(BS.backup_size / 1048576.0)) AS AvgSizeMB 
    FROM msdb.dbo.backupset as BS 
    WHERE NOT BS.database_name IN 
              ('master', 'msdb', 'model', 'tempdb') 
          AND BS.type = 'D' 
          AND BS.backup_start_date BETWEEN DATEADD(mm, - @months, @endDate) AND     @endDate 
    GROUP BY BS.database_name 
            ,YEAR(BS.backup_start_date) 
            ,MONTH(BS.backup_start_date)) 
SELECT @@SERVERNAME
      ,MAIN.DatabaseName 
      ,MAIN.YearMonth 
      ,MAIN.MinSizeMB 
      ,MAIN.MaxSizeMB 
      ,MAIN.AvgSizeMB 
      ,MAIN.AvgSizeMB  
       - (SELECT TOP 1 SUB.AvgSizeMB 
          FROM HIST AS SUB 
          WHERE SUB.DatabaseName = MAIN.DatabaseName 
                AND SUB.YearMonth < MAIN.YearMonth 
          ORDER BY SUB.YearMonth DESC) AS GrowthMB 
FROM HIST AS MAIN 
ORDER BY MAIN.DatabaseName 
        ,MAIN.YearMonth

Acho que o post de Brent Ozar está no local. Eu estive em um projeto de banco de dados bastante inchado e tive exatamente o mesmo problema que você faz aqui, e simplesmente não é assim tão simples.

Como é melhor pelo menos fazer algo - mesmo que não seja tão preciso -, eu configuraria as tabelas necessárias e um trabalho (ou qualquer outro método que você quiser, qualquer coisa para apenas consultar os tamanhos e armazená-lo em um local confiável) para rastrear as linhas e o espaço usados ​​para o DB e todas as suas tabelas semanalmente e usam isso para projetar a curva de crescimento mais provável. Usar o histórico de backup também é uma ótima ideia. Mas, independentemente do método, você precisa de tempo para obter dados remotamente confiáveis.

Fora isso, realmente depende da sua situação. Pode ser que a porcentagem de uso do seu DB agora seja apenas uma fração do que será nos próximos 6 meses, por exemplo, quando o seu software ganhar mais terreno, tornando impossível prever o crescimento explosivo que está por vir. Pode ser que haja transferências anuais maciças de dados que dobrarão o tamanho do banco de dados, mas você só descobrirá sobre essa massa após o fato.

Mas, como dito, se o crescimento é uma preocupação, você absolutamente deve fazer algo para acompanhá-lo. A última coisa que você quer é encontrar-se daqui a seis meses com um banco de dados duas vezes maior do que sua projeção de vida original, tendo que explicar ao seu cliente como ou por que isso aconteceu, sem mencionar que precisa começar a adivinhar o quanto ele crescerá nos próximos 6 meses. Também existem alguns benefícios muito óbvios de saber para onde foram os novos dados e qual o crescimento relativo de cada tabela em um determinado período de tempo, pois ele pode fornecer informações valiosas sobre diferentes tendências, possíveis problemas de software etc. tudo por um esforço relativamente pequeno .