J'ai récemment commencé à travailler avec SQL Server 2008 en tant que stagiaire DBA. J'ai besoin de calculer la taille de la base de données mais aussi d'estimer sa croissance au cours des derniers mois et la croissance prévue pour les 12 prochains mois.
Je peux utiliser l'instruction sp_spaceused pour calculer la taille réelle, mais comment puis-je calculer tout le reste?
Réponses:
Les autres réponses sont techniquement correctes, mais pas correctes dans le monde réel. Voici ce que vous devez demander à l'entreprise:
Quel horizon de temps suis-je en train de viser? Dans votre cas, vous recherchez un numéro de 12 mois.
Pendant ce temps, allons-nous archiver les données ou conserver toutes les données? Dans certaines entreprises, vous êtes autorisé (ou obligé de) conserver uniquement une certaine quantité de données, comme les 12 derniers mois. Dans ce cas, vous devrez déterminer la croissance des données (à laquelle les questions suivantes répondront), puis revenir aux 12 derniers mois consécutifs. Vous ne pouvez pas simplement dire: «Actuellement, cette quantité de données est de 100 Go», car si votre volume de données augmente, les 12 derniers mois augmentent également. La durée peut être constante, mais les données ne le sont pas.
Allons-nous ajouter des utilisateurs supplémentaires? Par exemple, l'entreprise pourrait se développer dans de nouveaux territoires ou acquérir de nouveaux clients. S'ils doublent la base d'utilisateurs, dans certains cas, les données commenceront également à doubler.
Nous attendons-nous à ce que le volume d'affaires augmente? Si vous suivez les ventes sur un site Web, par exemple, et que vous commencez à diffuser des annonces pour le Super Bowl ou la Coupe du monde, votre volume de données peut atteindre la courbe de croissance du bâton de hockey.
Allons-nous ajouter des fonctionnalités supplémentaires dans l'application? Si l'application commence soudainement à stocker des images, cela affectera considérablement la taille de la base de données.
Allons-nous ajouter des données provenant d'une autre source ou enregistrer de nouvelles données? Si vous commencez à capturer des clics sur le site Web, ou dans un entrepôt de données, en ajoutant des sources supplémentaires, le volume de données augmentera.
Les développeurs ou les administrateurs de base de données seront-ils des index de réglage des performances? Si vous allez laisser les gens créer des index, vous pouvez facilement doubler (ou tripler ou quadrupler) la taille de vos données en fonction de leur zèle excessif.
Et tant que vous posez ces questions, vous devez également vous demander si les performances devraient rester les mêmes, se dégrader ou s'améliorer. J'aime cartographier la croissance prévue sur un graphique linéaire, puis comparer les investissements en matériel et en formation du personnel sur cette même chronologie.
Vous ne pouvez pas projeter avec précision la croissance future sans un historique de croissance précédente. Vous pouvez cependant tricher et obtenir une tendance approximative en utilisant l'historique des sauvegardes, comme détaillé par Erin Stellato dans Trending Database Growth From Backups .
Tracez la sortie de la requête suivante dans 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]);Il existe de nombreuses façons de planifier la capacité d'une base de données.
l'historique des sauvegardes msdb si le découpage est régulier, vous n'aurez plus beaucoup de données à analyser
Comme Mark l'a souligné, cela peut être fait en utilisant la méthode décrite par Erin - la croissance de la base de données à partir de la sauvegarde.
Vous pouvez même utiliser PIVOT pour connaître la croissance de la base de données sur une période de 12 mois à partir de l'historique de sauvegarde comme ci-dessous:
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;Il y a une autre manière que vous trouverez vraiment utile comme décrit très bien par Chad Miller sur SSC - Database Space Capacity Planning . Il se concentre également sur days remainingce qui est très utile.
Il existe une autre méthode impliquant des calculs mathématiques et cela donnerait des résultats précis. Comme indiqué précédemment, les sauvegardes feraient mieux de se référer à la croissance des données, car vous avez dit que vous devez calculer et prévoir la taille de la base de données sous les liens Microsoft vous aiderait
Estimer la taille de la base de données
J'espère que ce code aide:
Fonctionne sur la base de l'historique de la taille des sauvegardes (en Mo), donne mois par mois min Mo, Mo moyen, max Mo et différence par rapport aux autres mois en Mo.
Répertorie toutes les bases de données avec des sauvegardes, à l'exception des bases de données système.
-- 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.YearMonthJe pense que le post de Brent Ozar est parfait. J'ai été dans un projet DB massivement gonflé et j'ai eu exactement le même problème que vous ici, et ce n'est tout simplement pas aussi simple.
Puisqu'il vaut mieux au moins faire quelque chose - même si ce n'est pas vraiment aussi précis -, je configurerais les tables requises et un travail (ou n'importe quelle autre méthode que vous voulez, n'importe quoi pour simplement interroger les tailles et les stocker quelque part de manière fiable) pour suivre les lignes et l'espace utilisés pour DB et toutes ses tables sur une base hebdomadaire et l'utiliser pour projeter la courbe de croissance la plus probable. L'utilisation de l'historique de sauvegarde est également une excellente idée. Mais quelle que soit la méthode, vous avez besoin de temps pour obtenir des données fiables à distance.
En dehors de cela, cela dépend vraiment de votre situation. Il se peut que l'utilisation% de votre base de données ne soit plus qu'une fraction de ce qu'elle sera dans les 6 prochains mois, par exemple lorsque votre logiciel gagne plus de terrain, ce qui rend impossible de prédire la croissance explosive à venir. Il se peut qu'il y ait des transferts de données massifs annuels qui doubleront la taille de la base de données, mais vous ne découvrirez cette masse qu'après coup.
Mais comme nous l'avons dit, si la croissance est une préoccupation, vous devez absolument faire quelque chose pour la suivre. La dernière chose que vous voulez est de vous retrouver dans 6 mois avec une base de données deux fois plus massive que sa projection de durée de vie d'origine, d'avoir à expliquer à votre client comment ou pourquoi cela s'est produit, sans même mentionner d'avoir à commencer à deviner combien elle va croître dans les 6 prochains mois. Il y a aussi des avantages très évidents à savoir où les nouvelles données sont passées et quelle est la croissance relative de chaque table dans un laps de temps donné, car cela peut fournir des informations précieuses sur les différentes tendances, les problèmes logiciels potentiels, etc., le tout pour un effort relativement faible. .