DBCC CHECKDB est vital pour les bases de données SQL Server pour être sûr à 100% qu'il n'y a pas de corruption. Cependant, en raison de la taille massive des bases de données, il est très difficile de trouver une fenêtre de maintenance lorsque vous prétendez être disponible 24h / 24 et 7j / 7. Au fil des ans, l'équipe de SQL Server a mis en œuvre divers mécanismes qui détecteront les formes de corruption les plus courantes, notamment liées à la corruption physique causée par le matériel.
SQL Server 2005 et versions ultérieures ont PAGE_VERIFY = CHECKSUM qui peut vous aider à détecter de manière proactive la corruption physique dans les pages de la base de données, ajoutant ainsi une somme de contrôle à chaque page lors de son écriture sur le système d'E / S et valide la somme de contrôle lors de sa lecture sur le disque.
De plus, une sauvegarde (complète ou différentielle) avec CHECKSUM garantira de détecter toute corruption d'E / S causée par le matériel.
Par conséquent, du côté matériel de la corruption, SQL Server fait un bon travail pour le détecter et le signaler. (Assurez-vous également de définir des alertes importantes concernant la corruption ).
Cela étant dit, corruption toujours logique , erreurs induites par le scribbler - où les pages en mémoire sont corrompues soit par du code tiers s'exécutant à l'intérieur du processus SQL Server, soit par des pilotes ou d'autres logiciels disposant de privilèges suffisants s'exécutant en mode noyau Windows et / ou SQL Server Les bogues , etc. sont indétectables en utilisant les méthodes ci-dessus et donc CHECKDB apparaît dans l'image.
DBCC CHECKDB effectue des vérifications plus approfondies qui incluent la vérification des en-têtes de page pour une éventuelle corruption non détectable par aucun autre moyen.
Des scripts existants?
Au lieu de réinventer la roue, je vous recommande fortement de jeter un œil à la solution Ola SQL Server Integrity Check
Exécution efficace de DBCC CHECKDB:
Vous avez juste besoin d'être créatif lorsque vous êtes serré dans la fenêtre de maintenance avec d'énormes bases de données ou un grand nombre de bases de données sur lesquelles exécuter CHECKDB.
Après avoir suivi la formation SQLSkills, ce que j'ai implémenté dans mon environnement est:
- donner la priorité aux tables qu'il est essentiel de vérifier.
- séparez les tables en groupes avec des priorités différentes, puis exécutez
DBCC CHECKTABLEavec l'exécution DBCC CHECKALLOCetDBCC CHECKCATALOG
- Créez une table de travail qui stockera les noms de table avec des priorités. Assurez-vous simplement que toutes les tables à haute priorité (qui sont massivement grandes) ne sont pas dans un groupe, sinon votre CHECKDB ne se terminera pas du tout.
- Vous pouvez même avoir une colonne de délai d'attente dans votre table de travail qui orchestrera quand votre CHECKDB sera tué une fois qu'il aura passé la fenêtre de maintenance
- Ajoutez le temps nécessaire à l'exécution de chaque table
DBCC CHECKTABLE, DBCC CHECKALLOCet DBCC CHECKCATALOG. Afin que vous puissiez avoir une idée du temps qu'il faut en général pour exécuter vos chèques.
- Vous pouvez même exécuter l'
NOINDEXoption, car elle accélérera l'opération car elle ne vérifie pas les index non clusterisés sur les tables utilisateur. Cela a un certain avantage car il n'est pas aussi critique que la corruption de données car aucune donnée n'est perdue et vous pouvez supprimer et recréer l'index si nécessaire.
De toute évidence, l'édition Enterprise peut tirer parti de l'exécution parallèle des instructions DBCC, mais faites attention au paramètre MAXDOP car il pourrait finir par prendre tout votre processeur. Cela peut être fortement limité par le gouverneur de ressources.
Remarque: Si vous avez une colonne SPARSE, votre CHECKDB sera lent comme décrit ici .
Enfin, comment prévenir la corruption de la base de données en utilisant tous les outils disponibles + votre confiance dans le système matériel de votre serveur de base de données et, surtout, la valeur de vos données.
Quelques excellentes références: