Discussion :

[lmerian]

Bonsoir
j'utilise depuis des années sql server et je n'ai jamais rencontré ce problème
dans mes bases il y a une base récente que je n'ai pas créée moi même BACKOFFICEPP
j'ai des enregistrements qui me posent problème du coup j'ai besoin de restaurer une sauvegarde antérieure pour y vérifier ce qui s'est passé
le plan de maintenance prévoyait des sauvegardes hebdo, aucun souci
j'ouvre le menu de sauvegarde , je choisi de restaurer la base de données sous un autre nom BACKOFFICEPP_OLD car je ne veux pas écraser la base actuelle et là
pour la première fois depuis des années en faisant cette opération de routine j'ai un message d'erreur qui dit
Echec de la restauration de la base de données BACKOFFICEPP_OLD
Impossible d'obtenir l'accès exclusif car la base de données est en cours d'utilisation

??? bizarre ? quelle base ? la base d'origine ? mais puisque je restaure cette sauvegarde sous un autre nom pourquoi a-t-il besoin d'un accès à la base d'origine ?
je me suis demandé si cela n'avait pas un rapport avec les journaux
toutes mes bases sont créées en mode recovery SIMPLE
en regardant je vois que celle là est en COMPLET
alors je la sauvegarde, je sauvegarde le journal et je la passe en SIMPLE

et je recommence, même problème

quelqu'un peut-il m'éclairer ?

merci de votre aide

loic

[Invité]

il faut que tu changes les noms / emplacements des fichiers de données de la restauration : par défaut, il reprend les fichiers de la bd d'origine pour la restauration et vu qu'elle existe encore, il y a conflit entre les fichiers de l'ancienne bd et ceux de la bd qui est en train d'être créée.

[lmerian]

bonsoir et merci mais ça fait des années que sur le sql manager ça le fait par défaut; j'ai la version 17.9 et quand on indique le nom de base de destination différent de la base d'origine ça restaure bien sous ces nouveaux noms de fichier mais pour celle là ça ne marche pas

et même quand je vais dans fichier, restaurer en tant que , je donne un nouveau nom de fichier de données et de fichier de log ... je lance la restauration, j'ai un message qui me dit qu'il va faire "une sauvegarde de la fin du journal de la base de données sources" et ensuite échec, toujours la même erreur

peut être est-ce parce que cette base est en mode RECOVERY COMPLETE ? d'habitude toutes mes bases sont en mode simple

je n'ose pas décocher l'option EFFECTUER LA SAUVEGARDE DE LA FIN DU JOURNAL AVANT D'EFFECTUER LA RESTAURATION (pourtant moi je veux restaurer sous un autre nom)
ni LAISSER LA BASE DE DONNEES SOURCE DANS L'ETAT DE RESTAURATION (NO RECOVERY) (je ne sais pas à quoi cela correspond)

je sauvegarde et je restaure mes bases très régulièrement je n'ai jamais été confronté à cela
loic

[Invité]

Ça serait bien dans ce cas, d'avoir votre commande complète de restauration ainsi que le message d'erreur complet.

[SQLpro]

bonsoir et merci mais ça fait des années que sur le sql manager ça le fait par défaut; j'ai la version 17.9 et quand on indique le nom de base de destination différent de la base d'origine ça restaure bien sous ces nouveaux noms de fichier mais pour celle là ça ne marche pas

Absolument pas ! les noms de fichiers restent strictement identique mais, SQL Server choisit l'emplacement par défaut... C'est donc le répertoire qui est différent et non les noms des fichiers....

et même quand je vais dans fichier, restaurer en tant que , je donne un nouveau nom de fichier de données et de fichier de log ... je lance la restauration, j'ai un message qui me dit qu'il va faire "une sauvegarde de la fin du journal de la base de données sources" et ensuite échec, toujours la même erreur

Il est probable que vous ayez choisit par inadvetyance d'écraser la base de données dans l'IHM. Ce message je le rencontre avec mes stagiaires au moins une fois dans l’exercice de restauration; Soyez attentifs aux cases coches dans les différents onglets...

peut être est-ce parce que cette base est en mode RECOVERY COMPLETE ? d'habitude toutes mes bases sont en mode simple

Non, rien à voir

je n'ose pas décocher l'option EFFECTUER LA SAUVEGARDE DE LA FIN DU JOURNAL AVANT D'EFFECTUER LA RESTAURATION (pourtant moi je veux restaurer sous un autre nom)

Si, c'est ce qu'il faut faire ! Décocher !

ni LAISSER LA BASE DE DONNEES SOURCE DANS L'ETAT DE RESTAURATION (NO RECOVERY) (je ne sais pas à quoi cela correspond)

Idem

je sauvegarde et je restaure mes bases très régulièrement je n'ai jamais été confronté à cela
loic

manque de pratique !!!!! Dans des cas limites...

A +

[lmerian]

bonjour
merci beaucoup de votre aide
effectivement en décochant les deux options ça fonctionne ... ouf ... pourquoi ce comportement différent, c'est sans doute à cause du mode RECOVERY
par contre je confirme, mais j'ose à peine tellement ma connaissance de SQL doit être infinitésimale par rapport à la votre, que dans SQL MANAGER, si je fais restaurer une base, je prends une sauvegarde de cette base appelons la BASE
et que je mets simplement dans restaurer un nom différent comme BASE_2, ça me crée une nouvelle base qui s'appelle BASE_2, avec de nouveaux fichiers nommés base_2 ldf et mdf et qui sont le backup de la base d'origine
je n'ai jamais besoin d'indiquer un nouveau nom de fichier, ça se fait tout seul et tout cela va dans le dossier DATA de MSSQL
mais je ne fais pas cela avec une commande mais avec le manager
loic

[SQLpro]

bonjour
merci beaucoup de votre aide
effectivement en décochant les deux options ça fonctionne ... ouf ... pourquoi ce comportement différent, c'est sans doute à cause du mode RECOVERY

Non, rien avoir avec le mode de journalisation. C'est juste l'IHM SSMS qui a été modifiée... Comme vous avez choisit de faire une restauration à partir d'une base existante, l'interface a rajouté ces coches pour protéger la base existante d'une fausse manœuvre. En donnant un autre nom à votre base, cela n'a pas décoché ces cases....

par contre je confirme, mais j'ose à peine tellement ma connaissance de SQL doit être infinitésimale par rapport à la votre, que dans SQL MANAGER, si je fais restaurer une base, je prends une sauvegarde de cette base appelons la BASE
et que je mets simplement dans restaurer un nom différent comme BASE_2, ça me crée une nouvelle base qui s'appelle BASE_2, avec de nouveaux fichiers nommés base_2 ldf et mdf et qui sont le backup de la base d'origine
je n'ai jamais besoin d'indiquer un nouveau nom de fichier, ça se fait tout seul et tout cela va dans le dossier DATA de MSSQL
mais je ne fais pas cela avec une commande mais avec le manager
loic

PAS NON PLUS.... je ne sais pas quelle manœuvre vous faites, mais la démo est simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
CREATE DATABASE toto
GO

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
BACKUP DATABASE toto TO DISK = 'toto.bak';
GO
/*
384 pages traitées pour la base de données 'toto', fichier 'toto' dans le fichier 1.
2 pages traitées pour la base de données 'toto', fichier 'toto_log' dans le fichier 1.
BACKUP DATABASE a traité avec succès 386 pages en 0.123*secondes (24.485*Mo/s).
*/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
RESTORE DATABASE toto_2 FROM DISK = 'toto.bak';
 
/*
Msg*1834, Niveau*16, État*1, Ligne*12
Impossible de remplacer le fichier 'H:\DATABASE_SQL\SQL2019FBIN2\DATA\toto.mdf' car il est utilisé par la base de données 'toto'.
Msg*3156, Niveau*16, État*4, Ligne*12
Impossible de restaurer le fichier 'toto' en 'H:\DATABASE_SQL\SQL2019FBIN2\DATA\toto.mdf'. Pour identifier un emplacement valide pour le fichier, faites appel à WITH MOVE.
Msg*1834, Niveau*16, État*1, Ligne*12
Impossible de remplacer le fichier 'H:\DATABASE_SQL\SQL2019FBIN2\TRAN\toto_log.ldf' car il est utilisé par la base de données 'toto'.
Msg*3156, Niveau*16, État*4, Ligne*12
Impossible de restaurer le fichier 'toto_log' en 'H:\DATABASE_SQL\SQL2019FBIN2\TRAN\toto_log.ldf'. Pour identifier un emplacement valide pour le fichier, faites appel à WITH MOVE.
Msg*3119, Niveau*16, État*1, Ligne*12
Des problèmes ont été identifiés lors de la planification de l'instruction RESTORE. Consultez les messages précédents pour plus de détails.
Msg*3013, Niveau*16, État*1, Ligne*12
RESTORE DATABASE s'est terminé anormalement.
*/

CQFD...

A +