Discussion :

[NULL008]

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]

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]

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.

@++

[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.

++

[NULL008]

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

un

Code :

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

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 :

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

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 ?

[Bernardos]

que donne

Code :

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

chkdsk

sur le disque où se trouve le fichier ?
Cordialement,

[mikedavem]

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

un

Code :

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

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 :

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

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 ?

++

[NULL008]

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

[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

++

[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

[mikedavem]

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

◦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.

++

[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