国产精品美女久久久久久免费,国产成人精品亚洲线观看,国产精品人人做人人爽

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

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

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

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

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

30-05)完整或差異備份會清除日志
不，因為日志備份包含了自上次日志備份以來所有的日志，這點無可改變，即使這期間的日志被完整或是差異備份所備份。我在Twitter上曾經(jīng)有一個有名的文章闡述了這點：Misconceptions around the log and log backups: how to convince yourself?？傊?，在完整或大容量事務(wù)日志恢復(fù)模式下，只有備份日志才會清除日志。

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

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

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

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

30-09)備份通過緩沖區(qū)中讀取數(shù)據(jù)
不，備份子系統(tǒng)會對數(shù)據(jù)文件單獨開一個通道以避免將所有涉及到的內(nèi)容讀到內(nèi)存后再存到存儲設(shè)備，因為如果這樣的話備份時性能會嚴重下降(因為這涉及到虛擬內(nèi)存置換回磁盤)。如果備份時你指定了WITH CHECKSUM，則會涉及到少量內(nèi)存使用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30-25)備份數(shù)據(jù)需要關(guān)閉SQL Server
這個，我真不知道這個謠言從哪來的。(編輯:顯然從Oracle來的，因為我們都知道和SQL Server比起來Oracle要強很多:-)。

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

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

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

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

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

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

錯誤

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

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

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

您可能感興趣的文章:

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個有關(guān)還原(Restore)的誤區(qū)
SQL Server誤區(qū)30日談第23天有關(guān)鎖升級的誤區(qū)
SQL Server誤區(qū)30日談第22天資源調(diào)控器可以調(diào)控IO
SQL Server誤區(qū)30日談第21天數(shù)據(jù)損壞可以通過重啟SQL Server來修復(fù)
SQL Server誤區(qū)30日談第20天破壞日志備份鏈之后，需要一個完整備份來重新開始日志鏈
SQL Server誤區(qū)30日談第19天 Truncate表的操作不會被記錄到日志
SQL Server誤區(qū)30日談第18天有關(guān)FileStream的存儲，垃圾回收以及其它
SQL Server誤區(qū)30日談第17天有關(guān)頁校驗和的誤區(qū)
SQL Server誤區(qū)30日談第16天數(shù)據(jù)的損壞和修復(fù)
SQL Server誤區(qū)30日談第15天 CheckPoint只會將已提交的事務(wù)寫入磁盤
SQL Server誤區(qū)30日談第14天清除日志后會將相關(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天鏡像在檢測到故障后瞬間就能故障轉(zhuǎn)移
SQL Server誤區(qū)30日談第10天數(shù)據(jù)庫鏡像在故障發(fā)生后馬上就能發(fā)現(xiàn)
SQL Server誤區(qū)30日談第9天數(shù)據(jù)庫文件收縮不會影響性能
SQL Server誤區(qū)30日談第8天有關(guān)對索引進行在線操作的誤區(qū)
SQL Server誤區(qū)30日談第7天一個實例多個鏡像和日志傳送延遲
SQL Server誤區(qū)30日談第6天有關(guān)NULL位圖的三個誤區(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天即時文件初始化特性可以在SQL Server中開啟和關(guān)閉
SQL Server誤區(qū)30日談第2天 DBCC CHECKDB會導(dǎo)致阻塞
SQL Server誤區(qū)30日談第1天正在運行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行

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

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