[MOSS 2007]SharePoint_Config DB ne démarre plus

Le
pher
Bonjour
j'ai perdu le fichier SharePoint_Config_log.ldf, et maintenant Sharepoint ne
fonctionne plus. La BD SharePoint_Config dans MS SQL 2005 est vide
(statuse536: suspect), et impossible de restaurer les données se trouvant
dans le fichier SharePoint_Config.mdf. J'ai essayé avec attach, ça n'a pas
fonctionné. Avec sp_configure 'allow updates', 1, ça ne fonctionne plus avec
MS SQL 2005 ! Et inutile de préciser que le dernier backup date du
pré-mésosoïque.
Comment faire pour recréer un log file, en démarrant la base en mode
Emergency ?

Pierrot
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Romelard Fabrice [MVP]
Le #17010481
Bonsoir,

Alors déjà : C'est mal de ne pas backuper ses log ;)
ensuite c'est très mal de ne pas backuper ses log ;)
et surtout c'est vraiment très très mal de ne pas backuper ses log ;)

Bref, vous êtes dans une situation assez complexe, vous pouvez regarder dans
ces deux liens :
- http://www.sqlservercentral.com/columnists/bknight/unmarksuspect.asp
ou celui la :
- http://www.devx.com/vb2themax/Tip/18624

Si cela ne fonctionne pas, il faut recréer la ferme SharePoint avec une
nouvelle base de config et recréer les WebApp en mappant les base de
contenu.

FAITES DE SAUVEGARDE AVANT CETTE FOIS :))

--
Cordialement

Romelard Fabrice [MVP]

"pher" news:
Bonjour
j'ai perdu le fichier SharePoint_Config_log.ldf, et maintenant Sharepoint
ne fonctionne plus. La BD SharePoint_Config dans MS SQL 2005 est vide
(statuse536: suspect), et impossible de restaurer les données se
trouvant dans le fichier SharePoint_Config.mdf. J'ai essayé avec attach,
ça n'a pas fonctionné. Avec sp_configure 'allow updates', 1, ça ne
fonctionne plus avec MS SQL 2005 ! Et inutile de préciser que le dernier
backup date du pré-mésosoïque.
Comment faire pour recréer un log file, en démarrant la base en mode
Emergency ?

Pierrot



pher
Le #17010431
Je crois distinguer une pointe d'ironie dans vos propos :-)
J'illustre donc bien l'adage qui veut que les cordonniers sont toujours les
plus mal chaussés (soyons positifs: personne n'est inutile, chacun peut au
moins servir de mauvais exemple).
Et qu'il vaut mieux faire les sauvegardes AVANT le crash, plutôt qu'après
(ça alors!).

Trêve de plaisanteries, tous les posteurs indiquent qu'il faut mettre la
base en mode Emergency avant de tenter de récupérer une base avec seulement
le fichier mdf.
Si cela marchait avec SQL 2000, ça ne fonctionne plus avec SQL 2005. Même en
démarrant MSSQLSERVER en mode DAC (Dedicated Administrator Connection) et
single-user, il est absolument impossible de changer la valeur de "status"
dans la table sys.databases.

L'option FOR_ATTACH_REBUILD_LOG ne fonctionne pas non plus, la base n'ayant
pas été shutdownée proprement (le disque était plein, 0 byte libre, et tout
était coincé, d'où Reboot et perte du gigantesque fichier log). DBCC
REBUILD_LOG ne fonctionne pas non plus, pour la même raison.

Ma nouvelle question est donc: comment créer un nouveau fichier log à partir
d'un mdf en mauvais état ?

Comment je fais pour mapper les bases de contenu ? A un moment donné, je
dois bien créer une WebApp, mais elle va écraser celle qui existe déjà, non
?

Pierrot


"Romelard Fabrice [MVP]" news:
Bonsoir,

Alors déjà : C'est mal de ne pas backuper ses log ;)
ensuite c'est très mal de ne pas backuper ses log ;)
et surtout c'est vraiment très très mal de ne pas backuper ses log ;)

Bref, vous êtes dans une situation assez complexe, vous pouvez regarder
dans ces deux liens :
- http://www.sqlservercentral.com/columnists/bknight/unmarksuspect.asp
ou celui la :
- http://www.devx.com/vb2themax/Tip/18624

Si cela ne fonctionne pas, il faut recréer la ferme SharePoint avec une
nouvelle base de config et recréer les WebApp en mappant les base de
contenu.

FAITES DE SAUVEGARDE AVANT CETTE FOIS :))

--
Cordialement

Romelard Fabrice [MVP]

"pher" news:
Bonjour
j'ai perdu le fichier SharePoint_Config_log.ldf, et maintenant Sharepoint
ne fonctionne plus. La BD SharePoint_Config dans MS SQL 2005 est vide
(statuse536: suspect), et impossible de restaurer les données se
trouvant dans le fichier SharePoint_Config.mdf. J'ai essayé avec attach,
ça n'a pas fonctionné. Avec sp_configure 'allow updates', 1, ça ne
fonctionne plus avec MS SQL 2005 ! Et inutile de préciser que le dernier
backup date du pré-mésosoïque.
Comment faire pour recréer un log file, en démarrant la base en mode
Emergency ?

Pierrot





Romelard Fabrice [MVP]
Le #17010421
Vous avez une aide possible ici :
http://64.233.183.104/search?qÊche:WGFMF-psklgJ:www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/SQL-Server-2005/Q_22704544.html+restore+sql+server+2005+db+suspect&hl=fr&ct=clnk&cd=1&gl=ch

soit :
---------------------
You will have data loss but it can be done.

1) Detach database and move your mdf to save location.
2) Create new databse of same name, same files, same file location and same
file size.
3) Stop SQL server.
4) Swap mdf file of just created DB to your save one.
5) Start SQL. DB will go suspect.
6) ALTER DATABSE <your db> SET EMERGENCY
ALTER DATABASE <your db> SET SINGLE_USER
7) DBCC CHECKDB (<your db>, REPAIR_ALLOW_DATA_LOSS)
8) ALTER DATABASE <your db> SET MULTI_USER
ALTER DATABSE <your db> SET ONLINE
----------------------

A voir si cela fonctionne.

Si vous avez un contrat support avec Microsoft, vous pouvez les contacter et
ouvrir un tiquet sur ce sujet.

--
Cordialement

Romelard Fabrice [MVP]

"pher" news:

Je crois distinguer une pointe d'ironie dans vos propos :-)
J'illustre donc bien l'adage qui veut que les cordonniers sont toujours
les plus mal chaussés (soyons positifs: personne n'est inutile, chacun
peut au moins servir de mauvais exemple).
Et qu'il vaut mieux faire les sauvegardes AVANT le crash, plutôt qu'après
(ça alors!).

Trêve de plaisanteries, tous les posteurs indiquent qu'il faut mettre la
base en mode Emergency avant de tenter de récupérer une base avec
seulement le fichier mdf.
Si cela marchait avec SQL 2000, ça ne fonctionne plus avec SQL 2005. Même
en démarrant MSSQLSERVER en mode DAC (Dedicated Administrator Connection)
et single-user, il est absolument impossible de changer la valeur de
"status" dans la table sys.databases.

L'option FOR_ATTACH_REBUILD_LOG ne fonctionne pas non plus, la base
n'ayant pas été shutdownée proprement (le disque était plein, 0 byte
libre, et tout était coincé, d'où Reboot et perte du gigantesque fichier
log). DBCC REBUILD_LOG ne fonctionne pas non plus, pour la même raison.

Ma nouvelle question est donc: comment créer un nouveau fichier log à
partir d'un mdf en mauvais état ?

Comment je fais pour mapper les bases de contenu ? A un moment donné, je
dois bien créer une WebApp, mais elle va écraser celle qui existe déjà,
non ?

Pierrot


"Romelard Fabrice [MVP]" news:
Bonsoir,

Alors déjà : C'est mal de ne pas backuper ses log ;)
ensuite c'est très mal de ne pas backuper ses log ;)
et surtout c'est vraiment très très mal de ne pas backuper ses log ;)

Bref, vous êtes dans une situation assez complexe, vous pouvez regarder
dans ces deux liens :
- http://www.sqlservercentral.com/columnists/bknight/unmarksuspect.asp
ou celui la :
- http://www.devx.com/vb2themax/Tip/18624

Si cela ne fonctionne pas, il faut recréer la ferme SharePoint avec une
nouvelle base de config et recréer les WebApp en mappant les base de
contenu.

FAITES DE SAUVEGARDE AVANT CETTE FOIS :))

--
Cordialement

Romelard Fabrice [MVP]

"pher" news:
Bonjour
j'ai perdu le fichier SharePoint_Config_log.ldf, et maintenant
Sharepoint ne fonctionne plus. La BD SharePoint_Config dans MS SQL 2005
est vide (statuse536: suspect), et impossible de restaurer les données
se trouvant dans le fichier SharePoint_Config.mdf. J'ai essayé avec
attach, ça n'a pas fonctionné. Avec sp_configure 'allow updates', 1, ça
ne fonctionne plus avec MS SQL 2005 ! Et inutile de préciser que le
dernier backup date du pré-mésosoïque.
Comment faire pour recréer un log file, en démarrant la base en mode
Emergency ?

Pierrot









pher
Le #17010281
J'avais entre-temps trouvé cette séquence d'opérations, et ça a fonctionné.
Le fichier log a été recréé. Ensuite j'ai dû ré-exécuter le Sharepoint
Configuration Wizard parce que je n'avais plus accès à la Central
Administration.
Tutto bene.
Sauf que je viens de constater que la base de données WSS_Content_Sites est
elle aussi privée de son log, donc plus d'accès aux sites correspondants, et
rebelote.
Au final, Sharepoint est reparti comme en 14, tout est bien qui continue
bien.

Merci
Pierrot


"Romelard Fabrice [MVP]" news:
Vous avez une aide possible ici :

http://64.233.183.104/search?qÊche:WGFMF-psklgJ:www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/SQL-Server-2005/Q_22704544.html+restore+sql+server+2005+db+suspect&hl=fr&ct=clnk&cd=1&gl=ch

soit :
---------------------
You will have data loss but it can be done.

1) Detach database and move your mdf to save location.
2) Create new databse of same name, same files, same file location and
same file size.
3) Stop SQL server.
4) Swap mdf file of just created DB to your save one.
5) Start SQL. DB will go suspect.
6) ALTER DATABSE <your db> SET EMERGENCY
ALTER DATABASE <your db> SET SINGLE_USER
7) DBCC CHECKDB (<your db>, REPAIR_ALLOW_DATA_LOSS)
8) ALTER DATABASE <your db> SET MULTI_USER
ALTER DATABSE <your db> SET ONLINE
----------------------

A voir si cela fonctionne.

Si vous avez un contrat support avec Microsoft, vous pouvez les contacter
et ouvrir un tiquet sur ce sujet.

--
Cordialement

Romelard Fabrice [MVP]

"pher" news:

Je crois distinguer une pointe d'ironie dans vos propos :-)
J'illustre donc bien l'adage qui veut que les cordonniers sont toujours
les plus mal chaussés (soyons positifs: personne n'est inutile, chacun
peut au moins servir de mauvais exemple).
Et qu'il vaut mieux faire les sauvegardes AVANT le crash, plutôt qu'après
(ça alors!).

Trêve de plaisanteries, tous les posteurs indiquent qu'il faut mettre la
base en mode Emergency avant de tenter de récupérer une base avec
seulement le fichier mdf.
Si cela marchait avec SQL 2000, ça ne fonctionne plus avec SQL 2005. Même
en démarrant MSSQLSERVER en mode DAC (Dedicated Administrator Connection)
et single-user, il est absolument impossible de changer la valeur de
"status" dans la table sys.databases.

L'option FOR_ATTACH_REBUILD_LOG ne fonctionne pas non plus, la base
n'ayant pas été shutdownée proprement (le disque était plein, 0 byte
libre, et tout était coincé, d'où Reboot et perte du gigantesque fichier
log). DBCC REBUILD_LOG ne fonctionne pas non plus, pour la même raison.

Ma nouvelle question est donc: comment créer un nouveau fichier log à
partir d'un mdf en mauvais état ?

Comment je fais pour mapper les bases de contenu ? A un moment donné, je
dois bien créer une WebApp, mais elle va écraser celle qui existe déjà,
non ?

Pierrot


"Romelard Fabrice [MVP]" news:
Bonsoir,

Alors déjà : C'est mal de ne pas backuper ses log ;)
ensuite c'est très mal de ne pas backuper ses log ;)
et surtout c'est vraiment très très mal de ne pas backuper ses log ;)

Bref, vous êtes dans une situation assez complexe, vous pouvez regarder
dans ces deux liens :
-
http://www.sqlservercentral.com/columnists/bknight/unmarksuspect.asp
ou celui la :
- http://www.devx.com/vb2themax/Tip/18624

Si cela ne fonctionne pas, il faut recréer la ferme SharePoint avec une
nouvelle base de config et recréer les WebApp en mappant les base de
contenu.

FAITES DE SAUVEGARDE AVANT CETTE FOIS :))

--
Cordialement

Romelard Fabrice [MVP]

"pher" news:
Bonjour
j'ai perdu le fichier SharePoint_Config_log.ldf, et maintenant
Sharepoint ne fonctionne plus. La BD SharePoint_Config dans MS SQL 2005
est vide (statuse536: suspect), et impossible de restaurer les
données se trouvant dans le fichier SharePoint_Config.mdf. J'ai essayé
avec attach, ça n'a pas fonctionné. Avec sp_configure 'allow updates',
1, ça ne fonctionne plus avec MS SQL 2005 ! Et inutile de préciser que
le dernier backup date du pré-mésosoïque.
Comment faire pour recréer un log file, en démarrant la base en mode
Emergency ?

Pierrot











Romelard Fabrice [MVP]
Le #17010111
N'oubliez pas :
- Faites vos sauvegardes de log maintenant :))

Fabrice

"pher" news:
J'avais entre-temps trouvé cette séquence d'opérations, et ça a
fonctionné.
Le fichier log a été recréé. Ensuite j'ai dû ré-exécuter le Sharepoint
Configuration Wizard parce que je n'avais plus accès à la Central
Administration.
Tutto bene.
Sauf que je viens de constater que la base de données WSS_Content_Sites
est elle aussi privée de son log, donc plus d'accès aux sites
correspondants, et rebelote.
Au final, Sharepoint est reparti comme en 14, tout est bien qui continue
bien.

Merci
Pierrot


"Romelard Fabrice [MVP]" news:
Vous avez une aide possible ici :

http://64.233.183.104/search?qÊche:WGFMF-psklgJ:www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/SQL-Server-2005/Q_22704544.html+restore+sql+server+2005+db+suspect&hl=fr&ct=clnk&cd=1&gl=ch

soit :
---------------------
You will have data loss but it can be done.

1) Detach database and move your mdf to save location.
2) Create new databse of same name, same files, same file location and
same file size.
3) Stop SQL server.
4) Swap mdf file of just created DB to your save one.
5) Start SQL. DB will go suspect.
6) ALTER DATABSE <your db> SET EMERGENCY
ALTER DATABASE <your db> SET SINGLE_USER
7) DBCC CHECKDB (<your db>, REPAIR_ALLOW_DATA_LOSS)
8) ALTER DATABASE <your db> SET MULTI_USER
ALTER DATABSE <your db> SET ONLINE
----------------------

A voir si cela fonctionne.

Si vous avez un contrat support avec Microsoft, vous pouvez les contacter
et ouvrir un tiquet sur ce sujet.

--
Cordialement

Romelard Fabrice [MVP]

"pher" news:

Je crois distinguer une pointe d'ironie dans vos propos :-)
J'illustre donc bien l'adage qui veut que les cordonniers sont toujours
les plus mal chaussés (soyons positifs: personne n'est inutile, chacun
peut au moins servir de mauvais exemple).
Et qu'il vaut mieux faire les sauvegardes AVANT le crash, plutôt
qu'après
(ça alors!).

Trêve de plaisanteries, tous les posteurs indiquent qu'il faut mettre la
base en mode Emergency avant de tenter de récupérer une base avec
seulement le fichier mdf.
Si cela marchait avec SQL 2000, ça ne fonctionne plus avec SQL 2005.
Même
en démarrant MSSQLSERVER en mode DAC (Dedicated Administrator
Connection)
et single-user, il est absolument impossible de changer la valeur de
"status" dans la table sys.databases.

L'option FOR_ATTACH_REBUILD_LOG ne fonctionne pas non plus, la base
n'ayant pas été shutdownée proprement (le disque était plein, 0 byte
libre, et tout était coincé, d'où Reboot et perte du gigantesque fichier
log). DBCC REBUILD_LOG ne fonctionne pas non plus, pour la même raison.

Ma nouvelle question est donc: comment créer un nouveau fichier log à
partir d'un mdf en mauvais état ?

Comment je fais pour mapper les bases de contenu ? A un moment donné, je
dois bien créer une WebApp, mais elle va écraser celle qui existe déjà,
non ?

Pierrot


"Romelard Fabrice [MVP]" news:
Bonsoir,

Alors déjà : C'est mal de ne pas backuper ses log ;)
ensuite c'est très mal de ne pas backuper ses log ;)
et surtout c'est vraiment très très mal de ne pas backuper ses log ;)

Bref, vous êtes dans une situation assez complexe, vous pouvez regarder
dans ces deux liens :
-
http://www.sqlservercentral.com/columnists/bknight/unmarksuspect.asp
ou celui la :
- http://www.devx.com/vb2themax/Tip/18624

Si cela ne fonctionne pas, il faut recréer la ferme SharePoint avec une
nouvelle base de config et recréer les WebApp en mappant les base de
contenu.

FAITES DE SAUVEGARDE AVANT CETTE FOIS :))

--
Cordialement

Romelard Fabrice [MVP]

"pher" news:
Bonjour
j'ai perdu le fichier SharePoint_Config_log.ldf, et maintenant
Sharepoint ne fonctionne plus. La BD SharePoint_Config dans MS SQL
2005
est vide (statuse536: suspect), et impossible de restaurer les
données se trouvant dans le fichier SharePoint_Config.mdf. J'ai essayé
avec attach, ça n'a pas fonctionné. Avec sp_configure 'allow updates',
1, ça ne fonctionne plus avec MS SQL 2005 ! Et inutile de préciser que
le dernier backup date du pré-mésosoïque.
Comment faire pour recréer un log file, en démarrant la base en mode
Emergency ?

Pierrot
















Publicité
Poster une réponse
Anonyme