Database Support Blog

  • Oracle Database
2018.12.21

【Oracle】押さえておきたいRAC One Nodeのアラートログの仕組み

RAC One Nodeのアラートログの仕組み

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のアラートログがどのように作成されているのか、その仕組みをご紹介します。

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のアラートログは全部で4つ作成される

上述のとおり、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. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • Oracle Database
2024.04.08

【Oracle Database】FAQで安定運用に貢献!サポートセンターのナレッジ公開の取り組み

アシストオラクルサポートセンターが公開しているFAQは、仕様に関するQAやエラー発生時の対処方法などはもちろん、不具合情報や障害発生時の情報取得方法といった安定運用に役立つ内容も扱っています。そのFAQをどのように作成しているのか、サポートセンターの取り組みをご紹介します。

  • Oracle Cloud
  • Oracle Database
2024.02.02

OCIにおけるOracle Database 11g R2、12g R1、12g R2の新規プロビジョニング終了とその影響

Oracle Databaseのバージョン11g R2、12g.R1、12g.R2は既にすべてのメーカーサポートが終了しています。OCIのBase Database Serviceでも2024年1月中旬ころから11g R2、12g R1、12g R2での新規プロビジョニングができなくなりました。

  • Oracle Database
  • その他
2023.12.21

【Oracle Database】サポートセンターでの生成AI(Glean)活用

アシストでは全社員にAIアシスタントGleanを導入しました。サポートセンターで2ヶ月間使ってみて感じた効果やメリットをお伝えします。

ページの先頭へ戻る