Une de mes bases qui possede 5 groupes de fichies + 1 fichier de log
était marqué en suspecte.
En analysant les journaux de windows il semblait que le problème venait
du journal de transaction.
J'ai essayé la porocédure SP_resetstatus en suivant pas à pas les
instructions.
La base est toujours en suspect.
J'ai donc couper SQL, renomé le .LDF, relancer SQL en espérant qu'il
recré un LDF... rien.
J'ai donc détacher la base marquée en suspect, renomer le .LDF et tenter
de rattacher la base afin qu'il recré un LDF mais là j'ai le message
suivant :
Erreur 1813 : Impossible d'ouvrir la nouvelle base de données 'URL'.
CREATE DATABASE s'est arreté. Erreur d'activation de l'unité. Le nom du
fichier physique 'F:\sql_transac\url_log.ldf' est peut-etre incorrect.
Si quelqu'un à une idée ... la restauration me tente moins, j'ai 30 Go
de donné à restauré.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel PRIORI
Ben t'es ben à plaindre !
Le journal des transactions est le talon d'achile de SQL server : Il ne faut pas le perdre ; surtout en prod !
Les ecritures (insert, update, delete) sont journalisées ... dans le journal de log (évidemment) ligne à ligne (anciennes valeurs ; nouvelles valeurs) avant de répondre au client 'opération effectuée'. L'écriture effective dans le fichier de base de donnée ne se fait que plus tard lors des 'chekpoint' (pour tout ou partie d'une transaction d'ailleur). Donc si tu perds le fichier journal tu ne sais pas déterminer parmis ce que tu trouves sur les fichiers de données quelles sont les lignes qui sont commitées de celles qui ne le sont pas. L'idée de chercher sur disque l'information de verrous n'est pas suffisante pour remettre la base en état cohérent. Bref t'es dans la merde.
En bon administrateur que tu es, tu disposes de sauvegardes de la base et des journaux. C'est bien. C'est le mieux qu'on puisse faire dans ce cas.
Ce qui m'interresse de savoir c'est qu'elle est l'origine de la panne ? 1- matérielle (clusters defectueux...) 2- logiciel (écriture incohérente) 2-1 sur un disque en NTFS 2-2 sur un disque FAT (?)
Merci de répondre sur le site
"" a écrit :
Bonjour,
Une de mes bases qui possede 5 groupes de fichies + 1 fichier de log était marqué en suspecte. En analysant les journaux de windows il semblait que le problème venait du journal de transaction.
J'ai essayé la porocédure SP_resetstatus en suivant pas à pas les instructions.
La base est toujours en suspect.
J'ai donc couper SQL, renomé le .LDF, relancer SQL en espérant qu'il recré un LDF... rien.
J'ai donc détacher la base marquée en suspect, renomer le .LDF et tenter de rattacher la base afin qu'il recré un LDF mais là j'ai le message suivant :
Erreur 1813 : Impossible d'ouvrir la nouvelle base de données 'URL'. CREATE DATABASE s'est arreté. Erreur d'activation de l'unité. Le nom du fichier physique 'F:sql_transacurl_log.ldf' est peut-etre incorrect.
Si quelqu'un à une idée ... la restauration me tente moins, j'ai 30 Go de donné à restauré.
Merci d'avance
Ben t'es ben à plaindre !
Le journal des transactions est le talon d'achile de SQL server : Il ne faut
pas le perdre ; surtout en prod !
Les ecritures (insert, update, delete) sont journalisées ... dans le journal
de log (évidemment) ligne à ligne (anciennes valeurs ; nouvelles valeurs)
avant de répondre au client 'opération effectuée'.
L'écriture effective dans le fichier de base de donnée ne se fait que plus
tard lors des 'chekpoint' (pour tout ou partie d'une transaction d'ailleur).
Donc si tu perds le fichier journal tu ne sais pas déterminer parmis ce que
tu trouves sur les fichiers de données quelles sont les lignes qui sont
commitées de celles qui ne le sont pas. L'idée de chercher sur disque
l'information de verrous n'est pas suffisante pour remettre la base en état
cohérent.
Bref t'es dans la merde.
En bon administrateur que tu es, tu disposes de sauvegardes de la base et
des journaux. C'est bien. C'est le mieux qu'on puisse faire dans ce cas.
Ce qui m'interresse de savoir c'est qu'elle est l'origine de la panne ?
1- matérielle (clusters defectueux...)
2- logiciel (écriture incohérente)
2-1 sur un disque en NTFS
2-2 sur un disque FAT (?)
Merci de répondre sur le site
"Fr@ncky" a écrit :
Bonjour,
Une de mes bases qui possede 5 groupes de fichies + 1 fichier de log
était marqué en suspecte.
En analysant les journaux de windows il semblait que le problème venait
du journal de transaction.
J'ai essayé la porocédure SP_resetstatus en suivant pas à pas les
instructions.
La base est toujours en suspect.
J'ai donc couper SQL, renomé le .LDF, relancer SQL en espérant qu'il
recré un LDF... rien.
J'ai donc détacher la base marquée en suspect, renomer le .LDF et tenter
de rattacher la base afin qu'il recré un LDF mais là j'ai le message
suivant :
Erreur 1813 : Impossible d'ouvrir la nouvelle base de données 'URL'.
CREATE DATABASE s'est arreté. Erreur d'activation de l'unité. Le nom du
fichier physique 'F:sql_transacurl_log.ldf' est peut-etre incorrect.
Si quelqu'un à une idée ... la restauration me tente moins, j'ai 30 Go
de donné à restauré.
Le journal des transactions est le talon d'achile de SQL server : Il ne faut pas le perdre ; surtout en prod !
Les ecritures (insert, update, delete) sont journalisées ... dans le journal de log (évidemment) ligne à ligne (anciennes valeurs ; nouvelles valeurs) avant de répondre au client 'opération effectuée'. L'écriture effective dans le fichier de base de donnée ne se fait que plus tard lors des 'chekpoint' (pour tout ou partie d'une transaction d'ailleur). Donc si tu perds le fichier journal tu ne sais pas déterminer parmis ce que tu trouves sur les fichiers de données quelles sont les lignes qui sont commitées de celles qui ne le sont pas. L'idée de chercher sur disque l'information de verrous n'est pas suffisante pour remettre la base en état cohérent. Bref t'es dans la merde.
En bon administrateur que tu es, tu disposes de sauvegardes de la base et des journaux. C'est bien. C'est le mieux qu'on puisse faire dans ce cas.
Ce qui m'interresse de savoir c'est qu'elle est l'origine de la panne ? 1- matérielle (clusters defectueux...) 2- logiciel (écriture incohérente) 2-1 sur un disque en NTFS 2-2 sur un disque FAT (?)
Merci de répondre sur le site
"" a écrit :
Bonjour,
Une de mes bases qui possede 5 groupes de fichies + 1 fichier de log était marqué en suspecte. En analysant les journaux de windows il semblait que le problème venait du journal de transaction.
J'ai essayé la porocédure SP_resetstatus en suivant pas à pas les instructions.
La base est toujours en suspect.
J'ai donc couper SQL, renomé le .LDF, relancer SQL en espérant qu'il recré un LDF... rien.
J'ai donc détacher la base marquée en suspect, renomer le .LDF et tenter de rattacher la base afin qu'il recré un LDF mais là j'ai le message suivant :
Erreur 1813 : Impossible d'ouvrir la nouvelle base de données 'URL'. CREATE DATABASE s'est arreté. Erreur d'activation de l'unité. Le nom du fichier physique 'F:sql_transacurl_log.ldf' est peut-etre incorrect.
Si quelqu'un à une idée ... la restauration me tente moins, j'ai 30 Go de donné à restauré.
Merci d'avance
Fr
J'ai effectivement restauré ma sauvegarde.
On ne le dira jamais assez... soyons vigilant sur le bon déroulement des sauvegarde ! Quand tout va bien on a tendance à ne pas trop s'en soucier, mais en cas de coup dur, on est content de les trouver.
Après restauration de la sauvegarde, tout semblait être rentré dans l'ordre...mais quelque heures après, la base n'était de nouveau plus accessible ou l'accès était très très lent.
Nous avons changé la carte mère, le disque système et les barttes de mémoires car les serveur rebootait tout seul !
Tout semblait OK...mais quelque minutes après ... même problème (sauf qu'il ne rebootait plus tout seul)
En fait en regardant les agents en cours d'éxecution au moment du ralentissement j'ai mis la main sur une proc qui fait des update dans une table. (cet agent tournait sans pb depuis des mois)
En regardant de plus près il manquait un index primordial à cette table de + de 9 millions d'enrg. Il n'y avait pas l'index sur le champ utilisé dans la clause WHERE.
Je ne m'en suis pas douté + tôt car cela fait des mois que je créé automatiquement une table par mois avec ses index... mais ce mois ci cet index n'avait pas été créé :-((
Le serveur tentait donc des UPDATE sans index sur une table qui est très souvent attaquer en select.
A mon avis, des verrous pendant plusieur heures + les pb matériel. Ca faisait beaucoup. D'ou la base marqué en suspect.
Morale de l'hitoire : DBA est un métier à plein temps quand les bases deviennent importante ! Mais malheureusement, dans les petites structures le DBA n'est pas que DBA :-((
En tout cas,merci Michel d'avoir pris le temps de répondre. J'ai quand même garder au chaud mes MDF suspect afin de "m'amuser" avec si j'ai le temps ;-)
Michel PRIORI wrote:
Ben t'es ben à plaindre !
Le journal des transactions est le talon d'achile de SQL server : Il ne faut pas le perdre ; surtout en prod !
Les ecritures (insert, update, delete) sont journalisées ... dans le journal de log (évidemment) ligne à ligne (anciennes valeurs ; nouvelles valeurs) avant de répondre au client 'opération effectuée'. L'écriture effective dans le fichier de base de donnée ne se fait que plus tard lors des 'chekpoint' (pour tout ou partie d'une transaction d'ailleur). Donc si tu perds le fichier journal tu ne sais pas déterminer parmis ce que tu trouves sur les fichiers de données quelles sont les lignes qui sont commitées de celles qui ne le sont pas. L'idée de chercher sur disque l'information de verrous n'est pas suffisante pour remettre la base en état cohérent. Bref t'es dans la merde.
En bon administrateur que tu es, tu disposes de sauvegardes de la base et des journaux. C'est bien. C'est le mieux qu'on puisse faire dans ce cas.
Ce qui m'interresse de savoir c'est qu'elle est l'origine de la panne ? 1- matérielle (clusters defectueux...) 2- logiciel (écriture incohérente) 2-1 sur un disque en NTFS 2-2 sur un disque FAT (?)
Merci de répondre sur le site
"" a écrit :
Bonjour,
Une de mes bases qui possede 5 groupes de fichies + 1 fichier de log était marqué en suspecte. En analysant les journaux de windows il semblait que le problème venait du journal de transaction.
J'ai essayé la porocédure SP_resetstatus en suivant pas à pas les instructions.
La base est toujours en suspect.
J'ai donc couper SQL, renomé le .LDF, relancer SQL en espérant qu'il recré un LDF... rien.
J'ai donc détacher la base marquée en suspect, renomer le .LDF et tenter de rattacher la base afin qu'il recré un LDF mais là j'ai le message suivant :
Erreur 1813 : Impossible d'ouvrir la nouvelle base de données 'URL'. CREATE DATABASE s'est arreté. Erreur d'activation de l'unité. Le nom du fichier physique 'F:sql_transacurl_log.ldf' est peut-etre incorrect.
Si quelqu'un à une idée ... la restauration me tente moins, j'ai 30 Go de donné à restauré.
Merci d'avance
J'ai effectivement restauré ma sauvegarde.
On ne le dira jamais assez... soyons vigilant sur le bon déroulement des
sauvegarde ! Quand tout va bien on a tendance à ne pas trop s'en
soucier, mais en cas de coup dur, on est content de les trouver.
Après restauration de la sauvegarde, tout semblait être rentré dans
l'ordre...mais quelque heures après, la base n'était de nouveau plus
accessible ou l'accès était très très lent.
Nous avons changé la carte mère, le disque système et les barttes de
mémoires car les serveur rebootait tout seul !
Tout semblait OK...mais quelque minutes après ... même problème (sauf
qu'il ne rebootait plus tout seul)
En fait en regardant les agents en cours d'éxecution au moment du
ralentissement j'ai mis la main sur une proc qui fait des update dans
une table. (cet agent tournait sans pb depuis des mois)
En regardant de plus près il manquait un index primordial à cette table
de + de 9 millions d'enrg. Il n'y avait pas l'index sur le champ utilisé
dans la clause WHERE.
Je ne m'en suis pas douté + tôt car cela fait des mois que je créé
automatiquement une table par mois avec ses index... mais ce mois ci cet
index n'avait pas été créé :-((
Le serveur tentait donc des UPDATE sans index sur une table qui est très
souvent attaquer en select.
A mon avis, des verrous pendant plusieur heures + les pb matériel. Ca
faisait beaucoup. D'ou la base marqué en suspect.
Morale de l'hitoire :
DBA est un métier à plein temps quand les bases deviennent importante !
Mais malheureusement, dans les petites structures le DBA n'est pas que
DBA :-((
En tout cas,merci Michel d'avoir pris le temps de répondre.
J'ai quand même garder au chaud mes MDF suspect afin de "m'amuser" avec
si j'ai le temps ;-)
Michel PRIORI wrote:
Ben t'es ben à plaindre !
Le journal des transactions est le talon d'achile de SQL server : Il ne faut
pas le perdre ; surtout en prod !
Les ecritures (insert, update, delete) sont journalisées ... dans le journal
de log (évidemment) ligne à ligne (anciennes valeurs ; nouvelles valeurs)
avant de répondre au client 'opération effectuée'.
L'écriture effective dans le fichier de base de donnée ne se fait que plus
tard lors des 'chekpoint' (pour tout ou partie d'une transaction d'ailleur).
Donc si tu perds le fichier journal tu ne sais pas déterminer parmis ce que
tu trouves sur les fichiers de données quelles sont les lignes qui sont
commitées de celles qui ne le sont pas. L'idée de chercher sur disque
l'information de verrous n'est pas suffisante pour remettre la base en état
cohérent.
Bref t'es dans la merde.
En bon administrateur que tu es, tu disposes de sauvegardes de la base et
des journaux. C'est bien. C'est le mieux qu'on puisse faire dans ce cas.
Ce qui m'interresse de savoir c'est qu'elle est l'origine de la panne ?
1- matérielle (clusters defectueux...)
2- logiciel (écriture incohérente)
2-1 sur un disque en NTFS
2-2 sur un disque FAT (?)
Merci de répondre sur le site
"Fr@ncky" a écrit :
Bonjour,
Une de mes bases qui possede 5 groupes de fichies + 1 fichier de log
était marqué en suspecte.
En analysant les journaux de windows il semblait que le problème venait
du journal de transaction.
J'ai essayé la porocédure SP_resetstatus en suivant pas à pas les
instructions.
La base est toujours en suspect.
J'ai donc couper SQL, renomé le .LDF, relancer SQL en espérant qu'il
recré un LDF... rien.
J'ai donc détacher la base marquée en suspect, renomer le .LDF et tenter
de rattacher la base afin qu'il recré un LDF mais là j'ai le message
suivant :
Erreur 1813 : Impossible d'ouvrir la nouvelle base de données 'URL'.
CREATE DATABASE s'est arreté. Erreur d'activation de l'unité. Le nom du
fichier physique 'F:sql_transacurl_log.ldf' est peut-etre incorrect.
Si quelqu'un à une idée ... la restauration me tente moins, j'ai 30 Go
de donné à restauré.
On ne le dira jamais assez... soyons vigilant sur le bon déroulement des sauvegarde ! Quand tout va bien on a tendance à ne pas trop s'en soucier, mais en cas de coup dur, on est content de les trouver.
Après restauration de la sauvegarde, tout semblait être rentré dans l'ordre...mais quelque heures après, la base n'était de nouveau plus accessible ou l'accès était très très lent.
Nous avons changé la carte mère, le disque système et les barttes de mémoires car les serveur rebootait tout seul !
Tout semblait OK...mais quelque minutes après ... même problème (sauf qu'il ne rebootait plus tout seul)
En fait en regardant les agents en cours d'éxecution au moment du ralentissement j'ai mis la main sur une proc qui fait des update dans une table. (cet agent tournait sans pb depuis des mois)
En regardant de plus près il manquait un index primordial à cette table de + de 9 millions d'enrg. Il n'y avait pas l'index sur le champ utilisé dans la clause WHERE.
Je ne m'en suis pas douté + tôt car cela fait des mois que je créé automatiquement une table par mois avec ses index... mais ce mois ci cet index n'avait pas été créé :-((
Le serveur tentait donc des UPDATE sans index sur une table qui est très souvent attaquer en select.
A mon avis, des verrous pendant plusieur heures + les pb matériel. Ca faisait beaucoup. D'ou la base marqué en suspect.
Morale de l'hitoire : DBA est un métier à plein temps quand les bases deviennent importante ! Mais malheureusement, dans les petites structures le DBA n'est pas que DBA :-((
En tout cas,merci Michel d'avoir pris le temps de répondre. J'ai quand même garder au chaud mes MDF suspect afin de "m'amuser" avec si j'ai le temps ;-)
Michel PRIORI wrote:
Ben t'es ben à plaindre !
Le journal des transactions est le talon d'achile de SQL server : Il ne faut pas le perdre ; surtout en prod !
Les ecritures (insert, update, delete) sont journalisées ... dans le journal de log (évidemment) ligne à ligne (anciennes valeurs ; nouvelles valeurs) avant de répondre au client 'opération effectuée'. L'écriture effective dans le fichier de base de donnée ne se fait que plus tard lors des 'chekpoint' (pour tout ou partie d'une transaction d'ailleur). Donc si tu perds le fichier journal tu ne sais pas déterminer parmis ce que tu trouves sur les fichiers de données quelles sont les lignes qui sont commitées de celles qui ne le sont pas. L'idée de chercher sur disque l'information de verrous n'est pas suffisante pour remettre la base en état cohérent. Bref t'es dans la merde.
En bon administrateur que tu es, tu disposes de sauvegardes de la base et des journaux. C'est bien. C'est le mieux qu'on puisse faire dans ce cas.
Ce qui m'interresse de savoir c'est qu'elle est l'origine de la panne ? 1- matérielle (clusters defectueux...) 2- logiciel (écriture incohérente) 2-1 sur un disque en NTFS 2-2 sur un disque FAT (?)
Merci de répondre sur le site
"" a écrit :
Bonjour,
Une de mes bases qui possede 5 groupes de fichies + 1 fichier de log était marqué en suspecte. En analysant les journaux de windows il semblait que le problème venait du journal de transaction.
J'ai essayé la porocédure SP_resetstatus en suivant pas à pas les instructions.
La base est toujours en suspect.
J'ai donc couper SQL, renomé le .LDF, relancer SQL en espérant qu'il recré un LDF... rien.
J'ai donc détacher la base marquée en suspect, renomer le .LDF et tenter de rattacher la base afin qu'il recré un LDF mais là j'ai le message suivant :
Erreur 1813 : Impossible d'ouvrir la nouvelle base de données 'URL'. CREATE DATABASE s'est arreté. Erreur d'activation de l'unité. Le nom du fichier physique 'F:sql_transacurl_log.ldf' est peut-etre incorrect.
Si quelqu'un à une idée ... la restauration me tente moins, j'ai 30 Go de donné à restauré.
