こんにちは！インサイトテクノロジーの松尾です。

この度の Insight SQL Testing の新バージョンリリースにおいて、RDS for Oracle からの SQL 取得を「ネイティブサポート」いたしました！本ブログでは、この新機能がなぜ異機種間移行（リプラットフォーム）において重要なのか、その技術的背景と利用手順を詳しく紹介します。

1. イントロダクション：移行アセスメントを阻んでいた「情報の欠損」

オンプレミスの Oracle Database を AWS へ移行する際、一足飛びに Amazon Aurora PostgreSQL を目指すと、アプリケーション改修のリスクが過大になることがあります。そのため、まずは「同じ Oracle ベース」である RDS for Oracle へ移行し、その後に Aurora PostgreSQL へ移行するという 2 ステップの戦略をとるケースは珍しくありません。

第 1 フェーズ（オンプレ → RDS Oracle）はエンジンが共通のためハードルは低いですが、問題は第 2 フェーズです。

Oracle から Aurora PostgreSQL への移行難易度を正確に評価する上で、最も信頼できるテストデータは「実際の Oracle 環境で稼働した SQL ワークロード」です。これらの SQL 群が PostgreSQL 上でも意図通りに動作するか、あるいはパフォーマンス特性がどう変化するかを把握することが、移行プロジェクトの成否を分ける最重要ポイントとなります。
これまでの Insight SQL Testing でも、RDS for Oracle 上で実行された SQL を取り込む手法は提供していました。しかし、従来の方式はインサイトテクノロジー社製ツール「Insight PISO」を介した監査ログ収集に依存しており、そこには仕様上の大きな制約が存在していました。
「取得対象が SELECT と DML（INSERT / UPDATE / DELETE）に限定されていた」という点です。

2. ネイティブサポートによりできるようになること

2.1. 「静的なスキーマ」と「動的なアプリ挙動」の乖離

従来の方式では、CREATE や TRUNCATE といった DDL（データ定義言語）が取得対象外でした。しかし、エンタープライズアプリケーションの多くは、バッチ処理内でのワークテーブル作成や、パーティションの動的メンテナンスなどをロジックに組み込んでいます。

従来の課題: テスト実行時に、前提となるテーブル操作ログが欠落しているため、後続の DML が「オブジェクトが存在しない」というエラーになり、テストが中断・失敗してしまいます。
新バージョンでの解決策: RDS の監査ログから直接 DDL を含む全イベントを抽出することで、「スキーマの状態変化」と「データ操作」を地続きで再現。アプリの動的な挙動をそのまま Aurora PostgreSQL で評価できます。

2.2. トランザクション・コンテキストの完全同期

PostgreSQL 移行で慎重になるべき点の一つに、トランザクション挙動の違いがあります。

従来の課題: COMMIT や ROLLBACK がログに含まれず、一連の処理が「一つの塊」として評価できませんでした。
新バージョンでの解決策: トランザクションの開始から終了までの境界線を完全に捕捉。Aurora PostgreSQL 上で、一連の業務フローがデータ整合性を保って完結するかという「トランザクション」の検証が可能になります。

3. Insight SQL Testing による SQL 取得

RDS for Oracle から直接監査ログファイルを読み取ることで、より高精度なアセスメントフローを実現します。

標準監査ログファイルのダイレクト取得: RDS for Oracle が出力する標準監査ログを取得・解析します。PISO を介在させないため、監査ログ上に記録された命令（SQL 文）をすべて収集します。
バインド変数の捕捉: SQL 文本体だけでなく、実行時のバインド変数も併せて取得。これにより、実データに基づいた高精度な実行プランの比較が可能になります。

4. 実際の手順：RDS for Oracle 設定からテスト実行まで

新機能を用いた具体的な操作の流れを解説します。詳細については、Insight SQL Testing マニュアルも併せて参照ください。

① RDS for Oracle 側の設定

まず、RDS インスタンスで必要な監査設定を有効にします。

audit_trail パラメータを XML,EXTENDED に設定。
監査対象を指定するために、データベースにログインし AUDIT ALL STATEMENTS 文を実行しトップレベルのSQLすべてを取得対象とします。
※特定のユーザーが実行する SQL のみに絞るなど、要件に応じて AUDIT コマンドの内容を調整してください。

② Insight SQL Testing の EC2 に権限を付与

Insight SQL Testing は、RDS API を経由してログファイルをダウンロードします。これに必要な IAM 権限を、製品が稼働する EC2 の IAM ロールに付与してください。※Cloudwatch Logs に出力されたものをダウンロードすることも可能

rds:DownloadDBLogFilePortion
rds:DescribeDBInstances
rds:DownloadCompleteDBLogFile
rds:DescribeDBLogFiles
rds:DescribeDBClusters

③ 評価 SQL セットの作成

管理画面の「評価 SQL セット」から「新規作成」を行います。

「評価 SQL セット作成方法」で「Amazon RDS から作成」を選択し、「リージョン」、「インスタンス ID 」を指定し、「評価 SQL セット名」を指定し、「新規作成」を選択します。

④ 取得 SQL の確認

作成された評価 SQL セットを確認すると、従来の SELECT/DML に加え、CREATE TABLE などの DDL、および COMMIT が記録されていることが確認できます。

以下は、ROLLBACK を実行した SQL を取得した例です。

⑤ テスト環境へのテスト実行

取得した SQL をターゲット環境へ流し込みます。ここで、「DDL が取得できていること」と「トランザクション制御が取得できていること」の重要性が顕著に現れます。
例えば、一時テーブル作成（DDL）が取得できていなければ、その後の操作はすべてエラーとなりますが、本機能ではそれらが地続きで実行されます。また、Oracle と PostgreSQL の「自動コミット」の挙動の違いも可視化されます。

Oracle と PostgreSQL の "トランザクション開始" の指定方法の違いへの対策
Oracle は明示的にトランザクション開始を指定せずともトランザクション開始として処理が始まりますが、PostgreSQL はデフォルトが自動コミットです。そのため、Oracle から取得した SQL をそのまま流すと、ROLLBACK を実行しても直前の処理が確定してしまっている場合があります。

このような場合、PostgreSQL 側でのセッション開始時に固定の SQL（例: begin;）を実行させる設定を入れることで、Oracle に近い挙動でのアセスメントが可能になります。

例えば、begin を明示的に指定せずに、Oracle から取得した SQL をそのまま実行した場合、PostgreSQL では ROLLBACK の後で SELECT を実行しても実際にはロールバックされていないことが確認できました。

Oracle と似た挙動をさせるには、アセスメント開始時のオプション設定として、セッション開始時に固定の SQL を実行させる設定をしておくとよさそうです。

なお、この評価 SQL セットの例では、セッション開始時に begin; を実行するよう設定することで、エラー SQL や、結果が異なる SQL がなくなりましたが、トランザクションについては、ddl を実行したときの扱いなど結構異なる部分も多いので、単に SQL の互換性を見るだけでなく慎重な確認が必要ですね。

まとめ：移行アセスメントの精度と効率が向上

これまでの「SELECT / DML 限定」のテストは、非互換 SQL（特にエラーになる SQL）を検出するには大きな効果を発揮するものの、DDL を活用しているようなバッチ処理やアプリケーションだったり、トランザクションを活用している場合などのアセスメントを実行するには、意図しないエラーの発生などにより効率的な評価を行うことができませんでした。
Insight SQL Testing が RDS for Oracle からネイティブに全情報を取得できるようになったことで、移行アセスメントの精度と効率は飛躍的に向上します。今まで「検証が難しい」と諦めていたシーンでも、ぜひ本機能を活用して、データベース移行を推進してください！

本機能や Insight SQL Testing にご興味がある方は、ぜひお気軽にお問い合わせください。