Нещодавно я почав працювати з SQL Server 2008 як стажист DBA. Мені потрібно обчислити розмір бази даних, але також оцінити її зростання за останні місяці та передбачуване зростання на наступні 12 місяців.
Я можу використовувати оператор sp_spaceused для обчислення фактичного розміру, але як я обчислюю все інше?
Відповіді:
Інші відповіді технічно правильні, але не реальні. Ось що потрібно запитати у компанії:
На який часовий горизонт я прагну? У вашому випадку ви шукаєте номер 12 місяців.
За цей час ми будемо архівувати дані чи зберігати всі дані? У деяких компаніях вам дозволяється (або вимагається) зберігати лише певний обсяг даних, як-от за останні 12 місяців. У такому випадку вам потрібно буде з’ясувати зростання даних (на які відповідатимуть наступні запитання), але потім повернутися до останнього періоду 12 місяців. Ви не можете просто сказати: "Зараз ця кількість даних становить 100 Гб", тому що якщо обсяг ваших даних зростає, то останні 12 місяців теж зростає. Кількість часу може бути постійною, але дані - ні.
Чи будемо додавати додаткових користувачів? Наприклад, бізнес може перерости в нові території або придбати нових клієнтів. Якщо вони подвоюють базу користувачів, то в деяких випадках дані також почнуть подвоюватися.
Чи очікуємо, чи зростатиме обсяг бізнесу? Наприклад, якщо ви відстежуєте продажі на веб-сайті, і ви починаєте показувати реклами Super Bowl або World Cup, ваш обсяг даних може вплинути на криву зростання хокейної палички.
Чи додамо ми додаткові функції в додаток? Якщо програма раптом почне зберігати зображення, це різко вплине на розмір бази даних.
Чи будемо ми додавати дані з іншого джерела чи реєструвати нові дані? Якщо ви почнете фіксувати кліки веб-сайтів або на сховищі даних, додаючи додаткові джерела, тоді обсяг даних зростатиме.
Чи будуть розробники або DBA підходити до індексів настройки продуктивності? Якщо ви збираєтеся дозволити людям створювати індекси, ви можете легко подвоїти (або потрійно, або вчетверо) розмір ваших даних залежно від того, наскільки вони надмірно ставляться.
І поки ви задаєте ці питання, вам слід також запитати, чи очікується, що ефективність роботи залишиться такою ж, знизиться чи покращиться. Мені подобається відображати прогнозований ріст на лінійній діаграмі, а потім порівнювати інвестиції в обладнання та навчання персоналу за цією ж шкалою.
Не можна точно спроектувати майбутнє зростання без історії попереднього зростання. Однак ви можете обдурити і отримати грубу тенденцію, використовуючи історію створення резервних копій, про що детально розповідає Ерін Стеллато в Trending Growth Database From Backup .
Накресліть висновок наступного запиту в 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, якщо вона регулярно піддається обробці, у вас не залишиться багато даних для аналізу
Як зазначав Марк, це можна зробити за допомогою методу, описаного Еріном - тенденція зростання бази даних із резервного копіювання.
Ви навіть можете використовувати 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 місяців. Є також дуже очевидні переваги того, щоб знати, куди пішли нові дані, і який відносний ріст кожної таблиці за певний проміжок часу, оскільки вона може надати цінну інформацію про різні тенденції, потенційні проблеми програмного забезпечення тощо. Все для порівняно невеликих зусиль .