欧美日韩国产成人高清视,亚洲国产91在线无码,国产、日韩第一二三区

誤區(qū) #30：有關(guān)備份的30個(gè)誤區(qū)
全是錯(cuò)的
在開始有關(guān)備份的誤區(qū)之前，如果你對(duì)備份的基礎(chǔ)沒有了解，請(qǐng)看之前我在TechNet Magazine的文章:Understanding SQL Server Backups。

30-01)備份操作會(huì)導(dǎo)致阻塞
不，備份不會(huì)導(dǎo)致對(duì)用戶對(duì)象加鎖，雖然備份對(duì)IO系統(tǒng)的負(fù)擔(dān)導(dǎo)致看起來(lái)阻塞了，但實(shí)際上不會(huì)。唯一的特例是當(dāng)備份包含到那些最小日志操作涉及到的數(shù)據(jù)區(qū)需要被加鎖時(shí)，這個(gè)操作會(huì)阻塞CheckPoint,但DML操作永遠(yuǎn)不會(huì)受到備份操作的阻塞。

30-02)由完整恢復(fù)模式切換到大容量事務(wù)日志恢復(fù)模式再切換回來(lái)會(huì)導(dǎo)致日志鏈斷裂
不，這兩種模式互相切換不會(huì)導(dǎo)致日志鏈斷裂。

30-03)只有完整備份才能重新開始被斷裂的日志鏈
除了完整備份模式可以重新日志鏈之外，差異備份也可以重新開始日志鏈-總而言之，日志斷裂那部分只要被差異備份所包含，就可以重新開始日志鏈。詳情請(qǐng)看我之前的一篇博文：SQL Server誤區(qū)30日談-Day20-破壞日志備份鏈之后，需要一個(gè)完整備份來(lái)重新開始日志鏈。

30-04)在完整或是差異備份時(shí)，不允許進(jìn)行日志備份
錯(cuò)誤，在SQL Server 2005之后，完整或是差異備份的同時(shí)可以進(jìn)行日志備份，詳情請(qǐng)看:Search Engine QA #16: Concurrent log and full backups。

30-05)完整或差異備份會(huì)清除日志
不，因?yàn)槿罩緜浞莅俗陨洗稳罩緜浞菀詠?lái)所有的日志，這點(diǎn)無(wú)可改變，即使這期間的日志被完整或是差異備份所備份。我在Twitter上曾經(jīng)有一個(gè)有名的文章闡述了這點(diǎn)：Misconceptions around the log and log backups: how to convince yourself。總之，在完整或大容量事務(wù)日志恢復(fù)模式下，只有備份日志才會(huì)清除日志。

30-06)如果使用大容量事務(wù)日志恢復(fù)模式中含有了那些最小記錄日志的操作，則下一次日志備份的日志會(huì)減少
不，“最小記錄日志”之所以這么叫是因?yàn)橹挥猩婕暗较嚓P(guān)的頁(yè)分配才會(huì)被記錄到日志。日志備份中必須包含使得這類操作可以回滾的部分，也就是所有日志以及“最小記錄日志”操作所涉及的相關(guān)區(qū)。這使得大容量事務(wù)日志模式下日志需要備份的內(nèi)容和完整恢復(fù)模式下日志需要備份的內(nèi)容大小基本一致。

30-07)完整或差異備份中所包含的日志僅僅是這個(gè)操作進(jìn)行時(shí)生成的日志
錯(cuò)誤，完整或差異備份需要日志來(lái)將數(shù)據(jù)庫(kù)還原到當(dāng)完整或差異備份結(jié)束時(shí)的事務(wù)一致性狀態(tài)。
下面兩篇博文對(duì)此有更詳細(xì)的解釋:

Debunking a couple of myths around full database backups
More on how much transaction log a full backup includes

30-08)備份操作會(huì)檢查頁(yè)的校驗(yàn)和
錯(cuò)誤，只有在備份時(shí)指定WITH CHECKSUM選項(xiàng)時(shí)才會(huì)檢查校驗(yàn)和，這也是備份應(yīng)該指定的選項(xiàng)。

30-09)備份通過(guò)緩沖區(qū)中讀取數(shù)據(jù)
不，備份子系統(tǒng)會(huì)對(duì)數(shù)據(jù)文件單獨(dú)開一個(gè)通道以避免將所有涉及到的內(nèi)容讀到內(nèi)存后再存到存儲(chǔ)設(shè)備，因?yàn)槿绻@樣的話備份時(shí)性能會(huì)嚴(yán)重下降(因?yàn)檫@涉及到虛擬內(nèi)存置換回磁盤)。如果備份時(shí)你指定了WITH CHECKSUM，則會(huì)涉及到少量?jī)?nèi)存使用。

30-10)備份會(huì)進(jìn)行一致性檢查（也就是和DBCC CHECKDB功能一樣）
不會(huì)，這沒什么好說(shuō)的。

30-11)如果備份成功，那么還原也能成功
錯(cuò)誤，希望你不要形成這樣的思維定勢(shì)。你必須定期檢查備份以確保在災(zāi)難發(fā)生時(shí)，可以正確的進(jìn)行還原。詳情請(qǐng)看:Importance of validating backups。

30-12)即使鏡像的路徑不可用，鏡像備份依然可以成功
錯(cuò)誤，如果鏡像中的一個(gè)路徑失效，那么整個(gè)鏡像備份都都會(huì)失敗。我倒是希望這種機(jī)制可以改成鏡像備份時(shí)即使一端路徑不可用，那另一端還可以成功備份，但遺憾的是，這不行。

30-13)任何時(shí)候都可以進(jìn)行尾端日志備份
錯(cuò)誤，尾端日志包含了自上次日志備份以來(lái)所有的日志，但這是一種緊急情況，如果數(shù)據(jù)文件受損，并且日志中包含了那些“最小記錄日志”的操作，由于此時(shí)需要備份日志以及這類“最小記錄日志”涉及到的相關(guān)區(qū)。如果數(shù)據(jù)文件中的這些區(qū)收縮，則無(wú)法備份尾端日志。所以，對(duì)于那些24*7的生產(chǎn)環(huán)境，永遠(yuǎn)不要使用大容量日志恢復(fù)模式。

30-14)備份可以替代DBCC CheckDB
錯(cuò)誤，詳情請(qǐng)看SQL Server誤區(qū)30日談-Day27-使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB

30-15)可以備份數(shù)據(jù)庫(kù)快照
不可以，雖然我也希望可以備份數(shù)據(jù)庫(kù)快照。

30-16)可以使用數(shù)據(jù)庫(kù)鏡像來(lái)替代日志備份
不，只有在數(shù)據(jù)庫(kù)鏡像所基于的數(shù)據(jù)庫(kù)可用時(shí)，鏡像才可用。如果數(shù)據(jù)庫(kù)本身被損壞，鏡像一般也不會(huì)幸免。而數(shù)據(jù)庫(kù)本身suspect,數(shù)據(jù)庫(kù)鏡像往往也會(huì)suspect。
當(dāng)然，由于當(dāng)數(shù)據(jù)庫(kù)中頁(yè)被修改時(shí)，也需要被同步到鏡像，因此存在多個(gè)鏡像對(duì)數(shù)據(jù)庫(kù)性能的影響會(huì)非常大。此外，當(dāng)數(shù)據(jù)庫(kù)中被修改的部分越來(lái)越多時(shí)，鏡像也會(huì)不斷膨脹。因此無(wú)法用鏡像代替日志備份。

30-17)日志備份所占的大小會(huì)和日志所占的大小一致
錯(cuò)誤。日志中包含了需要回滾活動(dòng)事務(wù)的日志。DBCC SQLPERF (LOGSPACE)所體現(xiàn)出來(lái)的日志空間使用并不能正確反映出日志條目所占的空間。Search Engine QA #25: Why isn't my log backup the same size as my log?。此外，需要備份的日志部分往往是自上次日志備份以來(lái)所有的日志。如果日志大于自上次日志備份以來(lái)所有的日志，說(shuō)明還有長(zhǎng)時(shí)間活動(dòng)未結(jié)束的事務(wù)。

30-18)無(wú)法備份損壞的數(shù)據(jù)庫(kù)
錯(cuò)誤，你可以使用WITH CONTINUE_AFTER_ERROR選項(xiàng)來(lái)備份損壞的數(shù)據(jù)庫(kù)（如果這個(gè)選項(xiàng)還不行，可能是boot頁(yè)或文件頭頁(yè)損壞了），這也是除了OS級(jí)別之上的SQL SERVER備份損壞數(shù)據(jù)庫(kù)的唯一辦法。

30-19)你不能禁止別人進(jìn)行BACKUP LOG .. WITH NO_LOG 和TRUNCATE_ONLY操作
錯(cuò)誤，在SQL Server 2005中，的確是這樣，但是在SQL Server 2008中，你可以通過(guò)跟蹤標(biāo)記3231來(lái)實(shí)現(xiàn)這一點(diǎn)。

30-20)日志備份無(wú)論在什么條件下都會(huì)清除日志
錯(cuò)誤。如果日志備份的同時(shí)并沒有并行執(zhí)行數(shù)據(jù)庫(kù)備份，則日志備份會(huì)嘗試清除不活動(dòng)的VLF。對(duì)于SQL Server的角度來(lái)說(shuō)，那些沒有備份的日志是也就是SQL Server所必須的日志，這類日志不能被清除。因此對(duì)于某些特殊情況，雖然進(jìn)行了日志備份，但SQL Server仍然認(rèn)為這些日志是必須的，SQL Server會(huì)不斷檢查這些日志直到認(rèn)為這些日志不再必須，我在TechNet雜志的一篇文章對(duì)此有詳細(xì)的探討:Understanding Logging and Recovery in SQL Server。

30-21)差異備份是增長(zhǎng)式的
錯(cuò)誤,差異備份所備份的數(shù)據(jù)是自上次完整備份后所有修改的數(shù)據(jù)區(qū)-所以是積累性質(zhì)的(譯者注：比如說(shuō)在期間你對(duì)用一個(gè)數(shù)據(jù)區(qū)進(jìn)行多次修改，差異備份的大小不會(huì)變)。只有日志是增長(zhǎng)式的。雖然很多人認(rèn)為差異備份是積累性質(zhì)的，但實(shí)際不是。

30-22)當(dāng)備份完成時(shí)，你就可以刪除前一個(gè)備份了
No. No. No.
如果當(dāng)你還原時(shí)發(fā)現(xiàn)完整備份已經(jīng)損壞，此時(shí)你就該束手無(wú)策了吧。如果此時(shí)你沒有前一個(gè)完整備份，你還是趕緊去招聘網(wǎng)站更新簡(jiǎn)歷吧。你需要按照策略多留幾個(gè)備份，這樣就能有備無(wú)患了。

30-23)可以備份鏡像數(shù)據(jù)庫(kù)
錯(cuò)誤，鏡像(Mirror)只能通過(guò)數(shù)據(jù)庫(kù)快照訪問(wèn)。對(duì)其也不能進(jìn)行備份。

30-24)你可以單獨(dú)備份一個(gè)表
錯(cuò)誤，如果湊巧這個(gè)單獨(dú)表在一個(gè)文件組上，那么你可以通過(guò)備份文件組來(lái)達(dá)到這個(gè)目的，但沒有所謂的:BACKUP TABLE。

30-25)備份數(shù)據(jù)需要關(guān)閉SQL Server
這個(gè)，我真不知道這個(gè)謠言從哪來(lái)的。(編輯:顯然從Oracle來(lái)的，因?yàn)槲覀兌贾篮蚐QL Server比起來(lái)Oracle要強(qiáng)很多:-)。

30-26)正在執(zhí)行的事務(wù)只要在備份完成之前提交就一定會(huì)包含在這個(gè)備份中
錯(cuò)誤，只有在備份的數(shù)據(jù)讀取階段完成之前提交并寫入磁盤的事務(wù)才會(huì)包含在備份之。詳情請(qǐng)看:Search Engine QA #6: Using fn_dblog to tell if a transaction is contained in a backup。

30-27)在備份之前收縮數(shù)據(jù)庫(kù)可以減少備份的大小
錯(cuò)誤，收縮僅僅是移動(dòng)頁(yè)，并不會(huì)引起備份大小的改變。詳情請(qǐng)看:Conference Questions Pot-Pourri #10: Shrinking the database before taking a backup。除此之外，還有一篇博文:SQL Server誤區(qū)30日談-Day9-數(shù)據(jù)庫(kù)文件收縮不會(huì)影響性能。不但如此，還有人提醒我說(shuō)，如果在完整備份之后進(jìn)行了數(shù)據(jù)庫(kù)收縮，則即使數(shù)據(jù)沒有改變，下一次差異備份也會(huì)變得巨大。

30-28)從備份進(jìn)行恢復(fù)是當(dāng)災(zāi)難發(fā)生時(shí)最好的辦法
錯(cuò)誤，只有當(dāng)0數(shù)據(jù)損失時(shí)，備份才是災(zāi)難恢復(fù)最好的辦法。但要減少DownTime由備份進(jìn)行還原并不是一個(gè)好辦法，如果業(yè)務(wù)允許，故障轉(zhuǎn)移或允許一些數(shù)據(jù)損失會(huì)更好。

30-29)不需要備份master, msdb, model...等幾個(gè)系統(tǒng)數(shù)據(jù)庫(kù)

錯(cuò)誤，這幾個(gè)系統(tǒng)數(shù)據(jù)庫(kù)是需要進(jìn)行備份的。Master數(shù)據(jù)庫(kù)包含了安全信息以及實(shí)例上存在哪些數(shù)據(jù)庫(kù)。MSDB數(shù)據(jù)庫(kù)包含了SSIS的包，代理任務(wù)，備份歷史。Model數(shù)據(jù)庫(kù)包含了新建數(shù)據(jù)庫(kù)的模版。不要僅僅只備份用戶數(shù)據(jù)庫(kù)，否則從頭開始配置實(shí)例將會(huì)非常痛苦。

30-30)你需要一個(gè)好的備份策略

錯(cuò)誤

我猜想你一定會(huì)說(shuō)”什么”?你需要的是一個(gè)好的還原計(jì)劃，而不是備份計(jì)劃。根據(jù)業(yè)務(wù)需求和技術(shù)限制來(lái)決定什么時(shí)間還原什么，再根據(jù)還原來(lái)決定應(yīng)該什么時(shí)間備份什么。請(qǐng)看下面兩篇文章:

Importance of having the right backups
Planning a backup strategy - where to start?

很多人都做了一個(gè)備份策略，但不測(cè)試也不想怎么還原。當(dāng)災(zāi)難發(fā)生時(shí)導(dǎo)致無(wú)法還原，希望你不是這樣。

您可能感興趣的文章:

SQL Server誤區(qū)30日談第29天有關(guān)堆碎片的誤區(qū)
SQL Server誤區(qū)30日談第28天有關(guān)大容量事務(wù)日志恢復(fù)模式的誤區(qū)
SQL Server誤區(qū)30日談第27天使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
SQL Server誤區(qū)30日談第26天 SQL Server中存在真正的“事務(wù)嵌套”
SQL Server誤區(qū)30日談第25天有關(guān)填充因子的誤區(qū)
SQL Server誤區(qū)30日談第24天 26個(gè)有關(guān)還原(Restore)的誤區(qū)
SQL Server誤區(qū)30日談第23天有關(guān)鎖升級(jí)的誤區(qū)
SQL Server誤區(qū)30日談第22天資源調(diào)控器可以調(diào)控IO
SQL Server誤區(qū)30日談第21天數(shù)據(jù)損壞可以通過(guò)重啟SQL Server來(lái)修復(fù)
SQL Server誤區(qū)30日談第20天破壞日志備份鏈之后，需要一個(gè)完整備份來(lái)重新開始日志鏈
SQL Server誤區(qū)30日談第19天 Truncate表的操作不會(huì)被記錄到日志
SQL Server誤區(qū)30日談第18天有關(guān)FileStream的存儲(chǔ)，垃圾回收以及其它
SQL Server誤區(qū)30日談第17天有關(guān)頁(yè)校驗(yàn)和的誤區(qū)
SQL Server誤區(qū)30日談第16天數(shù)據(jù)的損壞和修復(fù)
SQL Server誤區(qū)30日談第15天 CheckPoint只會(huì)將已提交的事務(wù)寫入磁盤
SQL Server誤區(qū)30日談第14天清除日志后會(huì)將相關(guān)的LSN填零初始化
SQL Server誤區(qū)30日談第13天在SQL Server 2000兼容模式下不能使用DMV
SQL Server誤區(qū)30日談第12天 TempDB的文件數(shù)和需要和CPU數(shù)目保持一致
SQL Server誤區(qū)30日談第11天鏡像在檢測(cè)到故障后瞬間就能故障轉(zhuǎn)移
SQL Server誤區(qū)30日談第10天數(shù)據(jù)庫(kù)鏡像在故障發(fā)生后馬上就能發(fā)現(xiàn)
SQL Server誤區(qū)30日談第9天數(shù)據(jù)庫(kù)文件收縮不會(huì)影響性能
SQL Server誤區(qū)30日談第8天有關(guān)對(duì)索引進(jìn)行在線操作的誤區(qū)
SQL Server誤區(qū)30日談第7天一個(gè)實(shí)例多個(gè)鏡像和日志傳送延遲
SQL Server誤區(qū)30日談第6天有關(guān)NULL位圖的三個(gè)誤區(qū)
SQL Server誤區(qū)30日談第5天 AWE在64位SQL SERVER中必須開啟
SQL Server誤區(qū)30日談第4天 DDL觸發(fā)器就是INSTEAD OF觸發(fā)器
SQL Server誤區(qū)30日談第3天即時(shí)文件初始化特性可以在SQL Server中開啟和關(guān)閉
SQL Server誤區(qū)30日談第2天 DBCC CHECKDB會(huì)導(dǎo)致阻塞
SQL Server誤區(qū)30日談第1天正在運(yùn)行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行

標(biāo)簽：上海新鄉(xiāng) 江蘇呼和浩特貴州重慶昭通拉薩

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《SQL Server誤區(qū)30日談第30天有關(guān)備份的30個(gè)誤區(qū)》，本文關(guān)鍵詞 SQL,Server,誤區(qū),30日談,第,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題，煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們，我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無(wú)關(guān)。