程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> 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 


此時,數據庫會處於【正在復原】的形態



假如發現備份不了可以用上面語句檢查,並把spid殺掉:

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

執行後果:


然後kill掉。

接著持續備份。

 然後停止復原,如圖:

先要復原完好備份,選擇最近的那次,由於日志備份的特性(當前其他文章再說),只認最後一次備份,所以要選擇最新的那次,否則復原不了。


這裡又有一個留意事項,記得選擇:


接著復原日志文件,這是最最重要的一步:


然後:


由於實驗的時分出了點問題,前面重做了,所以時間選擇到22:19分,我是在22:20分刪除數據的。這裡不必太在意,只需把時間點指定到你誤刪除的時間之前即可。而由於日志尾部備份都是最後一個備份文件,所以這裡選則紅框局部即可:


如今再反省一下:


可以看到,數據曾經復原成功。

總結:

平常不做備份,出問題來喊急,這是苟有自取,還有一些腦袋發熱的人喜歡看到ldf很大就直接刪除,那當前出問題就別怪微軟了。

本文中的辦法看上去有點繁瑣,但是實操幾次就覺得好了,但是步驟建議嚴厲依照下面說的,由於一旦操作錯誤,就很費事,此時再次強調——冷靜冷靜再冷靜!!!!!!

這種辦法有幾個缺陷:

1、假如你發現誤操作當前還有很多人做了操作,那麼你復原成功後,他人的操作就會沖掉,所以發作誤操作後,要馬上中止他人對數據庫的操作。

2、 這個辦法要對數據庫獨占,所以你想偷偷恢復是不行的了。英勇供認錯誤吧。

關於中心數據表,還是要先做好預防操作,可以看:SQLServer恢復表級數據。

以上就是本文的全部內容,希望對大家的學習有所協助。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved