Оценить прогнозируемый рост базы данных

Недавно я начал работать с SQL Server 2008 в качестве стажера DBA. Мне нужно рассчитать размер базы данных, а также оценить ее рост за последние месяцы и прогнозируемый рост на следующие 12 месяцев.

Я могу использовать оператор sp_spaceused для вычисления фактического размера, но как мне вычислить все остальное?

Другие ответы являются технически правильными, но не реальными. Вот что нужно спросить у бизнеса:

К какому временному горизонту я стремлюсь? В вашем случае вы ищете 12-месячный номер.

В течение этого времени мы будем архивировать данные или хранить все данные? В некоторых компаниях вам разрешено (или необходимо) хранить только определенный объем данных, как за последние 12 месяцев. В этом случае вам необходимо выяснить рост данных (на который будут отвечать последующие вопросы), но затем вернуться к последним 12 месяцам. Вы не можете просто сказать: «Сейчас этот объем данных составляет 100 ГБ», потому что, если объем ваших данных растет, то и последние 12 месяцев тоже растут. Количество времени может быть постоянным, но данные - нет.

Будем ли мы добавлять дополнительных пользователей? Например, бизнес может расти на новых территориях или приобретать новых клиентов. Если они удваивают пользовательскую базу, то в некоторых случаях данные также начинают удваиваться.

Ожидаем ли мы роста бизнеса? Например, если вы отслеживаете продажи на веб-сайте и начинаете показывать рекламу Суперкубка или Кубка мира, объем ваших данных может попасть в кривую роста хоккейной клюшки.

Будем ли мы добавлять дополнительные функции в приложение? Если приложение внезапно начнет хранить изображения, это существенно повлияет на размер базы данных.

Будем ли мы добавлять данные из другого источника или регистрировать новые данные? Если вы начнете регистрировать клики на веб-сайтах или в хранилище данных, добавляя дополнительные источники, объем данных будет расти.

Будут ли разработчики или администраторы баз данных работать с показателями настройки производительности?Если вы собираетесь позволить людям создавать индексы, вы можете легко удвоить (или утроить, или увеличить в четыре раза) размер ваших данных в зависимости от того, насколько они усердны.

И пока вы задаете эти вопросы, вы должны также спрашивать, ожидается ли, что производительность останется такой же, ухудшится или улучшится. Мне нравится отображать прогнозируемый рост на линейном графике, а затем сравнивать инвестиции в оборудование и обучение персонала за тот же график.

Вы не можете точно спроектировать будущий рост без истории предыдущего роста. Тем не менее, вы можете обмануть и получить грубый тренд, используя историю резервного копирования, как подробно описано Эрином Стеллато в статье « Тенденции роста базы данных из резервных копий». .

Составьте график вывода следующего запроса в 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]);

Существует много способов планирования емкости базы данных.

История резервного копирования MSDB, если регулярно обрезается, у вас не останется много данных для анализа

Как отметил Марк, это можно сделать, используя метод, описанный Erin - отслеживание роста базы данных из резервной копии.

Вы даже можете использовать PIVOT для определения роста базы данных в течение 12 месяцев из истории резервного копирования, как показано ниже:

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;

Есть еще один способ, который вы найдете действительно полезным, как превосходно описал Чэд Миллер в SSC - Планирование емкости пространства базы данных . Он также фокусируется на том, days remainingчто очень полезно.

Есть другой метод, включающий математические вычисления, и это даст точные результаты. Как уже указывалось, резервные копии лучше всего ссылаться на рост данных, поскольку вы сказали, что вам нужно рассчитать и предсказать размер базы данных ниже ссылок Microsoft, которые помогут вам

Оценить размер базы данных

Расчетный размер кластерного индекса

Оцените размер кучи

Оценить размер стола

Надеюсь, что этот код помогает:

Работает на основе истории размера резервной копии (в МБ), дает месяц за месяцем мин. МБ, средн. МБ., Макс. МБ и отличие от другого месяца в МБ.

Перечисляет все базы данных с резервными копиями, кроме системных баз данных.

-- 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

Я думаю, что пост Брента Озара на месте. Я был в огромном вздутии базы данных, и у меня была точно такая же проблема, как и у вас, но это не так просто.

Поскольку лучше хотя бы что-то сделать - даже если не совсем точно - я бы настроил необходимые таблицы и задание (или любой другой метод, который вы хотите, что-нибудь, чтобы просто запросить размеры и надежно сохранить его где-нибудь) для отслеживания строки и пространство, используемые для БД и всех ее таблиц на еженедельной основе, и используют это для проецирования наиболее вероятной кривой роста. Использование истории резервного копирования также отличная идея. Но независимо от метода вам нужно время для получения даже удаленно надежных данных.

Кроме этого, это действительно зависит от вашей ситуации. Может быть,% использования вашей БД теперь составляет лишь часть того, что будет в ближайшие 6 месяцев, например, когда ваше программное обеспечение набирает обороты, делая невозможным прогнозирование грядущего взрывного роста. Может случиться, что ежегодные массивные передачи данных удваивают размер БД, но вы узнаете об этой массе только после факта.

Но, как уже говорилось, если рост является проблемой, то вам обязательно нужно что-то предпринять, чтобы отслеживать это. Последнее, что вам нужно, - это найти себя через 6 месяцев с базой данных, вдвое массивной по сравнению с первоначальным прогнозом времени жизни, с необходимостью объяснить вашему клиенту, как и почему это произошло, не говоря уже о том, чтобы начать гадать, насколько больше он будет расти. в ближайшие 6 месяцев. Есть также некоторые очевидные преимущества знания того, куда делись новые данные и каков относительный рост каждой таблицы за определенный промежуток времени, поскольку она может предоставить ценную информацию о различных тенденциях, потенциальных проблемах с программным обеспечением и т. Д. За относительно небольшие усилия. ,