SQL Server 線上維護——虛假宣傳？
我受到了挑戰，因為我們的客戶在執行本應線上維護的過程中遇到了不同類型的錯誤。超時、掃描因數據移動而停止等錯誤。
我們的一些客戶購買了 SQL Server 企業版，以便能夠獲得重建索引線上功能。
為了重現這些問題，我一直在一個大數據庫上測試 dbcc checkdb，重組和重建索引以及更新統計資訊，同時我在一個幾乎 1TB 的數據庫上使用事務轟炸伺服器。
我的第一個測試是使用 maxdop=1 的 checkdb，而 sqlServer 正在處理 124000 個小事務…我從我的應用程序收到超時設置為 5 分鐘。研究檢查數據庫的工作方式，即創建快照，密集使用 tempdb 並創建 nolocks 來創建快照……那麼如果我的一個小事務不鎖定表，它怎麼能被阻止呢？
我的第二個測試是在處理 124000 個事務時重新組織所有索引（也應該是線上的），這次我遇到了死鎖……
我的第三個測試是在執行 124000 個事務時使用 maxdop=1 更新所有統計資訊。在這種情況下收到的錯誤是：Could not continue scan with no lock due to data move
我在執行 124000 個事務時線上重建所有索引的第四次測試將很快執行，我將用結果更新我的文章。
我在可以使用的地方使用的 maxdop=1 是為了消除資源爭用。
我已經閱讀了多篇文章，其中包括 Paul Randal 對重建索引的線上與離線的解釋，並了解其中的區別……但正如我所說，我面臨著解釋為什麼它不是真正線上的挑戰，儘管微軟聲稱它是線上的.
任何輸入將不勝感激。
我錯過了什麼
這裡有很多問題。不過，我有一種感覺，答案不會讓你開心。
DBCC 校驗數據庫
為了重現這些問題，我一直在一個大數據庫上測試 dbcc checkdb，重組和重建索引以及更新統計資訊，同時我在一個幾乎 1TB 的數據庫上使用事務轟炸伺服器。
我不知道我是否將
DBCC CHECKDB“線上維護”與“線上維護”混為一談，但它本質上肯定不是離線活動。話雖如此，它仍然可能是資源密集型的，這可能表現為應用程序“不工作”，儘管數據庫在技術上仍然線上且可用。我從我的應用程序收到了一個超時設置為 5 分鐘的超時……那麼如果我的一個小事務不鎖定表，它怎麼能被阻止呢？
這並不表示任何阻塞，特別是因為除非您指定它應該
DBCC CHECKDB不會導致阻塞。您應該仔細查看監控查詢以了解超時的原因可能是什麼 -老實說，這可能是很多事情。線上索引建構
我的第二個測試是在處理 124000 個事務時重新組織所有索引（也應該是線上的），這次我遇到了死鎖……
是索引重組語句還是其他應用程序語句的死鎖？我不記得曾經對我造成過這個問題的重組，但是死鎖是生活中的一個事實，應用程序應該能夠在遇到它們時優雅地重試。線上操作並不能保證您不會出現死鎖。
大多數人將索引維護安排在夜間/週末，以幫助避免與鎖定、阻塞和資源爭用有關的相關問題。針對正常工作時間的工作負載進行測試必然會給您帶來您所看到的問題。
更新統計
我的第三個測試是在執行 124000 個事務時使用 maxdop=1 更新所有統計資訊。在這種情況下收到的錯誤是：Could not continue scan with no lock due to data move
這個在你身上（或者更確切地說，應用程序）：不要使用
NOLOCK，你不會得到NOLOCK相關的錯誤。同樣，我不確定我是否建議在高容量期間更新繁忙系統上的所有統計資訊，所以這似乎也是一個注定會出現問題的測試。技術定義
我已經閱讀了多篇文章，其中包括 Paul Randal 對重建索引的線上與離線的解釋，並了解其中的區別……但正如我所說，我面臨著解釋為什麼它不是真正線上的挑戰，儘管微軟聲稱它是線上的.
如果你讀過這篇文章，那麼你就會知道線上並不意味著沒有鎖。這個詞的定義是高度上下文相關的。您可以將需要的任何人指向有關線上重建的文件：
雖然不常見，但線上索引操作在與數據庫更新互動時可能會因為使用者或應用程序活動而導致死鎖。在這些極少數情況下，SQL Server 數據庫引擎會選擇使用者或應用程序活動作為死鎖犧牲品。
結論
這就是說，無論維護操作是否能夠“線上”，大多數人都不會在全部工作負載期間對其進行測試，也不期望它們在正常事務量期間能夠正常工作。
大多數時候，即使在維護視窗期間，您也不需要同時重建/重組所有索引或更新**所有統計資訊。**如果您有 VLDB，請將其拆分
DBCC CHECKDB為不同的視窗（就像 Paul 已經很好地介紹了一樣）。我會更多地關注這些事情將如何/何時實際執行。使用像Ola 的維護解決方案這樣的東西，這樣您就不會讓 SQL Server 做更多的工作。
並讓您的客戶降低他們的期望！
也可以看看