Je travaille sur l'implémentation de la méthode de Paul Randal pour répartir manuellement DBCC CHECKDB sur plusieurs jours pour les très grandes bases de données, qui consiste essentiellement en:
- Diviser les tables de la base de données à peu près également entre 7 compartiments
- Exécution d'un DBCC CHECKALLOC deux fois par semaine
- Exécution d'un DBCC CHECKCATALOG une fois par semaine
- Exécution d'une table de contrôle DBCC sur un compartiment chaque jour de la semaine
Quelqu'un a-t-il utilisé cette technique? Des scripts existants?
Je crains que cela ne couvre pas tout ce que fait CHECKDB; la documentation Books Online pour CHECKDB indique qu'en plus de CHECKALLOC, CHECKCATALOG et CHECKTABLE, il:
- Valide le contenu de chaque vue indexée de la base de données.
- Valide la cohérence au niveau des liens entre les métadonnées de table et les répertoires et fichiers du système de fichiers lors du stockage de données varbinaires (max) dans le système de fichiers à l'aide de FILESTREAM. (SQL 2008 uniquement)
- Valide les données Service Broker dans la base de données.
Donc, voici mes questions:
Ces vérifications supplémentaires sont-elles nécessaires / importantes? (Les vues indexées me concernent probablement un peu plus, je ne pense pas que nous utilisons Service Broker ou FILESTREAM pour le moment.)
Si oui, existe-t-il des moyens d'effectuer ces vérifications supplémentaires séparément?
CHECKALLOC et CHECKCATALOG semblent fonctionner très rapidement, même sur de grandes bases de données. Une raison de ne pas les exécuter tous les jours?
(Remarque: ce sera une routine standard pour des milliers de bases de données existantes sur des centaines de serveurs, ou au moins toutes les bases de données d'une certaine taille. Cela signifie que des options telles que la restructuration de toutes les bases de données pour utiliser CHECKFILEGROUP ne sont pas vraiment pratiques pour nous.)
la source
Réponses:
Vous pouvez exécuter
DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKSdirectement sur les vues indexées . La vérification des vues indexées peut être problématique dans certaines circonstances , alors soyez prêt à enquêter sur les faux positifs qui en résultent. (Paul Randal mentionne également dans les commentaires de l'article référencé que les faux négatifs sont également possibles, mais je n'en ai aucune expérience directe.)Il n'y a aucune prise en charge pour exécuter le Service Broker ou les
FILESTREAMcontrôles séparément, non.Pas que je sache.
Vous pourriez également envisager de courir
DBCC CHECKCONSTRAINTS. Cette vérification n'est pas incluse dansDBCC CHECKDB, quelles que soient les options que vous pouvez spécifier. Vous voudrez peut-être aussi penser à courir de temps en tempsCHECKDB, au fur et à mesure des circonstances.la source
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.
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:
DBCC CHECKTABLEavec l'exécutionDBCC CHECKALLOCetDBCC CHECKCATALOGDBCC CHECKTABLE,DBCC CHECKALLOCetDBCC CHECKCATALOG. Afin que vous puissiez avoir une idée du temps qu'il faut en général pour exécuter vos chèques.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:
la source