程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> SQL Server 數據庫的備份詳細引見及留意事項

SQL Server 數據庫的備份詳細引見及留意事項

編輯：MySQL綜合教程

SQL Server 數據庫的備份詳細引見及留意事項。本站提示廣大學習愛好者：（SQL Server 數據庫的備份詳細引見及留意事項）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server 數據庫的備份詳細引見及留意事項正文

SQL Server 備份

前言

為什麼要備份？理由很復雜——為了復原/恢復。當然，假如不備份，還可以經過磁盤恢復來找回喪失的文件，不過SQL Server很生氣，結果很嚴重。到時分你就知道為什麼先叫你備份一次再開端看文章了。∩__∩。本系列將引見SQL Server一切可用的備份復原功用，並盡能夠用實例說話。

什麼是備份？SQL Server基於Windows，以文件方式寄存材料，所以備份就是Windows上SQL Server相關文件的一個某個時間點的正本。依據備份類型的不同，正本的品種和內容也有不同。

備份類型有哪些？SQL Server 目前版本中，可用的備份類型有：完好數據庫備份、差別數據庫備份、事務日志備份（後稱日志備份）、文件和文件組備份、局部備份，依據SQL Server版本不同，有些備份類型不支持，另外依據恢復形式的不同，某些備份類型也不支持。

什麼是恢復形式？

很多人只把關注點放在備份下面，而沒有在意恢復形式，其實一切的備份都應該從恢復形式作為切入點。恢復形式實踐上是一個控制備份復原的行為的數據庫級別選項。SQL Server 在以後一切發布版本中只要三種恢復形式：復雜恢復形式（前面簡稱復雜形式），大容量日志恢復形式（前面簡稱大容量形式），完好恢復形式（後稱完好形式）。

本文從恢復形式開端，提示一下，絕大局部的專業屬於都會陸續解釋，假如讀者有不明白，可以持續往下看或許上網搜索：

1.復雜形式，Simple recovery model：某些操作可以被最小日志化。這種形式下，不支持日志備份、時間點恢復和頁恢復。且文件恢復功用僅限於主要數據文件中的只讀文件。

2.大容量日志形式，Bulk-logged recovery model：和完好形式相似，有時分可以了解為完好形式於復雜形式的過渡形式。這種形式對某些大容量操作停止最小日志化，支持完好備份中的備份復原戰略，但是由於某些操作被最小日志化，所以不能保證時間點恢復。

3.完好形式，Full recovery model：在這個形式下，所以操作都被完好記載上去，並且支持一切類型的備份復原戰略。

默許狀況下，新庫會承繼Model庫的配置，包括恢復形式，也就是FULL形式。可以在創立或日常運用進程中修正，並且不需求重啟服務。恢復形式最重要的區別在於看待日志的行為。

復雜形式：

是三種形式中最容易管理的，可以停止完好，差別和文件備份，但是不能做日志備份。在這種形式下，每當Checkpoint 進程發作時，會自動把日志文件中不活動的日志（在日志備份一文引見）寫入數據文件，寫入後，對應的日志文件中的空間就可供新事務運用，留意這種空間重用或許截斷並不自動增加日志文件的物理大小，假如需求增加空間，需求運用DBCC SHRINKFILE/DATABASE等命令完成。讓日志空間重用的進程叫做截斷。在復雜形式下這個進程稱為自動截斷(auto-truncate)。在這種形式下，日志通常不需求管理，但是關於單個的大事務，日志文件能夠會增長得很快，這種狀況下最好把批處置降為小的批。復雜形式最次要的限制是不能停止日志備份，也就是說無法停止時間點復原。在一些測試，開發或許SLA要求不嚴厲的環境下，可以運用這種形式。

完好形式：

這種形式下，一切數據庫操作都被完好地記載在日志中，2008呈現某些操作在這種形式下也還是最小化日志。並且不是自動截斷。它支持任何備份復原戰略，特別是時間點復原，在日志復原一章引見。即便發作Checkpoint ，不活動的事務也不會截斷到數據文件中。獨一能控制日志文件的只要日志備份，所以這種形式下日志備份極端重要，一方面提供時間點復原，另外一方面控制日志文件大小。

日志文件會完好保管自上一次日志備份後的事務。運用copy_only或許no_truncate選項均不會截斷日志。

大容量日志：

這種形式是最少用到的，某些操作會被最小日志化，包括：

運用bcp停止導入 bulk insertinsert select *from openrowset(bulk ) select into 運用writetext/updatetext拔出或附加數據重建索引

在這種形式下，會用bitmap image記載發作最小日志化的區。假如數據庫毛病招致數據文件不了用，並且日志尾部包括最小化日志，不能做日志尾部備份，由於這個操作需求訪問數據文件中數據修正後的區。這種形式適用於大容量操作，但是假如事務包括最小化日志，則不能停止時間點復原，只能復原到之前。

恢復形式擴展闡明：

如上所說，恢復形式是數據庫級別的配置項，在創立進程中及後續運用中均可修正，但是由於種種緣由，盡量在規劃階段就做好配置，並且在創立進程中明白指定。

這個選項次要用於決議數據庫能否可以（或許需求）做日志備份？什麼事務需求被記載？還有能否可以做其他類型的備份復原操作等。

復雜形式：

某些操作能被最小化日志，這裡要闡明一下，很多人以為復雜形式下“不記載日志”，其實這是很嚴重的曲解，會招致後續運用的很多問題，無論任何恢復形式，都會記載日志，只是記載的方式和內容不同。在復雜形式下，日志備份選項被禁用，帶來的影響是不支持時間點復原、頁復原，而文件復原功用僅限於READONLY文件組中的主要數據文件。

復雜形式是最容易管理的恢復形式，在這種形式下，可以停止完好數據庫備份、差別數據庫備份和文件備份，但是不能停止日志備份。在日志備份一文會詳細引見，但是在這裡要提一下，關於日志空間重用的問題，不論任何恢復形式，都會有一個零碎進程在後台運轉——CHECKPOINT，每當這個進程啟動時，會把數據庫的日志文件（通常就是LDF文件）中，非活動的事務寫入數據文件，然後把這局部的空間標識為“可重用”，這個步驟稱為日志截斷，在復雜形式下稱為自動截斷（auto-truncate），記住可重用不代表空間被清空，獨一可以清空LDF文件物理大小的操作是膨脹數據庫/文件操作。復雜形式會自動執行這個截斷操作，截斷後，日志空間可被新事物重新運用，從微觀變現來說，就是LDF文件的物理大小不添加，或許添加遲緩，其實當運用復雜形式，並且LDF適宜的狀況下，假如LDF物理大小還在增長，能夠就需求惹起留意。

由於日志的自動截斷，招致復雜形式下無法停止時間點恢復，也無法停止日志備份。但是關於對數據要求不高的零碎，或許SLA（在復原根底一文中引見）沒有什麼特殊要求的環境，可以運用這種形式，可以最大限制增加對日志的管理。但是不是意味著運用了這種形式，就不必管理日志了，關於一些大規模、長時間運轉的批處置，會惹起少量的活動事務，此時LDF文件照舊會迅速增長，惹起一些潛在的問題。對此，盡能夠把批處置拆分為多個、短事務。

復雜來說，這種形式的優缺陷：

優點：
易於管理，大局部狀況下不需求
缺陷：

不能停止事務日志備份，無法時間點復原數據喪失的風險增大

選擇根據：依據業務需求選擇，關於十分重要的數據庫，無論以後數據庫大小，都不要運用這種形式，詳細內容參考復原根底中SLA的內容。

完好形式：

完好形式很多概念都是絕對於復雜形式來說的，這種形式下，一切操作被完好地記載在事務日志文件中，並且不會發作自動截斷（除了數據庫完全沒做過最少一次完好備份），事務日志只要在事務日志備份發作時，才會截斷到數據文件，並且使對應局部可用。這種形式可以執行一切類型的備份復原選項，特別是可以停止時間點恢復，保證數據接近0喪失。這是簡直一切正式環境（也稱消費環境）運用的恢復形式。

優點：

可以完好記載數據庫操作停止時間點恢復，保證數據盡能夠0喪失

缺陷：

需求嚴厲管理事務日志文件數據庫規模能夠會變得難以控制

大容量日志形式：

這是用的最少的恢復形式，讀者不要給名字忽悠了，見過很多人在停止大容量操作時切換到這種形式，然後操作完再切換回來，這種操作其實比擬風險。不建議運用。另外，它支持日志備份，能停止一定水平的時間點恢復。除了後面提到的可最小化日志的操作，其日常運用和管理與完好形式無疑。可以了解為是完好形式和復雜形式的過渡。

缺陷：

假如數據文件忽然變得不可用，並且日志尾部包括了大容量日志形式下停止的最小化日志操作，那麼不能夠停止日志尾部備份，由於這種備份要求訪問數據修正所發作的區，而這個區在最小化日志操作中僅記載“發作了操作”，而沒有完好地記載操作內容。招致無法停止時間點復原，存在一定的數據喪失風險。做壞事務管理的話，其實這種形式根本上沒什麼存在的價值。

備份成份：

如今來說說一個備份會包括什麼內容，很多人以為，特別是完好數據庫備份，就是把一切東西都備份，其實他們被名字迷惑了。在引見備份成份前，先引見SQL Server的數據庫成份，SQL Server數據庫是一系列基於Windows的文件，最復雜的形式包括一個數據文件（默許後綴名為MDF）和一個日志文件（默許後綴名為LDF），後綴名能改，但是沒有任何理由去改。結果很嚴重…。這兩個文件在創立數據庫時就自動創立，在後續運轉當中，能夠會創立多個數據文件（默許後綴名為ndf），多個日志文件（大局部狀況下沒必要，在日志備份一文引見），還有一些文件組，每個文件組包括若干個文件。
數據文件：
數據文件是用於存儲零碎及用戶數據及對象，復雜來說，就是數據、表、視圖、存儲進程、觸發器等等。除此之外，還包括權限信息。每個數據庫最少要有一個數據文件，默許為主數據文件，primary data file，默許後綴名為.MDF。存儲在主文件組（primary Filegroup中），假如需求新加文件，這些文件就是主要數據文件（雖然名字為主要，但是一點都不主要…），默許後綴名為.NDF。

主數據文件包括：一切零碎對象和數據、默許狀況下一切用戶自定義的對象和數據。還有其他主要數據文件的地址。
文件組：
文件組是文件的一個邏輯集合，它可以包括一個或許多個數據文件，默許創立數據庫時就會創立一個primary 文件組，寄存primary數據文件。這個同時是default文件組，一切數據都會寄存到這裡，除非額定指定，default文件組可以改，前提是有兩個或以上的文件組，這樣可以把數據強迫寫到別的文件組中，有時分經過這種方式可以緩解磁盤的壓力。另外primary文件組還存了其他一切文件組的途徑。

關於多個文件組的數據庫，可以停止文件組備份，這種方式關於超大型數據庫（VLDB）十分無效，由於據我任務經歷，即便一個150G的庫做一個完好備份，也往往要停止20分鐘左右，假如是150T的庫，恐怕幾個小時都搞不定，這時分，文件組備份就起到很重要的作用，把文件組控制在一定的大小，然後每次備份只對獨自文件組停止，這樣可以把一個延續的備份操作拆分為很多小操作。另外，文件組可以設為只讀（read-only），這樣可以在純讀操作中，增加鎖和等候的發生，對功能方面有一定水平上的協助。關於文件組配置放在其他章節，這裡不負擔。

需求提示的是，文件組帶來功能方面的改良同時，也帶來了管理方面復雜度的提升。所以需求慎重思索。
事務日志：
這局部也有獨自的引見，這裡只做簡介，一切SQLServer數據庫、一切恢復形式下，都有最少一個事務日志文件。雖然前面有專門的文章引見，但是這裡要誨人不倦地提示，別由於任何形式、或許LDF文件太大就刪除LDF讓SQLServer，最嚴重的狀況是會招致你的數據庫無法運用。

備份類型：

目前微軟已發布的SQLServer版本中，支持以下類型的備份：完好數據庫備份、差別數據庫備份、事務日志備份（後稱日志備份）、文件和文件組備份、局部備份，但是如後面所說，依據SQL Server版本不同，有些備份類型不支持，另外依據恢復形式的不同，某些備份類型也不支持。數據文件、文件組及日志文件組成了SQL Server數據庫，並且成為了各種備份類型的對象。上面簡介一下各種備份類型：

數據庫備份：把主數據文件和主要數據文件（假如有）下面的數據和對象存入備份文件中，這類細分為：

完好數據庫備份：備份特定數據庫的一切文件的一切數據和對象，還有足以用於在毛病時恢單數據庫到分歧性形態的日志局部。差別數據庫備份：備份特定數據庫上自最近一次完好數據庫備份之後發作修正的一切數據文件的數據和對象。事務日志備份：把特定數據庫自上一次日志備份後寫入LDF文件的日志記載寫入備份文件。