Always On 可用性グループのデータベースの正常性に関する情報を出力する：SQL Server動的管理ビューレファレンス（10）

「Microsoft SQL Server」が稼働するデータベースシステムを運用する管理者に向け、「動的管理ビュー」の活用を軸にしたトラブル対策のためのノウハウを紹介していきます。今回は、Always On 可用性グループにおけるデータベースの正常性に関する情報の出力について解説します。

[伊東敏章，＠IT]

SQL Server動的管理ビュー一覧

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で使用可能な動的管理ビューについて、動作概要や出力内容などを紹介していきます。今回は、Always On 可用性グループにおけるデータベースの正常性に関する情報を出力する「sys.dm_hadr_database_replica_cluster_states」について解説します。対応バージョンはSQL Server 2012以降です。

概要

　Always On 可用性グループには、複数の可用性データベースを含めることができます。可用性グループにおいて、レプリカの役割（プライマリ、セカンダリ）の変更は可用性レプリカごとに行われますが、同期処理は可用性データベースごとに行われます。

　「sys.dm_hadr_database_replica_cluster_states」動的管理ビューを出力することで、可用性データベースの正常性に関する情報を出力できます。この動的管理ビューを使用して、セカンダリデータベースへのフェールオーバーの準備が整っているか、同期が中断されていないか、さらには強制フェールオーバー時の復旧ポイントなどの情報も確認できます。

• sys.dm_hadr_database_replica_cluster_states（Transact-SQL）

出力内容

列名	データ型	説明
replica_id	uniqueidentifier	可用性レプリカ ID
group_database_id	uniqueidentifier	可用性データベース ID 可用性データベースの全てのレプリカで同値
database_name	sysname	可用性データベース名
is_failover_ready	bit	プライマリデータベースと同期され、フェールオーバーの準備ができているか 　0 = 準備できていない 　1 = 準備できている
is_pending_secondary_suspend	bit	強制フェールオーバー後に、データベースの同期が中断されているか 　0 = 中断されていない 　1 = 中断されている 　NULL = 不明 (クォーラムなし)
is_database_joined	bit	可用性レプリカ上で可用性データベースが可用性グループに参加しているか 　0 = 可用性グループに参加していない 　1 = 可用性グループに参加している 　NULL = 不明 (クォーラムなし)
recovery_lsn	numeric(25,0)	プライマリレプリカでの復旧後またはフェールオーバー後、レプリカが新しいログレコードを書き込む前のトランザクションログの末尾
truncation_lsn	numeric(25,0)	プライマリレプリカの最小のログ切り捨て値

動作例

　3つの可用性レプリカで構成された1つの可用性グループを構成しました（図1）。

図1　構成した可用性グループ

　2つの可用性レプリカが同期コミット、1つの可用性レプリカが非同期コミットで構成されています（図2）。

図2　「SRV01\SQL01」「SRV02\SQL02」が同期コミット、「SRV03\SQL03」が同期コミット

　プライマリレプリカに接続し、「sys.dm_hadr_database_replica_cluster_states」動的管理ビューを出力します（図3）。

図3　全てのレプリカの情報が表示される

　出力結果から、同期コミットに構成された可用性データベースでは「is_failover_ready」列の値が「1」となっており、フェールオーバーの準備が整っていることが分かります。非同期コミットのセカンダリレプリカでは、最新のトランザクションが配布されている状況でも、「is_failover_ready」列の値は「0」となっています。

　次に、同期コミットのセカンダリレプリカインスタンスを停止して、「sys.dm_hadr_database_replica_cluster_states」動的管理ビューを出力します。停止したセカンダリレプリカの「is_failover_ready」列の値が「0」になりました（図4）。

図4　セカンダリレプリカインスタンスを停止すると「is_failover_ready」列の値が「0」になる

　セカンダリレプリカインスタンスを再開せずに、プライマリレプリカで更新処理を繰り返しながら、トランザクションログバックアップを何回か実行します。

　可用性データベースでは、セカンダリレプリカに配布されていないトランザクションログは切り捨てられませんので、「sys.databases」カタログビューの「log_reuse_wait_desc」列の値を確認すると「AVAILABIRITY_REPLICA」となっており、ログの切り捨てを待機させる原因が可用性レプリカであることを確認できます（図5）。

図5　「sys.databases」カタログビューでは、ログの切り捨てを待機させる原因を確認できる

　プライマリレプリカで更新処理を繰り返しながら「sys.dm_hadr_database_replica_cluster_states」動的管理ビューの「truncation_lsn」列の値を確認すると、値が変化しないことが確認できます（図6）。

図6　セカンダリレプリカが停止している状態では、「truncation_lsn」列の値が変化しない

　停止していたセカンダリレプリカを再開し、セカンダリレプリカの同期が再開されると、ログの切り捨ても再開され「truncation_lsn」列の値は更新されました。

※本Tipsは、「Windows Server 2019」上に「SQL Server 2019 CTP2」をインストールした環境を想定して解説しています。

筆者紹介

椎名 武史（しいな たけし）

日本ユニシス株式会社所属。Microsoft MVP for Data Platform（2017〜）。入社以来 SQL Serverの評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。

伊東 敏章（いとう としあき）

日本ユニシス株式会社所属。入社以来SQL Server一筋で評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。社内のプログラミングコンテストで4回の優勝経験も持つ。趣味は輪行で週末は自転車を持っての旅行。目標は色々な日本百選を制覇すること。