Exploitation SQL Server

DBCC CHECKDB et stratégie pratique d'intégrité

Des défaillances de stockage, mémoire, firmware ou logiciel peuvent endommager des pages sans arrêter immédiatement l'application. Les sauvegardes peuvent conserver une corruption inconnue.

DBCC CHECKDB et stratégie pratique d'intégrité

Des défaillances de stockage, mémoire, firmware ou logiciel peuvent endommager des pages sans arrêter immédiatement l'application. Les sauvegardes peuvent conserver une corruption inconnue.

Ce qu'il faut mesurer

Suivez le dernier contrôle réussi, taille, durée, erreurs par objet et allocation, suspect pages, alertes E/S et existence d'une sauvegarde saine antérieure.

Approche pratique

Planifiez CHECKDB selon risque et taille, contrôlez des restaurations si la fenêtre de production manque, alertez sur les exécutions absentes, préservez les preuves et préférez restaurer plutôt que réparer.

Ce qu'il faut éviter

Ne lancez pas repair en premier, ne supposez pas que la redondance empêche la corruption et n'abandonnez pas les grandes bases à cause de la durée.

Résultat opérationnel

L'intégrité relie détection, conservation des preuves, récupération et correction prudente.

Checklist de production

Établissez une référence et définissez l'amélioration attendue. Testez avec des données et une concurrence représentatives. Conservez la configuration ou le plan d'origine, préparez un retour arrière et surveillez le prochain pic normal de charge.

Pour appliquer cette méthode à un environnement SQL Server précis, utilisez le formulaire ci-dessous et indiquez la version, la taille de la base, le profil de charge et les éléments déjà collectés.

Question sur cet article

Vous avez une question sur ce sujet ?

Expliquez ce que vous évaluez ou le point qui vous bloque. Nous vous répondrons avec une recommandation pratique.

Inquiries are not enabled in this preview.

Poser une question sur cet article