Bonjour, je m'appelle Kirk. Je suis ingénieur principal senior et je travaille avec l'équipe GSE. Cette vidéo est consacrée à l’analyse de l’outil de base de données TSQL DE Microsoft SQL, DBCC CHECKDB. Nous verrons pourquoi et quand exécuter DBCC CHECKDB, ainsi que les options de commande qui déterminent le niveau de vérification de la base de données et le runtime impliqué.
Mais avant de commencer la démo, j'aimerais aborder quelques points. DBCC CHECKDB est un outil TSQL qui examine l’intégrité logique et physique de tous les objets d’une base de données SQL Server donnée. Nous disposons également d’options de réparation, comme l’option TABLOCK, qui implique l’utilisation ou la non-utilisation d’un snapshot de la base de données. Nous allons examiner l’option « ESTIMATEONLY », la raison pour laquelle nous voudrions l’utiliser, et c’est en relation avec l’utilisation de « TEMPDB » au cours d’un processus CHECKDB.
Nous allons également examiner « PHYSICAL_ONLY », pourquoi nous voudrions utiliser cette option et quand. Nous allons également voir comment nous pouvons contrôler le nombre de processeurs impliqués dans le processus CHECKDB avec quelque chose appelé « MAXDOP ». À ce stade, nous allons examiner quelques exemples de ce que nous verrions lorsque nous exécutons DBCC CHECKDB. Ainsi, la première commande elle-même vérifie littéralement tout ce qu’il est possible pour DBCC CHECKDB d’examiner dans une base de données donnée.
Voici donc les résultats. La ligne de retour qui nous intéresse le plus lors de l’exécution de ce paramètre est le nombre d'« erreurs d’allocation » et d'« erreurs de cohérence » trouvées dans la base de données. Donc, j’ai une base de données « AdventureWorks2019 » saine, donc tout revient sans erreur. Comme cette base de données n'est pas très volumineuse, le processus s'exécute vraiment rapidement. Si nous avons une base de données beaucoup plus volumineuse, par exemple 100 fois plus grande que celle-ci, son exécution prendra beaucoup plus de temps.
Et, beaucoup de gens se demandent à quelle fréquence nous devrions essayer d’exécuter DBCC CHECKDB, et généralement les maîtres SQL vous diront que vous voulez essayer de l’exécuter dès que possible. S’il y a des incohérences ou des dommages logiciels dans la base de données, vous devez les découvrir le plus rapidement possible et y remédier. L’option suivante que nous allons examiner est celle dite « AVEC PHYSICAL_ONLY ».
Il s’agit de la même commande, sauf que, dans ce cas, elle ne vérifie littéralement que l’entité physique ou la structure de la base de données elle-même. Elle s’exécute généralement beaucoup plus rapidement qu’une vérification complète. C’est pourquoi nous préférons l’exécuter dans des environnements de production limités en termes de temps de maintenance. Nous avons également une autre option appelée « WITH TABLOCK », donc une chose que nous devons comprendre à propos de DBCC CHECKDB, l’une des premières choses qu’il fait est qu’il crée un fichier de snapshot qui est contenu dans la base de données « TEMPDB », et il y a des moments où nous ne pouvons pas utiliser « TEMPDB » pour quelque chose comme ça avec un processus CHECKDB.
Quelle que soit la désignation de « WITH TABLOCK », nous indiquons à DBCC CHECKDB de ne pas créer de fichier de snapshot, de sorte qu’il n’occupera pas cet espace dans « TEMPDB » et qu’il s’exécutera généralement plus rapidement à cause de cela. Une autre option que nous pouvons exécuter est « WITH ESTIMATEONLY ». Cette commande particulière nous indiquera la quantité d’espace que nous devrions avoir utilisée dans notre base de données « TEMPDB » lors de l’exécution de CHECKDB.
Voici un exemple du résultat, il revient en kilo-octets, soit environ 230 mégaoctets. Passons maintenant à l'option « WITH MAXDOP ». Désormais, quel que soit le DBCC CHECKDB exécuté, il essaie d’utiliser autant de processeurs qu’il en a besoin pour fonctionner en parallèle. Il souhaite exécuter plusieurs threads afin d’essayer de s’exécuter aussi rapidement que possible. Il peut donc y avoir des limites quant au nombre de processeurs que nous voulons autoriser à exécuter dans ce processus. Nous pouvons donc limiter cela avec l’instruction « WITH MAXDOP ».
Dans ce cas, je dis à SQL de n’utiliser qu’un seul processeur pour notre exécution CHECKDB. Et lorsque nous faisons cela, cela représente moins de processeurs dédiés à cela, mais l’exécution de votre DBCC CHECKDB prend généralement plus de temps. À présent, voyons les options de réparation. Il existe donc différentes options de réparation. La plus radicale est celle que l'on appelle « REPAIR_ALLOW_DATA_LOSS ». Vous risquez de perdre des données chaque fois que nous utilisons cette option pour essayer de réparer une base de données qui revient avec des erreurs. Nous pouvons aussi utiliser l'option « REPAIR_REBUILD ».
REPAIR_REBUILD est considéré comme une option de réparation douce. Ce que nous voulons dire par là, c’est qu’il garantit que nous n’allons pas perdre les données disponibles dans la base de données lorsque nous exécutons cette option. Cette commande est donc présentée, nous utiliserons le contexte de la base de données « Master ». Chaque fois que nous faisons quelque chose comme ça, nous devons mettre la base de données en mode « SINGLE_USER » afin de permettre une opération de réparation. C'est ce que nous allons faire ici.
Maintenant, nous avons ici l’option « ESTIMATEONLY », et encore une fois, « ESTIMATEONLY » va nous indiquer combien d’espace nous allons abandonner dans « TEMPDB » pour faire cela. Notre fichier d’instantané occupera environ 230 mégaoctets, d’après notre retour ici. Et après avoir fait une réparation avec cela, nous voudrions le remettre en mode « MULTI_USER ». Maintenant, avec « ESTIMATEONLY », nous n’avons pas réellement exécuté la réparation, nous avons seulement fait l’estimation. Voyons comment exécuter la commande avec le « REPAIR_REBUILD ».
Encore une fois, allons-y et « Execute » cela, nous allons le remettre dans « MULTI_USER ». Encore une fois, dans le contexte de la base de données « Master », nous allons la mettre en mode « SINGLE_USER ». Là, l'opération de réparation va se lancer. Il s'agit d'une opération de réparation logicielle. Ce que vous allez voir, c’est en grande partie ce que nous verrions dans une vérification de base de données normale, et bien sûr, encore une fois, nous voulons vérifier les erreurs signalées. Dans ce cas de figure, il n'y en a pas.
La base de données est saine. La dernière partie de cette opération consiste à le remettre en mode « MULTI_USER ». La commande de réparation « REPAIR_ALLOW_DATA_LOSS » est identique à la commande « REPAIR_REBUILD », sauf que nous utilisons le « REPAIR_ALLOW_DATA_LOSS ». Habituellement, nous exécutons cette commande lorsque nous avons tenté d’exécuter le « REPAIR_REBUILD » et que le « REPAIR_REBUILD » revient et nous indique qu’il n’a pas pu terminer la réparation de la base de données.
Donc, c’est notre dernier recours sans une bonne sauvegarde, et oui, nous devrions utiliser une bonne sauvegarde avant d’être obligés de faire un « REPAIR_ALLOW_DATA_LOSS ». Si aucune sauvegarde n’existe, il s’agit de notre seule option pour remettre la base de données en ligne et disponible. Voilà qui conclut notre démo sur DBCC CHECKDB, le moment d’utiliser CHECKDB et certaines des options de commande les plus courantes disponibles. J’espère que cette vidéo vous a aidé à comprendre l’intérêt d’utiliser DBCC CHECKDB lorsque vous tentez de maintenir une installation de base de données SQL Server cohérente et stable.
Merci de votre attention.
