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
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
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
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" wrote in message
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
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" <pierrot.heritier@unifr.ch> wrote in message
news:WuydneYXCKtGmjvbRVnyhQA@giganews.com...
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
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" wrote in message
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
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]" wrote in message
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" wrote in message
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
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]" <fromelard@hotmail.com> wrote in message
news:B2092414-8B9F-40B4-93A0-52A8245012BA@microsoft.com...
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" <pierrot.heritier@unifr.ch> wrote in message
news:WuydneYXCKtGmjvbRVnyhQA@giganews.com...
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
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]" wrote in message
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" wrote in message
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
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" wrote in message
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]" wrote in message
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" wrote in message
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
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" <pierrot.heritier@unifr.ch> wrote in message
news:YcednfID-vb1hTrbnZ2dnUVZ8vydnZ2d@giganews.com...
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]" <fromelard@hotmail.com> wrote in message
news:B2092414-8B9F-40B4-93A0-52A8245012BA@microsoft.com...
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" <pierrot.heritier@unifr.ch> wrote in message
news:WuydneYXCKtGmjvbRVnyhQA@giganews.com...
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
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" wrote in message
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]" wrote in message
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" wrote in message
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
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]" wrote in message
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" wrote in message
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]" wrote in message
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" wrote in message
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
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]" <fromelard@hotmail.com> wrote in message
news:CC8C2235-5A31-4EED-9FDD-8C1704CB3926@microsoft.com...
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" <pierrot.heritier@unifr.ch> wrote in message
news:YcednfID-vb1hTrbnZ2dnUVZ8vydnZ2d@giganews.com...
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]" <fromelard@hotmail.com> wrote in message
news:B2092414-8B9F-40B4-93A0-52A8245012BA@microsoft.com...
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" <pierrot.heritier@unifr.ch> wrote in message
news:WuydneYXCKtGmjvbRVnyhQA@giganews.com...
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
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]" wrote in message
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" wrote in message
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]" wrote in message
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" wrote in message
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