淺析SQL Server數據庫在項目中的備份與還原
筆者根據近一段時間所學的數據庫知識編寫了這篇關于SQL Server如何在項目中實現備份與還原的文章,與大家相互探討、學習。
--備份的設備有2種(臨時設備和***設備) 注意:默認下的備份類型是完整備份
--***種:
- backup database Company to disk='d:\backup\1.bak'
--臨時設備
/*如果這里不指定明確路徑的話(如:backup database company to disk='backup\1.bak'),那么備份的數據庫將會自動備份到系統指定的目錄下:
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup*/
--第二種:
/****步首先建立***備份設備 (系統自帶的存儲過程)在master 數據庫中就會找到如圖1:
*/
--執行語句如:
- exec sp_addumpdevice 'disk','disk_company','D:\2.bak'
--***設備
--執行結果就會出現如圖2:
--多了一個備份設備:disk_company
--第二步:
- backup database company to disk_company with noinit
--默認表示追加(不覆蓋)
--好了 備份完成 !
--現在我來還原數據庫(我用的是***種方法備份的,所以我要***種方法來還原) 。
--原來的數據如圖3:
--經過我手動刪除幾個表后的數據庫如圖4:
--執行語句:
- restore database Company from disk='d:\backup\1.bak'
--注意備份到哪里去就要從還原哪里來
--執行后會出現什么呢?請看錯誤消息:
- /*消息 3159,級別 16,狀態 1,第 1 行
- 尚未備份數據庫 "company" 的日志尾部。如果該日志包含您不希望丟失的工作,請使用 BACKUP LOG WITH NORECOVERY 備份該日志。
- 請使用 RESTORE 語句的 WITH REPLACE 或 WITH STOPAT 子句來只覆蓋該日志的內容。
- 消息 3013,級別 16,狀態 1,第 1 行
- RESTORE DATABASE 正在異常終止。*/
--為什么會出現這種錯誤呢 我們可以從錯誤的消息中找到解決方案!
--我們去看看這個數據庫的恢復模式如圖5:
--因為如圖的恢復模式是 :完整; 所以它的功能是將所有事務都寫入日志,把所有數據庫文件的都還原
--方案一:我現在只是還原的數據庫文件 并沒有備份日志文件 所以我再去備份日志文件
- backup log Company to disk='d:\backup\2.bak'
--備份日志文件
- restore database Company from disk='d:\backup\1.bak'
--再去還原數據庫
- restore log Company from disk='d:\backup\2.bak'
--這步可有可無
--執行的結果為:如圖6:
--方案二 由于錯誤消息中的提示:請使用 RESTORE 語句的 WITH REPLACE 或 WITH STOPAT 子句來只覆蓋該日志的內容。
---消息 3013,級別 16,狀態 1,第 1 行 所以 我想到去覆蓋掉日志文件 雖然恢復模式是完整的 但是我要覆蓋它 也是可以的
--只是對數據庫的操作沒有日志沒有完全還原而已 也是可以的
--執行語句如下:
- restore database Company from disk='d:\backup\1.bak' WITH REPLACE
--執行成功
- /*已為數據庫 'Company',文件 'Company_Data' (位于文件 1 上)處理了 224 頁。
- 已為數據庫 'Company',文件 'Company_Log' (位于文件 1 上)處理了 5 頁。
- RESTORE DATABASE 成功處理了 229 頁,花費 0.225 秒(8.319 MB/秒)。*/
--方案三:我想了一下 我只是備份了數據庫,但是沒有備份日志文件 根據備份還原的原理
- /*
- 恢復模式 說明
- 簡單 不用備份的事務日志,即可還原
- 用于小型數據庫和不經常更改的數據庫
- 完整 所有事務都被記錄到日志中
- 保留所有日志,直到事務日志備份
- 用于生產數據庫
- 大容量日志 完整恢復模式的補充
- 不將大容量日志操作寫入日志
- */
--所以我修改了這個數據庫的屬性中的恢復模式 改為 “簡單”
--如圖7:
--我直接執行還原的代碼
- restore database Company from disk='d:\backup\1.bak'
- /*執行結果:
- 已為數據庫 'Company',文件 'Company_Data' (位于文件 1 上)處理了 224 頁。
- 已為數據庫 'Company',文件 'Company_Log' (位于文件 1 上)處理了 5 頁。
- RESTORE DATABASE 成功處理了 229 頁,花費 0.224 秒(8.356 MB/秒)。*/
--三種還原的解決方案成功
--但是這用到項目中數據庫正在使用的話是不成功的 ,它具有排它性 !
--所以我寫了一個存儲過程來解決,這也是很多程序員花了很久才解決的問題
--代碼用法如下 :有附帶的例子下載
--創建存儲過程 killspid
- create proc killspid (@dbname varchar(20))
- as
- begin
- declare @sql nvarchar(500)
- declare @spid int
- set @sql='declare getspid cursor for
- select spid from sysprocesses where dbid=db_id('''+@dbname+''')'
- exec (@sql)
- open getspid
- fetch next from getspid into @spid
- while @@fetch_status < >-1
- begin
- exec('kill '+@spid)
- fetch next from getspid into @spid
- end
- close getspid
- deallocate getspid
- end
- GO
--說明:
--1.此存儲過程應寫在Master中;
--2.以上代碼就是解決因為數據庫正在使用,所以未能獲得對數據庫的排它訪問權的問題,不然系統有時會報錯;
我附帶一個簡單的備份還原的例子 (ASP.NET +SQL SERVER 2005 的運行環境)
http://files.cnblogs.com/qinpengming/BackUpDBSolution.rar
有時間我會寫一篇關于怎樣還原到指定時間點的例子 我會采用完整備份 差異備份 日志備份 我也會把原數據庫文件也損壞掉 再去還原的! !!!!!!!!!!
原文出處:http://www.cnblogs.com/qinpengming/archive/2011/03/07/struggle.html
【編輯推薦】
- 淺析SQL Server 2008中的代碼安全之一:存儲過程加密與安全上下文
- 淺析SQL Server 2008中的代碼安全之二:DDL觸發器與登錄觸發器
- 淺析SQL Server 2008中的代碼安全之三:通過PassPhrase加密
- SQL Server安全解析
- sql server安全的兩層模型