SQL Server

誤區 #26: SQL Server中存在真正的“事務嵌套”錯誤 嵌套事務可不會像其文法表現的那樣看起來允許事務嵌套。我真不知道為什麼有人會這樣寫代碼，我唯一能夠想到的就是某個哥們對SQL Server社區嗤之以鼻然後寫了這樣的代碼說：“玩玩你們”。 讓我更詳細的解釋一下，SQL Server允許你在一個事務中開啟嵌套另一個事務,SQL Server允許你提交這個嵌套事務，也允許你復原這個事務。 但是，嵌套事務並不是真正的“嵌套”，對於嵌套事務來說SQL

誤區 #16:多個關於資料的損壞和修複誤區 坊間流傳的很多版本都不正確 我已經聽過很多關於資料修複可以做什麼、不可以做什麼、什麼會導致資料損毀以及損壞是否可以自行消失。其實我已經針對這類問題寫過多篇博文，因此本篇博文可以作為“流言終結者”來做一個總結，希望你能有收穫。 首先，對於資料修複可以做什麼，不可以做什麼，我已經寫過一篇博文Misconceptions around database repair涵蓋了13個誤區—從不用DBCC

誤區 #25:多個有關填滿因數的誤區 都是錯誤的25a) 填滿因數是一直存在的 不是的，通過Books Online可以看到(譯者：我在新版的BOL沒有找到這句話):重要: 填滿因數僅僅在索引建立或重建時生效，SQL Server儲存引擎並不會一直保證頁內的空閑值和填滿因數保持一致。如果為了保證頁內的空餘值和指定的填滿因數保持一直那麼填滿因數就會失去意義。因為這時頁即使不滿也需要進行分頁。25 b)填滿因數0和100是不同的 錯誤，由BOL的一句話可以看到 填滿因數0和1

誤區 #15:CheckPoint只會將已提交的事務寫入磁碟 錯誤 這個誤區是由於太多人對日誌和恢複系統缺少全面的瞭解而存在已久。CheckPoint會將自上次CheckPoint以來所有在記憶體中改變的頁寫回磁碟(譯者註：也就是髒頁),或是在上一個CheckPoint讀入記憶體的髒頁寫入磁碟。無論事務是否已經提交，其所影響的頁都會在Checkpoint時寫回磁碟。但對於TempDB來說例外，因為TempDB的Checkpoint的事件周期中並不包含將髒頁寫回磁碟的步驟。

這樣還能減少CPU快取命中失效的問題(點擊這個連結來查看CPU的緩衝是如何工作的以及MESI協議)。下面讓我們來揭穿三個有關NULL位元影像的普遍誤區。 誤區 #6a:NULL位元影像並不是任何時候都會用到 正確 就算表中不存在允許NULL的列，NULL位元影像對於資料行來說會一直存在(資料行指的是堆或是叢集索引的葉子節點)。但對於索引行來說（所謂的索引行也就是叢集索引和非叢集索引的非葉子節點以及非叢集索引的葉子節點）NULL位元影像就不是一直有效了。 下面這條語句可以有效證明這一點:

誤區 #22: 資源管理員可以調控IO錯誤 資源管理員無法調控IO，希望下一個版本的SQL Server支援調控IO，調控IO對於對於減少對於大表的scan操作帶來的效能影響很有協助。 下面列表中的功能資源管理員同樣也無法完成:調控Buffer Pool的記憶體，記憶體調控器僅僅可以調控執行計畫所佔的記憶體，但對於Buffer Pool中緩衝的資料頁是無法調控的可以對多個執行個體進行當作一個邏輯實體進行資源調控。這是不能的，對於多執行個體的資源調控只能通過Windows

誤區 #13.在SQL Server 2000相容模式下不能使用DMV錯誤 對於相容模式已經存在了很多誤解。80的相容模式的資料庫是否意味著能夠附加或恢複到SQL Server 2000資料庫?當然不是。這隻是意味著一些T-SQL的文法，查詢計劃的行為以及一些其它方面和SQL Server 2000中行為一樣（當然，如果你設定成90相容模式則和SQL Server 2005中一樣）。 在SQL Server 2008中，你可以使用ALTER DATABASE SET

誤區 #5: AWE在64位SQL SERVER中必須開啟錯誤！ 在坊間流傳的有關AWE的設定的各種版本讓人非常困惑。比如說如何設定起作用，如何設定不起作用，在32位和64位上是否需要AWE等。好吧，我來概括一下: 在64位系統(SQL SERVER 2005+版本) AWE是不需要的(即使是ON狀態，也毫無影響)開啟“鎖定記憶體頁”使得緩衝池中的記憶體頁不會被置換到虛擬記憶體中(實際上所有的Single Page

誤區 #21:資料庫損壞可以通過重啟SQL Server或是Windows,或是附加和分離資料庫解決 錯誤 SQL Server中沒有任何一項操作可以修複資料損毀。損壞的頁當然需要通過某種機制進行修複或是恢複-但絕不是通過重啟動SQL Server,Windows亦或是分離附加資料庫。 而實際上，如果你的資料庫的損壞程度無法進行Crash Recovery的話(質疑狀態)，那麼分離附加資料庫將會是你做的最糟糕的決定。這個原理是由於附加資料庫中包含Crash Recovery步驟，如果Crash

誤區 #12:TempDB的檔案數和需要和CPU數目保持一致錯誤 哎，由於上述誤區是微軟“官方”的建議，並且還有大量博文堅持這個觀點，這個誤區已經是老生常談。 但讓人困惑的是SQL CAT團隊給出的建議就是1：1，但這個建議是源自擴充方面的原理來說,而不是一個通用法則。因為他們所面對的大型客戶資料量伺服器和IO子系統都是大部分人沒有機會遇到的。

理解SQL Server對於記憶體的管理是對於SQL Server問題處理和效能調優的基本，本篇文章講述SQL Server對於記憶體管理的記憶體原理。二級儲存(secondary storage)

誤區 #11:鏡像在檢測到故障後瞬間就能容錯移轉錯誤 資料庫鏡像的容錯移轉既可以自動發起，也可以手動發起。

誤區 #4: DDL觸發器(SQL Server 2005之後被引入)就是INSTEAD OF觸發器這是錯誤的 DDL觸發器的實現原理其實就是一個AFTER觸發器。這個意思是先發生DDL操作，然後觸發器再捕捉操作（當然如果你在觸發器內寫了Rollback,則也可能復原）。 存在Rollback也意味著這個觸發器並不像你想象的那麼輕量，來看下面的例子: ALTER TABLE MyBigTable ADD MyNewNonNullColumn VARCHAR (20)

誤區10.資料庫鏡像在故障發生後，馬上就能發現 錯誤 市面上大肆宣傳資料庫鏡像技術可以在故障發生後，立即檢測到錯誤並進行容錯移轉。 但事實並不是這樣，檢測到故障發生的速度要取決於故障的類型。 檢測故障發生的最快的情況是，鏡像中的主體執行個體崩潰，從而鏡像伺服器每秒一次的PING就無法傳回值，從而知道主體伺服器上不再有這個進程偵聽相應的TCP連接埠，這種情況下，鏡像伺服器幾乎瞬間就能發現故障。

誤區 #28:有關大容量交易記錄復原模式的幾個誤區28 a)常見的DML操作可以被“最小記錄日誌” 不是。在大容量交易記錄復原模式下只有一小部分大量操作可以被“最小記錄日誌”,這類操作的列表可以在Operations That Can Be Minimally Logged找到。這是適合SQL Server 2008的列表，對於不同的SQL Server版本，請確保查看正確的列表。28 b)使用大容量交易記錄復原模式不會影響災難恢複 首先，在前次交易記錄備份之後進行了“最小記錄日誌”

本系列文章是我在sqlskill.com的PAUL的部落格看到的，很多誤區都比較具有典型性和代表性，原文來自T-SQL Tuesday #11: Misconceptions about.... EVERYTHING!!,經過我們團隊的翻譯和整理髮布在AgileSharp和部落格園上。希望對大家有所協助。誤區 #3: 檔案立即初始化特性可以在SQL Server中 a)開啟 和 b)關閉a)是不允許的 b)是允許的 檔案立即初始化是一個在SQL Server

誤區 #18:如下多個有關FileStream的誤區全部錯誤18 a)FileStream資料可以在遠程儲存 不能，由於FileStream資料容器(指的是存放FileStream檔案的NTFS檔案夾，杜撰出來的術語)必須像資料檔案或記錄檔那樣符合本機存放區策略-也就是說，這個資料容器必須放在對於運行SQL Server的Windows

誤區 #9: 資料庫檔案收縮不會影響效能錯誤! 收縮資料庫檔案唯一不影響效能的情況是檔案末尾有剩餘空間的情況下，收縮檔案指定了TruncateOnly選項。 收縮檔案的過程非常影響效能，這個過程需要移動大量資料從而造成大量IO，這個過程會被記錄到日誌從而造成日誌暴漲，相應的，還會佔去大量的CPU資源。 不僅在收縮的過程中影響效能，並且在檔案收縮之後同樣影響應能，收縮產生的大量日誌會被交易記錄傳送，鏡像，複製能操作重複執行。而空間不夠時，檔案還需要填0初始化從而影響效能（

其實我之前已經有文章詳細解釋了頁校正和：How to tell if the IO subsystem is causing corruptions? 誤區 #17:幾個有關頁校正和的誤區坊間流傳的基本是錯誤的 17 a)頁校正和（Page CheckSum）在從SQL Server 2000或7.0升級上來之後自動開啟 其實不是，從舊的執行個體升級上來的資料庫不會自動開啟頁校正和，除非你顯式使用ALTER DATABASE databasename SET PAGE_VERIFY

誤區 #8: 線上索引操作不會使得相關的索引加鎖錯誤！ 線上索引操作並不是想象的那麼美好。 線上索引操作會在操作開始時和操作結束時對資源上短暫的鎖。這有可能導致嚴重的阻塞問題。 線上索引操作開始時,會在被整理的資源上加一個共用的表鎖,這個表鎖在會在新的索引建立時、老索引進行版本掃描時一直持續。