【RDS for Oracle】オンプレの調査SQLが動かない｜X$BHを直接参照できない理由

テクノロジー
2022.04.07

Oracle DatabaseをオンプレミスからAmazon RDS for Oracleへ移行する際、確認すべきなのは、アプリケーションが正常に動作するかだけではありません。

性能調査、障害解析、ログ取得、セッション管理など、DBAが日常的に使用している調査手順が、RDS上でも同じように成立するかを確認する必要があります。

本記事で取り上げるのは、DBバッファキャッシュの利用状況を調査する際に使用されるX$BHです。

オンプレミスOracleで使用していたX$BH参照SQLを、RDS for Oracleのマスターユーザーで実行すると、次のエラーが発生します。

ORA-00942: table or view does not exist

Oracle Databaseという製品自体は同じです。

しかし、通常のRDS for OracleではSYSとしてログインできず、SYSDBA権限も使用できません。そのため、オンプレミスと同じ方法でSYS.X$BHを直接参照することはできません。

一方、現在のRDS for Oracleには、対応する環境でX$BHを基にしたSYS.RDS_X$BHビューを作成する仕組みがあります。

また、調査の目的によっては、Oracleが公開している動的パフォーマンスビューV$BHによって必要な情報を取得できます。

本記事では、RDS for OracleでSYS.X$BHを直接参照できない理由と、現在利用できる代替手段を整理します。

RDS for Oracleでは、X$BH以外にも、SYSDBA権限、OSアクセス、ストレージ操作、ログ取得など、オンプレミスの運用前提がそのまま通用しない場面があります。

RDS for Oracle全体の設計ギャップと代替アプローチについては、以下の記事で整理しています。

関連記事
RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった

SYSDBA権限、OSアクセス、ログ取得など、RDS for Oracleで変わるオンプレミスとの設計・運用上の違いを整理しています。

noteで記事を読む →

今回調べたいのはDBバッファキャッシュの内訳

Oracle DatabaseのSGAには、データブロックを保持するDBバッファキャッシュがあります。

SQLによって読み込まれたデータブロックをメモリ上に保持しておくことで、同じブロックが再び必要になった際に、ストレージから読み込む処理を減らせます。

更新されたブロックについても、即座にすべてがデータファイルへ書き込まれるわけではありません。更新済みのブロックはバッファキャッシュ上に保持され、DBWRによって適切なタイミングで書き出されます。

このように、DBバッファキャッシュはOracle DatabaseのI/O性能に大きく関係するメモリ領域です。

ただし、バッファキャッシュは大きければ大きいほどよい、というものではありません。

DBインスタンスで利用できるメモリには上限があります。SGAに多く割り当てれば、その分だけPGAやOS、RDSの管理プロセスが利用できるメモリは少なくなります。

例えば、アプリケーションの機能追加によって同時接続数や処理量が増え、PGAの総使用量が増える可能性があるとします。

DBインスタンス全体のメモリに余裕がなければ、PGAに必要なメモリを確保するため、SGAを縮小できるか検討することになります。

SGAには、DBバッファキャッシュのほかにも、共有プール、ラージプール、Javaプール、REDOログバッファなどがあります。

その中でDBバッファキャッシュの縮小余地を検討する場合、まず確認したいのが、

どのテーブルやインデックスのブロックが、バッファキャッシュ上にどの程度存在しているか

という内訳です。

オンプレミスではX$BHを参照できる

オンプレミスOracleでは、DBバッファキャッシュの内部状態を詳しく調べるために、X$BHを参照する方法があります。

X$BHは、一般的なアプリケーション表や通常のデータディクショナリビューではありません。

Oracleが内部的に管理しているバッファヘッダーの情報を参照するための固定表です。

どのデータオブジェクトのブロックがバッファキャッシュ上に存在するかだけでなく、LRU_FLAGやTCHなど、バッファの利用状況を分析するための詳細な情報も保持しています。

例えば、TCHはバッファへのアクセス状況を調べる際に利用される情報です。

Oracle公式ドキュメントでは、X$BH.TCHはバッファのタッチカウントとして説明されており、値が高いブロックはホットブロックの候補になるとされています。

一般的には、次のような流れで調査します。

  1. SGAとPGAの使用状況を確認する

  2. DBバッファキャッシュがSGA内で占める容量を確認する

  3. X$BHとDBA_OBJECTSを結合する

  4. オブジェクトごとのキャッシュブロック数を集計する

  5. キャッシュ上で大きな割合を占めるテーブルやインデックスを確認する

  6. SQL、実行計画、物理読み込みなどの情報と照合する

重要なのは、特定のオブジェクトが大量にキャッシュされているだけでは、直ちに問題とは判断できないことです。

業務で頻繁に参照されるテーブルであれば、多くのブロックがキャッシュされていること自体は正常です。物理読み込みを減らし、性能向上に寄与している可能性があります。

一方で、利用頻度の低い大規模バッチが大量のブロックを読み込み、オンライン処理で必要なブロックをキャッシュから押し出している場合には、SQLや実行計画を見直す余地があります。

そのため、X$BHの結果だけでチューニングの要否を判断するのではなく、AWR、Statspack、SQL統計、待機イベント、実行計画などと組み合わせて評価する必要があります。

同じSQLをRDSで実行するとORA-00942になる

オンプレミスで使用しているX$BH参照SQLを、そのままRDS for Oracleのマスターユーザーで実行すると、次のエラーが発生します。

ORA-00942: table or view does not exist

このエラーだけでは、対象オブジェクトが存在しないのか、実行ユーザーに参照権限がないのかを判別できません。

Oracleでは、存在する表やビューであっても、実行ユーザーに必要なアクセス権限がない場合、ORA-00942が返ることがあります。

そのため、最初に考えられるのは、マスターユーザーに対する権限不足です。

しかし、X$BHのようなX$固定表は、通常の表やビューと同じ方法で、RDSのマスターユーザーへ参照権限を追加できるオブジェクトではありません。

AWSの公式ドキュメントでは、SYS.X$固定表はSYSだけが直接アクセスできる内部システムオブジェクトとして扱われています。通常のRDS for OracleではSYSとしてログインできないため、マスターユーザーに通常のGRANTを追加し、オンプレミスと同じ参照方法を再現することはできません。

RDSのマスターユーザーはSYSDBAではない

RDS for OracleのDBインスタンスを作成すると、マスターユーザーにはDBA権限が付与されます。

ただし、オンプレミスでSYSDBA権限を持つユーザーと、完全に同じ操作ができるわけではありません。

通常のRDS for Oracleでは、利用者はSYS、SYSTEMなど、Oracleがあらかじめ用意している管理ユーザーを使用できません。また、マスターユーザーにSYSDBA権限を付与することもできません。

Amazon RDSはマネージドサービスです。

バックアップ、パッチ適用、障害復旧、基盤監視などの一部をAWSが管理する代わりに、利用者が実行できるデータベース管理操作には一定の制限があります。

そのため、マスターユーザーにDBA権限が与えられていても、すべてのシステム権限やOracle内部オブジェクトへのアクセスが許可されるわけではありません。

今回参照しようとしているX$BHは、SYSだけが直接アクセスできるOracle内部の固定表です。

オンプレミスでSYSまたはSYSDBA権限を持つユーザーから参照できていても、RDSのマスターユーザーから同じ名前で直接参照することはできません。

grant_sys_objectでも何でも参照できるわけではない

RDS for Oracleでは、SYSが所有する一部のオブジェクトについて、次のRDS管理パッケージを使用し、別のデータベースユーザーへ権限を付与できます。

rdsadmin.rdsadmin_util.grant_sys_object

例えば、SYSが所有するデータディクショナリビューやパッケージに対して、SELECT権限やEXECUTE権限を付与する際に利用します。

ただし、このプロシージャを使用すれば、すべてのSYSオブジェクトへ自由にアクセスできるわけではありません。

grant_sys_objectで付与できるのは、マスターユーザー自身がロールまたは直接付与によって保持している権限に限られます。

マスターユーザー自身が持っていない権限を、このプロシージャによって新たに作り出すことはできません。

したがって、マスターユーザー自身がSYS.X$BHを直接参照できない環境では、grant_sys_objectを使って他のユーザーへX$BHの参照権限を付与することもできません。

オンプレミスで使用しているSQLがRDSで実行できなかった場合、

権限が足りない
　↓
GRANTを追加する
　↓
解決する

という単純な流れでは解決できないことがあります。

RDSで許可されている機能の中から、調査目的を満たせる別のビューや、RDS固有の管理プロシージャを探す必要があります。

現在はSYS.RDS_X$BHを作成できる

現在のRDS for Oracleには、対象となるX$固定表を基に、SYS.RDS_X$ビューを作成する仕組みがあります。

対応環境では、次のプロシージャを実行することで、RDS_X$ビューの作成対象として認められているX$固定表を確認できます。

SELECT *
FROM TABLE(
    rdsadmin.rdsadmin_util.list_allowed_sys_x$_views
);

実際に利用する際は、対象環境でこのプロシージャを実行し、その時点の一覧にX$BHが含まれていることを確認します。

対象として表示された環境では、次のプロシージャによって、X$BHを基にしたRDS_X$ビューを作成できます。

EXEC rdsadmin.rdsadmin_util.create_sys_x$_view('X$BH');

作成されるビュー名は、元のX$固定表名にRDS_が付いた形式です。

SYS.RDS_X$BH

作成されたRDS_X$ビューに対しては、マスターユーザーへSELECT WITH GRANT OPTIONが付与されます。必要に応じて、マスターユーザーから別のデータベースユーザーへ参照権限を付与できます。

RDS_X$ビューを利用できる環境

AWSの公式ドキュメントでは、RDS_X$ビューを利用できる環境として、次の条件が示されています。

  • 一度もアップグレードされていない既存DBインスタンスで、19cまたは21cの2023年10月以降の対象リリースを使用している

  • 新規に作成したDBインスタンス

  • エンジンをアップグレードした既存DBインスタンス

一度もアップグレードされていない既存インスタンスでは、19cは19.0.0.0.ru-2023-10.rur-2023-10.r1以降、21cは21.0.0.0.ru-2023-10.rur-2023-10.r1以降が対象として示されています。

ただし、利用条件や作成対象となるX$固定表は、今後変更される可能性があります。

実際に使用する際は、記事に記載されたバージョン情報だけで判断せず、次の2点を確認する必要があります。

  • 最新のAWS公式ドキュメントを確認する

  • 対象環境でlist_allowed_sys_x$_viewsを実行する

RDS_X$ビューを本番で使う場合の注意点

RDS_X$ビューを作成できるからといって、通常のデータディクショナリビューと同じ感覚で使用してよいわけではありません。

RDS_X$ビューの基になっているX$固定表は、Oracleの内部システムオブジェクトです。その構造や動作は、一般的な公開インターフェースとして保証されていません。

AWSは、特定のRDS_X$ビューを非本番環境で検証し、本番環境ではOracle Supportのガイダンスの下で作成することを推奨しています。

また、X$固定表の構造は、エンジンアップグレードの前後で同じであることが保証されていません。

RDS for Oracleでは、エンジンアップグレード時に既存のRDS_X$ビューが削除され、アップグレード後のX$固定表を基に再作成されます。その後、マスターユーザーにはSELECT WITH GRANT OPTIONが再び付与されます。

ただし、マスターユーザー以外のデータベースユーザーへ付与していた権限は、自動的には復元されません。アップグレード後に、必要なユーザーへ権限を再付与する必要があります。

RDS_X$ビューを監視や定期調査へ組み込む場合は、次の点を運用設計へ反映します。

  • 対象のX$固定表が作成対象に含まれているか確認する

  • 非本番環境でSQLの動作と負荷を検証する

  • エンジンアップグレード後にビューの状態を確認する

  • マスターユーザー以外へ付与した権限を再設定する

  • アップグレード後も必要な列が存在するか確認する

  • 列構造や挙動を公開仕様として前提にしない

RDS_X$BHを作成すれば、対象環境においてLRU_FLAGやTCHなど、V$BHでは確認できない情報を参照できる可能性があります。

ただし、X$固定表の列構造は公開仕様ではありません。特定の列が将来にわたって同じ形で存在することを前提にした監視や運用は避けるべきです。

X$BHを調査する3つの方法

RDS for OracleにおけるX$BHの扱いは、次のように整理できます。

調査方法RDSでの利用特徴
SYS.X$BHを直接参照通常のRDS for Oracleでは不可SYSだけが直接アクセスできる内部固定表
SYS.RDS_X$BHを作成対応環境で可能X$BHを基にしたRDS用ビュー。非本番での検証が必要
V$BHを参照必要な参照権限があれば可能Oracle公式リファレンスに記載された動的パフォーマンスビュー

したがって、現在のRDS for Oracleについては、次のように理解する必要があります。

通常のRDS for Oracleでは、SYS.X$BHを直接参照できない。ただし、対応環境ではSYS.RDS_X$BHを作成できる。

「SYS.X$BHを直接参照できないこと」と、「X$BHを基にした情報を一切取得できないこと」は同じではありません。

それでもV$BHを知っておく理由

ここで一つ疑問が出てきます。

RDS_X$BHを作成し、対象環境でLRU_FLAGやTCHなどの必要な列を参照できるのであれば、V$BHを使った代替調査は不要ではないか、という疑問です。

しかし、必ずしもそうとは限りません。

RDS_X$BHは、Oracle内部の非公開オブジェクトを基にしたビューです。

作成対象となるX$固定表や列構造、アップグレード後の互換性を、公開仕様として前提にすることはできません。

また、本番環境で利用する前に、非本番環境での検証やOracle Supportへの確認が推奨されています。

一方、V$BHはOracleの公式リファレンスに記載された動的パフォーマンスビューです。

V$BHからは、バッファの状態、ファイル番号、ブロック番号、データオブジェクト番号、表領域番号などを取得できます。

必要な参照権限を持つユーザーであれば、RDS_X$ビューを新たに作成せずに利用できます。

そのため、今回のように、

バッファキャッシュ上に、どのオブジェクトのブロックが何件存在するか確認したい

という目的であれば、まずV$BHで必要な情報を取得できるか検討するのが現実的です。

V$BHでは不足する情報があり、LRU_FLAGやTCHなどX$BH固有の情報が調査上どうしても必要になった場合に、RDS_X$BHの作成を検討するという順序が考えられます。

ただし、V$BHはX$BHの完全な代替ではありません。

V$BHから取得できる情報と取得できない情報を区別し、調査目的に応じて使い分ける必要があります。

同じOracleでも運用方法まで同じとは限らない

今回の事例で重要なのは、X$BHという一つの内部表を参照できるかどうかだけではありません。

RDS for Oracleでは、Oracle Databaseという同じエンジンを使用していても、管理権限や調査方法までオンプレミスと同じになるわけではありません。

移行前には、アプリケーションのSQLや接続方式だけでなく、次のようなDBA運用についても確認する必要があります。

  • 性能問題が起きた際に必要な情報を取得できるか

  • 障害解析で利用しているビューやパッケージを参照できるか

  • SYSDBAを前提とした運用手順が残っていないか

  • Oracle内部表に依存した監視や調査を行っていないか

  • RDS固有のプロシージャで代替できるか

  • 代替した場合に取得できなくなる情報はないか

  • 本番環境で使用する前に非本番環境で検証できるか

  • エンジンアップグレード後も同じ手順を利用できるか

  • アップグレード時に再設定が必要な権限はないか

オンプレミスの運用手順書に記載されたSQLを、そのままRDSへ移植するだけでは不十分です。

重要なのは、既存のコマンドをそのまま再現することではありません。

そのSQLを何のために実行しているのかを整理し、RDSで利用可能な手段によって同じ調査目的を満たせるか検証することです。

今回の目的は、DBバッファキャッシュ上に存在するオブジェクトと、そのキャッシュブロック数を把握することでした。

この目的に限定すれば、Oracleが公開している動的パフォーマンスビューV$BHを使って調査する方法があります。

一方、V$BHでは、X$BHが持つすべての内部情報を確認できるわけではありません。LRU_FLAGやTCHなど、V$BHからは取得できない情報もあります。

後編では、RDS for OracleでV$BHを使用してオブジェクトごとのキャッシュ量を確認するSQLと、X$BHから置き換える際の注意点を解説します。

まとめ

通常のRDS for Oracleでは、SYSまたはSYSTEMとしてログインできず、SYSDBA権限も使用できません。

そのため、オンプレミスと同じ方法でSYS.X$BHを直接参照することはできません。

ただし、現在のRDS for Oracleでは、対応する環境であれば、次のプロシージャを使用してSYS.RDS_X$BHビューを作成できます。

EXEC rdsadmin.rdsadmin_util.create_sys_x$_view('X$BH');

したがって、RDS for OracleにおけるX$BHの利用については、次の3点を区別する必要があります。

  • SYS.X$BHを直接参照できるか

  • SYS.RDS_X$BHを作成できる環境か

  • V$BHで調査目的を代替できるか

RDS_X$BHを利用できる環境であっても、X$固定表はOracle内部の非公開オブジェクトです。

本番環境へ導入する際は、非本番環境での検証、エンジンアップグレード後の確認、他ユーザーへの権限再付与などを考慮する必要があります。

RDS移行では、データベースエンジンが同じであっても、オンプレミスと同じDBA権限や調査方法が提供されるとは限りません。

アプリケーションの互換性だけでなく、性能調査や障害解析を含む運用手順についても、移行前のPoCで確認しておく必要があります。

コメント

タイトルとURLをコピーしました