SQL Q&A: Checksum Problems, Choosing the Correct Recovery Model and More

發行項
08/18/2016

SQL Q&A 選擇正確的復原模型和更多的加總檢查碼問題

Paul S. Randal

Q我在 SharePoint 系統管理員，我最近發現了我的內容資料庫的其中一個損毀時我每月的一致性檢查找到的錯誤。我們反向它追蹤至錯誤的 RAID 控制器，並且之後一些研究我們正在開啟在 [資料庫] 頁面上的總和檢查碼。我的問題是：如何可以我告訴時加總檢查碼發生問題而不需等待直到每月的維護計劃？

A有幾件事您可以執行。第一次，您可以將 WITH CHECKSUM 選項加入您的備份。完整及差異備份，此選項會導致備份作業來測試任何頁總合檢查碼它所見，因發生錯誤，如果發現損毀。 (我這更多詳細說明在上個月的文件，"瞭解 SQL Server 備份」)。

第二個，請考慮超過每月執行一致性檢查。建議至少每的週執行某種形式的一致性檢查是否這是 DBCC CHECKDB 資料庫或可能在還原的資料庫複本上。的就當然要取決於您環境的層級與您的 I/O 子系統。

第三個，加入一些 SQL 代理程式警示。若要引發的各種例如 SQL Server，引發特定嚴重性或跨越臨界值效能計數器發生錯誤所引發的特定錯誤號碼的因素，可以設定警示。這項功能提供一個真正功能強大的機制，要監視的伺服器發生問題。

當引發警示時，訊息傳送至預先定義的運算子使用一個或所有這些選項：呼叫器訊息、電子郵件，或 NET SEND。您可以使用若要定義運算子，預存程序 sp_add_notification.

I/O 子系統的問題是而言，您感興趣的錯誤是 823]、 [824，] 和 [825。 I/O 問題發生時，會引發前兩個 (特別是，824 時頁總和檢查碼發現不是中斷，825 時，則 SQL Server 必須完成之前嘗試讀取的作業多次)。這些是您想要知道儘速為了進一步限制對資料庫 (以及可能的修復的停機時間量) 的所有問題。

823] 和 [824 是兩個嚴重性層級 24 錯誤但 825 只為嚴重性層級 10 資訊」 (如需詳細資訊看到訊息後，我部落格」即將 doom 的一些已知徵兆：錯誤 825.") 下列的錯誤提醒您應該定義所有的重要性層級 24 錯誤，和一個特別為錯誤 825 警示 (在就實際上是最佳的作法有每個嚴重性層級介於 19 到 25 的警示)。

若要定義實際的警示，您可以使用 T-SQL 或管理 Studio。以下是新增提醒 825 錯誤的 T-SQL 程式碼的範例。

USE msdb;
GO 
EXEC msdb.dbo.sp_add_alert @name = N'825 - Read-Retry Required', 
    @message_id = 825,
    @severity = 0,
    @enabled = 1,
    @delay_between_responses = 0,
    @include_event_description_in = 1,
    @category_name = N'IO Subsystem Error';
GO

您可以找到更多的資訊，定義和新增包括新增警示管理 Studio，使用我的 SQL 代理程式部落格上一個逐步解說的警示類別」 ( SQL 2005 SP2 維護計劃 Bug 遮罩損毀)."

Q我在開發人員-DBA 人員負責一些程式碼與資料庫中執行的。我已經被 arguing 與一些其他的資料庫開發人員有關如何取得唯一識別資料表的資料列的值。我想要作為叢集的索引鍵，GUID，但其他的 arguing 可能會導致效能問題的索引。是這個則為 True，如果是這樣，可以解釋為什麼？

A 是的則為 True，GUID 是其中一個前置的 SQL Server 資料庫中的索引片段的原因。

GUID 是一個全域唯一識別元。在 SQL Server，這是 16 位元值是產生在 SQL Server 或其他地方 (例如透過.NET 用戶端或 mid-tier 中)。除非在 SQL Server 2005 引入 NEWSEQUENTIALID 函式以產生 GUID 通常會有隨機值。

這個函式會產生的 GUID 可協助減輕的一些我將說明此問題的範圍。但是它需要產生無法在許多應用程式環境中運作，因為向下傳送資料到資料層之前，必須產生唯一的識別項的伺服器端 GUID。

不論不連續的 GUID 的產生，讓它為前置字元的索引鍵索引中表示，因為索引鍵是基本上是以隨機插入點在索引中新資料錄的是也隨機 (索引鍵資料錄的值會決定它在索引中的位置。這也表示 16 位元 GUID 會出現在每一列的連結可從非叢集索引的記錄瀏覽要取得不在非叢集索引中所使用 (通常也稱為書籤查閱) 的資料行值的查詢選取清單的叢集的索引記錄，儲存引擎的一部分的每個非叢集索引。

為多個資料錄插入索引，[儲存記錄] 頁面會填滿。如果一筆資料錄會被插入已經完整的頁面上 (請記住，金鑰值會決定新的資料錄位置會)，然後頁面必須分割，移動到新配置的頁面部份記錄。頁面分割是昂貴的作業來執行 (配置新的網頁並連結至的索引和資料錄會被移到新頁)，並且片段。

頁面分割可藉由造成實體和邏輯順序的索引中的頁面不同而造成邏輯片段 (這會影響範圍掃描效能) 索引中。它也會造成不良的分頁密度 (可以在頁面上沒有未使用的空間) 的頁面和不佳的磁碟 I/O，記憶體使用率通往浪費的空間。

有關更多索引片段，以及如何偵測及移除，請參閱我的 2008 年 8 月文件」有效維護資料庫的最上層提示." 挑選一個很好的叢集的索引鍵不在本文的範圍內，我會將它保留到我的妻子 Kimberly L。說明 Tripp。請參閱主題也會進入詳細 GUID 和叢集的索引結構」 (後她很棒的部落格 GUID 作為主金鑰和/或叢集的索引鍵.")

Q我們的高可用性策略是使用記錄傳送到數個次要伺服器。我們管理小組 pressuring 我一些使用多餘的伺服器若要儲存在資本支出。我的概念是使用次要伺服器允許報告查詢以執行，也會有將卸載從主要伺服器報告工作負載的好處的。我可能到執行此動作執行什麼問題？

A 這種案例變得目前經濟氣候，位置公司不想要將伺服器坐周圍，似乎是閒置 (即使它們提供冗餘份資料庫) 中更常見的。

您可能已經知道，當您設定記錄傳送，您可以定義如何在次要伺服器上還原交易記錄檔備份，WITH NORECOVERY 或的待命。前者不允許任何存取權之的資料庫而後者則允許唯讀存取資料庫。這會使用特殊模式的修復執行和資料庫交易是以一致但是執行的作業都會儲存在不同的復原檔案中，以便於可以進一步還原交易記錄檔備份 (我將討論這更詳細地下個月的文件中有關使用還原)。

若要允許在次要伺服器上報告，您要使用的待命，使報告查詢可以連接至資料庫。一次您可以讓您立即執行一些問題最多的使用者連線。

第一次，使用的待命選項可能會導致 seeming 長時間的交易記錄檔備份還原次要的伺服器上，必須重新顯示復原檔案的內容下, 一個交易記錄檔備份可以還原之前。如果復原檔案包含大量的作業，這可以是問題。

第二個，還原的交易記錄檔備份不線上作業。沒有人可以連接到資料庫還原的持續期間。這表示您的第二個報表伺服器的所有連線必須是卸除，然後完成還原後重新連線。這裡有一個進退兩難：時的下一個的交易記錄檔備份還原的時候，您終止使用者連線或讓他們完成查詢嗎? 這完全給您。

一個問題，如果您決定不會終止連線，請記住：如何長並允許繼續之前您強制終止查詢? 您等待愈久，長，它是被自最後一次記錄檔備份還原，並進一步的後置次要的一個主要資料庫取得。這可能是問題，若要再容錯移轉至次要，因為可能有記錄檔備份還原等待將為目前最新盡可能，資料庫最小化資料遺失的佇列。

可以找到更多有關這些的選項如資訊和資訊監視的線上叢書》的主題中的次要伺服器上最後一次的記錄檔備份還原後的時間長度等問題" 使用查詢處理第二個伺服器."

Q如何選擇正確的復原模型? 我已讀取項目，好像我應該使用大量登入來減少我交易的記錄檔大小，但它看起來像我的記錄檔大小仍會持續成長。有可能使用模式，並不會在所有使用交易記錄檔完全避免整個問題嗎？

A ne 要求我聽說過多次的為未記錄資料庫時沒有交易記錄檔記錄產生完全 — 特別是針對 tempdb 的人檢視可用的資料庫因為它在伺服器啟動上重新建立。

就我知道這不會發生 SQL Server。您將得到的最是 BULK_LOGGED 模式，大幅剪下] 下的交易記錄量某些產生作業 (例如索引重建和大量載入)。所有資料庫，甚至 tempdb，都必須以允許復原的交易記錄某種層級 (也就是要復原的交易的所有作業) 使用者取消作業或某些錯誤，導致作業失敗的事件。

更重要的對於 tempdb，分開的資料庫是系統當機發生資料庫必須要能夠復原不需要離開交易不一致的資料] 或 [結構不一致 (也就是損毀) 資料庫。想像一下是否發生的內容已被變更之前損毀資料庫中沒有記錄，SQL Server 如何會執行修復？您可以閱讀更多關於運作我二月 2009年本文的記錄及復原」了解記錄和 SQL Server 中的復原."

選擇 [復原模式的一個覆寫的問題會決定您的選擇：要能」的時間點或最新」復原損毀的事件吗？如果是這樣，您要偶爾使用 FULL 復原模式 (和可能 BULK _LOGGED 模型)。如果您不想要執行這項操作，然後使用 SIMPLE 復原模型。

如果您不想要能夠復原資料庫 (而不遺失工作，最後一次資料庫或差異式備份後)，而不是滿的使用 SIMPLE 原因是以 SIMPLE 復原的模型您不需要採取的交易記錄檔備份來管理交易記錄檔的大小。

現在，可能有其他為什麼您必須使用 FULL 復原模式的原因，如果您想要使用的資料庫鏡像 (DBM 只支援 FULL 復原模式) 或記錄傳送 (記錄傳送支援這兩個 [BULK_LOGGED 和 FULL 復原模式) 對於執行個體。在任何的情況下，您要必須確定您要將交易記錄檔備份，使記錄檔無法成長太大 (即使只是您最後捨棄它們)。

我提到可能偶爾會想要使用 BULK_LOGGED 復原模式中，而非經常在該模式中執行。這是因為有一些限制採取，以及當已經是最少式記錄作業 BULK_LOGGED 復原模式中的最後一次交易記錄檔備份後，從記錄檔備份還原。詳細資料都太複雜，說明此的資料行中，但您可以找出更多的以及在線上叢書》的主題中，在就一般選擇復原模式」復原模型概觀."

Randal 保羅 S。是的 [管理] 主管 SQLskills.comMicrosoft 地區主管] 和 [在 SQL 伺服器 MVP。他曾在 SQL Server 儲存引擎小組在 Microsoft 從 1999年 2007。 Paul 撰寫的 SQL Server 2005 的 DBCC CHECKDB/修復但負責核心的儲存引擎在 SQL Server 2008 開發期間。 Paul 是嚴重損壞修復、高可用性和資料庫維護的專家，而且一般在世界各地的會議主持人。在他部落格 SQLskills.com/blogs/paul您可以發現他 Twitter 在上 Twitter.com/PaulRandal.

共用方式為

其他資源