Version imprimable
Bonjour,
Je souhaiterais savoir s’il est possible de restaurer une page corrompue à partir d’un backup complet.
Le point bloquant est que ce backup date d’environ un an.
Si je procède à la restauration de cette page depuis ce full backup, puis que j’applique ensuite le log backup d’aujourd’hui, est-ce que l’opération pourra fonctionner ?
Pouvez-vous me confirmer la faisabilité de cette restauration et m’indiquer les impacts éventuels ?
Merci d’avance pour votre retour.
Hello,
- Disposez-vous de l'intégralité absolue et ininterrompue de toutes les sauvegardes du journal des transactions (Transaction Log Backups) effectuées depuis la date du backup complet (il y a un an) jusqu'à aujourd'hui ?
- La base de données est-elle restée en mode de récupération FULL (ou BULK_LOGGED) de manière continue durant toute l'année écoulée ?
- Quelle est l'édition de votre instance SQL Server (Enterprise, Standard, Developer) ?
- Avez-vous identifié l'ID précis du fichier et de la page (ex: 1:15432) via une commande DBCC CHECKDB ou via la table msdb.dbo.suspect_pages ?
Lisez ceci :
https://blog.developpez.com/sqlpro/p...ver-corrompues
Notamment dans le PDF, § "3.2.2 – Réparation par restauration de page"
MAIS ATTENTION : SQL Server ne connais pas de bug capable de corrompre les données... Cela signifie que le corruption est externe. Il faut donc commencer par changer de support de stockage, c'est à dire soit :
- déplacer les fichiers de la base par détachement et rattachement (voir avec un REBUILD du journal de transactions)
- soit restaurer la base complète sur un autre support en ayant pris soi de faire une sauvegarde de la fin du journal en mode d'urgence
A +
Pour être sûr que vous puissiez restaurer avec la sauvegarde complète et le journal de transaction, il doit y avoir recoupement des LSN entre la sauvegarde FULL et la sauvegarde transactionnelle.
Cela signifie que votre base ne doit jamais avoir été mise dans un autre mode de récupération que FULL et qu'il n'y ait pas eu de sauvegarde transactionnelle par vidage (BACKUP LOG ... TO DISK = 'NUL') ce que pratique VEEAM par défaut (une belle merde !)
http://mssqlserver.fr/veeam-backup-e...e-piege-a-con/
Je doute qu'en un an de non sauvegarde cette opération soit possible...
A +
Je suis d'accord, il faut présumer une panne matérielle avant tout.Citation:
SQL Server ne connais pas de bug capable de corrompre les données...
Mais c'est une affirmation dogmatique et techniquement fausse. Bien que 99% des corruptions proviennent effectivement du sous-système I/O (disques, contrôleurs, drivers), des bugs logiciels dans SQL Server provoquant des corruptions ont existé et existent (ex: problèmes de latching sur certaines versions, bugs sur les index columnstore, etc.).
Cette suggestion est dangereuse. Si votre base est corrompue (état SUSPECT), la détacher peut empêcher définitivement son rattachement si l'en-tête ou des pages critiques sont touchés. Le REBUILD LOG ne répare pas une page de données corrompue, il reconstruit le journal (ce qui brise la chaîne de log, rendant votre restauration de page impossible par la suite).Citation:
déplacer les fichiers de la base par détachement et rattachement (voir avec un REBUILD du journal de transactions)
Personnellement j’essaierai d'abord de restaurer sur un autre serveur !Citation:
Envoyé par samirCA007
Une base de données qui n'a pas de backup full depuis aussi longtemps ne doit pas avoir un RTO stressant ...
J'espère pour vous qu'il y a eu des backup DIFF intermédiaires ...
Note :
1. il est TRES important de tester l'opérationnalité de ses sauvegardes ! et ce régulièrement
2. L'instruction DBCC CHECKDB permet de tester l'intégrité physique, mais pas forcément de réparer ; se référer au point n°1
Bugs oui, mais pas corruption. Un bug est un résultat logiquement faux, mais pas physiquement corrompu.Citation:
Envoyé par fred1599
À ce jour il n'existe plus depuis la version 2008 de SQL Server de corruptions liées à l'exécution de SQL Server... !
Continuer d'écrire sur une surface abimée ne peut qu'entrainer encore plus de défaillances...Citation:
Envoyé par fred1599
A +
Une croyance persistante au sein de la communauté des administrateurs de bases de données suggère que la corruption "physique" est exclusivement le résultat de défaillances du sous-système d'entrées/sorties (E/S) qu'il s'agisse de disques défectueux, de contrôleurs RAID instables ou de problèmes de firmware tandis que les bugs du moteur SQL Server ne produiraient que des erreurs "logiques", telles que des résultats de requêtes incorrectes.
Dans une interprétation restrictive, la corruption physique est souvent synonyme de détérioration du média. Cela se produit lorsque la représentation magnétique ou électronique des bits sur le support de stockage est altérée par une force externe (rayonnement cosmique, pic de tension, usure des SSD). Dans ce scénario, le moteur SQL Server a généré une page valide avec une somme de contrôle (checksum) correcte, mais le sous-système E/S restitue une version altérée. Le mécanisme de détection principal est la vérification de la somme de contrôle de la page (PAGE_VERIFY = CHECKSUM), qui échoue lors de la lecture, déclenchant typiquement une erreur 823 ou 824.
Cependant, il existe une seconde catégorie de corruption physique : la corruption structurelle d'origine logicielle. Un fichier de base de données SQL Server (.mdf) est constitué de pages de 8 Ko organisées en structures complexes (B-Trees, Heaps, chaînes IAM). Si le contenu de ces pages viole les règles strictes du format de stockage même si le disque stocke et restitue parfaitement les bits qui lui ont été envoyés la base de données est physiquement corrompue.
Ce phénomène survient lorsqu'un bug dans le moteur (par exemple, une condition de concurrence lors d'une scission de page) conduit à la construction d'une page malformée en mémoire. Le gestionnaire de tampons (Buffer Manager), agissant selon sa programmation, calcule alors une somme de contrôle valide pour cette page intrinsèquement corrompue et l'écrit sur le disque. Le sous-système de stockation, fonctionnant correctement, préserve cette corruption. Au sens strict, il s'agit d'une corruption physique du format de fichier, induite par une défaillance logique du moteur.
https://www.sqlservercentral.com/art...d-dbcc-checkdb
Le correctif KB2969896 concerne un bug critique affectant SQL Server 2012 et 2014. Il illustre parfaitement comment une logique défaillante entraîne des dommages physiques aux structures de données.
L'article KB indique explicitement que cela peut causer une "corruption d'index ou une perte de données". Concrètement, les structures B-Tree résultantes contenaient des incohérences de liaison, rendant l'index physiquement invalide. Il ne s'agit pas ici d'une erreur de calcul, mais bien d'une écriture défectueuse de la structure physique du fichier .mdf par le moteur.
https://sqlhands.com/2014/06/16/sql-...-indexing-bug/
L'existence de ce bug réfute catégoriquement l'idée que les corruptions moteur ont disparu après 2008, puisque SQL Server 2012 et 2014 sont directement concernés.
KB3176518 et l'Architecture Columnstore (SQL Server 2016)
Les symptômes décrits incluent des erreurs d'assertion et des échecs de DBCC CHECKTABLE signalant des objets non référencés ou des nœuds de données hors ligne orphelins ("The off-row data node... is not referenced"). Ces erreurs indiquent que la structure interne de l'index Columnstore est brisée. Le moteur a persisté sur le disque des blobs de données illisibles ou déconnectés de leur métadonnée, ce qui constitue une corruption physique par définition.
https://support.microsoft.com/en-us/...b-2172e153127e
Le correctif KB3188950, connexe à cette période, confirme qu'une simple mise à jour (UPDATE) pendant une compression pouvait corrompre l'index non-cluster, prouvant encore une fois l'origine logicielle du dégât physique.
https://support.microsoft.com/en-us/...1-b4b9d16c74c1
et j'en passe...
L'idée que SQL Server 2008 marque la fin des corruptions logicielles est factuellement fausse. Au contraire, chaque version majeure (2012, 2014, 2016, 2017, 2019) a apporté son lot de correctifs adressant spécifiquement des corruptions de données. La complexité croissante du moteur augmente statistiquement la surface d'exposition aux bugs de concurrence et de gestion mémoire.
Historiquement, de nombreux administrateurs évitaient les mises à jour cumulatives (Cumulative Updates - CU) au profit des Service Packs (SP), jugés plus stables. Cependant, Microsoft a changé son modèle de service, et depuis SQL Server 2017, les Service Packs n'existent plus. Les correctifs de corruption cités dans ma réponse sont souvent délivrés via des CUs.
Pour se prémunir contre la corruption physique d'origine logicielle, l'application régulière des CUs est impérative. Attendre un "Service Pack" (sur les anciennes versions) ou différer les mises à jour expose les bases de données à des bugs connus capables de détruire silencieusement des données.
https://learn.microsoft.com/en-us/tr...els-sql-server
https://sqlserverupdates.com/sql-server-2022-updates/
Les preuves accumulées à travers les articles KB3176518, KB4096054 et KB2969896 démontrent sans équivoque que le moteur SQL Server, en tant que logiciel complexe, est sujet à des défauts de logique (race conditions, memory leaks, pointeurs invalides) capables de générer une corruption physique structurelle des fichiers de base de données. Bien que la corruption matérielle reste la cause la plus fréquente statistiquement, ignorer la possibilité d'une cause logicielle expose les administrateurs à des diagnostics erronés et à des risques de perte de données, particulièrement lors de l'utilisation de fonctionnalités avancées telles que les index Columnstore ou les opérations en ligne parallélisées. La distinction correcte ne doit pas être "Matériel = Physique" vs "Logiciel = Logique", mais plutôt "Défaillance du Média" vs "Corruption Structurelle", cette dernière pouvant être causée indifféremment par le matériel ou le logiciel.
Lors de l’exécution de DBCC CHECKTABLE, des erreurs ont été détectées indiquant une corruption. et vu que ce n'est possible de le lancer en prod Nous envisageons une solution consistant à transférer les données vers une table d’archive ayant la même structure.
J’aimerais avoir vos retours d’expérience : est-il possible d’isoler uniquement les pages corrompues afin de transférer le reste des données intègres vers cette table d’archive ?
Désolé, dans ma carrière je n'ai eu qu'une seule fois un pb avec des corruptions SQLCitation:
Envoyé par samirCA007
C'était il y presque 10 ans, suite à un live motion Vmware ; et comme il prenait du temps l'admin à tenté de le rollback et le relancer dans la foulée ...
On a résolu avec les sauvegardes et les procédures de reprises
Pour répondre à votre question, je commencerais pas identifier quel objet est dépendant de la page corrompue.
Voir ici : https://www.sqlskills.com/blogs/paul...-name-page-id/
Mais pas sûr qu'ils soit possible de faire une lecture sur la table sans aller tenter de poser un verrou sur la page endommagée ...
En tous les cas, je suis intéressé par le retour d'expérience
Il faut tout d'abord identifier les pages corrompues,
Avant tout transfert, vous devez localiser précisément les zones affectées sans réparer directement
(pour éviter la perte de données avec REPAIR_ALLOW_DATA_LOSS).
Étape 1 : Vérification avec DBCC
Exécutez :
(ou DBCC CHECKDB sur la base entière si possible).Code:
2
Cela liste les erreurs avec les IDs de pages corrompues (par exemple :
"Page (1:12345) is corrupted").
Étape 2 : Analyse des logs
Analysez les logs SQL Server (via xp_readerrorlog ou SSMS) pour repérer les erreurs I/O liées à des pages spécifiques.
Étape 3 : Cas des indexes non clusterisés
Si la corruption est sur des indexes non clusterisés (ID > 1 dans l’output de DBCC),
vous pouvez les désactiver et les reconstruire sans toucher aux données :
Code:
2
3
Cela peut rendre la table accessible sans perte.
Étape 4 : Environnement de test
Si DBCC ne peut pas s’exécuter en production sans downtime, exécutez-le sur une copie restaurée d’un backup.
Oups, désolé ne ne pas avoir lu correctement la demande.Citation:
Envoyé par samirCA007
Passer par les sauvegardes, me semble le plus sûr
Une solution dangereuse pour "transférer" toute la base, et quelque soit sont état :
1. libérer le verrou de lecture sur les fichiers de la base : détacher la base ou arrêter l'instance
2. copier les fichiers
3. rouvrir la base ... et croiser les doigts qu'à l'ouverture toute la base ne soit pas considérée comme suspecte sur le serveur initial
Une autre solution consiste à exporter
1. les instructions DDL (Create)
2. les données ... en continuant malgré les erreurs ; ce qui peut être lu sera sécurisé
3. pour ce qui ne peut pas être lu par un SELECT, essayez de passer par DBCC PAGE (https://techcommunity.microsoft.com/...cc-page/383094)
Avez vous pensé à ouvrir un ticket M$ ?
Et je reste intéressé par le REx