累積更新プログラム3を適用したSQL Server 2005 SP4を実行する2つの運用SQLサーバーがあります。両方のサーバーは同一の物理マシンで実行されます。4 x 12コアCPUと512GB（yes GB）のRAMを備えたDELL PowerEdge R815、すべてのSQLデータベースとログ用の10GB iSCSI SAN接続ドライブ。OSはMicrosoft Windows Server 2008 R2 Enterpriseエディションで、すべてのSPおよびWindowsが更新されています。OSドライブは、3 x 72GB 2.5 "15k SASドライブのRAID 5アレイです。SANは、48 x 10K SAS 3.5"ドライブを備えたDell EqualLogic 6510で、RAID 50で構成され、2つのSQL ServerのさまざまなLUNにスライスされ、共有されますExchangeマシンと複数のVMWareサーバーを使用します。
20を超えるデータベースがあり、そのうち11がミラーリングされ、ミラーリング監視サーバーを使用しています。ミラーリング監視サーバーは、ミラーリング監視サービスを提供する以外に使用されないSQL Serverインスタンスを実行する低出力のマシンです。最大のミラーリングされたデータベースは450GBで、約100〜300 iopsを生成します。データベースミラーリングモニターは、現在の送信速度を毎秒約100 kb〜10 mb、ミラーコミットオーバーヘッド（通常）0ミリ秒を報告します。ミラーサーバーは、プリンシパルについていくことに問題はありません。
ミラーリングフェールオーバーが常に発生しています。単一のデータベースがフェールオーバーすることもあれば、ほぼすべてのデータベースが同時にフェールオーバーすることもあります。たとえば、昨夜、11のデータベースのうち10がフェイルオーバーし、手動でフェイルオーバーするまで残りのデータベースはアクセス可能なままでした。
問題を特定するためにいくつかのトラブルシューティング手順を実行しましたが、これまでのところ問題を解決できませんでした。
1）マシンには、最初にプライマリネットワーク接続として使用したBroadcom BCM5709C NetXtreme II 4ポートギガビットネットワークアダプターが付属していました。以来、問題としてNICを排除するために、両方のマシンにIntel（R）PRO / 1000 PTデュアルポートサーバーアダプターをインストールしました。
2）すべてのデータベースには、ミラーリングに関係するデータベースのログバックアップとともに、夜間の自動フルバックアップがあります。ログファイルの使用状況は監視されており、使用率が15％を超えることはめったにありません。メインデータベースのログファイルは125GBで、サイズが511MBから1GBまでの159個の仮想ログファイルで構成されています。TempDBは独自のLUN上にあり、24 x 2GBファイルで構成されています。
3）ミラーリング監視サーバーのSQL Serverのログには、次のエラー以外は表示されません。「TCP：//SQL02.DOMAIN.INET：5022」へのミラーリング接続は、応答なしで30秒後にデータベース「Data」に対してタイムアウトになりました。サービスとネットワーク接続を確認してください。
プライマリサーバーとセカンダリサーバーのSQL Serverログには、ミラーリングに関するメッセージが表示されます。
「TCP：//SQL01.DOMAIN.INET：5022」へのミラーリング接続は、応答なしで30秒後にデータベース「Data」に対してタイムアウトになりました。サービスとネットワーク接続を確認してください。
ミラー化されたデータベース「Data」は、ロールの同期化により、ロールを「PRINCIPAL」から「MIRROR」に変更しています。 （同期は、実際のメッセージが正確に表示される方法であるため、ここでは意図的にスペルを間違えています。）
ミラーリングされたデータベース「Data」は、フェイルオーバーのためにロールを「PRINCIPAL」から「MIRROR」に変更しています。
パートナーからのフェールオーバーにより、ミラーリングされたデータベース「Data」は「MIRROR」から「PRINCIPAL」にロールを変更しています。
SQL Serverサービスは引き続き実行され、ネットワーク接続は維持されているようです。各サーバー（主に、単一のデータベース上のService Brokerキューに接続するロボットアプリケーション）に接続された500〜2500セッションが常にあります。
4）TCP ChimneyおよびRSSなどは、NET SH構文を使用して無効にされます。
5）SQL Server 2005ベストプラクティスアナライザーを両方のマシンに対して実行しましたが、非常にまれに発生するアプリケーションイベントログエラー833以外は見つかりませんでした。フェールオーバーイベントとは一致しません。
SQL Serverは、データベース[データ]（9）のファイル[F：\ Data.MDF]で完了するまでに15秒以上かかるI / O要求が1回発生しました。OSファイルハンドルは0x00000000000010A0です。最新のロングI / Oのオフセットは0x000007d4b10000です）。
6）「クライアントは、接続プーリング用にリセットされたSPID XXXのセッションを再利用できませんでした。このエラーは、以前の操作の失敗が原因である可能性があります。 」両方のサーバーによって生成されます。問題を示す「以前の」メッセージはないようです。
7）データベースメールがアプリケーションイベントログにエラーを書き込むことがあります。
例外の種類：Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseExceptionメッセージ：接続でエラーが発生しました。理由：タイムアウトになりました。操作の完了またはサーバーが応答しない前にタイムアウト期間が経過しました。接続パラメーター：サーバー名：MGSQL02、データベース名：msdbデータ：System.Collections.ListDictionaryInternal TargetSite：Void OpenConnection（Microsoft.SqlServer.Management.Common。 SqlConnectionInfo）HelpLink：NULLソース：DatabaseMailEngine
Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection（SqlConnectionInfo ci）のMicrosoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnection（String dbServerName、String dbName、String userName、String passwordのStackTrace情報）Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems（String dbName、String dbServerName、Int32 lifetimeMinimumSec、LogLevel loggingLevel）
タイムアウトがフェールオーバーを引き起こしていると思います。これらのタイムアウトの原因は何ですか？明らかに、ケーブルの不良やスイッチの不良など、実際のネットワークの問題があった場合、パケット損失とタイムアウトが発生する可能性がありますが、他にタイムアウトが発生する可能性があるものはありますか？ブロッキング？MSDBまたは他のシステムデータベースにI / Oタイムアウトがある場合、ミラーリングフェールオーバーが発生する可能性がありますか？
アドバイスをありがとう！
MSDNには、タイムアウトメカニズム自体について次のように記述されています。
ミラーリングのタイムアウトメカニズム
ソフトエラーはサーバーインスタンスによって直接検出されないため、ソフトエラーによりサーバーインスタンスが無期限に待機する可能性があります。これを防ぐために、データベースミラーリングでは、ミラーリングセッションの各サーバーインスタンスに基づいて、開いている接続ごとに固定間隔でpingを送信する独自のタイムアウトメカニズムを実装します。
接続を開いたままにするために、サーバーインスタンスは、定義されたタイムアウト期間内にその接続でpingを受信し、さらにpingをもう1つ送信するのに必要な時間を受信する必要があります。タイムアウト期間中にpingを受信すると、接続がまだ開いており、サーバーインスタンスがそれを介して通信していることを示します。pingを受信すると、サーバーインスタンスはその接続のタイムアウトカウンターをリセットします。
タイムアウト期間中に接続でpingが受信されない場合、サーバーインスタンスは接続がタイムアウトしたと見なします。サーバーインスタンスは、タイムアウトした接続を閉じ、セッションの状態と動作モードに従ってタイムアウトイベントを処理します。
netsh interface tcp show global ショー：
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disabled
netsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510
SELECT name, value_in_use FROM sys.configurations
アドホック分散クエリ0
アフィニティI / Oマスク0
アフィニティマスク0
affinity64 I / Oマスク0
affinity64マスク0
エージェントXP 1
更新を許可0
we敬の念を有効に0
ブロックされたプロセスのしきい値5
c2監査モード0
clr有効1
有効な共通基準コンプライアンス0
並列処理のコストしきい値4
クロスDB所有権チェーン0
カーソルのしきい値-1
データベースメールXP 1
デフォルトのフルテキスト言語1033
デフォルト言語0
デフォルトのトレースが有効1
トリガー0からの結果を許可しません
フィルファクター（％）0
ftクロール帯域幅（最大）100
ftクロール帯域幅（分）0
ft通知帯域幅（最大）100
ft通知帯域幅（分）0
インデックス作成メモリ（KB）0
未確定のxact解像度0
軽量プーリング0
ロック0
最大並列度6
フルテキストクロールの最大範囲4
最大サーバーメモリ（MB）393216
最大テキストreplサイズ（B）65536
最大ワーカースレッド0
メディア保持0
クエリごとの最小メモリ（KB）2048
最小サーバーメモリ（MB）52427
ネストされたトリガー1
ネットワークパケットサイズ（B）1400
オーレ自動化手順1
オブジェクトを開く0
PHタイムアウト（秒）60
事前計算ランク0
優先度ブースト0
クエリガバナーのコスト制限0
クエリ待機（s）-1
回復間隔（分）0
リモートアクセス1
リモート管理接続0
リモートログインタイムアウト（秒）20
リモートプロシージャトランス0
リモートクエリタイムアウト（秒）600
レプリケーションXP 0
スタートアッププロシージャ0のスキャン
サーバートリガー再帰1
ワーキングセットサイズ0を設定します
高度なオプションを表示1
SMOおよびDMO XP 1
SQL Mail XPs 0
ノイズワード0の変換
2桁の年のカットオフ2049
ユーザー接続0
ユーザーオプション4216
Web Assistantの手順0
xp_cmdshell 1
少し前に、mirroring_connection_timeoutミラーリングされたすべてのデータベースの値を手動で30秒に変更して、問題の修正を試みました。これにより、フェイルオーバーイベント間の時間が単純に長くなりました。でmirroring_connection_timeout10秒のデフォルトの設定のセット、私たちが見るたくさんより多くのフェイルオーバー。
IPSecが無効になっていることを確認するようにというコメントがあったためnetsh、オペレーティングシステムのIPSec構成を表示するいくつかのコマンドの内容を投稿しています。
C：\> netsh ipsec dynamic show all 現在割り当てられているポリシーはありません メインモードポリシーは利用できません。 クイックモードポリシーは利用できません。 汎用メインモードフィルターは使用できません。 特定のメインモードフィルターは使用できません。 汎用クイックモードフィルターは使用できません。 特定のクイックモードフィルターは使用できません。 IPsec MainModeセキュリティアソシエーションは利用できません。 IPsec QuickModeセキュリティアソシエーションは利用できません。 IPsec構成パラメーター ------------------------------ StrongCRLCheck：1 IPsecexempt：3 IPsec統計 ---------------- アクティブな連合：0 SAのオフロード：0 保留キー：0 キーの追加：0 キー削除：0 キー再生成：0 アクティブなトンネル：0 悪いSPIパケット：0 復号化されていないパケット：0 認証されていないパケット：0 リプレイ検出付きのパケット：0 送信された機密バイト：0 受信した機密バイト：0 送信された認証済みバイト：0 受信した認証済みバイト：0 送信された転送バイト：0 受信したトランスポートバイト：0 トンネルで送信されたバイト数：0 トンネルで受信したバイト：0 オフロード送信バイト数：0 オフロードされた受信バイト数：0 C：\> netsh ipsec static show all ERR IPsec [05072]：ポリシーストアにポリシーがありません
更新：2012-12-20
これで、運用システムをSQL Server 2012に移行しました。12月17日の朝からこれを実行していますが、これまでのところフェールオーバーはありません。ただし、2005年ベースのシステムで見た範囲内で数日は十分です。
私たちの新しいシステムのパフォーマンスを文書化するために、私はsys.dm_os_wait_statsもっと注意深く見てきました。そしてDBMIRROR_DBM_EVENT、ドキュメント化されていない待機タイプであることに気付きました。MicrosoftのGraham Kentが、予期しないフェイルオーバーとこの待機タイプのトラブルシューティングに関する興味深い記事を公開しています。ここで彼の発見を要約します。
顧客は、すべてのヘッドブロッカーがDBMIRROR_DBM_EVENTで待機している大容量OLTPデータベース上に構築された巨大なブロッキングチェーンを経験していました。以下に、私が経験した一連のイベントを示します。
ブロッキングチェーン自体を確認します-ここで役立つのは、DBMIRROR_DBM_EVENTで待機していることだけです。
文書化されていない待機タイプのソースを確認してください。明らかに、MSの外でこれを行うことはできませんが、この待機タイプは、プリンシパルがミラーがLSNを強化するのを待機しているときに使用する待機を表していると言えます。 。これは、プリンシパルがミラーで待機しているためトランザクションをコミットできないという問題をすぐに具体的に示しています。ここで、ミラーがトランザクションをコミットしていない理由、またはプリンシパルがトランザクションをコミットしていない理由を調査する必要があります。
msdbシステムテーブルを確認する
（a）[backupset]テーブルを調べて、問題発生時に生成されたログのサイズが通常よりも大幅に大きいかどうかを確認します。それらが非常に大きい場合は、ミラーがトランザクションであふれており、ボリュームに追いついていない可能性があります。このため、インデックスの再構築など、非常に大規模なログ操作を行う必要がある場合、オンラインブックからミラーリングを無効にするように指示されることがあります。（これがhttp://technet.microsoft.com/en-us/library/cc917681.aspxにある理由の参照）。ここでは、次のTSQLを使用しました
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'（b）次に、テーブル[dbm_monitor_data]のデータを見ました。ここで重要なのは、問題が発生した時間枠を特定し、次のいずれかの変更が大幅に発生しているかどうかを確認することです。
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateこれらはすべて、応答していないコンポーネントまたはアーキテクチャの一部を示す可能性があるという点で、パート（a）と同様のインジケータです。たとえば、send_queueが突然大きくなり、re_doキューが大きくならない場合、プリンシパルはログレコードをミラーに送信できないため、接続性やサービスブローカーのキューを確認したいことを意味します。実際の送信を処理します。
この特定のシナリオでは、すべてのカウンターが奇妙な値を持っているように見え、通常のサイズのログバックアップが行われたが、ステータスの変更はなく、0送信キュー、0 REDOキュー、フラット送信レート、フラットやり直し率。これは、DBMモニターが問題期間中どこからでも値を記録できなかったことを意味するため、非常に奇妙です。
SQL Serverエラーログを確認します。この場合、エラーや情報メッセージはまったくありませんでしたが、このような他のシナリオでは、1400の範囲のエラーが報告されることが非常に一般的です。その例は、他のミラーリングブログの他の場所で見つけることができます。このエラー1413の例
デフォルトのトレースファイルを確認します。このシナリオでは、デフォルトのトレースは提供されませんでしたが、すべてのパートナーの状態変更イベントを記録するため、DBMの問題情報の素晴らしいソースです。
これにより、1つまたはすべてのパートナー間でネットワーク接続が失敗したときや、その後のパートナーシップの状態がどのようになったかなど、シナリオの全体像がよくわかります。
結論：
この特定のシナリオでは、現在2つの重要なデータが欠落していますが、それとは別に、上記の情報について妥当な仮説を立てることができます。ブロッキングは、すべてのブロッカーがDBMIRROR_DBM_EVENT待機タイプを待機しているために、DBMが有効にされたという事実によって引き起こされたと言うことができます。大規模なログ操作でミラーをフラッディングせず、この展開は通常このモードで正常に実行されることがわかっているため、通常ではない大規模な操作を除外できます。これは、この段階で2つの潜在的な候補があることを意味します。
一部またはすべてのパートナー間の接続に関するハードウェアの問題。
ミラーサーバーでのCPUの枯渇-単にREDOに対応できない-CPUの枯渇自体は、SQL Serverの外部またはこのミラーパートナーシップの外部のプロセスから発生する可能性があります。
ミラーリングコード自体に問題があります（ただし、これを確認するにはメモリダンプが本当に必要です）。
経験に基づいて、1または2を疑いますが、常に3についても心を開いています。この問題をさらに詳しく調べるために、さらにデータを収集しようとしています。