Misoperation data recovery without backup in SQL Server 2008 (2)

Misoperation data recovery without backup in SQL Server 2008.
Solution:
The method mentioned in this article - log tail backup.
Steps:
(1). Check the recovery mode of the database, as shown in the figure:


or use the script to check:

SELECT recovery_model,recovery_model_desc
FROM sys.databases
WHERE name ='AdventureWorks'

The result is as follows:

Ensure that the recovery model of the database cannot at least be [simple].

Remember, for any important environment, not only the customer's official environment (commonly known as the production environment), it is strongly recommended to use [full recovery mode], although for the other two (large-capacity log (BULK_LOGGED), simple (SIMPLE)), The log generated by the full recovery model will be large, but when a problem occurs, it will feel that these are nothing.

(2) Another step is actually implied here, and a full backup has been done at least once. Because all types of backups are based on full backups, without at least one full backup, other types of backups are redundant. After creating a new database, it is highly recommended and even mandatory to do a full backup.

SELECT  database_name,recovery_model,name 
FROM msdb.dbo.backupset

Using the above statement, you can roughly see which databases have been backed up. Due to the test, I have made several backups. You can see that I have made backups at this point in time.

(3) Make sure that no one else connects to the database, and then do a log tail backup:
first create a little data:

/*
这里使用微软的示例数据库AdventureWorks
*/
USE AdventureWorks
GO
IF OBJECT_ID('testRestore') IS NOT NULL 
    DROP TABLE testRestore
GO
CREATE TABLE testRestore
    (
      id INT IDENTITY(1, 1) ,
      NAME VARCHAR(50)
    );
--插入测试数据：   
INSERT INTO testRestore(Name)
SELECT 'test1'
UNION ALL 
SELECT 'test2'
UNION ALL 
SELECT 'test3'
UNION ALL 
SELECT 'test4'
UNION ALL 
SELECT 'test5'
UNION ALL 
SELECT 'test6'
UNION ALL 
SELECT 'test7'
UNION ALL 
SELECT 'test8'
SELECT * FROM testRestore

Check the result:

Then do a delete operation. In order to locate when it happened, add a waitfor command to make it happen at a certain time, so that there will be accuracy when restoring:

USE AdventureWorks
GO
WAITFOR TIME '21:45'
DELETE FROM dbo.testRestore

Now look at the data:

USE AdventureWorks
GO
SELECT * FROM dbo.testRestore

At this point, disaster strikes. But remember to stay calm.
The following is the key point of this article. To do a log backup, the most important thing is to select [Backup Log Tail]

and then select on the [Options] page: Except for [Transaction Log], the places wrapped in red boxes are strongly recommended to be checked. And ensure that no one else is connected to the database, because the tail of the backup log will make the database in a restored state, rejecting the connection of other sessions, if you do not disconnect other connections, it will not be backed up.

Then press OK, of course, you can use the above [script] to generate statements:

USE Master
GO
BACKUP LOG [AdventureWorks] TO  DISK = N'E:\AdventureWorks.bak' WITH  NO_TRUNCATE , NOFORMAT, NOINIT,  NAME = N'AdventureWorks-事务日志 备份', SKIP, NOREWIND, NOUNLOAD,  NORECOVERY , COMPRESSION,  STATS = 10, CHECKSUM
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'AdventureWorks' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'AdventureWorks' )
if @backupSetId is null begin raiserror(N'验证失败。找不到数据库“AdventureWorks”的备份信息。', 16, 1) end
RESTORE VERIFYONLY FROM  DISK = N'E:\AdventureWorks.bak' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO

At this time, the database will be in the state of [restored]

If you find that the backup cannot be performed, you can use the following statement to check and kill the spid:

SELECT  * FROM sys.sysprocesses WHERE dbid=DB_ID('AdventureWorks')

Execution result:

Then kill it.
Then continue with the backup.
Then restore, as shown in the figure:
first restore the full backup, select the most recent one, because of the characteristics of log backup (to be discussed in other articles later), only the last backup is recognized, so you must select the latest one, otherwise it will not be restored.

Here is another note, remember to choose:

then restore the log file, this is the most important step:

then:

because something went wrong during the experiment, it was redone later, so the time selection is at 22:19, which is at 22:20 to delete the data. Don't worry too much here, just specify the time point before the time you deleted by mistake. Since the backup at the end of the log is the last backup file, just select the part in the red box here:

Now check again:

you can see that the data has been restored successfully.