[SQL Server 2005] base en mode Restauration

Version imprimable

Bonsoir à tous,

J'espère que vous allez bien.

Voilà j'ai malentreusement effectué un drop table sur une base, je me suis donc dit pas de souci je vais faire un restore à partir des logs. Alors j'ai fait un backup complet de la base puis un bakup du fichier de log et ensuite j'ai joué cette instruction SQL pour restaurer ma base :
Code:

1 2 3 4 5 6 7 8 9 10 11 ALTER DATABASE [PROD2] SET SINGLE_USER WITH NO_WAIT RESTORE DATABASE [PROD2] FROM DISK = N'E:\PROD2\PROD2.bak' WITH FILE = 1, RECOVERY, NOUNLOAD, REPLACE, STATS = 10 GO RESTORE LOG [PROD2] FROM DISK = N'E:\PROD2\PROD2.trn' WITH STOPAT = N'2011/11/05 15:30:45 PM', RECOVERY--WITH FILE = 1, NOUNLOAD, STATS = 10 GO ALTER DATABASE [PROD2] SET MULTI_USER WITH NO_WAIT
Ma bétise s'est produite après 15:30.
Lorsque cette instruction se termine ma base se met en mode Restauration, j'ai déjà effectué ce genre de manip à deux reprises auparavant et tout avait bien fonctionné.

Qu'ai-je manqué ce coup ci ?
Comment remettre ma base en ligne sans mon erreur ?

Merci pour votre aide

Votre script n'est pas bon. Dans la première phase vous effectuez une restauration complète en mode WITH RECOVERY. Il faut le faire en WITH NO RECOVERY pour pouvoir ensuite restaurer la partie du journal qui vous intéresse.
Code:

1 2 3 4 5 6 7 8 9 10 11 ... RESTORE DATABASE [PROD2] FROM DISK = N'E:\PROD2\PROD2.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10 GO RESTORE LOG [PROD2] FROM DISK = N'E:\PROD2\PROD2.trn' WITH STOPAT = N'2011/11/05 15:30:45 PM', RECOVERY--WITH FILE = 1, NOUNLOAD, STATS = 10 GO ...
++

12/05/2011, 09h24
Herlece

Bonjour,

Merci mikedavem, mais j'avais déjà essayé avec NORECOVERY, et le résultat est le même.

Je ne vois toujours pas pourquoi ma base est en mode récupération.

Aurais-tu une autre piste ?
12/05/2011, 09h51
mikedavem

Que donne la commande suivante après restauration des sauvegardes :

Code:

RESTORE DATABASE <maBase> WITH RECOVERY;

++
12/05/2011, 11h08
Herlece

Merci encore une fois,

Code:

RESTORE DATABASE <maBase> WITH RECOVERY;

met ma base en ligne. En revanche je vois que ma table n'est pas la. Pourtant je suis certain de mon heure quand j'ai fais le drop. J'ai essayé une autre heure et le souci est le même je ne vois toujours pas ma table.

Aurais-tu une idée sur ce point si ce n'est pas abusé de ma part ?
12/05/2011, 11h46
mikedavem

Est ce qu'avec la sauvegarde complète seulement vous retrouvez votre table ?

++
12/05/2011, 12h02
SQLpro

Utilisez un outil comme le log explorer que Apex pour voir ou est la table dans les JT.

A +
12/05/2011, 12h24
elsuket

Bonjour,

N'est-il pas possible de le trouver dans fn_dblog (Colonne AllocUnitName) ?

@++ ;)
12/05/2011, 12h37
Herlece

non je ne la retrouve pas avec ma sauvegarde complète. Mais ma sauvegarde complète a été faite après le drop de la table, car je n'avais pas de sauvegarde récente en fait.
MAis une fois j'avais eu le même souci et j'avais réussi avec cette façon, mais je n'avais pas fait de drop table, juste un delete.

Merci de ton aide encore.
12/05/2011, 13h45
mikedavem

Si vous avez fait votre sauvegarde après le DROP TABLE il n'est normal de ne pas la retrouvez.

Si vous voulez retrouver votre table il va falloir partir d'une sauvegarde antérieure à ce DROP plus les journaux nécessaires (si vous en avez)

++
12/05/2011, 14h14
Herlece

Citation:

Si vous avez fait votre sauvegarde après le DROP TABLE il n'est normal de ne pas la retrouvez.

je pensai justement que les logs étaient la pour ça ?

Citation:

Si vous voulez retrouver votre table il va falloir partir d'une sauvegarde antérieure à ce DROP plus les journaux nécessaires (si vous en avez)

Non je n'ai aucun des deux.

Donc conclusion il n'y aurai aucun moyen de retrouver ma table ? Pourtant lorsque j'avais effectué un delete sur l'ensemble de mes tables j'ai pu tout retrouver avec les logs. Alors que je n'avais pas de sauvegarde récente; j'avais fais la même manipulation.

Dans le cas d'un drop ce n'est pas le même mécanisme ?
12/05/2011, 14h40
mikedavem
Votre point de référence ici est la sauvegarde complète de votre base.
Celle-ci ne contient pas votre table puisqu'elle a été supprimée antérieurement à votre sauvegarde. Les sauvegardes de journaux que vous appliquez rejouent les transactions à partir de votre sauvegarde complète. Celles-ci ne peuvent donc pas retrouver votre table comme par miracle ...
Code:

1 2 1---------------- 2----------------------------3----------- Suppression table Backup FULL Backup LOG
Quand vous restaurez vous repartez du point 2 ... à ce moment là votre sauvegarde ne contient plus la table que vous avez supprimé

Il faudrait avoir le scénario suivant :
Code:

1 2 1---------------T------2------------------------3----------- Backup FULL DROP TABLE BACKUP LOG
Dans ce cas vous pourrez sans aucun problème revenir à T en rejouant votre sauvegarde complète + sauvegarde du journal avec STOPAT = T

++
12/05/2011, 14h59
Herlece

Merci mikedavem pour cette explication.

Néanmoins il reste quand même une zone d'ombre dans ma tête. Lorsque je fais un delete de ma table comme ceci

Citation:

1-----------------------2------------3---------------
delete enregistrements--->backup full--->Restore logs

Mon restore à partir des logs part bien du point 2 donc postérieur à la suppression de mes enregistrements. Dans ce cas, je viens de tester, je retrouve les enregistrements. Pourquoi ? Vous pourriez me dire de lire les articles à ce sujet mais je l'ai fait et j'ai toujours cette zone d'ombre.

Je vois pas comment vous arrivez à ce résultat.

Voici ce que j'obtiens avec le script suivant en suivant votre démarche :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
CREATE DATABASE TEST;
GO
 
USE TEST;
GO
 
CREATE TABLE TEST
(
 texte VARCHAR(50)
);
GO
 
-- insert 2 lignes de données
INSERT TEST VALUES ('texte1');
INSERT TEST VALUES ('texte2');
 
-- Suppression une ligne de données
DELETE FROM TEST WHERE texte = 'texte1';
GO
 
-- Backup full après suppression 
BACKUP DATABASE test TO DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\test.bak'
WITH INIT;
GO
-- Backup log qui se base sur le backup full
BACKUP LOG test TO DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\test.trn'
WITH INIT;
GO
 
-- On restaure la base avec le backup full + log
USE master;
 
RESTORE DATABASE TEST FROM DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\test.bak'
WITH REPLACE, NORECOVERY;
GO
 
RESTORE LOG TEST FROM DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\test.trn'
WITH REPLACE, RECOVERY;
GO
 
-- On vérifie si on récupère toutes les données
USE TEST;
 
SELECT *
FROM TEST;

12/05/2011, 21h13
Herlece

Tel que vous faites le restaure de la base de données en effet on ne récupère pas la ligne supprimée. Mais si vous utilisez l'instruction STOPAT tel que le l'ai fait dans la commande sql que j'ai écrite au début on arrive à récupérer la ligne supprimée.

Je met le STOPAT avant l'heure supposée de la suppression. Je le fais avec SSMS, mais je suppose que c'est la même intruction qui est jouée.
12/05/2011, 21h20
mikedavem

Citation:

Je met le STOPAT avant l'heure supposée de la suppression. Je le fais avec SSMS, mais je suppose que c'est la même intruction qui est jouée.

Justement comment pouvez vous faire un STOPAT sur une date qui est antérieure à celle de votre BACKUP FULL qui de surcroît s'est exécuté après votre suppression ? Vous êtes en train de me dire que vous remontez des transactions qui n'existeraient même pas dans vos sauvegardes de journaux effectuées après la sauvegarde FULL..

++