Share via

  • 發行項

SQL 問答集 未預期的一致性檢查、記憶體使用量疑難排解及其他

Paul S. Randal

問題我注意到異常發生，因為已經移動了某些資料庫到 SQL Server 2005 的項目。 當伺服器啟動時，看錯誤記錄檔，指出 SQL Server 會執行在資料庫上的一致性檢查，做為啟動程序的一部分中的郵件。 它會適合某些的資料庫，但並不適合系統資料庫。 檢查看起來非常快速地執行，不論多少資料庫是，] 及每次啟動 SQL Server。 您可以解釋的狀況吗？

答案非常少數的人有被詢問關於此各種線上論壇中。 以下是其中一個錯誤記錄檔訊息有問題的範例：

2009-06-16 18:12:16.85 spid5s
CHECKDB for database 'master' finished without errors
on 2009-05-12 16:07:15.647 (local time).
This is an informational message only; 
no user action is required.

它肯定不會看起來 」 母片 」 上執行 DBCC CHECKDB (其會執行整個資料庫的一致性檢查)資料庫，但實際上它不是。 這個訊息只關於資料庫稱為 「 最後一個已知的好 」 報告統計資料時間。

從 SQL Server 2005 向前，時 DBCC CHECKDB 完成一致性檢查資料庫而不尋找任何一致性錯誤 (也就是資料庫是無損毀的)，DBCC CHECKDB 完成的時間註記的資料庫 (單一網頁儲存重要的中繼資料相關的資料庫中) 的 [開機] 頁中。

每次啟動資料庫 (執行個體啟動或資料庫上附加)，會檢查 [開機] 頁面，以查看是否有一個預存 「 最後一個已知的良好 」時間，如果因此，會報告錯誤記錄檔中。 不幸的是，沒有任何記錄的方法來查詢這個的值，但是您可以使用未記載的命令數來尋找。 一個夥伴 MVP，Sankar Reddy，最近 blogged 會報告了一個指令碼。

基本原理後儲存 「 最後一個已知的好"時間是它可以在知道多久 (可能) 資料庫可能已經損毀的嚴重損壞修復情況下非常有用。

問題我想要能夠判斷 SQL Server 的記憶體中有多少正由每個資料庫。 我注意到一個 SQL Server 2005 執行個體突然使用伺服器上的幾乎所有可用的記憶體，我擔心的某處有問題。 有可能找出其中這個記憶體正在使用從 SQL Server 中嗎？

答案的好消息是這並不是很有可能發生問題。 SQL Server 2005 會使用最多記憶體，它是可以必要時，但會回應來自作業系統，以釋出記憶體記憶體壓力要求。 您看見突然記憶體使用量可能是展開，讓多個資料庫，會保留在記憶體中緩衝區集區。

緩衝集區 (有時也稱為緩衝快取區) 是 SQL Server 中，儲存引擎層的一部份，並負責管理記憶體中複本部份中不同的資料庫，SQL Server 執行個體中的資料檔案。 如果查詢啟動需要大量的資料庫分頁讀入記憶體 (例如，大型資料表掃描或聯結)，緩衝集區可能抓取從作業系統的多個伺服器記憶體，因此它可以展開。 這可讓它不必一定捨棄記憶體中正在使用的其他查詢的其他資料庫網頁份容納額外的頁面影像在記憶體中。

為一個另外，其中一個新增更多記憶體使用的 SQL Server 的好處是緩衝集區可以較大。 這表示更多的資料可在記憶體中在任何特定的時間可能會導致減少的 I/O 及較佳的工作負載輸送量。

為執行個體如果大量的不同的查詢計劃會被快取中稱為計劃快取區，但我猜測的記憶體的另一個區域的最可能是緩衝集區，如前所述我已有的 SQL Server 使用大量的記憶體，其他可能的原因。

在 SQL Server 2005 中, 您可以決定何種比例的緩衝集區用於使用動態管理檢視] sys.dm_os_buffer_descriptors 每個資料庫。 這個簡單的查詢會告訴您多少 8 KB 頁位於緩衝集區的每個資料庫：

SELECT   
  (CASE WHEN ([is_modified] = 1) THEN 'Dirty'
ELSE 'Clean' END) AS 'Page State',
  (CASE WHEN ([database_id] = 32767) THEN 'Resource Database'
ELSE DB_NAME (database_id) END) AS 'Database Name',
   COUNT (*) AS 'Page Count'FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id], [is_modified]
   ORDER BY [database_id], [is_modified];GO

我解釋這稍微部落格張貼在 「 內部，儲存引擎：緩衝區集區中有什麼?"

其他區段的 SQL Server 會使用的記憶體，您可以使用 [DBCC MEMORYSTATUS] 指令來監視多少記憶體 SQL Server 執行個體正在使用整個，但是它並不允許記憶體使用方式來劃分每個資料庫。 請看一下知識庫文件 907877 的描述"如何使用 [DBCC MEMORYSTATUS] 指令來監視記憶體使用量，在 SQL Server 2005"

問題有時候，通常我們的 SQL Server 2005 執行個體上的資料庫的其中一個會 」 有疑問。我們無法存取的資料庫，而它的狀態是可疑。 偶而狀態會顯示 RECOVERY_PENDING。 我知道這某些排序，損毀所致，但可以您說明它其實是所表示，以及如何修復？ 我們通常會需要從舊的備份還原，並不是理想的資料遺失。

答案有的很多有關這些兩個內容資料庫的混淆的狀態表示，但是您可以更正它們因某種形式的損毀。 它們都表示項目已經損毀修復錯誤。

如果資料庫不完全關機 (亦即如果資料庫關閉時，有未認可的交易) 然後，資料庫啟動時設定一次，它必須通過損毀修復。 損毀修復的確保一次的資料庫已認可的所有交易關機程序會正確反映在的資料庫並在關機時，未認可的所有交易不會都反映在資料庫中的任何方式。

如更深入說明復原如何運作的請參閱我的文件上"瞭解記錄和修復在 SQL Server"從 2 月 2009年問題。

資料庫會知道它是否正常關機向下或未 — 此資訊儲存在我所述第一個問題的解答資料庫開機網頁中。 如果需要損毀修復，則再交易記錄檔必須是可存取，它會儲存其中 (認可) 交易需要會重新顯示所有詳細資料，而且的 (認可) 交易必須復原。 如果交易記錄檔無法使用 (因為它已被刪除，執行個體)、 損毀修復無法啟動，而資料庫狀態會變成 RECOVERY_PENDING。 RECOVERY_PENDING 狀態表示修復無法啟動。

如果交易記錄檔損毀修復啟動執行。 如果它不能完成因任何原因而，資料庫為交易不一致，且狀態變成可疑。 可疑的狀態表示已啟動修復，但無法完成。

有兩個原因復原無法完成。 第一個是損毀交易記錄檔本身中, 導致無法處理 SQL Server 交易記錄檔記錄。 第二個是損毀的資料檔案發生時復原系統正在若要在 [資料庫] 頁面上套用交易記錄檔資料錄] 或 [若要反轉資料庫頁面上的交易記錄檔資料錄的效果。

一個其他的問題可以推資料庫到可疑的狀態。 如果交易已取消使用者或應用程式資料庫遇到損毀時復原的交易影響滾回無法完成然後資料庫不一致交易。 在這種情況下資料庫將會自動離線，並將狀態將設定為可疑]。

有兩個常見的方法，在這種情況下復原。 第一個是從最新的備份還原。 如果您備份舊，您很可能會遺失工作和資料，並應該重新評估您的備份策略與備份多經常要允許復原而不遺失大量資料的目標。 請參閱我的文件"dd822915(v=msdn.10).md 的瞭解 SQL Server 備份"在 7 月 2009年 秘訣有關規劃備份策略的 TechNet 雜誌 的問題。 如果您要在需要還原路由，您應該永遠嘗試一個的記錄尾端] 備份的為 explained，文件中，因為這會讓您復原權限設定對資料庫有疑問的問題點。

如果沒有備份可用，您可以使用稱為緊急模式修復機制。 看一下 我完整的部落格張貼，說明此功能、 解釋它的使用量，並顯示一些範例。

問題我們有同步的資料庫鏡像與 SQL Server 2005 安裝，我們已經注意到有時可能需要相當數秒針對資料庫鏡像容錯移轉時發生錯誤與主要伺服器。 我以為同步的資料庫鏡像使用一個見證原本提供立即的錯誤偵測。 怎麼會這樣呢？

問題見證伺服器與資料庫鏡像的使用只允許鏡像伺服器會自動啟動容錯移轉。 見證同意 (或不) 是否鏡像它可以 「 查看"主要的伺服器。 如果見證和鏡像無法看到主體，鏡像會啟動容錯移轉，並會變成新主體。 在資料庫鏡像設定見證伺服器的存在有沒有軸承如何快速失敗是偵測到或如何快速發生容錯移轉。

立即偵測是一個 misconception) 偵測到失敗時速度取決於失敗的型別。 這裡列出一些範例：

  1. SQL Server 執行個體 (裝載主體資料庫) 損毀。 只要 Windows 仍在執行，而且回應，失敗應該會偵測到最多一秒內。 每一秒，鏡像與見證 Ping 主體。 如果 SQL Server 執行個體並未接聽 TCP 連接埠設定，Windows 就會知道這，並且可以立即回應 SQL Server 並不是有。
  2. 整個主體伺服器當機。 在此情況下，為 Windows 是不有說出 SQL Server 並未定義 TCP 通訊埠上接聽，因此並沒有什麼有說有什麼有。 在這種情況下失敗將不會偵測到之前經過鏡像的夥伴逾時。 這是每秒一次 Ping 必須未回應，直到鏡像宣告的主體失敗的數目。 預設情況下，這個數設定為 10 的 Ping (和是 10 秒)]，但如果已因任何原因而增加，失敗偵測會比較長的時間。
  3. 在主體上失敗，交易記錄檔磁碟機。 一開始不會發生在於 I/O 將開始佇列記錄磁碟機。 後 20 秒，SQL Server 將會列印錯誤記錄檔中的一個警告。 這是不在 40 秒經過 SQL Server 會宣告 ­ 離線記錄磁碟機，並讓資料庫離線，就也觸發鏡像失敗之前。
  4. 資料庫頁面會變成損毀。 在這種情況下如果規則的查詢會碰到損毀，沒有完全反應鏡像。 但是，如果交易已回復與發現頁面損毀，資料庫將會變成可疑，我所述，先前的答案和，就會立即觸發鏡像的失敗。
  5. 如果檔案群組離線主體資料庫中主要檔案群組並不會影響部分資料庫可用性開始在企業版，然後失敗不會發生。 在標準版，但是，失敗會觸發。

如您見鏡像失敗偵測到與速度真的取決於何種失敗發生及是否發生在鏡像的夥伴逾時。

非常感謝 Kimberly L。 SQLskills.com 技術上檢視的 Tripp 這個月的資料行。

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