sys.availability_groups (Transact-SQL)
適用対象:SQL Server
SQL Server のローカル インスタンスが可用性レプリカをホストしている各可用性グループの行を返します。 各行には、可用性グループ メタデータのキャッシュされたコピーが含まれます。
列名 | データ型 | 説明 |
---|---|---|
group_id | uniqueidentifier | 可用性グループの一意識別子 (GUID)。 |
name | sysname | 可用性グループの名前。 これはユーザー指定の名前であり、Windows Server フェールオーバー クラスター (WSFC) 内で一意であることが必要です。 |
resource_id | nvarchar(40) | WSFC クラスター リソースのリソース ID。 |
resource_group_id | nvarchar(40) | 可用性グループの WSFC クラスター リソース グループのリソース グループ ID。 |
failure_condition_level | int | 自動フェールオーバーをトリガーする必要があるユーザー定義の障害条件レベル。この表のすぐ下の表に示されている整数値の 1 つです。 エラー状態レベルの範囲は 1 ~ 5 で、レベル 1 が最も制限が緩く、レベル 5 が最も制限の厳しい指定です。 任意の状態レベルは、それより制限が緩いすべてのレベルを含みます。 したがって、最も厳しい状態レベル 5 にはそれより制限が緩い状態レベル (1 から 4) が含まれ、レベル 4 にはレベル 1 から 3 が含まれます。以下同様です。 この値を変更するには、ALTER AVAILABILITY GROUPTransact-SQL ステートメントの FAILURE_CONDITION_LEVEL オプションを使用します。 |
health_チェック_timeout | int | サーバー インスタンスが低速であるか応答していないと見なされるまで、sp_server_診断 システム ストアド プロシージャがサーバー正常性情報を返すまでの待機時間 (ミリ秒)。 既定値は 30000 ミリ秒 (30 秒) です。 この値を変更するには、ALTER AVAILABILITY GROUPTransact-SQL ステートメントの HEALTH_CHECK_TIMEOUT オプションを使用します。 |
automated_backup_preference | tinyint | この可用性グループ内の可用性データベースに対してバックアップを実行するための推奨される場所。 使用される値とその説明を次に示します。 0 : プライマリ。 バックアップは常にプライマリ レプリカで行う必要があります。 1 : セカンダリのみ。 セカンダリ レプリカでバックアップを実行することをお勧めしています。 2: セカンダリを優先します。 セカンダリ レプリカでバックアップを実行することをお勧めしますが、バックアップ操作に使用できるセカンダリ レプリカがない場合は、プライマリ レプリカでバックアップを実行できます。 これが既定の動作です。 3: 任意のレプリカ。 バックアップがプライマリ レプリカとセカンダリ レプリカのどちらで実行されるかに関する設定はありません。 詳細については、「アクティブなセカンダリ: セカンダリ レプリカでのバックアップ (Always On 可用性グループ)」を参照してください。 |
automated_backup_preference_desc | nvarchar(60) | automated_backup_preferenceの説明。次のいずれかです。 PRIMARY SECONDARY_ONLY SECONDARY NONE |
version | smallint | Windows フェールオーバー クラスターに格納されている可用性グループ メタデータのバージョン。 このバージョン番号は、新機能が追加されるとインクリメントされます。 |
basic_features | bit | これが Basic 可用性グループかどうかを指定します。 詳細については、「基本的な可用性グループ (AlwaysOn 可用性グループ)」を参照してください。 |
dtc_support | bit | この可用性グループに対して DTC サポートが有効になっているかどうかを指定します。 CREATE AVAILABILITY GROUP の DTC_SUPPORT オプションによって、この設定が制御されます。 |
db_failover | bit | 可用性グループがデータベースの正常性状態のフェールオーバーをサポートするかどうかを指定します。 CREATE AVAILABILITY GROUP の DB_FAILOVER オプションによって、この設定が制御されます。 |
is_distributed | bit | これが分散型可用性グループかどうかを指定します。 詳細については、「分散型可用性グループ (AlwaysOn 可用性グループ)」を参照してください。 |
cluster_type | tinyint | 0: Windows Server フェールオーバー クラスター 1: 外部クラスター (Linux Pacemaker など) 2: なし |
cluster_type_desc | nvarchar(60) | クラスターの種類のテキストの説明 |
required_synchronized_secondaries_to_commit | int | コミットが完了するために同期状態である必要があるセカンダリ レプリカの数 |
sequence_number | bigint | 可用性グループの構成シーケンスを識別します。 可用性グループのプライマリ レプリカがグループの構成を更新するたびに増分的に増加します。 |
is_contained | bit | 1: 高可用性のために構成されたビッグ データ クラスター マスター インスタンス。 0: その他すべて。 |
エラー条件レベルの値
次の表では、failure_condition_level列で発生する可能性のあるエラー条件レベルについて説明します。
Value | エラーの状態 |
---|---|
1 | 次のいずれかが発生した場合に自動フェールオーバーを開始する必要があることを指定します。 - SQL Server サービスがダウンしています。 - サーバー インスタンスから ACK を受信しないため、WSFC フェールオーバー クラスターに接続するための可用性グループのリースが期限切れになります。 詳細については、「How It Works:SQL Server Always On Lease Timeout」 (動作方法: SQL Server Always On のリース タイムアウト) を参照してください。 |
2 | 次のいずれかが発生した場合に自動フェールオーバーを開始する必要があることを指定します。 - SQL Server のインスタンスがクラスターに接続せず、可用性グループのユーザー指定のhealth_チェック_timeoutしきい値を超えています。 - 可用性レプリカが失敗状態です。 |
3 | 孤立したスピンロック、重大な書き込みアクセス違反、ダンプが多すぎるなどの重大な SQL Server 内部エラーが発生した場合に自動フェールオーバーを開始する必要があることを指定します。 これが既定値です。 |
4 | SQL Server 内部リソース プールに永続的なメモリ不足の状態があるなど、中程度の SQL Server 内部エラーが発生した場合に自動フェールオーバーを開始する必要があることを指定します。 |
5 | 以下のような任意の修飾エラー状態に対して自動フェールオーバーを開始する必要があることを指定します。 - SQL エンジンワーカースレッドの枯渇。 - 解決できないデッドロックの検出。 |
セキュリティ
アクセス許可
サーバー インスタンスに対する VIEW ANY DEFINITION 権限が必要です。
参照
sys.availability_replicas (Transact-SQL)
Always On 可用性グループ (SQL Server)
可用性グループの監視 (Transact-SQL)
可用性グループの監視 (Transact-SQL)
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示