DataGuard構築後に使うSQLコマンドまとめ（逆引き）

DataGuard構築後に管理者が押さえておくべきSQLコマンドを逆引きでまとめました。DataGuard環境で一般的に利用するSQLは、マニュアルにも記載されていますが、逆引きの形ではまとまっていません。緊急時など、いざという時に焦らないよう押さえておきましょう。

1.インスタンスのロール（プライマリかスタンバイ）を確認するSQL
2.管理リカバリモードの開始／停止と確認するSQL
3.スイッチオーバーが可能かどうかを確認するSQL
4.スタンバイREDOの作成有無を確認するSQL
5.保護モードの設定を確認するSQL

前提事項

実行例は、OS：Oracle Linux 5.2 64bit、Oracle Database 11gR2で確認しています。 OSやOracleのバージョンによっては異なる結果になる可能性があります。あらかじめご了承ください。また、結果の例は、正常な結果のみを記載しています。各SQLや実行例は、プライマリ、スタンバイのどちらのインスタンスで実施するかを[]内に記載しています。

1. インスタンスのロール（プライマリかスタンバイ）を確認するSQL

利用ケース

プライマリとスタンバイのどちらで作業するかを確認するケース

SQL

--インスタンスのロールを確認[プライマリ／スタンバイ]
COL DB_UNIQUE_NAME FOR A20
COL DATABASE_ROLE FOR A20
SELECT DB_UNIQUE_NAME,DATABASE_ROLE FROM V$DATABASE;

実行例

DATABASE_ROLE列よりプライマリかスタンバイかを判断します。

--プライマリの場合
SQL> COL DB_UNIQUE_NAME FOR A20
COL DATABASE_ROLE FOR A20
SELECT DB_UNIQUE_NAME,DATABASE_ROLE FROM V$DATABASE;
　
DB_UNIQUE_NAME       DATABASE_ROLE
-------------------- --------------------
v1123                PRIMARY

--プライマリの場合
SQL> COL DB_UNIQUE_NAME FOR A20
COL DATABASE_ROLE FOR A20
SELECT DB_UNIQUE_NAME,DATABASE_ROLE FROM V$DATABASE;
　
DB_UNIQUE_NAME       DATABASE_ROLE
-------------------- --------------------
v1123                PRIMARY

--スタンバイの場合
SQL> COL DB_UNIQUE_NAME FOR A20
COL DATABASE_ROLE FOR A20
SELECT DB_UNIQUE_NAME,DATABASE_ROLE FROM V$DATABASE;
　
DB_UNIQUE_NAME       DATABASE_ROLE
-------------------- --------------------
v1123s               PHYSICAL STANDBY

2. 管理リカバリモードの開始／停止と確認するSQL

利用ケース

スタンバイでREDOの適用を開始または停止するケース
※Active Data Guardのライセンスを保有している場合には、OPEN状態で実施、ライセンスを保有していない場合には、MOUNT状態で実施

SQL

--管理リカバリモードの開始（リアルタイム適用しない場合）[スタンバイ]
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
　
--管理リカバリモードの開始（リアルタイム適用する場合）[スタンバイ]
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; 
　
※12cではUSING CURRENT LOGFILE句は不要

--管理リカバリモードを停止[スタンバイ]
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

--管理リカバリモードかどうかを確認[スタンバイ]
SELECT PROCESS,STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';
　　
--リアルタイム適用かどうかを確認[プライマリ]
COL DEST_NAME FOR A30
COL RECOVERY_MODE FOR A50
SET PAGES 1000
SET LINE 1000
SELECT DEST_NAME,RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE TYPE = 'PHYSICAL';

実行例

特にエラーが返されなければ正常終了です。

--管理リカバリモードの開始（リアルタイム適用しない場合）[スタンバイ]
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
データベースが変更されました。
　
--管理リカバリモードの開始（リアルタイム適用する場合）[スタンバイ]
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; 
データベースが変更されました。

−−管理リカバリモードを停止[スタンバイ]
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
データベースが変更されました。

リアルタイム適用かどうかを確認するコマンドは、プライマリで実施する必要があることにご注意ください。
STATUS列がWAIT_FOR_LOG、RECOVERY_MODE列が、MANAGED REAL TIME APPLY であればリアルタイム適用です。

--管理リカバリモードかどうかを確認[スタンバイ]
SQL> SELECT PROCESS,STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';
　
PROCESS                     STATUS
--------------------------- ------------------------------------
MRP0                        WAIT_FOR_LOG
　
--リアルタイム適用かどうかを確認[プライマリ]
SQL> COL DEST_NAME FOR A30
COL RECOVERY_MODE FOR A50
SET PAGES 1000
SET LINE 1000
SELECT DEST_NAME,RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE TYPE = 'PHYSICAL';
　
DEST_NAME                      RECOVERY_MODE
------------------------------ --------------------------------------------------
LOG_ARCHIVE_DEST_2             MANAGED REAL TIME APPLY

3. スイッチオーバーが可能かどうかを確認するSQL

利用ケース

スイッチオーバー前にスイッチオーバーが可能かどうかを確認するケース

SQL

−−スイッチオーバー前の事前確認[プライマリ]
SELECT SWITCHOVER_STATUS FROM V$DATABASE;

実行例

SWITCHOVER_STATUSが、TO STANDBYであればスイッチオーバーが可能です。

−−スイッチオーバー前の事前確認[プライマリ]
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
　
SWITCHOVER_STATUS
------------------------------------------------------------
TO STANDBY

4. スタンバイREDOの作成有無を確認するSQL

利用ケース

最大保護モードや最大可用性モードへ保護モードの設定を変更するケース。最大パフォーマンスモードの場合、スタンバイREDOの作成は10gR2までは必須ではないが、11gR1以降は必須。

SQL

--スタンバイREDOを確認[スタンバイ]
COL STATUS FOR A20
SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

実行例

1行以上の結果が返されたら、スタンバイREDOは存在します。

SQL> --スタンバイREDOを確認[スタンバイ]
COL STATUS FOR A20
SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
　
GROUP#     THREAD#    SEQUENCE#  ARCHIVED  STATUS
---------- ---------- ---------- --------- ----------
         4          1         29       YES     ACTIVE
         5          0          0       YES UNASSIGNED
         6          0          0       YES UNASSIGNED
         7          0          0       YES UNASSIGNED

5. 保護モードの設定を確認するSQL

利用ケース

構築時など保護モードの設定を変更したケース

SQL

--保護モードの確認[プライマリ]
COL PROTECTION_MODE FOR A30
COL PROTECTION_LEVEL FOR A30
SELECT PROTECTION_MODE,PROTECTION_LEVEL FROM V$DATABASE;

実行例

PROTECTION_MODEは、保護モードの設定を確認するための列です。
PROTECTION_LEVELは、現在有効になっている保護モードを確認するための列です。障害が発生している場合にPROTECTION_LEVELの値が変わっているケースがあります。

--最大保護モードの場合[プライマリ]
SQL>  COL PROTECTION_MODE FOR A30
COL PROTECTION_LEVEL FOR A30
SELECT PROTECTION_MODE,PROTECTION_LEVEL FROM V$DATABASE;
　
PROTECTION_MODE                PROTECTION_LEVEL
------------------------------ ------------------------------
MAXIMUM PROTECTION             MAXIMUM PROTECTION
　
--最大可用性モードの場合[プライマリ]
SQL> COL PROTECTION_MODE FOR A30
COL PROTECTION_LEVEL FOR A30
SELECT PROTECTION_MODE,PROTECTION_LEVEL FROM V$DATABASE;
　
PROTECTION_MODE                PROTECTION_LEVEL
------------------------------ ------------------------------
MAXIMUM AVAILABILITY           MAXIMUM AVAILABILITY
　
--最大パフォーマンスモードの場合[プライマリ]
SQL>  COL PROTECTION_MODE FOR A30
COL PROTECTION_LEVEL FOR A30
SELECT PROTECTION_MODE,PROTECTION_LEVEL FROM V$DATABASE;
　
PROTECTION_MODE                PROTECTION_LEVEL
------------------------------ ------------------------------
MAXIMUM PERFORMANCE            MAXIMUM PERFORMANCE

執筆者情報

栗原章二

2006年にアシストに入社し、2011年よりバックサポートとしてお客様対応を行なっているメンバーのフォローを主に行っています。バックサポートの活動として、メンバーが利用する検証環境を構築しています。このブログでは、検証環境構築の手順や、これまでのサポート業務で蓄積してきたノウハウを提供します。

■本記事の内容について
　本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。

■商標に関して
　・Oracle®、Java及びMySQLは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
　・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
　　文中の社名、商品名等は各社の商標または登録商標である場合があります。

【Oracle AI Database 26ai】同時リフレッシュでON COMMITマテリアライズド・ビューのenqueue待ちにサヨナラ！OLTP／DWHスループットを実測検証

本記事では、従来のON COMMIT MViewが抱えてきたこのようなスループット低下や待機イベントのボトルネックを振り返りつつ、Oracle AI Database 26aiが提供する「同時リフレッシュ（Concurrent Refresh）」によって、OLTP／DWHそれぞれのユースケースでどのような改善が見込めるのかを検証していきます。