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