マルチテナントはトラブル調査をどう変えるのか

Oracle Multitenant（以下マルチテナント）はOracle Database 12c R1（12.1.0.1）から登場したアーキテクチャで、12.1.0.2以降は推奨の構成とされてきました。現時点でのOracle Databaseの最新バージョンは19cですが、次期バージョンとなる21cからマルチテナント構成が標準となり、従来の構成はサポート対象外となります。

今年、Oracle Databaseに関しアシストのサポートセンターへ寄せられたお問い合わせのバージョン動向をみる限り、お客様が導入されているのは19c未満のバージョンが90%を占め、19cの導入はまだ10%程度というのが現状です。

しかし、今後上位バージョンへの移行を計画している場合には、資料作成時点の最新バージョンである19cなのか、それとも今後オンプレミスでリリースされるであろう21cなのかによって、大きく関わってくるのがマルチテナント対応になります。

本記事では、マルチテナントと従来構成の違いについて簡単に紹介し、マルチテナントが標準となった場合にトラブル対応にどう影響するのかを解説していきます。

まずはマルチテナント・アーキテクチャについて簡単におさらいします。

従来、データベースシステムを統合・集約するためには、１．サーバを仮想化する、２．同じホスト上に複数のデータベース（DB）を作成する、３．同一DB上で複数のスキーマを管理する、という3つの手法がありました。

Oracle Database 12cからは、DBの中に仮想的なDBを複数作成できるマルチテナントというユニークなアーキテクチャが登場しました。マルチテナントはコンテナ・データベース（CDB）とプラガブル・データベース（PDB）の２つから構成されます。従来構成（非CDB構成）のDBに該当するのがPDBで、複数のPDBの器であり、かつDB全体で共有するオブジェクトやメタデータ情報を格納しているのがCDBになります。

また、非CDB構成の場合、DBとOracle インスタンスは１対１の関係でした。一方マルチテナントでは、PDBが何個あろうとOracle インスタンスは１つしか起動せず、またシステムグローバル領域（SGA）やバックグラウンドプロセスはCDBと複数のPDBで共有されるという点が大きな特徴となっています。つまり、マルチテナントでは、単一のインフラで複数のDBを稼働させ、リソースの無駄を大幅に節約できるという大きなメリットがあるのです。

さらにマルチテナントでは、制御ファイルとオンラインREDOログファイルはCDBが管理しますが、データファイルについてはCDBとそれぞれのPDBが管理します。このように各PDBは論理的に別のDBのように振る舞いますが、パッチ適用ではCDBに対する1回の作業で済みます。また、バックアップではCDBと全てのPDBを一度に取得する、あるいはPDB単位で取得することもできることから、柔軟なバックアップ計画を立てることができるようになるといったように、管理面での無駄は排除しつつ柔軟性を実現した構成と言えます。

マルチテナントでは、DB（CDB）の中にDB（PDB）を作るということはお分かりいただけたと思いますが、マルチテナント構成でトラブルが発生した場合、非CDB構成と比べどのように変わるでしょうか。トラブルに関連するログファイルとデータディクショナリに着目して見ていきましょう。

トラブルが発生した場合、一番最初に確認するのがログファイルです。Oracleインスタンスは、主にアラートログファイルとトレースファイルを出力します。

非CDB構成では、Oracleインスタンスごとにアラートログファイルが出力されるため、DBが2つあれば２つのアラートログファイルが出力されます。マルチテナントの場合は、PDBがいくつあってもCDBとPDBで１つの同じアラートログファイルに出力されます。

また、プロセスの稼働状況が出力されるトレースファイルは、マルチテナント、非CDB構成どちらの場合もプロセスごとに出力されます。ただ、マルチテナントの場合、PDBが複数あってもOracleインスタンスは１つしか生成されず、CDBとPDBでバックグラウンドプロセスが共有されるため、トレースファイルではPDBとCDB情報が混在することになります。

マルチテナントの場合のアラートログファイルの出力例を見てみましょう。マルチテナントでは、CDBと複数のPDBで１つのアラートログファイルに出力されるため、エラーの発生したコンテナの特定には「PDBNAME=」部分を確認します。

下の例の赤字部分である「PDBNAME=CDB$ROOT」は、エラーの発生箇所がCDBであることを示しています。

下の例にある「PDBNAME=PDB1」はPDB1という名前のPDBでエラーが発生していることを示しています。

また、PDBに特化した情報は「PDB名（数値）」で表されます。下の例では赤字のPDB1(3)が該当部分となります。※数値の説明については後述します。

マルチテナントでは複数のDB情報が１つのアラートログファイルに書き込まれるため、エラー解析を行う立場からすると、解析作業がやや煩雑になったという印象があります。しかし、従来の非CDB構成でトラブルが発生した場合、弊社からお客様に「複数のDBから出力されるログファイル情報を精査した上でご提供ください」とお願いしていたものが、マルチテナントでは「１つのファイルをそのままご提供ください」に変わるので、お客様のご負担はかなり軽減されます。

次は、トレースファイルとインシデントファイルの特徴についてです。マルチテナントではCDBとPDBでプロセスが共有されるため、どちらの情報も混在してファイルに書き込まれます。

プロセスが稼働していたコンテナの情報は、次のように、ファイルのヘッダー部の「CONTAINER ID」に表示されます。この例では「CONTAINER ID=1」に関する情報を表しています。

CONTAINER IDが「1」の場合はCDB$ROOT、「２」がPDB$SEEDというPDBのテンプレート、「3」以上はユーザー作成のPDB情報となっています。

コンテナIDに関連するPDBを一覧表示したい場合は、以下のようにCDBへ接続し「show pdbs」と入力する方法が簡単かつお勧めです。PDBの一覧はディクショナリへの問い合わせでも確認できます。

CDBとPDB情報の取得には、データディクショナリビューまたは動的パフォーマンスビュー（V$ビュー）を利用します。非CDB構成の場合は、どちらもDB全体の情報を確認できましたが、マルチテナントの場合は、CDBに接続するとCDBと関連するPDBの情報をすべて確認でき、PDBに接続すると該当PDBだけの情報を確認できます。参照したい範囲によって、接続先のコンテナやビューを使い分ける必要があります。

USER_xx、ALL_xx、DBA_xxビューに加え、CDB_xxビューも利用できます。

ALL_xxビューとUSER_xxビューは従来と変わらず、接続ユーザーがアクセス可能なオブジェクト情報に参照は限定されますが、CDB_xxビューとDBA_xxビューは接続先がCDBかPDBかにより参照できる情報が異なります。また、PDBに関しては接続したPDB情報しか参照できないという点においては、非CDB構成と変わりがないとも言えます。

CDBに接続した場合のCDBビューとDBAビューの参照範囲の違いについては、以下の図もご参照ください。

データディクショナリビューと同様、V$ビューも接続先により参照可能な範囲が異なります。

・CDBに接続⇒CDBとPDBすべての情報が参照可能
・PDBに接続⇒接続しているPDBの情報を参照可能

「PDBに接続」している場合でも、例外的に、CDB全体に関する情報（DB全体で共有される制御ファイルやオンラインREDOログファイルの情報など）を参照することができます。これらの情報はCON_ID列で識別できます。下の例では赤字のCON_IDが0になっている部分が該当箇所です。

ちなみに、CDB_xxビューやV$ビューでCON_IDを指定すると、トレースファイルのコンテナID同様、どのコンテナに関する情報かを識別できるようになっています。

CON_ID
0：CDB全体に関する情報
1：CDB$ROOTに関する情報
2：PDB$SEEDに関する情報
3：PDBに関する情報

トレースファイルではshow pdbsコマンドの例を紹介しましたが、以下はCDBへ接続しV$CONTAINERSビューで確認している例です。

show pdbsコマンドではコンテナID=1は表示されませんでしたが、V$CONTAINERSビューでは１がCDB$ROOTと表示されます。コンテナIDを確認したいだけならshow pdbsで十分です。このほかに、V$PDBS、CDB_PDBSビューなどを利用して一覧を確認できます。

以上、ログファイルやデータディクショナリに焦点をあててマルチテナントと非CDB構成の違いをご紹介しました。

ここからは、ORAエラーの発生と、CPU使用率の高騰に焦点をあてたトラブルシュートを例に、マルチテナントと従来の非CDB構成ではどのように対応が異なるのかをご紹介します。マルチテナント構成での障害に備えたフローの確立に役立てていただければ幸いです。

まずはDBAの皆さんの宿敵とも言えるORA-00600エラーが発生した場合の対応を例にマルチテナント構成での違いをご紹介します。

初動対応で必要なものは(1)アラートログファイル、(2)トレースファイル/インシデントファイルです。順番に取得方法を見ていきましょう。

アラートログに関しては、どのシステムでどのエラーが発生しようと、初動対応に必要なファイルは１つです。トラブル発生時（または弊社サポートセンターへご連絡いただく際）には、問題が発生したPDB名と発生した日時も合わせて確認してください。

アラートログファイルの出力先は以下の通りです。
<dianogostic_dest>/diag/rdbms/<DB>/<SID>/trace/alert_<SID>.log

アラートログファイルは、初期化パラメータ「diagnostic_dest」配下にDBごとに出力されます。

アラートログの出力内容をみてみましょう。

ポイントは、以下の3点です。

(1)問題が発生しているPDB名を確認する
(2)対象となるトレースファイルのフルパスを確認する
(3)ORA-00600やその他のクリティカルなエラーについてはトレースファイルよりも詳細な診断情報が含まれるインシデントファイルのフルパスを確認する

上記の(1)についてですが、出力内容の４行目を見てください。問題が発生したPDBは「PDB1」だということがわかります。

２行目、３行目からトレースファイルのフルパスを確認できます。

また、PDB1のインシデントファイルのフルパスも下2行から確認できます。

ここで注意が必要なのは、トレースファイルとインシデントファイルでは出力先が異なるという点です。これは非CDB構成の場合も同様です。トレースファイルはアラートログと同じディレクトリですが、インシデントファイルはインシデント番号ごとにディレクトリが分けられます。

これらのファイルはプロセスごとに出力されるため、名称からエラーを受けた対象ファイルを予測することは非常に困難です。そのため、事象が発生した近辺のタイムスタンプのファイルも確認してください。弊社のサポートセンターへお問い合わせの際は合わせてご提供いただければ初動対応は完璧となります。

以下はトレースファイルの出力先です。
<dianogostic_dest>/diag/rdbms/<DB>/<SID>/trace/*.trc

以下はインシデントファイルの出力先です。
<dianogostic_dest>/diag/rdbms/<DB>/<SID>/incident/incdir_<incident>/*.trc

まずはトレースファイルの出力例を確認してみましょう。今回エラーを受けたプロセスが稼働していたのは、コンテナID=3だとわかります。コンテナID=3以上はユーザー作成のコンテナであるため、ここで何か公開しているサービスに影響がないか、といったところが懸念事項となります。

具体的にどんなSQLの実行時にエラーが発生したのかを「Current SQL Statement」から確認します。この例ではINSERT処理でORA600が発生していることがわかります。
※この例では内容を抜粋していますが、実際にはSQL全文が掲載されます。

また、お客様が直接解析することは少ないかと思いますが、エラー発生時にプロセスがコールしていた関数は以下の例にある「Incidenet Context Dump」や「Call Stack Trace」から確認できます。

関数の流れやエラーを受けた関数（Signaling）も、エラー解析やサポートを行う上で不具合の判断材料の１つとなります。

また、エラーを受けたプロセスのセッション情報は、以下のようにPROCESS STATEから確認できます。

SIDやSERIALはこちらに表示されています。

マルチテナント構成では、CON_IDやコンテナ名も確認できます。コンテナIDの出力から3番であることはわかっていましたが、このPROCESS STATEというセクションから、PDBがPDB1だというところまで確認できます。

以下はマルチテナントでORAエラーが発生したときに押さえておくべきポイントです。

１．アラートログファイルは１つ
PDBが何個あろうともアラートログファイルは１つです。そのため、アラートログファイルの出力先パスを必ず押さえておくことが重要です。

２．エラーを受けたPDBを確認
アラートログから、どのPDBに対するエラーなのか、対象のトレースファイルがどれかを確認しておくことが重要です。

上記の通り、マルチテナントの場合、アラートログファイルの出力パスとエラーを受けたPDBの特定方法を押さえておけば、エラー発生時の初動対応は完璧です。

CPUが高騰しているというシステムアラートを検知したというケースでの初動対応をご紹介します。

まず最初に押さえておきたいポイントは、リソースを高騰させているのがOarcle のプロセスかどうかということです。Oracleのプロセスであれば、どのコンテナのどのプロセスかを確認し、処理を停止させるなどの対処を行うことでトラブルを沈静化できます。このように、Oracleのプロセスかどうかの見極めが、トラブルを迷宮入りさせないための大きなポイントになります。それではリソースを使用するプロセスの確認、どのコンテナのプロセスかを確認する方法、最後に特定したセッションを強制終了する方法を順にみていきましょう。

CPUを使用するプロセスがOracleプロセスかを確認するために、以下のようにtopコマンド（Linuxの場合）を実行します。
※Windowsの場合はpslist

topコマンドを確認すると、COMMAND列からorclインスタンスのPID=653のプロセスがCPUを高騰させていることがわかります。しかし、どのコンテナなのかという肝心な点を確認できません。ここがマルチテナントの難しいところです。

topコマンドではどのPDBがCPUを高騰させているかを確認できません。そのため、以下のようにCDBへ接続しshowコマンドからCDBに紐づくPDB情報を確認します。以下ではorclインスタンスに紐づくPDBが３つあることが確認できます（PDB$SEEDは除きます）。

topコマンドで「PID=653のプロセスがCPUを高騰させている」ところまで確認できていたため、CDBへ接続し、V$PROCESSビューで表示された画面上で「CON_ID」列を確認すると、どのPDBで稼働しているプロセスなのかを確認できます。

SPID列が653になっているプロセスに着目します。

そのプロセスのCON_IDが4だということがわかります。つまり、CON_IDが4番のPDBで稼働しているプロセスであることが特定できます。

ここで、このプロセスとセッション情報を紐づけるために、該当プロセスのアドレス「00000000915BCAC8」を控えておきます。

次に、V$SESSIONを使用してセッション情報を参照し、どの端末からどのSQLが実行されているのか、などを確認します。

●V$SESSIONからセッション情報を見る

先ほどひかえておいたプロセスのアドレス「00000000915BCAC8」をセッション情報と紐づけます。

「00000000915BCAC8」に紐づく、接続元のマシンやプログラムを特定することで、どんなアプリケーションからこのプロセスに繋いでいるのか、といった当たりがつきます。このケースであればB1902から始まるマシンで稼働しているJDBCであることがわかり、Javaのプログラムからの処理でCPUが高騰している様子が伺えます。

CPUを高騰させている具体的なSQL文を確認するには、このV$SESSIONビューのSQL_ID列を控えておきます。

SQL文を確認する場合は、V$SQLビューからSQL_ID列を参照します。今回、CPU使用率を高騰させていたSQLは「select count(*) from source b. souce d」であることが特定できます。

このCPU高騰を沈静化するためにセッションを強制終了します。セッションの終了には、セッションのSIDとSERIAL#が必要です。

alter system kill sessionコマンドを使用してSID=752、SERIAL#=36031のセッションを終了させることでCPUを占有する問題は解消します。

Oracle Database 18cから、SQLの実行を中断させるコマンドとしてalter system cancel sqlが登場しました。SQLは中断してもセッションは継続したいといった要件があれば、alter system kill sessionではなく、alter system cancel sqlを利用してください。

alter system kill sessionをマルチテナント構成で実行する際の注意点があります。ここまでの例ではCDBに接続してビューを参照してきましたが、このalter system kill sessionコマンドは、CDBまたはプロセスが稼働するPDB、今回であればCON_ID=4のPDBに接続することで実行できます。ここでCON_IDが3であったり5であったりと接続先のPDBを誤ると、下の例のようにコマンドが失敗に終わるため、トラブル時は基本的にCDBでの操作を推奨します。

DBサーバの使用率が高騰したというアラートが発生した場合には、以下の2点を行います。

１．リソースを占有するプロセスの特定

サーバリソースの使用率が高騰したシステムアラートを検知した際には、まずリソースを占有するプロセスを明確化することが大切です。それがOracleのプロセスである場合にはどのコンテナで処理を行うプロセスなのか、などの考慮が必要となってきます。

２．コンテナの確認

高騰を引き起こしているのがOracleのプロセスであれば、topコマンドなどからプロセスIDを確認し、V$ビューにより、CPUを高騰させているプロセスが稼働するコンテナを確認します。

システムトラブル発生時には、CDBからV$ビュー等を参照することで漏れなく情報収集することがお勧めです。

マルチテナントは、DBの中にDBを入れるという新たなコンセプトでシステムの統合・集約を容易にしました。Oracle Database 21cからはマルチテナントが標準構成となるため、バージョンアップを計画している場合、次の移行先がマルチテナント構成である可能性が非常に高くなります。そのため、本記事でのマルチテナントに関する注意点を参考にしながら、トラブルに備えたフローをマルチテナント仕様へとアップデートしてほしいと思います。

トラブル調査において必須であるアラートログファイルはCDBと複数のPDBが１つのファイルに書き込まれます。トレースファイルについてもプロセスがコンテナ間で共有されるため、同一ファイルへ書き込まれるのが特徴となります。万が一のトラブルに備え、アラートログファイルの出力先を押さえておき、エラー発生時にはトレースファイルの出力時に対象となるPDBがどれかを識別できることが望ましいです。

データディクショナリビューには、CDBとすべてのPDBを参照するためのCDB_xxビューが登場しました。データディクショナリビューとV$ビューは接続先のコンテナにより参照可能な範囲が異なるという特徴があるため、必要な情報に応じて接続先のコンテナやビューを上手に使い分けができると、マルチテナント構成をうまく活用できているといえるのではないでしょうか。

「Oracle Databaseの構成が変わる」とマイナスに捉えるのではなく、リソース節約や容易なシステム統合といった利点をいかし、是非、一歩先の運用管理へと踏み切っていただきたいと思います。マルチテナントをまだ利用していないお客様、今後のシステム切り替えに前向きに検討したいお客様は是非弊社サポートセンターへご相談ください。

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。