ミラーリングセッションがタイムアウトしてフェイルオーバーする原因は何ですか？
SQL Server 2005 SP4を実行し、累積的な更新プログラム3を実行する2つの運用SQL Serverがあります。両方のサーバーは、同一の物理マシンで実行されます。 Dell PowerEdge R815、4 x 12コアCPU、512 GB（yes GB）のRAM、10 GBのiSCSI SANすべてのSQLデータベースおよびログ用に接続されたドライブ。OSはMicrosoft Windows Server 2008 R2 EnterpriseエディションすべてのSPとWindowsのアップデート。OSドライブは3 x 72GB 2.5インチ15kのRAID 5アレイですSASドライブ。SANは48 xのDell EqualLogic 6510です10K SAS 3.5 "ドライブ、RAID 50で構成され、2つのSQL ServerのさまざまなLUNにスライスされ、ExchangeマシンといくつかのVMWareサーバーと共有されます。
20を超えるデータベースがあり、そのうち11はミラーリング監視サーバーを使用して高可用性でミラーリングされています。ミラーリング監視サーバーは、SQLサーバーインスタンスを実行する低能力のマシンであり、ミラーリング監視サービスの提供以外には何も使用されません。最大のミラーリングデータベースは450GBで、約100〜300 IOPSを生成します。データベースミラーリングモニターは、現在の送信速度が毎秒約100 kb〜10 mbであり、ミラーコミットのオーバーヘッドが（通常）0ミリ秒であることを報告します。ミラーサーバーはプリンシパルに追いつくのに問題はありません。
ミラーリングフェイルオーバーが常に発生しています。単一のデータベースがフェイルオーバーする場合もあれば、ほぼすべてのデータベースが同時にフェイルオーバーする場合もあります。たとえば、昨夜、11のデータベースのうち10のフェイルオーバーがあり、残りのデータベースは手動でフェイルオーバーするまでアクセス可能なままでした。
問題を特定するためにいくつかのトラブルシューティング手順を実行しましたが、これまでのところ問題を解決できていません。
1）このマシンには、最初にプライマリネットワーク接続として使用したBroadcom BCM5709C NetXtreme II 4ポートギガビットネットワークアダプターが付属しています。以降、両方のマシンにIntel（R）PRO/1000 PTデュアルポートサーバーアダプターをインストールして、NICを問題として排除しました。
2）すべてのデータベースには、ミラーリングに関係するデータベースのログバックアップに加えて、夜間に自動完全バックアップがあります。ログファイルの使用状況が監視され、15％以上使用されることはほとんどありません。メインデータベースのログファイルは125GBで、サイズは511MBから1GBまでの159の仮想ログファイルで構成されています。 TempDBは独自のLUN上にあり、24 x 2GBファイルで構成されています。
3）ミラーリング監視サーバーのSQL Serverログには、次のエラー以外は表示されません。 "TCP：//SQL02.DOMAIN.INET：5022"へのミラーリング接続が、データベース "データ"に対して30秒後に応答なしでタイムアウトしました。サービスとネットワーク接続を確認してください。
プライマリサーバーとセカンダリサーバーのSQL Serverログに、ミラーリングに関連するメッセージが表示されます。
"TCP：//SQL01.DOMAIN.INET：5022"へのミラーリング接続は、30秒後にデータベース "Data"の応答がないためタイムアウトになりました。サービスとネットワーク接続を確認してください。
ミラーリングされたデータベース「データ」は、役割の同期により、役割を「プリンシパル」から「ミラー」に変更しています。 （同期は、実際のメッセージが表示される方法とまったく同じであるため、ここでは意図的にスペルを誤っています。）
ミラーリングされたデータベース「データ」は、フェイルオーバーにより、役割が「プリンシパル」から「ミラー」に変更されます。
ミラーリングされたデータベース「データ」は、パートナーからのフェイルオーバーにより、役割が「ミラー」から「プリンシパル」に変更されます。
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.DataAccessAdapter.OpenConnection（String dbServerName、String dbName、String userName、String password）にあるMicrosoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection（SqlConnectionInfo ci）にある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 有効0 ブロックプロセスしきい値5 c2監査モード0 clr有効1 有効な共通基準コンプライアンス0 並列処理のコストしきい値4 DB所有権の連鎖0 カーソルしきい値-1 データベースメールXPs 1 デフォルトのフルテキスト言語1033 デフォルトの言語0 デフォルトのトレースが有効1 トリガーからの結果を許可しない0 フィルファクター（％）0 ft crawl bandwidth（max）100 ft crawl bandwidth（min）0 ft notify bandwidth（max）100 ft notify bandwidth（min）0 インデックス作成メモリ（KB）0 未確定xact解決0 軽量プーリング0 ロック0 最大並列度6 最大フルテキストクロール範囲4 最大サーバーメモリ（MB） 393216 最大テキストreplサイズ（B）65536 最大ワーカースレッド0 メディア保持0 クエリあたりのメモリ（KB）2048 分サーバーメモリ（MB）52427 ネストされたトリガー1 ネットワークパケットサイズ（B）1400 Ole自動化手順1 オープンオブジェクト0 PHタイムアウト（s）60 事前計算ランク0 優先度ブースト0 クエリガバナコスト制限0 クエリ待機（s）-1 リカバリ間隔（ min）0 リモートアクセス1 リモート管理接続0 リモートログインタイムアウト（s）20 リモートproc trans 0 リモートクエリタイムアウト（s）600 レプリケーションXP 0 起動プロセスのスキャン0 サーバートリガーの再帰1 ワーキングセットサイズ0の設定 詳細オプションの表示1 SMOおよびDMO XPs 1 SQL Mail XPs 0 変換ノイズワード0 2桁の年のカットオフ2049 ユーザー接続0 ユーザーオプション4216 Web Assistant手続き拘束0 xp_cmdshell 1
少し前に、ミラーリングされたすべてのデータベースのmirroring_connection_timeout値を手動で30秒に変更して、問題の修正を試みました。これにより、フェイルオーバーイベント間の時間が増加しました。 mirroring_connection_timeout設定をデフォルトの10秒に設定すると、lotより多くのフェイルオーバーが発生します。
コメントで、IPSecが無効になっていることを確認するように求められたため、オペレーティングシステムのIPSec構成を表示するいくつかのnetshコマンドの内容を投稿しています。
C：\> netsh ipsec dynamic show all 現在割り当てられているポリシーはありません メインモードポリシーは利用できません。 クイックモードポリシーは利用できません。 一般的なメインモードフィルターは使用できません。 特定のメインモードフィルターは使用できません。 一般的なクイックモードフィルターは使用できません。 特定のクイックモードフィルターは使用できません。 IPsec MainMode Securityアソシエーションは利用できません。 IPsec QuickModeセキュリティアソシエーションは利用できません。 IPsec構成パラメータ ---------------- -------------- StrongCRLCheck：1 IPsecexempt：3 IPsec Statistics --- ------------- アクティブな関連付け：0 オフロードSA：0 保留中のキー：0 キーの追加：0 キーの削除：0 リキー：0 アクティブトンネル：0 不良SPI Pkts ：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日の朝からこれを実行しており、これまでのところフェイルオーバーはありません。しかし、2、3日は、2005ベースのシステムで見た範囲内です。
新しいシステムのパフォーマンスを文書化するために、私はsys.dm_os_wait_statsをより注意深く検討してきました。文書化されていない待機タイプであるDBMIRROR_DBM_EVENTに気づきました。 MicrosoftのGraham Kentには、予期しないフェイルオーバーとこの待機タイプのトラブルシューティングに関して興味深い 記事 があります。ここで彼の調査結果を要約します。
大量のブロッキングチェーンがお客様に発生していたOLTPすべてのヘッドブロッカーがDBMIRROR_DBM_EVENTで待機していたデータベース。ここに、私が経験した一連のイベントがあります。
ブロッキングチェーン自体を確認します。ここで役立つのは、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、送信レートフラット、フラットやり直し率。 DBMモニターが問題の期間中どこからでも値を記録できなかったことを意味するため、これは非常に奇妙です。
SQL Serverエラーログを確認します。この場合、エラーや情報メッセージはまったくありませんでしたが、このような他のシナリオでは、1400の範囲のエラーが報告されることは非常に一般的です。このエラー1413の例
デフォルトのトレースファイルを確認します。このシナリオでは、デフォルトのトレースは提供されませんでしたが、すべてのパートナーの状態変更イベントを記録するため、DBMの問題情報の素晴らしいソースです。
これにより、1つまたはすべてのパートナー間でネットワーク接続に障害が発生した場合や、その後のパートナーシップの状態がどのようになったかなどのシナリオがよくわかります。
結論：
この特定のシナリオでは、現在2つの重要なデータポイントがありませんが、それでも、上記の情報について妥当な仮説を立てることはできます。ブロッキングは、DBMIRROR_DBM_EVENT待機タイプですべてのブロッカーが待機しているため、DBMが有効になっているために発生したと言えます。ログに記録された大規模な操作でミラーをフラッディングしなかったことがわかっているため、この展開は通常、このモードで問題なく動作するため、異常な大規模な操作を除外できます。つまり、この段階では2つの候補者が存在することになります。
一部またはすべてのパートナー間の接続に関するハードウェアの問題。
ミラーサーバーでのCPUの枯渇–単にredoに追いつくことができない– CPUの枯渇自体は、SQL Serverの外部のプロセスまたはこのミラーパートナーシップの外部のプロセスが原因である可能性があります。
ミラーリングコード自体に問題があります（ただし、これを確認するにはメモリダンプが必要です）。
私は1または2の疑いのある経験に基づいていますが、3についても常に心を開いています。この問題をより詳細に調べるために、さらにいくつかのデータを収集しようとしています。
SQL ServerのTCPポートが不足している可能性があります。サーバーに対して一度にいくつの接続が表示されていますか？
そのようなタイムアウトは間違いなく問題を引き起こしています。
確認できますか sys.dm_os_schedulers ？具体的には、work_queue_countかなりの時間、0から逸脱しますか？これは worker starvation を示し、多くの症状を説明します。