Estimar el crecimiento proyectado de la base de datos

Recientemente comencé a trabajar con SQL Server 2008 como aprendiz de DBA. Necesito calcular el tamaño de la base de datos, pero también estimar su crecimiento en los últimos meses y el crecimiento previsto para los próximos 12 meses.

Puedo usar la instrucción sp_spaceused para calcular el tamaño real, pero ¿cómo calculo todo lo demás?

Las otras respuestas son técnicamente correctas, pero no correctas en el mundo real. Esto es lo que necesita preguntar al negocio:

¿A qué horizonte de tiempo estoy apuntando? En su caso, está buscando un número de 12 meses.

Durante ese tiempo, ¿archivaremos datos o conservaremos todos los datos? En algunas empresas, se le permite (o se le exige) mantener solo una cierta cantidad de datos, como los últimos 12 meses. En ese caso, deberá calcular el crecimiento de los datos (que responderán las preguntas posteriores), pero luego volver a los últimos 12 meses consecutivos. No puede simplemente decir: "En este momento, esa cantidad de datos es de 100 GB", porque si su volumen de datos está creciendo, entonces los últimos 12 meses también están creciendo. La cantidad de tiempo puede ser constante, pero los datos no lo son.

¿Agregaremos usuarios adicionales? Por ejemplo, el negocio podría estar creciendo en nuevos territorios o adquiriendo nuevos clientes. Si duplican la base de usuarios, en algunos casos, los datos comenzarán a duplicarse también.

¿Esperamos que el volumen de negocios crezca? Si realiza un seguimiento de las ventas en un sitio web, por ejemplo, y comienza a publicar anuncios de Super Bowl o World Cup, su volumen de datos puede alcanzar la curva de crecimiento del palo de hockey.

¿Agregaremos funcionalidad adicional en la aplicación? Si la aplicación comienza a almacenar imágenes de repente, esto afectará dramáticamente el tamaño de la base de datos.

¿Agregaremos datos de otra fuente o registraremos datos nuevos? Si comienza a capturar clics en el sitio web, o en un almacén de datos, agregando fuentes adicionales, el volumen de datos crecerá.

¿Los desarrolladores o los DBA serán índices de ajuste de rendimiento? Si va a permitir que las personas creen índices, puede duplicar fácilmente (o triplicar o cuadruplicar) el tamaño de sus datos dependiendo de cuán celosos se pongan.

Y mientras haga estas preguntas, también debe preguntar si se espera que el rendimiento permanezca igual, se degrade o mejore. Me gusta mapear el crecimiento proyectado en un gráfico de líneas y luego comparar las inversiones en hardware y capacitación del personal en esa misma línea de tiempo.

No puede proyectar con precisión el crecimiento futuro sin un historial de crecimiento anterior. Sin embargo, puede hacer trampa y obtener una tendencia aproximada utilizando el historial de copias de seguridad, como lo detalla Erin Stellato en Trending Database Growth From Backups .

Trace el resultado de la siguiente consulta en 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]);

Hay muchas maneras de cómo puede planificar la capacidad de la base de datos.

historial de copia de seguridad de msdb si se recorta regularmente, no le quedarán muchos datos para el análisis

Como Mark señaló, se puede hacer usando el método descrito por Erin: tendencia en el crecimiento de la base de datos desde la copia de seguridad.

Incluso puede usar PIVOT para descubrir el crecimiento de la base de datos durante un período de 12 meses a partir del historial de copias de seguridad de la siguiente manera:

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;

Hay otra forma que le resultará realmente útil, como lo describe excelentemente Chad Miller en SSC: Planificación de la capacidad espacial de la base de datos . También se centra en lo days remainingque es muy útil.

Hay otro método que involucra cálculos matemáticos y esto daría resultados precisos. Como ya se indicó, las copias de seguridad serían las mejores para referirse al crecimiento de datos, ya que usted dijo que necesita calcular y predecir el tamaño de la base de datos debajo de los enlaces de Microsoft.

Tamaño estimado de la base de datos

Tamaño estimado del índice agrupado

Tamaño estimado del montón

Tamaño estimado de la mesa

Espero que este código ayude:

Funciona en función del historial del tamaño de la copia de seguridad (en MB), proporciona mes a mes MB mínimos, MB promedio, MB máximo y diferencia con respecto a otros meses en MB.

Lista todas las bases de datos con copias de seguridad, excepto las bases de datos del 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

Creo que la publicación de Brent Ozar es acertada. He estado en un proyecto de DB de hinchazón masiva y tuve exactamente el mismo problema que tú aquí, y no es tan simple.

Dado que es mejor al menos hacer algo, incluso si no es realmente tan preciso, configuraría las tablas requeridas y un trabajo (o cualquier otro método que desee, cualquier cosa para consultar los tamaños y almacenarlo en algún lugar de manera confiable) para realizar un seguimiento las filas y el espacio utilizados para DB y todas sus tablas semanalmente y utilícelo para proyectar la curva de crecimiento más probable. Usar el historial de copias de seguridad también es una gran idea. Pero independientemente del método, necesita tiempo para obtener incluso datos confiables de forma remota.

Aparte de eso, realmente depende de su situación. Puede ser que el porcentaje de uso de su base de datos ahora sea solo una fracción de lo que será en los próximos 6 meses, por ejemplo, cuando su software gane más terreno, lo que hace imposible predecir el crecimiento explosivo que se avecina. Es posible que haya transferencias masivas de datos anuales que duplicarán el tamaño de la base de datos, pero solo se enterará de esa masa después del hecho.

Pero como se dijo, si el crecimiento es una preocupación, entonces absolutamente debe hacer algo para seguirlo. Lo último que desea es encontrarse dentro de 6 meses con una base de datos dos veces más grande que su proyección original de por vida, tener que explicarle a su cliente cómo o por qué sucedió eso, sin mencionar que tiene que comenzar a adivinar cuánto más crecerá. en los próximos 6 meses También hay algunos beneficios muy obvios de saber dónde se han ido los nuevos datos y cuál es el crecimiento relativo de cada tabla en un período de tiempo dado, ya que puede proporcionar información valiosa sobre diferentes tendencias, posibles problemas de software, etc. todo por un esfuerzo relativamente pequeño .