Discussion :

[mikedavem]

Si vous restaurez avec celle du 26 vous aurez probablement supprimé les erreurs d'allocation mais effectivement comme le dit SQLPro cela ne garantira pas la cohérence de vos données. Vous pouvez toujours revenir à un moment plus proche si vous avez implémenter des sauvegardes du journal de votre base.

Avec la sauvegarde avant réparation ... vous sauvegardez une base corrompue.. vous aurez donc une base corrompue au final ...

Vous allez effectivement être coincé ... vous pouvez tentez de réparer avec l'option REPAIR_ALLOW_ DATA_LOSS vu que vous avez déjà fait une sauvegarde.

Cependant si cela ne fonctionne pas il ne vous restera pas choix possible : restaurer votre sauvegarde du 26/02/2010. Avez vous implémenter également une sauvegarde de vos journaux .. vous pourriez à un moment plus proche avant la corruption de votre base.

Code :

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

1
2
3
4
5
6
7
 
ALTER DATABASE <votreBase> SET EMERGENCY;
GO
ALTER DATABASE <votreBase> SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB('<votreBase>', REPAIR_ALLOW_ DATA_LOSS);
GO

++

[Msysteme]

ALTER DATABASE <votreBase> SET EMERGENCY; pourquoi cela
GO
ALTER DATABASE <votreBase> SET SINGLE_USER WITH ROLLBACK IMMEDIATE;pourquoi cela
GO
DBCC CHECKDB('<votreBase>', REPAIR_ALLOW_ DATA_LOSS);
GO

pour le DBCC je peux le mettre dans un rollback ?

Je fais les sauvegarde manuellement, des sauvegardes completes, je sais pas comment puis je recuperer les données qui ne sont pas corrompu et puis faire une sauvegarde, pour eviter le decalage entre la bd du 26 et aujourdh'hui ?
J'ai pas encore fais de restore !

[mikedavem]

pour le DBCC je peux le mettre dans un rollback ?

Non...

Je fais les sauvegarde manuellement, des sauvegardes completes, je sais pas comment puis je recuperer les données qui ne sont pas corrompu et puis faire une sauvegarde, pour eviter le decalage entre la bd du 26 et aujourdh'hui ?

Vous avez intérêt à implémenter une stratégie de sauvegarde beaucoup plus fine je pense .. surtout si vos données sont sensibles ..

Apparemment 2 tables sont concernés :

--> Pour la table XML : TABLE 'XML' (object ID 1061578820).
Le problème se situe au niveau de l'index (ID 2) : ce qui signifie que cela concerne un index non cluster. Vous pouvez déjà essayer de le supprimer et le recréer.. Vous ne devriez plus avoir d'erreur concernant l'objet XML.

--> Pour la table 'Ess' : TABLE 'Ess' (object ID 933578364).
les pages de niveau feuille de l'index cluster sont concernés par les erreurs donc les données de la table elle-même. Le problème est plus délicat. Soit vous essayez de récupérer un maximum de données de cette table, soit vous tentez une réparation avec l'option REPAIR_ALLOW_ DATA_LOSS pour voir si cela règle votre problème.

Avant de faire ces opérations, je déplacerais mes fichiers de bases sur une partition saine ...

Bon courage

++

[Msysteme]

merci pour votre orientation

Avant de faire ces opérations, je déplacerais mes fichiers de bases sur une partition saine ...

quelle sont ces fichiers ?

On a essayé de voir l'etat du raid 5 avec un utilitaire hp diagontic, il nous remonte aucun probleme au niveau raid ????

est ce vraiment un probleme physique, et comment le disk peut lacher surtout avec le raid 5 qui nous signalait avant en rouge que son etat n'est pas bon ?

ca ne peut pas être un probleme logiciel relatif a sql server ?

[mikedavem]

quelle sont ces fichiers ?

Code :

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

1
2
3
4
5
SELECT 
 logical_name,
 physical_name
FROM sys.master_files
WHERE database_id = DB_ID('<votreBase>');

Vous devez :

- Détacher votre base de données (sp_detach_db)
- Déplacer le fichier de données concerné
- Attacher la base de données (sp_attach_db)
- Procédez enfin aux opérations décrites sur le précédent post

Il n'existe pas de bugs logiciels connus sur la version 2005 SQL Server. Il s'agit en général d'un problème sous jacent à SQL Server dans la plupart des cas. (Disques , contrôleur etc ...).

++

[Msysteme]

en quoi ca m'aider le detachement et atachement ? est ce que je vais recréer la meme bd ?

Une chose qui peut etre utile dans notre cas :

pour nous un flux s'enregistre dans plusieurs tables, on commence par la 1 ere si ok on passe a la deuxieme sinon on le supprime. donc dans la table par exemple 1 , 2 et 3 on doit avoir le meme nombre de lignes sinon il y a une partie du flux qui n'a pas etatit enregistré dans une table. dand mon cas je trouve des problemes dans la table 1 et 3 et pas la table 2 qui est sensé aussi etre corrumpu ???

[mikedavem]

en quoi ca m'aider le detachement et atachement ? est ce que je vais recréer la meme bd ?

Comment voulez vous déplacer vos fichiers de base de données et que SQL Server reconnaisse la nouvelle localisation des fichiers de votre base ?

Je vous invite à regarder la documentation concernant ces 2 commandes.

++

[Msysteme]

J'ai trouuuuuuuuuuuuuuuuuvé, pour les deux tables ou il y a le problemes, j'ai recréer les index et ca resolu le probleme.

Merci pour vos orientations vous etes excelent

Mais cela me pousse a poser la question suivante : est ce bien un probleme physique au niveau du disk ?

[mikedavem]

Mais cela me pousse a poser la question suivante : est ce bien un probleme physique au niveau du disk ?

Parler de problème de disque peut être vague dans votre cas car vous êtes en configuration raid 5 ce qui veut dire que n'importe quel élément de l'architecture peut avoir posé souci : disques, contrôleur disque, driver. Il faudrait en connaître plus pour cela. Surveillez quand même ceci pendant les jours qui viennent ...

++

[Msysteme]

Je me permet de psoter dans le meme portail pour comprendre quelque trucs :

Lorsqu'on parle de reconstitution d'index, qui effectivement résolu le problème, cela veut dire quoi ?

[mikedavem]

Lorsqu'on parle de reconstitution d'index, qui effectivement résolu le problème, cela veut dire quoi ?

Vous aviez 2 index endommagés dans votre cas avec des problèmes de liens entre pages :

Pour faire simple, le fait de recréer vos index permet de recréer les structures d'index et donc de refaire correctement ces liens.

++

[Msysteme]

mais ce que je veux savoir c'est pourquoi ces index ont été endommagés ?

[mikedavem]

mais ce que je veux savoir c'est pourquoi ces index ont été endommagés ?

cf post précédent

Parler de problème de disque peut être vague dans votre cas car vous êtes en configuration raid 5 ce qui veut dire que n'importe quel élément de l'architecture peut avoir posé souci : disques, contrôleur disque, driver. Il faudrait en connaître plus pour cela. Surveillez quand même ceci pendant les jours qui viennent ...

++

[Msysteme]

l'analyse qui me parait logique : au moment de coupure d'electricité(le 03/04), les disque ont été stoppé logicielement a l'aide des onduleur, a ce moment il y avaient des transactions en cours qui n'ont pas terminé. le retour d'electricité "le 4/03 a 9h30", date et heure des pages suspectés, sql server a decouvert qu'il y a des problemes au niveau des index, ce qui a crée le probleme.

[mikedavem]

l'analyse qui me parait logique : au moment de coupure d'electricité(le 03/04), les disque ont été stoppé logicielement a l'aide des onduleur, a ce moment il y avaient des transactions en cours qui n'ont pas terminé. le retour d'electricité "le 4/03 a 9h30", date et heure des pages suspectés, sql server a decouvert qu'il y a des problemes au niveau des index, ce qui a crée le probleme.

Effectivement une coupure de courant peut être à l'origine de ce problème.
Une question me vient cependant à l'esprit : Avez vous activité un cache disque sur votre configuration RAID ?

++

[Msysteme]

oui, prq ?

[SQLpro]

JAMAIS de cache disque en écriture sur un SGBDR, c'est incompatible, car le SGBDR doit pouvoir écrire DIRECTEMENT sur le disque et ne pas être trompé par le cache disque.

Désactivez le !!!!!

A +

[Msysteme]

Comment puis je le désactiver ? si vous avez des docs interessant priere de me les transmettre je suis preneur