Discussion :

[Herlece]

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 :

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

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

[mikedavem]

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 :

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

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

...

++

[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 ?

[mikedavem]

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

Code :

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

RESTORE DATABASE <maBase> WITH RECOVERY;

++

[Herlece]

Merci encore une fois,

Code :

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

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 ?

[mikedavem]

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

++

[SQLpro]

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

A +

[elsuket]

Bonjour,

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

@++

[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.

[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)

++

[Herlece]

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 ?

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 ?

[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 :

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

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 :

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

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

++

[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

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.

[mikedavem]

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

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

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
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;

++

[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.

[mikedavem]

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..

++