主頁 > 知識庫 > SQL Server 數(shù)據(jù)庫的備份詳細介紹及注意事項

SQL Server 數(shù)據(jù)庫的備份詳細介紹及注意事項

熱門標簽:AI電銷 地方門戶網(wǎng)站 鐵路電話系統(tǒng) 呼叫中心市場需求 網(wǎng)站排名優(yōu)化 百度競價排名 Linux服務(wù)器 服務(wù)外包

SQL Server 備份

前言

為什么要備份?理由很簡單——為了還原/恢復(fù)。當然,如果不備份,還可以通過磁盤恢復(fù)來找回丟失的文件,不過SQL Server很生氣,后果很嚴重。到時候你就知道為什么先叫你備份一次再開始看文章了?!蒧_∩。本系列將介紹SQL Server所有可用的備份還原功能,并盡可能用實例說話。

什么是備份?SQL Server基于Windows,以文件形式存放資料,所以備份就是Windows上SQL Server相關(guān)文件的一個某個時間點的副本。根據(jù)備份類型的不同,副本的種類和內(nèi)容也有不同。

備份類型有哪些?SQL Server 目前版本中,可用的備份類型有:完整數(shù)據(jù)庫備份、差異數(shù)據(jù)庫備份、事務(wù)日志備份(后稱日志備份)、文件和文件組備份、部分備份,根據(jù)SQL Server版本不同,有些備份類型不支持,另外根據(jù)恢復(fù)模式的不同,某些備份類型也不支持。

什么是恢復(fù)模式?

很多人只把關(guān)注點放在備份上面,而沒有在意恢復(fù)模式,其實所有的備份都應(yīng)該從恢復(fù)模式作為切入點?;謴?fù)模式實際上是一個控制備份還原的行為的數(shù)據(jù)庫級別選項。SQL Server 在當前所有發(fā)布版本中只有三種恢復(fù)模式:簡單恢復(fù)模式(后面簡稱簡單模式),大容量日志恢復(fù)模式(后面簡稱大容量模式),完整恢復(fù)模式(后稱完整模式)。

本文從恢復(fù)模式開始,提醒一下,絕大部分的專業(yè)屬于都會陸續(xù)解釋,如果讀者有不明白,可以繼續(xù)往下看或者上網(wǎng)搜索:

1.簡單模式,Simple recovery model:某些操作可以被最小日志化。這種模式下,不支持日志備份、時間點恢復(fù)和頁恢復(fù)。且文件恢復(fù)功能僅限于次要數(shù)據(jù)文件中的只讀文件。

2.大容量日志模式,Bulk-logged recovery model:和完整模式類似,有時候可以理解為完整模式于簡單模式的過渡模式。這種模式對某些大容量操作進行最小日志化,支持完整備份中的備份還原策略,但是由于某些操作被最小日志化,所以不能保證時間點恢復(fù)。

3.完整模式,F(xiàn)ull recovery model: 在這個模式下,所以操作都被完整記錄下來,并且支持所有類型的備份還原策略。

默認情況下,新庫會繼承Model庫的配置,包括恢復(fù)模式,也就是FULL模式。可以在創(chuàng)建或日常使用過程中修改,并且不需要重啟服務(wù)?;謴?fù)模式最重要的區(qū)別在于對待日志的行為

簡單模式:

是三種模式中最容易管理的,可以進行完整,差異和文件備份,但是不能做日志備份。在這種模式下,每當Checkpoint 進程發(fā)生時,會自動把日志文件中不活動的日志(在日志備份一文介紹)寫入數(shù)據(jù)文件,寫入后,對應(yīng)的日志文件中的空間就可供新事務(wù)使用,注意這種空間重用或者截斷并不自動減少日志文件的物理大小,如果需要減少空間,需要使用DBCC SHRINKFILE/DATABASE等命令實現(xiàn)。讓日志空間重用的過程叫做截斷。在簡單模式下這個過程稱為自動截斷(auto-truncate)。在這種模式下,日志通常不需要管理,但是對于單個的大事務(wù),日志文件可能會增長得很快,這種情況下最好把批處理降為小的批。簡單模式最主要的限制是不能進行日志備份,也就是說無法進行時間點還原。在一些測試,開發(fā)或者SLA要求不嚴格的環(huán)境下,可以使用這種模式。

完整模式:

這種模式下,所有數(shù)據(jù)庫操作都被完整地記錄在日志中,2008出現(xiàn)某些操作在這種模式下也還是最小化日志。并且不是自動截斷。它支持任何備份還原策略,特別是時間點還原,在日志還原一章介紹。即使發(fā)生Checkpoint ,不活動的事務(wù)也不會截斷到數(shù)據(jù)文件中。唯一能控制日志文件的只有日志備份,所以這種模式下日志備份極其重要,一方面提供時間點還原,另外一方面控制日志文件大小。

日志文件會完整保存自上一次日志備份后的事務(wù)。使用copy_only或者no_truncate選項均不會截斷日志。

大容量日志:

這種模式是最少用到的,某些操作會被最小日志化,包含:

  • 使用bcp進行導(dǎo)入
  • bulk
  • insertinsert
  • select *from openrowset(bulk )
  • select into
  • 使用writetext/updatetext插入或附加數(shù)據(jù)
  • 重建索引

在這種模式下,會用bitmap image記錄發(fā)生最小日志化的區(qū)。如果數(shù)據(jù)庫故障導(dǎo)致數(shù)據(jù)文件不了用,并且日志尾部包含最小化日志,不能做日志尾部備份,因為這個操作需要訪問數(shù)據(jù)文件中數(shù)據(jù)修改后的區(qū)。這種模式適用于大容量操作,但是如果事務(wù)包含最小化日志,則不能進行時間點還原,只能還原到之前。

恢復(fù)模式擴展說明:

如上所說,恢復(fù)模式是數(shù)據(jù)庫級別的配置項,在創(chuàng)建過程中及后續(xù)使用中均可修改,但是由于種種原因,盡量在規(guī)劃階段就做好配置,并且在創(chuàng)建過程中明確指定。

這個選項主要用于決定數(shù)據(jù)庫是否可以(或者需要)做日志備份?什么事務(wù)需要被記錄?還有是否可以做其他類型的備份還原操作等。

簡單模式:

某些操作能被最小化日志,這里要說明一下,很多人以為簡單模式下“不記錄日志”,其實這是很嚴重的誤解,會導(dǎo)致后續(xù)使用的很多問題,無論任何恢復(fù)模式,都會記錄日志,只是記錄的形式和內(nèi)容不同。在簡單模式下,日志備份選項被禁用,帶來的影響是不支持時間點還原、頁還原,而文件還原功能僅限于READONLY文件組中的次要數(shù)據(jù)文件。

簡單模式是最容易管理的恢復(fù)模式,在這種模式下,可以進行完整數(shù)據(jù)庫備份、差異數(shù)據(jù)庫備份和文件備份,但是不能進行日志備份。在日志備份一文會詳細介紹,但是在這里要提一下,關(guān)于日志空間重用的問題,不管任何恢復(fù)模式,都會有一個系統(tǒng)進程在后臺運行——CHECKPOINT,每當這個進程啟動時,會把數(shù)據(jù)庫的日志文件(通常就是LDF文件)中,非活動的事務(wù)寫入數(shù)據(jù)文件,然后把這部分的空間標識為“可重用”,這個步驟稱為日志截斷,在簡單模式下稱為自動截斷(auto-truncate),記住可重用不代表空間被清空,唯一可以清空LDF文件物理大小的操作是收縮數(shù)據(jù)庫/文件操作。簡單模式會自動執(zhí)行這個截斷操作,截斷后,日志空間可被新事物重新使用,從宏觀變現(xiàn)來說,就是LDF文件的物理大小不增加,或者增加緩慢,其實當使用簡單模式,并且LDF合適的情況下,如果LDF物理大小還在增長,可能就需要引起注意。

由于日志的自動截斷,導(dǎo)致簡單模式下無法進行時間點恢復(fù),也無法進行日志備份。但是對于對數(shù)據(jù)要求不高的系統(tǒng),或者SLA(在還原基礎(chǔ)一文中介紹)沒有什么特殊要求的環(huán)境,可以使用這種模式,可以最大限度減少對日志的管理。但是不是意味著使用了這種模式,就不用管理日志了,對于一些大規(guī)模、長時間運行的批處理,會引起大量的活動事務(wù),此時LDF文件依舊會迅速增長,引起一些潛在的問題。對此,盡可能把批處理拆分為多個、短事務(wù)。

簡單來說,這種模式的優(yōu)缺點:

優(yōu)點:

易于管理,大部分情況下不需要

缺點:

  • 不能進行事務(wù)日志備份,無法時間點還原
  • 數(shù)據(jù)丟失的風險增大

選擇依據(jù):根據(jù)業(yè)務(wù)需要選擇,對于非常重要的數(shù)據(jù)庫,無論當前數(shù)據(jù)庫大小,都不要使用這種模式,詳細內(nèi)容參考還原基礎(chǔ)中SLA的內(nèi)容。

完整模式:

完整模式很多概念都是相對于簡單模式來說的,這種模式下,所有操作被完整地記錄在事務(wù)日志文件中,并且不會發(fā)生自動截斷(除了數(shù)據(jù)庫完全沒做過最少一次完整備份),事務(wù)日志只有在事務(wù)日志備份發(fā)生時,才會截斷到數(shù)據(jù)文件,并且使對應(yīng)部分可用。這種模式能夠執(zhí)行所有類型的備份還原選項,特別是可以進行時間點恢復(fù),保證數(shù)據(jù)接近0丟失。這是幾乎所有正式環(huán)境(也稱生產(chǎn)環(huán)境)使用的恢復(fù)模式。

優(yōu)點:

  • 能夠完整記錄數(shù)據(jù)庫操作
  • 進行時間點恢復(fù),保證數(shù)據(jù)盡可能0丟失

缺點:

  • 需要嚴格管理事務(wù)日志文件
  • 數(shù)據(jù)庫規(guī)??赡軙兊秒y以控制

大容量日志模式:

這是用的最少的恢復(fù)模式,讀者不要給名字忽悠了,見過很多人在進行大容量操作時切換到這種模式,然后操作完再切換回來,這種操作其實比較危險。不建議使用。另外,它支持日志備份,能進行一定程度的時間點恢復(fù)。除了前面提到的可最小化日志的操作,其日常使用和管理與完整模式無疑??梢岳斫鉃槭峭暾J胶秃唵文J降倪^渡。

缺點:

如果數(shù)據(jù)文件突然變得不可用,并且日志尾部包含了大容量日志模式下進行的最小化日志操作,那么不可能進行日志尾部備份,因為這種備份要求訪問數(shù)據(jù)修改所發(fā)生的區(qū),而這個區(qū)在最小化日志操作中僅記錄“發(fā)生了操作”,而沒有完整地記錄操作內(nèi)容。導(dǎo)致無法進行時間點還原,存在一定的數(shù)據(jù)丟失風險。做好事務(wù)管理的話,其實這種模式基本上沒什么存在的價值。

備份成份:

現(xiàn)在來說說一個備份會包含什么內(nèi)容,很多人以為,特別是完整數(shù)據(jù)庫備份,就是把所有東西都備份,其實他們被名字迷惑了。在介紹備份成份前,先介紹SQL Server的數(shù)據(jù)庫成份,SQL Server數(shù)據(jù)庫是一系列基于Windows的文件,最簡單的模式包含一個數(shù)據(jù)文件(默認后綴名為MDF)和一個日志文件(默認后綴名為LDF),后綴名能改,但是沒有任何理由去改。后果很嚴重…。這兩個文件在創(chuàng)建數(shù)據(jù)庫時就自動創(chuàng)建,在后續(xù)運行當中,可能會創(chuàng)建多個數(shù)據(jù)文件(默認后綴名為ndf),多個日志文件(大部分情況下沒必要,在日志備份一文介紹),還有一些文件組,每個文件組包含若干個文件。

數(shù)據(jù)文件:

數(shù)據(jù)文件是用于存儲系統(tǒng)及用戶數(shù)據(jù)及對象,簡單來說,就是數(shù)據(jù)、表、視圖、存儲過程、觸發(fā)器等等。除此之外,還包含權(quán)限信息。每個數(shù)據(jù)庫最少要有一個數(shù)據(jù)文件,默認為主數(shù)據(jù)文件,primary data file,默認后綴名為.MDF。存儲在主文件組(primary Filegroup中),如果需要新加文件,這些文件就是次要數(shù)據(jù)文件(雖然名字為次要,但是一點都不次要…),默認后綴名為.NDF。

主數(shù)據(jù)文件包含:所有系統(tǒng)對象和數(shù)據(jù)、默認情況下所有用戶自定義的對象和數(shù)據(jù)。還有其他次要數(shù)據(jù)文件的地址。

文件組:

文件組是文件的一個邏輯集合,它可以包含一個或者多個數(shù)據(jù)文件,默認創(chuàng)建數(shù)據(jù)庫時就會創(chuàng)建一個primary 文件組,存放primary數(shù)據(jù)文件。這個同時是default文件組,所有數(shù)據(jù)都會存放到這里,除非額外指定,default文件組可以改,前提是有兩個或以上的文件組,這樣可以把數(shù)據(jù)強制寫到別的文件組中,有時候通過這種方式可以緩解磁盤的壓力。另外primary文件組還存了其他所有文件組的路徑。

對于多個文件組的數(shù)據(jù)庫,可以進行文件組備份,這種方式對于超大型數(shù)據(jù)庫(VLDB)非常有效,因為據(jù)我工作經(jīng)驗,即使一個150G的庫做一個完整備份,也往往要進行20分鐘左右,如果是150T的庫,恐怕幾個小時都搞不定,這時候,文件組備份就起到很重要的作用,把文件組控制在一定的大小,然后每次備份只對單獨文件組進行,這樣可以把一個連續(xù)的備份操作拆分為很多小操作。另外,文件組可以設(shè)為只讀(read-only),這樣可以在純讀操作中,減少鎖和等待的產(chǎn)生,對性能方面有一定程度上的幫助。對于文件組配置放在其他章節(jié),這里不累贅。

需要提醒的是,文件組帶來性能方面的改進同時,也帶來了管理方面復(fù)雜度的提升。所以需要慎重考慮。

事務(wù)日志:

這部分也有單獨的介紹,這里只做簡介,所有SQLServer數(shù)據(jù)庫、所有恢復(fù)模式下,都有最少一個事務(wù)日志文件。雖然后面有專門的文章介紹,但是這里要不厭其煩地提醒,別因為任何模式、或者LDF文件太大就刪除LDF讓SQLServer,最嚴重的情況是會導(dǎo)致你的數(shù)據(jù)庫無法使用。

備份類型:

目前微軟已發(fā)布的SQLServer版本中,支持以下類型的備份:完整數(shù)據(jù)庫備份、差異數(shù)據(jù)庫備份、事務(wù)日志備份(后稱日志備份)、文件和文件組備份、部分備份,但是如前面所說,根據(jù)SQL Server版本不同,有些備份類型不支持,另外根據(jù)恢復(fù)模式的不同,某些備份類型也不支持。數(shù)據(jù)文件、文件組及日志文件組成了SQL Server數(shù)據(jù)庫,并且成為了各種備份類型的對象。下面簡介一下各種備份類型:

數(shù)據(jù)庫備份:把主數(shù)據(jù)文件和次要數(shù)據(jù)文件(如果有)上面的數(shù)據(jù)和對象存入備份文件中,這類細分為:

  • 完整數(shù)據(jù)庫備份:備份特定數(shù)據(jù)庫的所有文件的所有數(shù)據(jù)和對象,還有足以用于在故障時恢復(fù)數(shù)據(jù)庫到一致性狀態(tài)的日志部分。
  • 差異數(shù)據(jù)庫備份:備份特定數(shù)據(jù)庫上自最近一次完整數(shù)據(jù)庫備份之后發(fā)生修改的所有數(shù)據(jù)文件的數(shù)據(jù)和對象。事務(wù)日志備份:把特定數(shù)據(jù)庫自上一次日志備份后寫入LDF文件的日志記錄寫入備份文件。
文件備份:把數(shù)據(jù)文件或者文件組中的數(shù)據(jù)及對象寫入備份文件,可以細分為:
  • 完整文件備份:備份在特定數(shù)據(jù)文件或文件組上的所有數(shù)據(jù)和對象。
  • 差異文件備份:備份從上一次完整文件備份后特定數(shù)據(jù)文件或文件組中修改的數(shù)據(jù)和對象。
  • 部分備份(完整部分備份):備份數(shù)據(jù)庫中除只讀文件/文件組外(除非特殊指定)的所有可寫部分。
  • 差異部分備份:備份自上一次完整部分備份后發(fā)生變更的數(shù)據(jù)和對象。

再次說明,這些備份類型不是總是可用的,有些先決條件,特別是恢復(fù)模式,本系列將逐步演示這些操作。

備份需要考慮的因素:

備份時需要考慮以下幾個因素,不能認為備份是簡單操作,作為任何數(shù)據(jù)庫管理(包括專業(yè)DBA或者兼職管理人員),備份都是第一要務(wù),所以要認真對待:

  • SLA
  • 備份存放位置
  • 備份周期及備份類型組合
  • 備份文件存放周期
  • 執(zhí)行備份的工具
  • 對性能的影響

這些部分將在后續(xù)陸續(xù)介紹。

What's the next?

1、準備環(huán)境,本系列主要使用Windows Server 2012 R2+SQL Server 2008 R2企業(yè)版+AdventureWorks 2008 R2數(shù)據(jù)庫及為了演示而額外創(chuàng)建的一些數(shù)據(jù)庫。

2、下文將演示完整數(shù)據(jù)庫備份,需要注意,是完整數(shù)據(jù)庫備份,而不是完整備份,雖然大部分情況下這是等價的,但是完整備份實際上包含完整文件備份,為了減少誤解,這里需要說明是數(shù)據(jù)庫備份。

感謝閱讀,希望能幫助到大家,謝謝大家對本站的支持!

您可能感興趣的文章:
  • SQL Server 2005“備份集中的數(shù)據(jù)庫備份與現(xiàn)有的數(shù)據(jù)庫不同”解決方法
  • SQL Server導(dǎo)入、導(dǎo)出、備份數(shù)據(jù)方法
  • SQL Server 數(shù)據(jù)庫備份和還原認識和總結(jié) (一)
  • SQL Server 2005/2008 用戶數(shù)據(jù)庫文件默認路徑和默認備份路徑修改方法
  • sql server 2000數(shù)據(jù)庫備份還原的圖文教程
  • SQLServer2005 按照日期自動備份的方法
  • sqlserver2005打造自動備份的維護計劃圖解教程
  • SQL Server 2008 備份數(shù)據(jù)庫、還原數(shù)據(jù)庫的方法
  • sql server 2005數(shù)據(jù)庫備份還原圖文教程
  • 將備份的SQLServer數(shù)據(jù)庫轉(zhuǎn)換為SQLite數(shù)據(jù)庫操作方法

標簽:湖南 銅川 湘潭 仙桃 黃山 衡水 蘭州 崇左

巨人網(wǎng)絡(luò)通訊聲明:本文標題《SQL Server 數(shù)據(jù)庫的備份詳細介紹及注意事項》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266