程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> MSSQL2008 >> SQL Server 2008及更高版本數據庫恢復辦法之日記尾部備份

SQL Server 2008及更高版本數據庫恢復辦法之日記尾部備份

編輯：MSSQL2008

SQL Server 2008及更高版本數據庫恢復辦法之日記尾部備份。本站提示廣大學習愛好者：（SQL Server 2008及更高版本數據庫恢復辦法之日記尾部備份）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server 2008及更高版本數據庫恢復辦法之日記尾部備份正文

常常看到有人誤刪數據，或許誤操作，特殊是update和delete的時刻沒有加where，然後就喊爹喊娘了。人非聖賢孰能無過，做錯可以懂得，但不克不及縱容，這個今後再說，如今先來處理成績。

碰到這類情形，普通都是沒有做備份，否則也不會來提問了。起首要沉著，不然會有更年夜的災害。直到你廢棄。

處理辦法：

關於這類成績，重要是找回誤操作之前的數據，在2008之前，有個很知名的對象Log Exploer，據說還挺好用的，這個網上年夜把教程，這裡就不多說了。然則獨一遺憾的是，不支撐2008及更高版本，這時候除其他第三方對象，那末最經常使用的就是本文提到的辦法——日記尾部備份。本文試驗情況2008R2，關於2008及其以上版本可使用這個辦法，其實2005也能夠，2000很罕用，沒試過，只是2008之前可使用Log Exploer，所以就沒需要用這類辦法。

上面圖文並茂講授操作辦法，至於道理，不屬於本文規模，並且我信任真碰到誤操作的時刻，估量沒人會看道理了。

步調：

（1）、檢討數據庫的恢復形式，如圖：

或許應用劇本檢討：

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

成果以下：

確保數據庫的恢復形式最最少不克不及為【簡略】。至於若何修正成完全形式，我認為這些應當沒需要多說了。

切記，關於任何主要情況，不只僅是客戶正式情況（俗稱臨盆情況），都激烈建議應用【完全恢復形式】，固然關於別的兩種（年夜容量日記（BULK_LOGGED）、簡略（SIMPLE））來講，完全恢復形式發生的日記會年夜，然則在湧現成績的時刻，就會認為這些都不算甚麼了。而且我也想不就任何來由關於正式情況不應用完全恢復形式。只需治理適合，完全恢復形式的日記也不會太失常。

（2）、這裡其實隱含別的一步，已經做過起碼一次的完全備份。由於一切類型的備份都基於完全備份，假如沒有起碼一次完全備份，其他類型的備份都是過剩的，所以在這裡強調一下，在創立完一個新數據庫以後，激烈建議乃至強迫做一次完全備份。

SELECT database_name,recovery_model,name 
FROM ms

應用下面的語句粗略可以看到有那些數據庫做過備份，因為測試，所以做了幾回備份，可以看到我這個時光點曾經做了備份了。

（3）、確保他人不再銜接數據庫，然後做一第二天志尾部備份：

起首先創立一點數據：

因為tempdb永久為簡略恢復形式，所以不合適做案例。
這裡應用微軟的示例數據庫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

檢討一下成果：

然後來做個刪除操作，為了定位是啥時刻產生的，我加了一個waitfor敕令，讓它在某個時光產生，如許恢復的時刻就有精確性：

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

如今來看看數據：

USE AdventureWorks 
GO 
SELECT * FROM dbo.testRestore

到這一步，災害湧現了，然則切紀要沉著。

上面就是本文的重點開端，做一第二天志備份，最主要是選擇【備份日記尾部】

然後在【選項】頁選擇：除【事務日記】除，其他紅框包裹的處所為激烈建議勾選的處所。而且包管數據庫不要有他人在銜接，由於備份日記尾部會使數據庫處於復原狀況，謝絕其他會話的銜接，假如赓續開其他銜接，是備份不了的。

然後按肯定，固然，可使用上方的【劇本】來生成語句：

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

此時，數據庫會處於【正在復原】的狀況