
- Oracle Cloud
- Oracle Database
Oracle Cloud VMware SolutionでのVMware HCX環境構築手順(後編)
前回の記事でOCVS)でHCXを利用するための前提となる手順の前半をお伝えしました。本記事では後続の手順であるサービスメッシュ作成・L2延伸手順を記載し、仮想マシンを移行できる状態、つまりHCX環境の構築完了までを説明します。
|
Real Application Clusters One Node(以下、RAC One Node)は、Oracle Database 11g Release2から提供されている新機能です。2台のサーバーを使用しますが、Real Application Clusters(以下、RAC)とは異なりインスタンスが稼働するのはそのうち1台のサーバーのみです。いわゆるアクティブ・スタンバイ構成と呼ばれているものに近い構成です。
RAC One Nodeの登場から時間が経ち、ご利用のお客様も多くなり、RAC One Node環境で発生した障害のお問い合わせをいただくことも増えました。RAC One Nodeはアラートログの仕組みが独特なため、調査に必要なログの判断がお客様側では難しい場合があります。
そこで今回は、RAC One Nodeのアラートログがどのように作成されているのか、その仕組みをご紹介します。
アラートログは「alert_<SID>.log」という名称で作成されます。SIDとインスタンスは通常同じ名前です。
アラートログの名称にSID(インスタンス名)が含まれるため、RAC One Nodeのアラートログについて理解する際にはRAC One Nodeのインスタンス名の仕組みを押さえることが重要です。
RAC One Nodeデータベースのインスタンス名は「<データベース名>_1」または「<データベース名>_2」となっており、接尾辞「_1」、「_2」がつきます。この接尾辞はオンライン・データベース再配置(srvctl relocate databaseコマンドでインスタンスを対向ノードに移動させる処理)を行った際にのみ変更されます。
[検証環境情報]
ノード1:supodax51、ノード2:supodax52、データベース名:ron
--現在のインスタンス名、インスタンス稼働ノードを確認 $ srvctl status database -db ron インスタンスron_1はノードsupodax51で実行中です。 オンライン再配置: INACTIVE --オンライン・データベース再配置を実行 $ srvctl relocate database -db ron -node supodax52 --オンライン・データベース再配置後のインスタンス名、インスタンス稼働ノードを確認 $ srvctl status database -d ron インスタンスron_2はノードsupodax52で実行中です。 オンライン再配置: INACTIVE
RAC One Nodeのインスタンスは、オンライン・データベース再配置の実施以外にもサーバー障害等により対向ノードに移動されます(フェイルオーバーと言います)。フェイルオーバー時にはインスタンスの接尾辞は変更されません。また、srvctlコマンドでデータベースを再起動しても変更されません。インスタンスを別ノードで起動した場合も同じです。
--現在のインスタンス名、インスタンス稼働ノードを確認 $ srvctl status database -db ron インスタンスron_1はノードsupodax51で実行中です。 オンライン再配置: INACTIVE --データベースを再起動 $ srvctl stop database -db ron $ srvctl start database -db ron --データベース再起動後のインスタンス名、インスタンス稼働ノードを確認 $ srvctl status database -db ron インスタンスron_1はノードsupodax51で実行中です。 オンライン再配置: INACTIVE --データベースを対向ノードで起動 $ srvctl stop database -db ron $ srvctl start database -db ron -node supodax52 --対向ノードで起動後のインスタンス名、インスタンス稼働ノードを確認 $ srvctl status database -db ron インスタンスron_1はノードsupodax52で実行中です。 オンライン再配置: INACTIVE --この状態でオンライン・データベース再配置を実施 $ srvctl relocate database -db ron -node supodax51 --オンライン・データベース再配置後のインスタンス名、インスタンス稼働ノードを確認 $ srvctl status database -db ron インスタンスron_2はノードsupodax51で実行中です。 オンライン再配置: INACTIVE
このようにインスタンス名とインスタンス稼働ノードとの間には相関関係がないため、それぞれのノードで2種類の名称のインスタンス(「<データベース名>_1」「<データベース名>_2」)が起動する可能性があります。
上述のとおり、RAC One Node環境ではそれぞれのノードで「<データベース名>_1」「<データベース名>_2」という名称のインスタンスが起動し得るため、アラートログも各ノードで2つずつ、最大で合計4つ作成されます。1つのデータベース毎に4つですので、データベースが複数あればデータベース×4のアラートログが作成されることになります。
例:
データベース名がronであれば、起動するインスタンス名は「ron_1」/「ron_2」になります。
各インスタンス(「ron_1」/「ron_2」)が両方のノードで起動するため、「alert_ron_1.log」/「alert_ron_2.log」が両方のノードで作成され、合計4つのアラートログが存在します。
|
ここまでの説明だけではイメージしづらいかと思いますので、ユーザから「検証作業中にエラーが発生した」という連絡を受けた状況を想定したアラートログの確認例を見ていきましょう。
前提:
19時頃、RAC One Node環境を使用しているユーザから「18時頃に検証作業中に突然エラーが発生した。エラーコードを控えられていないため原因調査して欲しい。」との連絡が入りました。当時のインスタンス稼働状況などの詳細が不明なため、アラートログから状況を追う必要があります。
まずは現在のインスタンス名、インスタンス稼働ノードを確認します。
$ srvctl status database -db ron インスタンスron_1はノードsupodax51で実行中です。 オンライン再配置: INACTIVE
インスタンスはノード1(supodax51)にてインスタンス名「ron_1」で起動していることが分かりました。そのためノード1に出力されている「alert_ron_1.log」を確認すればよいだろうと当たりをつけ、「alert_ron_1.log」を確認します。
アラートログの出力先はOracle Databaseのバージョンにより異なります。11gR1以降は「$ADR_BASE/diag/rdbms/<データベース名>/<SID>/trace/alert_<SID>.log」です。※ADR_BASEは初期化パラメータDIAGNOSTIC_DESTで指定されているディレクトリです。
$ hostname supodax51 $ pwd /u01/app/oracle/diag/rdbms/ron $ ls -l 合計 8 -rw-r----- 1 oracle oinstall 0 10月 20 2016 i_1.mif drwxr-x--- 16 oracle oinstall 4096 10月 20 2016 ron_1 drwxr-xr-x 16 oracle oinstall 4096 10月 31 2016 ron_2 $ cd ron_1/trace/ $ ls -l alert_ron_1.log -rw-r----- 1 oracle oinstall 447061524 11月 20 18:30 alert_ron_1.log $ less alert_ron_1.log : --インスタンス停止開始 Tue Nov 20 17:38:25 2018 Instance reconfiguration: current system load 19 (hiload) Tue Nov 20 17:38:25 2018 Reconfiguration started (old inc 2, new inc 4) List of instances (total 2) : 1 2 New instances (total 1) : 2 My inst 1 Global Resource Directory frozen Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out : Tue Nov 20 17:38:39 2018 Shutting down instance (transactional local) : --インスタンス停止完了 Tue Nov 20 17:39:11 2018 Instance shutdown complete --インスタンス起動開始 Tue Nov 20 18:15:45 2018 Starting ORACLE instance (normal) (OS id: 86321) : --インスタンス起動完了 Tue Nov 20 18:16:00 2018 minact-scn: Inst 1 is a slave inc#:8 mmon proc-id:86532 status:0x2 minact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0000.00000000 gcalc-scn:0x0000.00000000 Starting background process CJQ0 Completed: ALTER DATABASE OPEN /* db agent *//* {1:25591:58361} */ :
しかし「alert_ron_1.log」にはORAエラーが出力されている形跡が見られず、ユーザ申告のエラー発生時間帯である18時頃にはオンライン・データベース再配置が行われた形跡が見受けられました。そのためノード2の「alert_ron_2.log」を確認します。
$ hostname supodax52 $ pwd /u01/app/oracle/diag/rdbms/ron $ ls -l total 8 -rw-r----- 1 oracle oinstall 0 Oct 28 2016 i_1.mif drwxr-xr-x 16 oracle oinstall 4096 Feb 22 2017 ron_1 drwxr-xr-x 16 oracle oinstall 4096 Oct 28 2016 ron_2 $ cd ron_2/trace/ $ ls -l alert_ron_2.log -rw-r----- 1 oracle oinstall 567275 Nov 20 18:16 alert_ron_2.log $ less alert_ron_2.log : --インスタンス起動開始 Tue Nov 20 17:38:22 2018 Starting ORACLE instance (normal) (OS id: 73013) : --インスタンス起動完了 Tue Nov 20 17:38:37 2018 minact-scn: Inst 2 is a slave inc#:4 mmon proc-id:73698 status:0x2 minact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0000.00000000 gcalc-scn:0x0000.00000000 Starting background process CJQ0 Completed: ALTER DATABASE OPEN /* db agent *//* {1:25591:57941} */ : --ORA-1652エラー発生 Tue Nov 20 17:59:53 2018 ORA-1652: unable to extend temp segment by 128 in tablespace TEMP2 : --インスタンス停止開始 Tue Nov 20 18:16:02 2018 Shutting down instance (transactional local) : --インスタンス停止完了 Tue Nov 20 18:16:25 2018 Instance shutdown complete
ノード2の「alert_ron_2.log」にORA-1652エラーが出力されていることが確認できました。他にエラーの出力は確認できず、ユーザ申告のエラー発生時間帯とも合致するため、これが問題のエラーと判断します。
このように、RAC One Node環境でアラートログを確認する際は、確認したい時間帯にどちらのノードでどのインスタンス名でインスタンスが稼働していたかを意識する必要があります。当時の状況が不明な場合は各アラートログを1つずつ確認するしかありません。
ただ、RAC One NodeはOracleデータ・リカバリ・ポリシーが適用される構成のため、通常はノード1でインスタンスが稼働します。そのためノード1のアラートログを優先的に確認するのが良いでしょう。※Oracleデータ・リカバリ・ポリシーについては
Oracle社のFAQ
を参照ください。
RAC One Node ではアラートログが4つ作成されるため、アラートログからの調査が複雑になるケースがあります。障害発生時の出力がどのアラートログに出ているかが分かっていれば該当のアラートログのみを確認すれば良いのですが、そうでない場合は各アラートログを確認し、障害発生時点の出力を見つけるところから始める必要があります。
障害発生時の出力がどのアラートログにあるかの判断が難しいことも多いかと思いますので、サポートセンターへお問い合わせの際は4つすべてのアラートログをご提供ください。
■本記事の内容について
本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
前回の記事でOCVS)でHCXを利用するための前提となる手順の前半をお伝えしました。本記事では後続の手順であるサービスメッシュ作成・L2延伸手順を記載し、仮想マシンを移行できる状態、つまりHCX環境の構築完了までを説明します。
23aiで読取り専用モードの機能が拡張されました。ユーザー/セッション単位で読み書き可能/読取り専用モードの使い分けができるようになり、今まで以上にメンテナンス操作やアプリケーションからの接続の権限管理が柔軟にできるようになっています。
Oracle Database 23aiの新機能であるロックフリー予約により、トランザクション同士がブロックすることなく、効率的なデータ更新を実現できます。本記事では、ロックフリー予約の使い方をご紹介します。