Base corrompue

**NULL008** · 15/10/2016, 01h17

bonjour

Un mauvais jour pour moi dans tous les sens du terme le 15/10/2016 ,l'histoire a commencé a 16:12 ou j'ai reçu des alertes provenant du mon serveur en indiquant la présence d'une erreur Fatale 024 Matrielle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
 
SQL Server a détecté une erreur d'E/S logique et relative à la cohérence. L'erreur somme de contrôle incorrecte (somme de contrôle attendue : 0x96edf769 ; somme de contrôle réelle : 0x719bebd0) s'est produite pendant une opération de lire de la page (1:48918620) dans la base de données avec l'ID 9 au niveau du décalage 0x00005d4e0b8000 dans le fichier 'D:\SQL2005\data\suivi.mdf'. Vous trouverez peut-être plus de détails dans les messages supplémentaires qui figurent dans le journal des erreurs et le journal des évènements système de SQL Server. Il s'agit d'une condition d'erreur sévère qui met en péril l'intégrité de la base de données et qui doit être corrigée immédiatement. Effectuez une vérification complète de la cohérence de la base de données (DBCC CHECKDB). Cette erreur peut être due à de nombreux facteurs ; pour plus d'informations, reportez-vous à la documentation en ligne de SQL Server.

Directement j'ai procéder a lire l'article de sqlpro et suivre le démarche http://blog.developpez.com/sqlpro/fi...corrompues.pdf
j'ai lancer la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from  msdb..suspect_pages

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
DBCC TRACEON (3604)
 
dbcc page (suivi,1,48918620,1) WITH TABLERESULTS

en suivant le même démarche mis dans l'article de sqlpro l'object corrompu doit porter id 375776496 et que l'index c'est celle 6 comme c'est monter dans l'imprime écran

maintenant j'ai lançer cette requête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
SELECT s.name AS TABLE_SCHEMA, o.name AS TABLE_NAME,
 o.type_desc AS TABLE_TYPE, i.name AS INDEX_NAME,
 CASE WHEN i.index_id <= 1 THEN 'TABLE'
 WHEN i.type_desc = 'NONCLUSTERED' THEN 'INDEX'
ELSE i.type_desc END as INDEX_TYPE
FROM sys.objects AS o
 INNER JOIN sys.schemas AS s
 ON o.schema_id = s.schema_id
 INNER JOIN sys.indexes AS i
 ON o.object_id = i.object_id
WHERE o.object_id =375776496
AND i.index_id = 6;

heureusement j'ai eu comme résultat un index non_cluster

maintenant je veux s'avoir si mon démarche est juste et que je suis dans le bon chemin si oui est ce que la suppression de cette indexe et leur creation est suffisant pour étre sure que ma base a été réparer ,ou je doit faire d'autre opération
merci pour le partage de vos expérience

**Bernardos** · 15/10/2016, 11h53

Bonjour,
Argh c'est dur ca, un vendredi à 16h

AS tu un backup récent de ta base (backup full, backup diff, backup journal de transaction)? jusque quand peux tu remonter avec ton/tes backup?
as tu identifié la cause de ton problème? (disque, controleur, autre)?
Comme écrit dans l'article de Frédéric Brouard, la cause est plus que probablement matérielle et plus que probablement un disque défaillant. s'il s'agit du/des disques la première chose à faire est de bouger tes fichiers avant d'avoir d'autres corruptions.
Après, tu détruis et reconstruit l'index que tu as identifié.
Par contre, je pense que si tu as un backup suffisament récent, tu changes le disque défecteux, et tu fais un restore ou tu fais un restore sur un autre disque.
Cordialement,

**elsuket** · 15/10/2016, 12h58

Bonjour,

Étant donné que vous savez quelles pages sont endommagées, si vous êtes en mode de récupération complet, vous pouvez restaurer les page en question.
Pour cela, vous pouvez :

Réaliser une sauvegarde du fichier du journal des transactions actuel, avec l'option WITH NORECOVERY
Restaurer les pages endommagées (RESTORE DATABASE <database> PAGE='F:N1, F:N2, ...' FROM <mon fichier de backup complet> WITH NORECOVERY)
Restaurer toute la séquence de sauvegardes du fichier du journal des transactions avec l'option WITH NORECOVERY
Restaurer la dernière sauvegarde du fichier du journal des transactions avec l'option WITH RECOVERY

Dans le 2e point, F représente le numéro de fichier, et N le numéro de page.

@++

**mikedavem** · 15/10/2016, 14h46

Je pense que pour un index non cluster la solution la plus rapide est de le reconstruire.

Après reconstruction (si tout s'est bien passé), je te conseille de te diriger vers les entrées dans le journal des événements Windows à la recherche d'éventuelles de stockage. Une petite commande chkdsk à la recherche de clusters défaillants n'est pas de trop non plus. Après en fonction de ton stockage il faudra probablement aviser (DAS, SAN ...). Avec un SAN par exemple, la probabilité d'avoir une corruption directement depuis les disques reste très faible de nos jours. En général le problème se situe plus au niveau d'un driver ou d'un contrôleur défaillant.

++