Il se trouve que ---DGI972--- a formulé :---DGI972--- a exposé le 07/01/2010 :---DGI972--- a formulé ce mercredi :Gloops a couché sur son écran :---DGI972--- a écrit, le 05/01/2010 23:01 :Dans son message précédent, Gloops a écrit :---DGI972--- a écrit, le 05/01/2010 12:29 :Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a quelques
mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers, qui
effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et qu'on
n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé' est
le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un désordre
mécanique ou électrique du disque, auquel cas il faut commencer par
réparer la panne, mais bien entendu, ça ne suffit pas à remettre les
tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système, maintenant
attends un peu, si quelqu'un a une idée pour éviter d'en arriver là,
avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il n'est
pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go ultra160
a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
Il se trouve que ---DGI972--- a formulé :
---DGI972--- a exposé le 07/01/2010 :
---DGI972--- a formulé ce mercredi :
Gloops a couché sur son écran :
---DGI972--- a écrit, le 05/01/2010 23:01 :
Dans son message précédent, Gloops a écrit :
---DGI972--- a écrit, le 05/01/2010 12:29 :
Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a quelques
mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers, qui
effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et qu'on
n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé' est
le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un désordre
mécanique ou électrique du disque, auquel cas il faut commencer par
réparer la panne, mais bien entendu, ça ne suffit pas à remettre les
tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système, maintenant
attends un peu, si quelqu'un a une idée pour éviter d'en arriver là,
avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il n'est
pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go ultra160
a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
Il se trouve que ---DGI972--- a formulé :---DGI972--- a exposé le 07/01/2010 :---DGI972--- a formulé ce mercredi :Gloops a couché sur son écran :---DGI972--- a écrit, le 05/01/2010 23:01 :Dans son message précédent, Gloops a écrit :---DGI972--- a écrit, le 05/01/2010 12:29 :Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a quelques
mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers, qui
effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et qu'on
n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé' est
le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un désordre
mécanique ou électrique du disque, auquel cas il faut commencer par
réparer la panne, mais bien entendu, ça ne suffit pas à remettre les
tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système, maintenant
attends un peu, si quelqu'un a une idée pour éviter d'en arriver là,
avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il n'est
pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go ultra160
a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
---DGI972--- a formulé la demande :Il se trouve que ---DGI972--- a formulé :---DGI972--- a exposé le 07/01/2010 :---DGI972--- a formulé ce mercredi :Gloops a couché sur son écran :---DGI972--- a écrit, le 05/01/2010 23:01 :Dans son message précédent, Gloops a écrit :---DGI972--- a écrit, le 05/01/2010 12:29 :Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a
quelques mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers,
qui effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et
qu'on n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé'
est le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un
désordre mécanique ou électrique du disque, auquel cas il faut
commencer par réparer la panne, mais bien entendu, ça ne suffit pas à
remettre les tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système,
maintenant attends un peu, si quelqu'un a une idée pour éviter d'en
arriver là, avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il n'est
pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go
ultra160 a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a
l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
J'ai recopié tous les fichiers (en arrêtant Sql) ce week end sur un disque
dur usb externe (en réseau sur un w2k0).
43 heures de copie pour 2 X 71 G de base de donnée.
J'attends tjrs le disque neuf ...
---DGI972--- a formulé la demande :
Il se trouve que ---DGI972--- a formulé :
---DGI972--- a exposé le 07/01/2010 :
---DGI972--- a formulé ce mercredi :
Gloops a couché sur son écran :
---DGI972--- a écrit, le 05/01/2010 23:01 :
Dans son message précédent, Gloops a écrit :
---DGI972--- a écrit, le 05/01/2010 12:29 :
Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a
quelques mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers,
qui effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et
qu'on n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé'
est le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un
désordre mécanique ou électrique du disque, auquel cas il faut
commencer par réparer la panne, mais bien entendu, ça ne suffit pas à
remettre les tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système,
maintenant attends un peu, si quelqu'un a une idée pour éviter d'en
arriver là, avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il n'est
pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go
ultra160 a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a
l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
J'ai recopié tous les fichiers (en arrêtant Sql) ce week end sur un disque
dur usb externe (en réseau sur un w2k0).
43 heures de copie pour 2 X 71 G de base de donnée.
J'attends tjrs le disque neuf ...
---DGI972--- a formulé la demande :Il se trouve que ---DGI972--- a formulé :---DGI972--- a exposé le 07/01/2010 :---DGI972--- a formulé ce mercredi :Gloops a couché sur son écran :---DGI972--- a écrit, le 05/01/2010 23:01 :Dans son message précédent, Gloops a écrit :---DGI972--- a écrit, le 05/01/2010 12:29 :Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a
quelques mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers,
qui effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et
qu'on n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé'
est le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un
désordre mécanique ou électrique du disque, auquel cas il faut
commencer par réparer la panne, mais bien entendu, ça ne suffit pas à
remettre les tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système,
maintenant attends un peu, si quelqu'un a une idée pour éviter d'en
arriver là, avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il n'est
pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go
ultra160 a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a
l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
J'ai recopié tous les fichiers (en arrêtant Sql) ce week end sur un disque
dur usb externe (en réseau sur un w2k0).
43 heures de copie pour 2 X 71 G de base de donnée.
J'attends tjrs le disque neuf ...
---DGI972--- a émis l'idée suivante :---DGI972--- a formulé la demande :Il se trouve que ---DGI972--- a formulé :---DGI972--- a exposé le 07/01/2010 :---DGI972--- a formulé ce mercredi :Gloops a couché sur son écran :---DGI972--- a écrit, le 05/01/2010 23:01 :Dans son message précédent, Gloops a écrit :---DGI972--- a écrit, le 05/01/2010 12:29 :Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a
quelques mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers,
qui effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et
qu'on n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé'
est le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un
désordre mécanique ou électrique du disque, auquel cas il faut
commencer par réparer la panne, mais bien entendu, ça ne suffit pas à
remettre les tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système,
maintenant attends un peu, si quelqu'un a une idée pour éviter d'en
arriver là, avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il
n'est pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go
ultra160 a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a
l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
J'ai recopié tous les fichiers (en arrêtant Sql) ce week end sur un disque
dur usb externe (en réseau sur un w2k0).
43 heures de copie pour 2 X 71 G de base de donnée.
J'attends tjrs le disque neuf ...
Tjrs pas de disque neuf ...
J'ai lancé un DBCC CHECKDB et au bout de 4 heures tjrs pas fini.
J'attends le résultat demain (Du moins j'espère) ....
---DGI972--- a émis l'idée suivante :
---DGI972--- a formulé la demande :
Il se trouve que ---DGI972--- a formulé :
---DGI972--- a exposé le 07/01/2010 :
---DGI972--- a formulé ce mercredi :
Gloops a couché sur son écran :
---DGI972--- a écrit, le 05/01/2010 23:01 :
Dans son message précédent, Gloops a écrit :
---DGI972--- a écrit, le 05/01/2010 12:29 :
Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a
quelques mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers,
qui effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et
qu'on n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé'
est le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un
désordre mécanique ou électrique du disque, auquel cas il faut
commencer par réparer la panne, mais bien entendu, ça ne suffit pas à
remettre les tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système,
maintenant attends un peu, si quelqu'un a une idée pour éviter d'en
arriver là, avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il
n'est pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go
ultra160 a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a
l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
J'ai recopié tous les fichiers (en arrêtant Sql) ce week end sur un disque
dur usb externe (en réseau sur un w2k0).
43 heures de copie pour 2 X 71 G de base de donnée.
J'attends tjrs le disque neuf ...
Tjrs pas de disque neuf ...
J'ai lancé un DBCC CHECKDB et au bout de 4 heures tjrs pas fini.
J'attends le résultat demain (Du moins j'espère) ....
---DGI972--- a émis l'idée suivante :---DGI972--- a formulé la demande :Il se trouve que ---DGI972--- a formulé :---DGI972--- a exposé le 07/01/2010 :---DGI972--- a formulé ce mercredi :Gloops a couché sur son écran :---DGI972--- a écrit, le 05/01/2010 23:01 :Dans son message précédent, Gloops a écrit :---DGI972--- a écrit, le 05/01/2010 12:29 :Bonjour,
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 ?
Cordialement et meilleurs voeux à tous.
Bonjour,
L'erreur de redondance cyclique, ça ne relève pas d'une compétence
SQL, mais d'une compétence système (c'est Windows ?)
On a abordé cette question dans le newsgroup windowsxp il y a
quelques mois. Google dit des trucs, là-dessus, aussi.
Il s'agit d'une incohérence entre les tables d'index des fichiers,
qui effectivement empêche d'effectuer une sauvegarde, et en fait
d'utiliser normalement le disque.
ça peut provenir d'un mauvais état matériel du disque (cause la plus
fréquente à ce que j'ai compris, auquel cas il n'y a pas à tortiller
il faut le remplacer, il y a intérêt à avoir le CD pour installer le
système) mais il peut arriver qu'un chkdsk arrange les choses et
qu'on n'entende plus parler du problème ensuite.
Bonjour,
Effectivement le raid avait un pb mais maintenant il est 'rebuildé'
est le pb est tjrs le même.
Ah oui je ne suis pas plus étonné que cela.
Il s'agit d'une incohérence des tables, elle peut être due à un
désordre mécanique ou électrique du disque, auquel cas il faut
commencer par réparer la panne, mais bien entendu, ça ne suffit pas à
remettre les tables en ordre.
C'est pour ça que j'ai suggéré une réinstallation du système,
maintenant attends un peu, si quelqu'un a une idée pour éviter d'en
arriver là, avec un peu de chance ...
Si tu as fait récemment une sauvegarde de l'image du disque (avant la
panne), ça peut être le moyen le plus simple de sortir de ce mauvais
pas.
Bonsoir,
Comme l'utilitaire de la carte raid me donnait encore des messages
d'erreurs data lost etc..., j'ai décidé de faire appel a un tech bull.
On a remit un disque tout neuf car l'idée c'est lorsque je l'ai déplugé
et replugé il a remit ses compteurs smart d'erreurs a zéro mais il
n'est pas bon.
il est court de rebuilid (2h pour 30%) pour un disque SCSI 36 Go
ultra160 a 10k tours/minutes.
Donc affaire a suivre ... je pars tôt demain matin pour voir les dégats
...
Promis je vous tiens au courant.
Au fait la version est MSQL 7.0 SP2.
Merci.
CATA ...
Le disque n'était pas exactement le même en capacité.
L'OS ne démmarre plus il reste bloqué sur un chkdsk puis freeze a
l'écran.
J'ai remis l'ancien disque c'est reparti pour 4 heure de rebuild.
J'y retourne ce matin tôt ...
Le rebuild s'est bien déroulé et Ouf l'OS a redémarré.
J'ai eu très chaud sur ce coup là ...
Je n'ai plus d'erreur pour l'instant (mais j'attends 24h).
Je lancerais un sauvegarde demain matin.
Le disque neuf est presque introuvable.
Affair a suivre encore ...
Les erreurs sont tjrs présentes.
le disque est en commande a suivre ...
J'ai recopié tous les fichiers (en arrêtant Sql) ce week end sur un disque
dur usb externe (en réseau sur un w2k0).
43 heures de copie pour 2 X 71 G de base de donnée.
J'attends tjrs le disque neuf ...
Tjrs pas de disque neuf ...
J'ai lancé un DBCC CHECKDB et au bout de 4 heures tjrs pas fini.
J'attends le résultat demain (Du moins j'espère) ....
> Bonjour,
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
> Bonjour,
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
> Bonjour,
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
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
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
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
---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 +
---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 +
---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 +
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 ?
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.
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 ?
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.
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 ?
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.
---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 +
---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 +
---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 +
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
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
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
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éren ce
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 don né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 manag er
( 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'a ujourd'hui.
- On l'a déjà fait une fois est c'était hyper hyper long ( plus ieurs
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 ce la
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 savoi r 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 I D =
1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 6 5535
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 à fair e
é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 e t 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 ch kdsk
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
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éren ce
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 don né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 manag er
( 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'a ujourd'hui.
- On l'a déjà fait une fois est c'était hyper hyper long ( plus ieurs
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 ce la
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 savoi r 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 I D =
1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 6 5535
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 à fair e
é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 e t 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 ch kdsk
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
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éren ce
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 don né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 manag er
( 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'a ujourd'hui.
- On l'a déjà fait une fois est c'était hyper hyper long ( plus ieurs
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 ce la
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 savoi r 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 I D =
1077578877, index ID = 0, pas à l'objet ID = -1, index ID = 6 5535
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 à fair e
é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 e t 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 ch kdsk
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
