Parmi les tâches journalières d'un DBA, il y a la surveillance journalière de la taille des DB.
La capture et le stockage de cette information permettant par ailleurs d'anticiper les futurs besoins et problèmes de stockage.
Cas pratique
Pour les développeurs impliqués dans des processus de migration de données, la surveillance de la taille des DBs (espace libre par fichier physique) peut également s'avérer utile. Il servira, par exemple, à placer judicieusement des opérations SHRINKFILE pour éviter l'engorgement du/des disque(s) en cours de test migration.
En exemple pratique, la migration d'une table de 50 millions de records vers de nouvelles structures peut générer d'assez grosses variations en besoin de stockage. Même avec un recovery model=simple pour limiter le gonflement du transaction log, un delta de plusieurs gigas (15Go dans mon cas) entre deux filegroups est tout à fait possible.
La stored procedure sp_SDS
La stored procedure sp_SDS de Richard Ding est, encore une fois, une des nombreuses perles qu'internet dissimule si facilement.
Compatible Sql Serveur 2000, 2005 et 2008, sp_SDS (Sql Database Space) permet de connaitre exactement l'espace physique occupé par une DB (ou toutes les DB d'un serveur).
Outre la consommation physique, sp_SDS indique également le ratio d'occupation de la DB (son taux de remplissage). Cette dernière information peut s'avérer extrêmement pertinente durant un processus de migration de données.
Cerise sur le gâteau, sp_SDS peut fournir ses statistiques par fichier composant la (ou les) DB(s).
Pour plus d'information:
- voir l'article "Check SQL Server database and log file size with this stored procedure" de Richard Ding sur SearchSqlServer.com
- Source de la stored procedure sp_SDS au format doc, ou sa copie miroir en sql.
Aucun commentaire:
Enregistrer un commentaire