SQL 線上問答：無跡可循
像備份與還原還有一致性檢查等處理程序可能會導致一些非預期的行為，但這是有道理的。
Paul S. Randal
還原的嚴格程度
**Q。**我出停機時間要求我們作為災害復原規劃的一部分的 SQL Server 實例的一些工作。 它是充分考慮只需還原備份的時間嗎？
**答：**沒有，您需要考慮的其他一些事情。 首先，考慮還原所有必要的備份所花費的總時間。 這包括您的最新的完整資料庫備份、 最新的差異備份和所有事務記錄備份。 總是假設最壞的情況 — — 凡在考慮下一個完整備份之前，資料庫被破壞了，所以你有盡可能多的記錄備份。
下一步，考慮更多的時間，它將會採取恢復初始的完全備份創建的資料和事務日誌檔 （如果它們已經不存在。 如果您啟用了即時檔初始化，然後將近即時創建資料檔案。 但是，事務日誌檔，必須初始化為零。
如果您有向上數百 gb 的大檔，然後恢復可能需要幾個小時。 如果您然後必須還原差異備份，這將再次完全零初始化事務日誌檔。 你得考慮這個時間。 如果有任何額外的交易被暫時的日誌檔添加 （但不是刪除） 你得初始化為零這些以及 — — 有可能兩次。
資料庫還原過程的最後階段是運行崩潰恢復。 為此所需的時間將取決於您需要多少事務日誌記錄回滾。 他們在最後的記錄備份時未提交的事務的一部分。 如果您在您的資料庫中有長時間運行的事務，最壞的假設。 假設你要回滾幾乎所有的最長可能的交易。 您需要將該時間添加到公式。
最後，還應考慮多長時間物理伺服器，以獲取到那裡可以啟動還原備份點。 換句話說，不會多久才要引導 （運行開機自檢，記憶體檢查，等等），然後啟動 Windows 的伺服器？ 這也可以添加到停機時間。
如果您考慮在其最壞的情況下，它會給您最大的可能停機時間的所有這些事情。 當您添加的一切時，你可能會驚訝。
不要打斷
**Q。**我最近碰到一個有趣的問題。 我試圖打斷正在採取比平時更長的 DBCC CHECKDB 進程。 我發現不能中斷它，並不得不等待很長的時間，為要結束的進程。 你能解釋發生了什麼事情？
**答：**這被預期行為，但不是直觀在所有。 DBCC CHECKDB 啟動時它會創建一個隱藏的資料庫快照。 資料庫快照被需要提供 DBCC CHECKDB 資料庫的事務一致、 不變的視圖。 這樣，DBCC CHECKDB 知道它檢查不應該有損壞的靜態資料庫的一致性。
這一進程的第一次檢查點資料庫創建一個資料庫快照。 然後它將創建空的資料庫快照，並使用資料庫的事務日誌在資料庫快照上運行故障恢復。 換句話說，它將回滾任何活躍的交易到資料庫快照不會實際影響真正的資料庫。 因此，資料庫快照成為事務一致。
雖然創建的資料庫快照是數額和未提交的事務在資料庫中的長度成正比，啟動資料庫快照時運行故障恢復所需時間。 如果有一個長時間運行的事務，則可能需要很長時間才能回滾。 這意味著創建資料庫快照和 DBCC CHECKDB 進程將花費更長時間。
在極端情況下，當創建資料庫快照要花費比正常的長得多，您決定要殺死 DBCC CHECKDB 進程，不會發生馬上。 您必須等待完成之前的進程將回應 kill 信號資料庫快照崩潰恢復。 您不能中斷崩潰恢復，和沒有區別崩潰恢復代碼中在 SQL Server 中和之間有真正的崩潰恢復意外關機後崩潰恢復為資料庫快照。
惟有在這種情況下是重新開機實例的 SQL Server 中，這將刪除隱藏的資料庫快照。 這不會在執行定期資料庫真正崩潰恢復工作。 在這些情況下，實例重新開機後，將繼續崩潰恢復。
有幾種方法，您可以避免這種情況。 嘗試只運行 DBCC CHECKDB 時你知道沒有長時間運行的事務在資料庫中的活動。 您將必須有這些熱軋回作為創建的 DBCC CHECKDB 隱藏的資料庫快照的一部分。 您也可以使用一致性檢查機制，這是要將資料庫還原到另一個伺服器，然後一致性檢查還原的副本。 這完全可以避免長時間運行的事務的可能性。
找到正確的時間
**Q。**上星期我不得不還原備份，以挽救表有人意外下降。 預設跟蹤已經失去了資訊有關當表被刪除，所以這是一個單調乏味的過程，要找到我需要還原的備份位置。 有沒有辦法在我應還原到的時間找到右側點嗎？
**答：**你想要確定除去表時，任何時間檢查預設跟蹤。 這使得資料定義語言 (DDL) 事件的注意。 你可以閱讀更多有關預設跟蹤在 SQL Server 連線叢書。
預設跟蹤的唯一問題是它是一個有限的大小。 它也已被否決而 SQL 伺服器 2012 年擴展事件。 所以如果有大量的伺服器上發生的活動，除去表時的記錄可能不存在跟蹤中任何更多。
這也意味著找到除去表時的唯一方法是做我的稱之為"緩慢通過事務日誌"。到時候表已知存在時間還原資料庫的副本。 然後反復執行時間點恢復使用與注意和與待機選項。 在每次的時間稍微向前移動。 當你發現時表不再存在的時間時，還原資料庫，以在該時間之前只是和您可以檢索表格中的資料。
這個過程是很乏味，可以花很長時間。 每次您使用還原資料庫與待機狀態，所有未提交的事務該點都將回滾到恢復檔案。 下一步還原過程中的撤銷撤銷，恢復多一點，並到恢復檔案回滾再次未提交的事務。 您必須重複此過程，直到你找到正確的時間。
有巧妙的替代方法來執行此操作。 分析中尋找交易稱為 DROPOBJ 的事務記錄備份的日誌記錄。 這樣做與無證的表值函數稱為 fn_dump_dblog。 這在相同的方式更加廣為人知的 fn_dblog，轉儲日誌記錄從一個活動事務日誌，資料庫備份針對工作中的行為。
可以使用此函數來找到的交易記錄的刪除您所感興趣的物件。 然後您可以使用交易記錄的日誌序號 （或 LSN） 來執行還原與損壞 = ' lsn： < 交易記錄的 LSN >'。 這將達，還原事務日誌，但不是包括的交易記錄的刪除表。 這樣做，這樣可以節省從有到如上文所述"英寸通過日誌"。 有關此功能的詳細資訊以及如何使用它，您可以閱讀在我的博客。
事件過濾
**Q。**現在，SQL 追蹤 SQL 伺服器 2012年中已棄用，想要瞭解更多有關擴展事件。 你能解釋一下如何擴展事件理應是更輕量比 SQL 追蹤嗎？
**答：**性能這兩種機制之間的差異的主要原因是事件的篩選方式。 當定義一個跟蹤或事件的會話，您可以篩選基於事件的各項準則的兩宗事件。 在某些資料庫中活性篩選是一個很好的例子。
與 SQL 追蹤事件生成所有的時間。 事件消費程式沒有過濾。 這意味著 SQL Server 負擔沉重與生成的所有事件，即使一些不會被消耗。 這一過程是非常低效的。
擴展的事件，與 SQL Server 中的擴展事件引擎執行事件過濾。 擴展事件引擎計算事件會話被定義時指定的謂詞。 這意味著時觸發該事件，需要收集基地事件資料只有極少的工作。 這樣，可以評估謂詞的事件引擎。 如果謂詞計算結果為 false，則立即丟棄事件。 事件引擎將執行任何進一步的處理。 這將大大減少收集事件時相比 SQL 追蹤的性能開銷。
另外，SQL 追蹤收集與事件關聯的所有列和丟棄不需要的任何列。 另一方面，擴展的事件，僅收集列和指定的其他資料。 這進一步將以觸發事件所需的工作量降至最低。
雖然擴展事件收集故障排除資料遠遠優越的機制，它可以仍然不利影響 SQL Server 的性能，如果仔細構造事件會話，並不是。 如果事件會話要求生產一個 T-SQL 呼叫堆疊，每次一個非常常見的事件發生 （如獲取一個執行緒等待或鎖），這顯然會影響性能。
與任一機制，您應該測試之前將它投入生產的事件集合。 您需要確保工作負荷性能不會受到影響。
.jpg)
Paul S. Randal 是的董事總經理 SQLskills.com，Microsoft 區域主任和 SQL 伺服器 MVP。 他對 SQL Server 儲存引擎團隊在 Microsoft 從 1999 年到 2007 年工作。 他寫 DBCC CHECKDB/修復了 SQL Server 2005，並在 SQL Server 2008 開發期間負責核心儲存引擎。 Randal 是災害復原、 高可用性和資料庫維護方面的專家，經常在世界各地的會議簡報者。 在他的博客 SQLskills.com/blogs/paul，你可以找到他在 Twitter 上和 twitter.com/PaulRandal。