Base corrompue

Version imprimable

2 pièce(s) jointe(s)

Base corrompue

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:

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:

select * from msdb..suspect_pages

puis
Code:

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:

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

15/10/2016, 11h53
Bernardos

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,
15/10/2016, 12h58
elsuket
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 :
1. Réaliser une sauvegarde du fichier du journal des transactions actuel, avec l'option WITH NORECOVERY
2. Restaurer les pages endommagées (RESTORE DATABASE <database> PAGE='F:N1, F:N2, ...' FROM <mon fichier de backup complet> WITH NORECOVERY)
3. Restaurer toute la séquence de sauvegardes du fichier du journal des transactions avec l'option WITH NORECOVERY
4. 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.

@++ ;)
15/10/2016, 14h46
mikedavem

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.

++
15/10/2016, 15h52
NULL008

il était un index non_cluster ,je l'ai supprimer et je l'ai crée de nouveau

un

Code:

checktable

sur la table en question m'a confirmer que tout est dans l'ordre---> aucun erreur

mais si je reviens et j’exécute de nouveau

Code:

select from msdb..suspect_pages

elle ma donne la même résultat malgré que l'index corrompu a été recrée et la table en question il ne contient aucun erreur
Qui a une explication ?
15/10/2016, 16h06
Bernardos

que donne

Code:

chkdsk

sur le disque où se trouve le fichier ?
Cordialement,
15/10/2016, 16h44
mikedavem

Citation:

Envoyé par NULL008

il était un index non_cluster ,je l'ai supprimer et je l'ai crée de nouveau

un

Code:

checktable

sur la table en question m'a confirmer que tout est dans l'ordre---> aucun erreur

mais si je reviens et j’exécute de nouveau

Code:

select from msdb..suspect_pages

elle ma donne la même résultat malgré que l'index corrompu a été recrée et la table en question il ne contient aucun erreur
Qui a une explication ?

Mais quelle est la valeur de la colonne event_type pour la ligne correspondante cette fois ?

++
15/10/2016, 18h28
NULL008

1 pièce(s) jointe(s)

Citation:

Envoyé par mikedavem

Mais quelle est la valeur de la colonne event_type pour la ligne correspondante cette fois ?

++

Pour le colonne event_type il a pris la valeur 2

autre point remarque la date mentionné dans le colonne last_update_stats a été changer
15/10/2016, 19h46
mikedavem

Après réflexion dans ton cas c'est normal.

Tu as détruit et reconstruit ton index non cluster et ceci ne sera pas reporté dans la table suspect_pages.
Tu peux supprimer la ligne correspondante dans la table si tu es certain que ton erreur est résolue

++
16/10/2016, 11h15
cristophe0071983

Non

Sur le site de Microsoft indique que si votre base a été bien réparer tu doit avoir 5 comme value pour le colonne event-type et non 2 comme il est

mentionnée dans votre imprime écran

bonne lecture https://msdn.microsoft.com/en-us/library/ms191301.aspx
16/10/2016, 12h26
mikedavem

Citation:

Envoyé par cristophe0071983

Sur le site de Microsoft indique que si votre base a été bien réparer tu doit avoir 5 comme value pour le colonne event-type et non 2 comme il est
mentionnée dans votre imprime écran

bonne lecture https://msdn.microsoft.com/en-us/library/ms191301.aspx

Sauf que si tu lis bien dans l'article que tu mentionnes

Citation:

◦After a listed page is fixed by a restore or a repair operation, the operation updates the suspect_pages row to indicate that the page is repaired (event_type = 5) or restored (event_type = 4).

Hors dans le cas de NULL008, cette page ne sera jamais réparée par une opération DBCC CHECKDB. En effet, la structure d'index non cluster a été entièrement reconstruite, ce qui veut implique une nouvelle structure avec nouvelles pages de données allouées. Par conséquent, il n'y aura jamais de mise à jour dans msdb pour cette page via une opération DBCC CHECKDB dans ce cas précis.

++
16/10/2016, 13h02
NULL008

merci bien c'est vraiment génial

C'est a cause de vous SQLPRO,mikedavem,elsuket que j'ai arrivé finalement a voir ce jolie message

CHECKDB a trouvé 0 erreurs d'allocation et 0 erreurs de cohérence dans la base de donnée...

une autre remerciement pour le livre SQL Server 2014 (Frédéric Brouard, Christian Soutou, Nicolas Souquet et David Barbarin)
https://www.amazon.fr/SQL-Server-201...ql+server+2014