Comment résoudre ce pb svp ?
Hier la sauvegarde manuelle sur bande de ma base de donnée Msql 6.5 (1
base découpée en 2 fois 70Go) sur nt4 serveur refuse de se lancer avec
le message d'erreur:
Error disk read controle de redondance ... des fichiers mdf redondance
cyclique · Sql server sauvegarde erreur d'e/s 23 erreur ...
je pense a un pb hard bande lecteur nettoyage etc... puis je décide de
redémmarrer et la je m'apercois que mon raid 5 a un disque malade.
Je fais le nécéssaire et après la recontruction le message est tjrs le
même.
La deuxième base semble fonctionnée car on écrit et lis normalement,
mais la première refuse la sauvegarde, le plan de maintenance etc.
Je suis vraiment dans la m....de. Surtout que je n'ai pas de compétence
SQL sous la main.
Je suis tenté de faire une restauration mais il y en a pour 2 jours et
j'ai pas assez de place sur le disque dur.
Avez vous un commande SQL pour recontruire ou tester l'intégralitée de
la base SVP ?
Ce que je ferais est la chose suivante : 1) obtenir le script SQL de reconstruction de la base 2) obtenir les ordre SQL INSERT 3) prendre une version SQL 2008 à l'essais 180 jours 4) tenter de restaurer la base sous 2008 5) si cela se passe bien, vérifier la base avec un DBCC CHECK... REPAIR ALLOW DATA LOSS 6) supprimer les index non cluster et les reconstruire 7) si cela ne suffit pas, reconstruire les index cluster et changeant leur destination avec DROP_EXISTING 8) si tout cela s'avère négatif, prendre les script SQL et reconstruire la base par ce biais
A +
---DGI972--- a écrit :
---DGI972--- a émis l'idée suivante :
Il se trouve que Fred BROUARD a formulé :
---DGI972--- a écrit :
Fred BROUARD a utilisé son clavier pour écrire :
---DGI972--- a écrit : [...]
Voila le résultat de dbcc checkdb (au bout de 8 heures):
dbcc checkdb
Serveur: Msg 2535, Niveau 16, État 2, Ligne 0 Table endommagée : La page (1:5805948) est affectée à l'objet ID = 1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 65535 trouvé dans l'en-tête de page. Serveur: Msg 8909, Niveau 16, État 1, Ligne 0 Table endommagée : Objet ID = -1, index ID = 65535, page ID = (1:5805948). ID de page de l'en-tête de page = (65535:-1). CHECKDB a trouvé 0 erreurs d'allocation et 2 erreurs de cohérence dans la table '(Object ID -1)' (objet ID = -1). Résultats DBCC pour 'DNC'. Résultats DBCC pour 'sysobjects'. Il y a 127 lignes dans 3 pages pour l'objet 'sysobjects'. Résultats DBCC pour 'sysindexes'. Il y a 209 lignes dans 9 pages pour l'objet 'sysindexes'.
Je fait quoi maintenant ? J'ai tjrs pas mon disque neuf
1 sauvegarde d'urgence 2 restore de la base 3 reprise du binaire de la page endommagée depuis une sauvegarde plus ancienne à l'aide de DBCC WRITEPAGE. A vous d'auditer toutes les sauvegardes que vous avez conservé pour savoir laquelle est valable et la plus récente et si elle est cohérente avec les données avant et après. Voyez ce que contiennent les pages avant et après celle-ci pour retrouver la table visée
s'il s'agit d'une table (indexid = 0) il n'est pas possible de la reconstruire comme un index.
Sinon, la table/base est perdue.
De toute façon ce genre d'erreur est à 99,99% un problème matériel du disque ou du contrôleur, donc la 1ere chose à faire est sauvegarde et changement de disque.
A +
Merci pour votre réponse. Elle n'est pas très rassurante mais bon ...
1/ Plus possible depuis le 24 décembre a partir de Entreprise manager ( Error disk read controle de redondance ... des fichiers mdf redondance cyclique · Sql server sauvegarde erreur d'e/s 23 erreur ...) mais, j'ai recopié tous les fichiers sur un disque dur externe le weeb-end du 09/01/2010. Par contre dans la sauvegarde du 24 décembre il n'y avait pas de pb de redondance.
2/ J'hésite car: - je n'ai pas assez de place sur le disque pour mettre 2 fois la base ancienne (au cas où) et la nouvelle a partir de la bande. - Elle date du 24 décembre, mais je peux refaire toutes les opérations qui ont été injectées dans la base à la date d'aujourd'hui.
- On l'a déjà fait une fois est c'était hyper hyper long ( plusieurs jours) on avait mis une semaine pour tout remmettre en ordre.
3/ Reprise du binaire ??? Si je restaure une sauvegarde ok il n'y a rien a faire non ? Ou alors je tente de réparer l'existant de la base cassée mais cela mettra du temps et la base n'est plus accéssible en production, et si cela se passe mal ... a moins que je tente ce week end je lance un: DBCC WRITEPAGE ou un DBCC REINDEX ou autre chose ? Vous en pensez quoi ?
Vous dites si index id =0 c'est foutue ?
non, c'est probablement qu'il ne sait pas quelle objet c'est car un ID à -1, c'est bizarre ! Donc en comparant les pages avant et après on peut peut être savoir de quel objet il s'agit puisque SQL Server travaille par extension (bloc de 8 pages)
C'est mon cas là non ? ( ci dessous le résultat dbcc checkdb au bout de 8 heures):
Serveur: Msg 2535, Niveau 16, État 2, Ligne 0 Table endommagée : La page (1:5805948) est affectée à l'objet ID = 1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 65535 trouvé dans l'en-tête de page. Serveur: Msg 8909, Niveau 16, État 1, Ligne 0 Table endommagée : Objet ID = -1, index ID = 65535, page ID = (1:5805948). ID de page de l'en-tête de page = (65535:-1). CHECKDB a trouvé 0 erreurs d'allocation et 2 erreurs de cohérence dans la table '(Object ID -1)' (objet ID = -1). Résultats DBCC pour 'DNC'. Résultats DBCC pour 'sysobjects'. Il y a 127 lignes dans 3 pages pour l'objet 'sysobjects'. Résultats DBCC pour 'sysindexes'. Il y a 209 lignes dans 9 pages pour l'objet 'sysindexes'.
Une donnée importante: Vous avez raison c'était du a un défaut matériel a l'origine et je n'ai pas encore reçu le disque neuf et j'ai encore vu des petites erreurs dans la carte Raid (possibility data lost).
Cordialement et merci pour votre soutien à tous.
De toutes façons, c'est pas bon du tout. La meilleure chose à faire étant de reprendre la sauvegarde stable la plus récente et reconstituer à la main les données manquantes, le reste étant de la haute volée !
A +
J'ai mis mon disque tout neuf hier APM.
On a lancé la reconstruction et j'ai redémmarré l'OS dans la nuit. Le chkdsk se lance au démmarrage, J'ai tapé sur une touche et l'OS NT 4 Serveur a bien démmarré ainsi que la base MSSQL. J'ai redemmarré une deuxiéme fois en laissant se lancer le chkdsk et la plantage aucune progression pas d'activité sur le disque pendant plus de 10 minutes. J'ai redémmarré en appuyant sur une touche pour ne pas lancer le chkdsk et NT a démmarré et MS SQL aussi. J'observe un peu pendant 48 heures les log de la carte RAID pour m'attaquer au Pb de la base. Une idée pour le CHKDSK ? quoi modifier pour eviter qu'il se lance a chaque fois ? Est ce que je peux restaurer un seul fichier mdb parmi les deux que constitue la base ?
Cordialement
Ma sauvegarde refonctionne. Il n'y a plus d'erreur de disque sur le Raid. Mais les procédures stockées (plan de maintenance) ne fonctionne tjrs pas: erreurs redondance. Est ce que je sauvegarde correctement la base ou dois je restaurer pour repartir sur une bonne base et ré archiver ? J'ai mis de coté le jeu de cassette avant l'incident au cas et remis un jeu tout neuf en circulation (24 décembre).
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
Ce que je ferais est la chose suivante :
1) obtenir le script SQL de reconstruction de la base
2) obtenir les ordre SQL INSERT
3) prendre une version SQL 2008 à l'essais 180 jours
4) tenter de restaurer la base sous 2008
5) si cela se passe bien, vérifier la base avec un DBCC CHECK... REPAIR
ALLOW DATA LOSS
6) supprimer les index non cluster et les reconstruire
7) si cela ne suffit pas, reconstruire les index cluster et changeant
leur destination avec DROP_EXISTING
8) si tout cela s'avère négatif, prendre les script SQL et reconstruire
la base par ce biais
A +
---DGI972--- a écrit :
---DGI972--- a émis l'idée suivante :
Il se trouve que Fred BROUARD a formulé :
---DGI972--- a écrit :
Fred BROUARD a utilisé son clavier pour écrire :
---DGI972--- a écrit :
[...]
Voila le résultat de dbcc checkdb (au bout de 8 heures):
dbcc checkdb
Serveur: Msg 2535, Niveau 16, État 2, Ligne 0
Table endommagée : La page (1:5805948) est affectée à l'objet ID =
1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 65535
trouvé dans l'en-tête de page.
Serveur: Msg 8909, Niveau 16, État 1, Ligne 0
Table endommagée : Objet ID = -1, index ID = 65535, page ID =
(1:5805948). ID de page de l'en-tête de page = (65535:-1).
CHECKDB a trouvé 0 erreurs d'allocation et 2 erreurs de cohérence
dans la table '(Object ID -1)' (objet ID = -1).
Résultats DBCC pour 'DNC'.
Résultats DBCC pour 'sysobjects'.
Il y a 127 lignes dans 3 pages pour l'objet 'sysobjects'.
Résultats DBCC pour 'sysindexes'.
Il y a 209 lignes dans 9 pages pour l'objet 'sysindexes'.
Je fait quoi maintenant ?
J'ai tjrs pas mon disque neuf
1 sauvegarde d'urgence
2 restore de la base
3 reprise du binaire de la page endommagée depuis une sauvegarde
plus ancienne à l'aide de DBCC WRITEPAGE. A vous d'auditer toutes
les sauvegardes que vous avez conservé pour savoir laquelle est
valable et la plus récente et si elle est cohérente avec les
données avant et après.
Voyez ce que contiennent les pages avant et après celle-ci pour
retrouver la table visée
s'il s'agit d'une table (indexid = 0) il n'est pas possible de la
reconstruire comme un index.
Sinon, la table/base est perdue.
De toute façon ce genre d'erreur est à 99,99% un problème matériel
du disque ou du contrôleur, donc la 1ere chose à faire est
sauvegarde et changement de disque.
A +
Merci pour votre réponse.
Elle n'est pas très rassurante mais bon ...
1/ Plus possible depuis le 24 décembre a partir de Entreprise
manager ( Error disk read controle de redondance ... des fichiers
mdf redondance cyclique · Sql server sauvegarde erreur d'e/s 23
erreur ...) mais, j'ai recopié tous les fichiers sur un disque dur
externe le weeb-end du 09/01/2010.
Par contre dans la sauvegarde du 24 décembre il n'y avait pas de pb
de redondance.
2/ J'hésite car:
- je n'ai pas assez de place sur le disque pour mettre 2 fois la
base ancienne (au cas où) et la nouvelle a partir de la bande.
- Elle date du 24 décembre, mais je peux refaire toutes les
opérations qui ont été injectées dans la base à la date d'aujourd'hui.
- On l'a déjà fait une fois est c'était hyper hyper long ( plusieurs
jours) on avait mis une semaine pour tout remmettre en ordre.
3/ Reprise du binaire ???
Si je restaure une sauvegarde ok il n'y a rien a faire non ?
Ou alors je tente de réparer l'existant de la base cassée mais cela
mettra du temps et la base n'est plus accéssible en production, et
si cela se passe mal ... a moins que je tente ce week end je lance un:
DBCC WRITEPAGE ou un DBCC REINDEX ou autre chose ?
Vous en pensez quoi ?
Vous dites si index id =0 c'est foutue ?
non, c'est probablement qu'il ne sait pas quelle objet c'est car un
ID à -1, c'est bizarre !
Donc en comparant les pages avant et après on peut peut être savoir
de quel objet il s'agit puisque SQL Server travaille par extension
(bloc de 8 pages)
C'est mon cas là non ?
( ci dessous le résultat dbcc checkdb au bout de 8 heures):
Serveur: Msg 2535, Niveau 16, État 2, Ligne 0
Table endommagée : La page (1:5805948) est affectée à l'objet ID =
1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 65535
trouvé dans l'en-tête de page.
Serveur: Msg 8909, Niveau 16, État 1, Ligne 0
Table endommagée : Objet ID = -1, index ID = 65535, page ID =
(1:5805948). ID de page de l'en-tête de page = (65535:-1).
CHECKDB a trouvé 0 erreurs d'allocation et 2 erreurs de cohérence
dans la table '(Object ID -1)' (objet ID = -1).
Résultats DBCC pour 'DNC'.
Résultats DBCC pour 'sysobjects'.
Il y a 127 lignes dans 3 pages pour l'objet 'sysobjects'.
Résultats DBCC pour 'sysindexes'.
Il y a 209 lignes dans 9 pages pour l'objet 'sysindexes'.
Une donnée importante:
Vous avez raison c'était du a un défaut matériel a l'origine et je
n'ai pas encore reçu le disque neuf et j'ai encore vu des petites
erreurs dans la carte Raid (possibility data lost).
Cordialement et merci pour votre soutien à tous.
De toutes façons, c'est pas bon du tout. La meilleure chose à faire
étant de reprendre la sauvegarde stable la plus récente et
reconstituer à la main les données manquantes, le reste étant de la
haute volée !
A +
J'ai mis mon disque tout neuf hier APM.
On a lancé la reconstruction et j'ai redémmarré l'OS dans la nuit.
Le chkdsk se lance au démmarrage, J'ai tapé sur une touche et l'OS NT
4 Serveur a bien démmarré ainsi que la base MSSQL.
J'ai redemmarré une deuxiéme fois en laissant se lancer le chkdsk et
la plantage aucune progression pas d'activité sur le disque pendant
plus de 10 minutes.
J'ai redémmarré en appuyant sur une touche pour ne pas lancer le
chkdsk et NT a démmarré et MS SQL aussi.
J'observe un peu pendant 48 heures les log de la carte RAID pour
m'attaquer au Pb de la base.
Une idée pour le CHKDSK ? quoi modifier pour eviter qu'il se lance a
chaque fois ?
Est ce que je peux restaurer un seul fichier mdb parmi les deux que
constitue la base ?
Cordialement
Ma sauvegarde refonctionne.
Il n'y a plus d'erreur de disque sur le Raid.
Mais les procédures stockées (plan de maintenance) ne fonctionne tjrs
pas: erreurs redondance.
Est ce que je sauvegarde correctement la base ou dois je restaurer pour
repartir sur une bonne base et ré archiver ?
J'ai mis de coté le jeu de cassette avant l'incident au cas et remis un
jeu tout neuf en circulation (24 décembre).
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ce que je ferais est la chose suivante : 1) obtenir le script SQL de reconstruction de la base 2) obtenir les ordre SQL INSERT 3) prendre une version SQL 2008 à l'essais 180 jours 4) tenter de restaurer la base sous 2008 5) si cela se passe bien, vérifier la base avec un DBCC CHECK... REPAIR ALLOW DATA LOSS 6) supprimer les index non cluster et les reconstruire 7) si cela ne suffit pas, reconstruire les index cluster et changeant leur destination avec DROP_EXISTING 8) si tout cela s'avère négatif, prendre les script SQL et reconstruire la base par ce biais
A +
---DGI972--- a écrit :
---DGI972--- a émis l'idée suivante :
Il se trouve que Fred BROUARD a formulé :
---DGI972--- a écrit :
Fred BROUARD a utilisé son clavier pour écrire :
---DGI972--- a écrit : [...]
Voila le résultat de dbcc checkdb (au bout de 8 heures):
dbcc checkdb
Serveur: Msg 2535, Niveau 16, État 2, Ligne 0 Table endommagée : La page (1:5805948) est affectée à l'objet ID = 1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 65535 trouvé dans l'en-tête de page. Serveur: Msg 8909, Niveau 16, État 1, Ligne 0 Table endommagée : Objet ID = -1, index ID = 65535, page ID = (1:5805948). ID de page de l'en-tête de page = (65535:-1). CHECKDB a trouvé 0 erreurs d'allocation et 2 erreurs de cohérence dans la table '(Object ID -1)' (objet ID = -1). Résultats DBCC pour 'DNC'. Résultats DBCC pour 'sysobjects'. Il y a 127 lignes dans 3 pages pour l'objet 'sysobjects'. Résultats DBCC pour 'sysindexes'. Il y a 209 lignes dans 9 pages pour l'objet 'sysindexes'.
Je fait quoi maintenant ? J'ai tjrs pas mon disque neuf
1 sauvegarde d'urgence 2 restore de la base 3 reprise du binaire de la page endommagée depuis une sauvegarde plus ancienne à l'aide de DBCC WRITEPAGE. A vous d'auditer toutes les sauvegardes que vous avez conservé pour savoir laquelle est valable et la plus récente et si elle est cohérente avec les données avant et après. Voyez ce que contiennent les pages avant et après celle-ci pour retrouver la table visée
s'il s'agit d'une table (indexid = 0) il n'est pas possible de la reconstruire comme un index.
Sinon, la table/base est perdue.
De toute façon ce genre d'erreur est à 99,99% un problème matériel du disque ou du contrôleur, donc la 1ere chose à faire est sauvegarde et changement de disque.
A +
Merci pour votre réponse. Elle n'est pas très rassurante mais bon ...
1/ Plus possible depuis le 24 décembre a partir de Entreprise manager ( Error disk read controle de redondance ... des fichiers mdf redondance cyclique · Sql server sauvegarde erreur d'e/s 23 erreur ...) mais, j'ai recopié tous les fichiers sur un disque dur externe le weeb-end du 09/01/2010. Par contre dans la sauvegarde du 24 décembre il n'y avait pas de pb de redondance.
2/ J'hésite car: - je n'ai pas assez de place sur le disque pour mettre 2 fois la base ancienne (au cas où) et la nouvelle a partir de la bande. - Elle date du 24 décembre, mais je peux refaire toutes les opérations qui ont été injectées dans la base à la date d'aujourd'hui.
- On l'a déjà fait une fois est c'était hyper hyper long ( plusieurs jours) on avait mis une semaine pour tout remmettre en ordre.
3/ Reprise du binaire ??? Si je restaure une sauvegarde ok il n'y a rien a faire non ? Ou alors je tente de réparer l'existant de la base cassée mais cela mettra du temps et la base n'est plus accéssible en production, et si cela se passe mal ... a moins que je tente ce week end je lance un: DBCC WRITEPAGE ou un DBCC REINDEX ou autre chose ? Vous en pensez quoi ?
Vous dites si index id =0 c'est foutue ?
non, c'est probablement qu'il ne sait pas quelle objet c'est car un ID à -1, c'est bizarre ! Donc en comparant les pages avant et après on peut peut être savoir de quel objet il s'agit puisque SQL Server travaille par extension (bloc de 8 pages)
C'est mon cas là non ? ( ci dessous le résultat dbcc checkdb au bout de 8 heures):
Serveur: Msg 2535, Niveau 16, État 2, Ligne 0 Table endommagée : La page (1:5805948) est affectée à l'objet ID = 1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 65535 trouvé dans l'en-tête de page. Serveur: Msg 8909, Niveau 16, État 1, Ligne 0 Table endommagée : Objet ID = -1, index ID = 65535, page ID = (1:5805948). ID de page de l'en-tête de page = (65535:-1). CHECKDB a trouvé 0 erreurs d'allocation et 2 erreurs de cohérence dans la table '(Object ID -1)' (objet ID = -1). Résultats DBCC pour 'DNC'. Résultats DBCC pour 'sysobjects'. Il y a 127 lignes dans 3 pages pour l'objet 'sysobjects'. Résultats DBCC pour 'sysindexes'. Il y a 209 lignes dans 9 pages pour l'objet 'sysindexes'.
Une donnée importante: Vous avez raison c'était du a un défaut matériel a l'origine et je n'ai pas encore reçu le disque neuf et j'ai encore vu des petites erreurs dans la carte Raid (possibility data lost).
Cordialement et merci pour votre soutien à tous.
De toutes façons, c'est pas bon du tout. La meilleure chose à faire étant de reprendre la sauvegarde stable la plus récente et reconstituer à la main les données manquantes, le reste étant de la haute volée !
A +
J'ai mis mon disque tout neuf hier APM.
On a lancé la reconstruction et j'ai redémmarré l'OS dans la nuit. Le chkdsk se lance au démmarrage, J'ai tapé sur une touche et l'OS NT 4 Serveur a bien démmarré ainsi que la base MSSQL. J'ai redemmarré une deuxiéme fois en laissant se lancer le chkdsk et la plantage aucune progression pas d'activité sur le disque pendant plus de 10 minutes. J'ai redémmarré en appuyant sur une touche pour ne pas lancer le chkdsk et NT a démmarré et MS SQL aussi. J'observe un peu pendant 48 heures les log de la carte RAID pour m'attaquer au Pb de la base. Une idée pour le CHKDSK ? quoi modifier pour eviter qu'il se lance a chaque fois ? Est ce que je peux restaurer un seul fichier mdb parmi les deux que constitue la base ?
Cordialement
Ma sauvegarde refonctionne. Il n'y a plus d'erreur de disque sur le Raid. Mais les procédures stockées (plan de maintenance) ne fonctionne tjrs pas: erreurs redondance. Est ce que je sauvegarde correctement la base ou dois je restaurer pour repartir sur une bonne base et ré archiver ? J'ai mis de coté le jeu de cassette avant l'incident au cas et remis un jeu tout neuf en circulation (24 décembre).
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
