- Oracle Cloud
- Oracle Database
Oracle Cloud VMware Solutionを構築してみました!
前回の記事でOCVSの概要やメリットをお伝えしました。 本記事では実際にOCVSを構築する手順、および作成したvCenterへ実際に接続する手順をお伝えします!
|
DataGuard構築後に管理者が押さえておくべきSQLコマンドを逆引きでまとめました。DataGuard環境で一般的に利用するSQLは、マニュアルにも記載されていますが、逆引きの形ではまとまっていません。緊急時など、いざという時に焦らないよう押さえておきましょう。
実行例は、OS:Oracle Linux 5.2 64bit、Oracle Database 11gR2で確認しています。 OSやOracleのバージョンによっては異なる結果になる可能性があります。あらかじめご了承ください。また、結果の例は、正常な結果のみを記載しています。各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
スタンバイでREDOの適用を開始または停止するケース
※Active Data Guardのライセンスを保有している場合には、OPEN状態で実施、ライセンスを保有していない場合には、MOUNT状態で実施
--管理リカバリモードの開始(リアルタイム適用しない場合)[スタンバイ] 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
スイッチオーバー前にスイッチオーバーが可能かどうかを確認するケース
−−スイッチオーバー前の事前確認[プライマリ] SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUSが、TO STANDBYであればスイッチオーバーが可能です。
−−スイッチオーバー前の事前確認[プライマリ]
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
------------------------------------------------------------
TO STANDBY
最大保護モードや最大可用性モードへ保護モードの設定を変更するケース。最大パフォーマンスモードの場合、スタンバイREDOの作成は10gR2までは必須ではないが、11gR1以降は必須。
--スタンバイ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
構築時など保護モードの設定を変更したケース
--保護モードの確認[プライマリ] 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及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
前回の記事でOCVSの概要やメリットをお伝えしました。 本記事では実際にOCVSを構築する手順、および作成したvCenterへ実際に接続する手順をお伝えします!
Exadata X10Mでは、システムのコアとなるCPUにAMD EPYCプロセッサが搭載されました。気になるのはこれまでのExadataと比べて良くなっているのか?でしょう。今回はCPUにフォーカスして最新のExadataについてご紹介します。
2024年5月のアップデートで、Computeインスタンスを再作成せずにブートボリュームをリストアできるブートボリューム置き換えの機能が追加されました。この機能追加により、従来のリストア方法よりも手順が少なくなり、障害発生時にも迅速な復旧が可能になりました。