web-dev-qa-db-ja.com

存在しないデータベースのデータベースID-ページのバッファラッチを待機するタイムアウトがエラーログに表示されます

背景：最近、さまざまな状態のデータベースがたくさんある新しいショップを始めました。私は今朝（SQL DBAメーリンググループに追加されたばかりです）到着し、昨夜、いずれかのサーバーでCHECKDBジョブが失敗したことに関する電子メールを見つけました（警告を受けたものは問題がありました）。

ここでは詳しく説明しませんが、バッファラッチを待機しているタイムアウトの数が原因であると考えられます。これが原因であるはずであるので、それ自体が原因を特定することは困難です（そして、これが実行されたときの昨夜のシステム使用はほとんどありません。

ログに15秒を超えるI/Oリクエストに関する継続的な問題があり、VMwareの担当者はストレージに関する通信の問題（進行中のネットワークの問題）があると言っているので、これは私が考える問題を説明するためにいくらか行きます。

重要な注意：今朝CHECKDBを再実行したところ、完全に迅速に実行され、エラーは0で、昨夜の失敗以来何も起こっていないことがわかっています。 、（私が間違っている場合は修正してください）、データベースの問題はないと確信しています。昨夜は異常で、ネットワークまたはストレージの問題が原因である可能性があります（ネットワークに関する問題が発生したら、このことについて詳しく知ります私に戻って...もしそうなら）。

これの実際のポイント：ログでは、昨夜のCHECKDBジョブが失敗した時点で、バッファラッチを待機するタイムアウトがあります-奇妙なことに、ラッチしようとしているページのデータベースIDは11であり、インスタンスにそのIDを持つデータベースはありません。IDは10までしかありません。

これに続いて、1つのエラーが見つかり、0が修復され、分割ポイントを持つ内部データベースのスナップショットを指しているCHECKDB行が続きます（エラーログについては以下を参照）

特定の質問：

  1. 存在しないデータベースIDへの参照があるのはなぜですか（内部データベースのスナップショットには、ある時点でデータベースIDが割り当てられますが、それがそれを参照していました）。
  2. とにかく、問題のデータベーススナップショットが何であるかを調べる方法はありますか（それはCHECKDBの動作方法と関係があるのでしょうか、それとも別のものですか）
  3. 問題のスナップショットに何が起こったかを見つける方法はありますか（今朝CHECKDBを再度実行したときは明らかに問題ではなかったため）。

エラーログ：

2017年1月4日23:50 spid101不明DBCC CHECKDB（zenworks_UAL）WITH ARTSLOCAL\svc_zcmsqlによって実行されたno_infomsgsにより、1個のエラーが見つかり、0個のエラーが修復されました。経過時間：0時間28分51秒。内部データベーススナップショットには、分割ポイントLSN = 00adf51f：00019bf4：0001と最初のLSN = 00adf51f：00019bf3：0001があります。

2017年1月4日23:50 spid101不明ラッチタイプSHでページ（1：2067184）を読み取ってラッチできません。ラッチが失敗しました。

2017年1月4日23:50 spid101不明なエラー：8966重大度：16状態：2。

2017年1月4日23:50 spid101不明バッファラッチの待機中にタイムアウトが発生しました-タイプ2 bp 00000004FFFF4A80ページ1：2067184統計0xc2040dデータベースID：11アロケーションユニットID：0/281474976710656タスク0x000000015BA6A088：0待機時間300フラグ0x100000001a所有タスク0x000000015BA6A088。待ち続けない。

enter image description here

注：知る限り、他の誰もデータベースを操作していないか、昨夜の失敗から今朝CHECKDBを実行しています。システムは使用中でしたが、それほどではありませんでした。ログには何も表示されません。

確認のために、ID 11のDBはありません。また、今まであったことはないと思います（そして、昨夜と今朝の間にあるはずがないので、確かです

クエリ：

SELECT db_name(11)

結果：

NULL

クエリ：

SELECT * FROM sys.databases

結果：

╔════════════════════╦═════════════╗
║        name        ║ database_id ║
╠════════════════════╬═════════════╣
║ master             ║           1 ║
║ tempdb             ║           2 ║
║ model              ║           3 ║
║ msdb               ║           4 ║
║ ReportServer       ║           5 ║
║ ReportServerTempDB ║           6 ║
║ z_xxxxxx_L         ║           7 ║
║ z_xxxxxx_p         ║           8 ║
║ S_xxxxxx_t         ║           9 ║
║ z_xxxxxx_t         ║          10 ║
╚════════════════════╩═════════════╝
sql-serversql-server-2008-r2snapshotdbcc-checkdblatch
5
Ian_H

この問題は、ホストでの大量のI/Oの特徴的な症状です。おそらく、その時点でSAN=）で複数のバックアップ、DBCC、およびその他の "メンテナンス"アクティビティが発生している可能性があります。

VMwareの担当者と協力して、SQL Server VMがVMに存在するLUNにPVSCSIアダプターを使用していることを確認します。 VMwareの SQL Serverのベストプラクティス ドキュメントには、SCSIアダプターについて次のように記載されています。

データおよびログVMDKの仮想SCSIコントローラーとして、VMware準仮想化SCSI（PVSCSI）コントローラーを利用します。

PVSCSIコントローラーは、vSphere上のI/O集中型アプリケーションに最適なSCSIコントローラーです。このコントローラーのキューの深さは、デフォルトで64（デバイスごと）および254（コントローラーごと）です（LSIロジックのサイズの2倍SASコントローラー）。PVSCSIコントローラーのデバイスごとおよびコントローラのキューの深さをそれぞれ254と1024に増やして、仮想化されたワークロードのI/O帯域幅をさらに増やすこともできます。 VMware準仮想化SCSI（PVSCSI）アダプタを使用するディスクの構成（1010298） を参照してください。

また、 VMware vSphere環境でキューの深さを増やす方法 も参照してください。

注意：
仮想SCSIコントローラーのデフォルトのキューの深さを増やすことは、SQL ServerベースのVMにとって有益な場合がありますが、適切に行わないと、全体的なパフォーマンスに意図しない悪影響をもたらす可能性もあります。

ヴイエムウェアは、適切なストレージベンダーのサポート担当者と相談して協力し、そのような変更の影響を評価して、仮想SCSIコントローラーのキューの深さの増加をサポートするために必要な推奨事項やその他の調整を取得することを強く推奨します。

複数のvSCSIアダプターを使用します。 OS、データ、トランザクションログを個別のvSCSIアダプターに配置すると、複数のターゲットデバイスに負荷を分散し、オペレーティングシステムレベルでより多くのキューを許可することにより、I/Oを最適化します。すべてのPVSCSIアダプターにI/O負荷を分散して、ゲストからのI/Oを最適化します。多くのデータおよびトランザクションログディスクが必要な場合は、PVSCSIを使用するようにOSブートディスクを設定することも有益です。

SQL Serverのデフォルトのトレースをチェックして、DatabaseID 11が表示されるかどうかを確認します。

これにより、デフォルトのトレースが一時テーブルに読み込まれます。

_DECLARE @trcfilename VARCHAR(1000);

SELECT @trcfilename = path 
FROM sys.traces 
WHERE is_default = 1;

IF OBJECT_ID(N'tempdb..#trctemp', N'U') IS NOT NULL
BEGIN
    DROP TABLE #trctemp;
END

SELECT *
INTO #trctemp
FROM sys.fn_trace_gettable(@trcfilename, default) tt;
_

これにより、_DatabaseID = 11_のトレースイベントが表示されます。

_SELECT tt.DatabaseID
    , tt.DatabaseName
    , tt.StartTime
    , tt.HostName
    , tt.LoginName
    , tt.ApplicationName
    , te.name
FROM #trctemp tt
    LEFT JOIN sys.trace_events te ON tt.EventClass = te.trace_event_id
WHERE tt.DatabaseID = 11 --missing database ID
ORDER BY tt.StartTime DESC;
_

DBCC CHECKDB (db_name) will データベースの内部スナップショットを作成 。スナップショットファイルは、実際のデータベースファイルに添付されたNTFS代替データストリームとして見ることができます。したがって、_dir C:\some\path /r_を実行すると、_C:\some\path_はデータベースファイルの場所です。内部データベーススナップショットファイルは次のように表示されます。

2018-03-29 03:06 PM 402,653,184 Test_DB.mdf 
 402,653,184 Test_DB.mdf：MSSQL_DBCC25：$ DATA

上記のサンプルでは、​​データベースに_Test_DB.mdf_という名前のファイルがあることがわかります。 _Test_DB.mdf:MSSQL_DBCC25:$DATA_という名前の代替データストリームもあります。 _sys.databases_の既存のデータベースIDを関連付けることにより、名前の_25_部分の_DBCC25_がスナップショットのデータベースIDであると推測できます。

2
Max Vernon