Alors que 2014 touche à sa fin, je lance une série d'articles sur les vérifications proactives de l'état de SQL Server, basé sur celui que j'ai écrit au début de cette année - Problèmes de performances :la première rencontre. Dans cet article, j'ai expliqué ce que je recherche en premier lors du dépannage d'un problème de performances dans un environnement inconnu. Dans cette série d'articles, je souhaite parler de ce que je recherche lorsque je consulte mes clients de longue date. Nous fournissons un service DBA à distance, et l'une de nos tâches régulières est un "mini" audit de santé mensuel de leur environnement. Nous avons une surveillance en place et, généralement, je travaille sur des projets, donc je suis régulièrement dans l'environnement. Mais comme étape supplémentaire pour nous assurer que nous ne manquons de rien, une fois par mois, nous parcourons les mêmes données que nous recueillons dans notre audit de santé standard et recherchons tout ce qui sort de l'ordinaire. Cela pourrait être beaucoup de choses, non ? Oui! Alors, commençons par l'espace.
Oh, l'espace ? Oui, l'espace. Ne vous inquiétez pas, je passerai à d'autres sujets. ☺
Ce qu'il faut vérifier
Pourquoi devrais-je commencer par l'espace ? Parce que c'est quelque chose que je vois souvent négligé, et si vous manquez d'espace disque pour vos fichiers de base de données, vous devenez extrêmement limité dans ce que vous pouvez faire dans votre base de données. Vous avez besoin d'ajouter des données mais vous ne pouvez pas agrandir le fichier car le disque est plein ? Désolé, les utilisateurs ne peuvent plus ajouter de données. Ne pas prendre de sauvegardes du journal pour une raison quelconque, de sorte que le journal des transactions remplit le lecteur ? Désolé, vous ne pouvez plus modifier aucune donnée. L'espace est critique. Nous avons des tâches qui surveillent l'espace libre sur le disque et dans les fichiers, mais je vérifie toujours les éléments suivants pour chaque audit et compare les valeurs à celles du mois précédent :
- Taille de chaque fichier journal
- Taille de chaque fichier de données
- Espace libre dans chaque fichier de données
- Espace libre sur chaque lecteur avec les fichiers de base de données
- Espace libre sur chaque lecteur avec les fichiers de sauvegarde
Croissance du fichier journal
La majorité des problèmes que je vois liés à l'espace disque sont dus à la croissance des fichiers journaux. La croissance se produit généralement pour l'une des deux raisons suivantes :
- La base de données est en récupération COMPLÈTE et les sauvegardes du journal des transactions ne sont pas effectuées pour une raison quelconque
- Quelqu'un exécute une seule transaction très volumineuse qui consomme tout l'espace de journal existant, ce qui oblige le fichier à grossir
J'ai également vu le fichier journal grossir dans le cadre de la maintenance de l'index. Pour les reconstructions, chaque allocation est journalisée et pour les index volumineux, cela peut générer une quantité importante de journal. Même avec des sauvegardes régulières du journal des transactions, le journal peut toujours croître plus rapidement que les sauvegardes ne peuvent se produire. Pour gérer le journal, vous devez ajuster la fréquence de sauvegarde ou modifier votre méthodologie de maintenance de l'index.
Vous devez déterminer pourquoi le fichier journal a augmenté, ce qui peut être délicat à moins que vous ne le suiviez. J'ai un travail qui s'exécute toutes les heures pour prendre un instantané de la taille et de l'utilisation du fichier journal :
USE [Baselines];
GO
IF (NOT EXISTS (SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'SQLskills_TrackLogSpace'))
BEGIN
CREATE TABLE [dbo].[SQLskills_TrackLogSpace](
[DatabaseName] [VARCHAR](250) NULL,
[LogSizeMB] [DECIMAL](38, 0) NULL,
[LogSpaceUsed] [DECIMAL](38, 0) NULL,
[LogStatus] [TINYINT] NULL,
[CaptureDate] [DATETIME2](7) NULL
) ON [PRIMARY];
ALTER TABLE [dbo].[SQLskills_TrackLogSpace] ADD DEFAULT (SYSDATETIME()) FOR [CaptureDate];
END
CREATE TABLE #LogSpace_Temp (
DatabaseName VARCHAR(100),
LogSizeMB DECIMAL(10,2),
LogSpaceUsed DECIMAL(10,2),
LogStatus VARCHAR(1)
);
INSERT INTO #LogSpace_Temp EXEC('dbcc sqlperf(logspace)');
INSERT INTO Baselines.dbo.SQLskills_TrackLogSpace
(DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus)
SELECT DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus
FROM #LogSpace_Temp;
DROP TABLE #LogSpace_Temp; J'utilise ces informations pour déterminer quand le fichier journal a commencé à se développer, et je commence à parcourir les journaux et l'historique des tâches pour voir quelles informations supplémentaires je peux trouver. La croissance du journal doit être statique - le journal doit être correctement dimensionné et géré via des sauvegardes (s'il est exécuté en mode de récupération COMPLET), et si le fichier doit être plus volumineux, je dois comprendre pourquoi et le redimensionner en conséquence.
Si vous êtes confronté à ce problème et que vous ne suiviez pas déjà de manière proactive les événements de croissance des fichiers, vous pourrez peut-être encore comprendre ce qui s'est passé. Les événements de croissance automatique sont capturés par SQL Server; Aaron Bertrand de SQL Sentry a écrit à ce sujet en 2007, où il montre comment découvrir quand ces événements se sont produits (tant qu'ils étaient suffisamment récents pour exister encore dans la trace par défaut).
Taille et espace libre dans les fichiers de données
Vous avez probablement déjà entendu dire que vos fichiers de données doivent être pré-dimensionnés afin qu'ils n'aient pas à grandir automatiquement. Si vous suivez ces conseils, vous n'avez probablement pas rencontré l'événement où le fichier de données se développe de manière inattendue. Mais si vous ne gérez pas vos fichiers de données, vous avez probablement une croissance régulière, que vous vous en rendiez compte ou non (en particulier avec les paramètres de croissance par défaut de 10 % et 1 Mo).
Il existe une astuce pour pré-dimensionner les fichiers de données - vous ne voulez pas dimensionner une base de données trop grande, car rappelez-vous, si vous restaurez, par exemple, un environnement de développement ou d'assurance qualité, les fichiers ont la même taille, même s'ils ' re pas plein de données. Mais vous voulez toujours gérer manuellement la croissance. Je trouve que les DBA ont le plus de mal avec les nouvelles bases de données. Les utilisateurs professionnels n'ont aucune idée des taux de croissance et de la quantité de données ajoutées, et cette base de données est un peu un canon lâche dans votre environnement. Vous devez porter une attention particulière à ces fichiers jusqu'à ce que vous maîtrisiez la taille et la croissance attendue. J'utilise une requête qui donne des informations sur la taille et l'espace libre :
SELECT
[file_id] AS [File ID],
[type] AS [File Type],
substring([physical_name],1,1) AS [Drive],
[name] AS [Logical Name],
[physical_name] AS [Physical Name],
CAST([size] as DECIMAL(38,0))/128. AS [File Size MB],
CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128. AS [Space Used MB],
(CAST([size] AS DECIMAL(38,0))/128) - (CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128.) AS [Free Space],
[max_size] AS [Max Size],
[is_percent_growth] AS [Percent Growth Enabled],
[growth] AS [Growth Rate],
SYSDATETIME() AS [Current Date]
FROM sys.database_files; Chaque mois, je vérifie la taille des fichiers de données et l'espace utilisé, puis je décide si la taille doit être augmentée. Je surveille également la trace par défaut des événements de croissance, car cela m'indique exactement quand la croissance se produit. À l'exception des nouvelles bases de données, je peux toujours garder une longueur d'avance sur la croissance automatique des fichiers et la gérer manuellement. Bon, presque toujours. Juste avant les vacances de l'année dernière, j'ai été informé par le service informatique d'un client du manque d'espace libre sur un lecteur (retenez cette pensée pour la section suivante). Désormais, la notification est basée sur un seuil de moins de 20% de gratuité. Ce lecteur faisait plus de 1 To, il y avait donc environ 150 Go libres lorsque j'ai vérifié le lecteur. Ce n'était pas encore une urgence, mais j'avais besoin de comprendre où était passé l'espace.
En vérifiant les fichiers de base de données pour une base de données, j'ai pu voir qu'ils étaient pleins - et le mois précédent, chaque fichier avait plus de 50 Go d'espace libre. J'ai ensuite fouillé dans les tailles de table et j'ai découvert que dans une table, plus de 270 millions de lignes avaient été ajoutées au cours des 16 derniers jours, totalisant plus de 100 Go de données. Il s'avère qu'il y avait eu une modification du code et que le nouveau code enregistrait plus d'informations que prévu. Nous avons rapidement mis en place une tâche pour purger les lignes et récupérer l'espace libre dans les fichiers (et ils ont corrigé le code). Cependant, je ne pouvais pas récupérer d'espace disque - je devais réduire les fichiers, et ce n'était pas une option. J'ai ensuite dû déterminer la quantité d'espace restant sur le disque et décider si c'était une quantité avec laquelle j'étais à l'aise ou non. Mon niveau de confort dépend du fait de savoir combien de données sont ajoutées par mois - le taux de croissance typique. Et je ne connais la quantité de données ajoutées que parce que je surveille l'utilisation des fichiers et que je peux estimer l'espace nécessaire pour ce mois, pour cette année et pour les deux prochaines années.
Espace disque
J'ai mentionné plus tôt que nous avons des travaux pour surveiller l'espace libre sur le disque. Ceci est basé sur un pourcentage et non sur un montant fixe. Ma règle générale a été d'envoyer des notifications lorsque moins de 10 % du disque est libre, mais pour certains lecteurs, vous devrez peut-être le définir plus haut. Par exemple, avec un disque de 1 To, je reçois une notification lorsqu'il reste moins de 100 Go de libre. Avec un disque de 100 Go, je reçois une notification lorsqu'il reste moins de 10 Go de libre. Avec un lecteur de 20 Go… eh bien, vous voyez où je veux en venir. Ce seuil doit vous alerter avant qu'il n'y ait un problème. Si je n'ai que 10 Go d'espace libre sur un lecteur qui héberge un fichier journal, je n'aurai peut-être pas assez de temps pour réagir avant qu'il ne se présente comme un problème pour les utilisateurs - en fonction de la fréquence à laquelle je vérifie l'espace disponible et du problème. est.
Il est très facile d'utiliser xp_fixeddrives pour vérifier l'espace libre, mais je ne le recommanderais pas car il n'est pas documenté et l'utilisation de procédures stockées étendues en général est obsolète. Il ne signale pas non plus la taille totale de chaque lecteur et peut ne pas signaler tous les types de lecteur que vos bases de données peuvent utiliser. Tant que vous exécutez SQL Server 2008R2 SP1 ou supérieur, vous pouvez utiliser sys.dm_os_volume_stats, beaucoup plus pratique, pour obtenir les informations dont vous avez besoin, au moins sur les lecteurs sur lesquels les fichiers de base de données existent :
SELECT DISTINCT vs.volume_mount_point AS [Drive], vs.logical_volume_name AS [Drive Name], vs.total_bytes/1024/1024 AS [Drive Size MB], vs.available_bytes/1024/1024 AS [Drive Free Space MB] FROM sys.master_files AS f CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) AS vs ORDER BY vs.volume_mount_point;
Je vois souvent un problème d'espace disque sur les volumes qui hébergent tempdb. J'ai perdu le compte des fois où j'ai eu des clients avec une croissance tempdb inexpliquée. Parfois, il ne s'agit que de quelques Go; plus récemment, il était de 200 Go. Tempdb est une bête délicate - il n'y a pas de formule à suivre lors du dimensionnement, et trop souvent, il est placé sur un lecteur avec peu d'espace libre qui ne peut pas gérer l'événement fou causé par le développeur débutant ou DBA. Le dimensionnement des fichiers de données tempdb nécessite que vous exécutiez votre charge de travail pendant un cycle commercial "normal" afin de déterminer dans quelle mesure elle utilise tempdb, puis de la dimensionner en conséquence.
J'ai récemment entendu une suggestion pour éviter de manquer d'espace sur un lecteur :créez une base de données sans données et dimensionnez les fichiers de manière à ce qu'ils consomment l'espace que vous souhaitez "réserver". Ensuite, si vous rencontrez un problème, supprimez simplement la base de données et alto, vous disposez à nouveau d'espace libre. Personnellement, je pense que cela crée toutes sortes d'autres problèmes et je ne le recommanderais pas. Mais si vous avez des administrateurs de stockage qui n'aiment pas voir des centaines de Go inutilisés sur un disque, ce serait une façon de donner l'impression qu'un disque est plein. Cela me rappelle quelque chose que j'ai entendu dire par un bon ami :"Si je ne peux pas travailler avec toi, je travaillerai avec toi."
Sauvegardes
L'une des principales tâches d'un DBA est de protéger les données. Les sauvegardes sont une méthode utilisée pour le protéger, et en tant que tels, les lecteurs qui contiennent ces sauvegardes font partie intégrante de la vie d'un DBA. Vous conservez probablement une ou plusieurs sauvegardes en ligne, à restaurer immédiatement si nécessaire. Votre carnet d'exécution SLA et DR vous aide à dicter le nombre de sauvegardes que vous conservez en ligne, et vous devez vous assurer que vous disposez de cet espace. Je préconise que vous ne supprimiez pas non plus les anciennes sauvegardes tant que la sauvegarde actuelle n'est pas terminée avec succès. Il est trop facile de tomber dans le piège de supprimer les anciennes sauvegardes, puis d'exécuter la sauvegarde actuelle. Mais que se passe-t-il si la sauvegarde en cours échoue ? Et que se passe-t-il si vous utilisez la compression ? Attendez une seconde… les sauvegardes compressées sont plus petites, n'est-ce pas ? Ils sont plus petits, finalement. Mais saviez-vous que la taille du fichier .bak commence généralement par être supérieure à la taille finale ? Vous pouvez utiliser l'indicateur de trace 3042 pour modifier ce comportement, mais vous devez penser qu'avec les sauvegardes, vous avez besoin de beaucoup d'espace. Si votre sauvegarde est de 100 Go et que vous conservez 3 jours en ligne, vous avez besoin de 300 Go pour les 3 jours de sauvegarde, puis probablement d'une bonne quantité (taille actuelle de la base de données 2X) gratuite pour la prochaine sauvegarde. Oui, cela signifie qu'à tout moment, vous disposerez de plus de 100 Go d'espace libre sur ce lecteur. C'est bon. C'est mieux que de réussir la tâche de suppression, d'échouer la tâche de sauvegarde et de découvrir trois jours plus tard que vous n'avez aucune sauvegarde (cela est arrivé à un client lors de mon travail précédent).
La plupart des bases de données grossissent avec le temps, ce qui signifie que les sauvegardes deviennent également plus volumineuses. N'oubliez pas de vérifier régulièrement la taille des fichiers de sauvegarde et d'allouer de l'espace supplémentaire si nécessaire - avoir une politique "200 Go gratuits" pour une base de données qui a atteint 350 Go ne sera pas très utile. Si les besoins en espace changent, veillez également à modifier les alertes associées.
Utilisation de l'assistant de performances
Il existe plusieurs requêtes incluses dans cet article que vous pouvez utiliser pour surveiller l'espace, si vous avez besoin de lancer votre propre processus. Mais si vous avez SQL Sentry Performance Advisor dans votre environnement, cela devient beaucoup plus facile avec les conditions personnalisées. Plusieurs conditions de stock sont incluses par défaut, mais vous pouvez également créer les vôtres.
Dans le client SQL Sentry, ouvrez le navigateur, cliquez avec le bouton droit sur Groupes partagés (globaux) et sélectionnez Ajouter une condition personnalisée → SQL Sentry. Fournissez un nom et une description pour la condition, puis ajoutez une comparaison numérique et remplacez le type par Requête de référentiel. Saisissez la requête :
SELECT MIN(FreeSpace*100.0/Size) FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk;
Changez Égal à Est inférieur à et définissez une Valeur explicite de 10. Enfin, changez la Fréquence d'évaluation par défaut en quelque chose de moins fréquent que toutes les 10 secondes. Une fois par jour ou une fois toutes les 12 heures est probablement une bonne valeur - vous ne devriez pas avoir besoin de vérifier l'espace libre plus d'une fois par jour, mais vous pouvez le vérifier aussi souvent que vous le souhaitez. La capture d'écran ci-dessous montre la configuration finale :
Une fois que vous avez cliqué sur Enregistrer pour la condition, il vous sera demandé si vous souhaitez attribuer des actions pour la condition personnalisée. L'option Envoyer aux canaux d'alerte est sélectionnée par défaut, mais vous souhaiterez peut-être effectuer d'autres tâches, telles que Exécuter une tâche - par exemple, copier d'anciennes sauvegardes vers un autre emplacement (s'il s'agit du lecteur avec peu d'espace).
Comme je l'ai mentionné précédemment, une valeur par défaut de 10 % d'espace libre pour tous les lecteurs n'est probablement pas appropriée pour tous les lecteurs de votre environnement. Vous pouvez personnaliser la requête pour différentes instances et lecteurs, par exemple :
SELECT Alert = MAX(CASE WHEN Name = N'C:' AND [FreeSpace%] < 10 THEN 1 WHEN Name = N'S:' AND [FreeSpace%] < 25 THEN 1 WHEN Name = N'T:' AND [FreeSpace%] < 20 THEN 1 ELSE 0 END) FROM ( SELECT d.Name, d.FreeSpace * 100.0/d.Size AS [FreeSpace%] FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk AS d INNER JOIN SQLSentry.dbo.EventSourceConnection AS c ON d.DeviceID = c.DeviceID WHERE c.ObjectName = N'HANK\SQL2012' -- replace with your server/instance ) AS s;
Vous pouvez modifier et développer cette requête selon les besoins de votre environnement, puis modifier la comparaison dans la condition en conséquence (essentiellement en évaluant à true si le résultat est toujours 1) :
Si vous souhaitez voir Performance Advisor en action, n'hésitez pas à télécharger une version d'essai.
Notez que pour ces deux conditions, vous ne serez alerté qu'une seule fois, même si plusieurs lecteurs tombent en dessous de votre seuil. Dans les environnements complexes, vous souhaiterez peut-être vous tourner vers un plus grand nombre de conditions plus spécifiques pour fournir des alertes plus flexibles et personnalisées, plutôt que moins de conditions "fourre-tout".
Résumé
Il existe de nombreux composants critiques dans un environnement SQL Server, et l'espace disque en est un qui doit être surveillé et entretenu de manière proactive. Avec juste un peu de planification, c'est simple à faire, et cela atténue de nombreuses inconnues et une résolution réactive des problèmes. Que vous utilisiez vos propres scripts ou un outil tiers, s'assurer qu'il y a suffisamment d'espace libre pour les fichiers de base de données et les sauvegardes est un problème facile à résoudre et qui en vaut la peine.
