Oracle Database@AWS 移行に向けてアプリケーションの SQL*Net レイテンシーを把握する

本記事は 2026 年 8 月 18 日 に公開された「Characterizing SQL*Net latency in your application for Oracle Database@AWS migrations」を翻訳したものです。

Oracle Database@AWS (ODB@AWS) は、AWS データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャを利用できるサービスです。ODB@AWS は、Amazon Virtual Private Cloud (Amazon VPC) 内で稼働する Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS) などの AWS サービスとの間で、低レイテンシーのネットワーク接続を提供します。アプリケーションホストと Exadata 間の SQL*Net トラフィックは ODB Peering を経由し、Amazon VPC と ODB ネットワーク間でプライベートにルーティングされます。

本記事では、データベースとアプリケーションのワークロードを ODB@AWS へ移行する準備を進めるための手法を紹介します。この手法を使うと、オンプレミスのワークロードが SQL*Net レイテンシーに敏感かどうかを評価し、ODB@AWS のマルチクラウドアーキテクチャで増える SQL*Net レイテンシーの影響を把握できます。さらに、ODB@AWS の移行候補となるワークロードにおける接続とデプロイの考慮事項も解説します。

ODB@AWS 移行で SQL*Net レイテンシーの評価が重要な理由

ODB@AWS への移行では、ワークロードが SQL*Net レイテンシーの増加に敏感かどうかが重要な検討ポイントになります。極めて短時間 (データベース処理時間がサブミリ秒) で、頻繁 (毎秒数千回の実行) に、かつ少数のセッションに集中して実行される SQL 文を含むワークロードは、SQL*Net ラウンドトリップレイテンシーが数百マイクロ秒増えるだけでも影響を受け、アプリケーションパフォーマンスに直接響く可能性があります。本記事の手法を使えば、アプリケーションのワークロードがこの 3 つの特性を持つかどうかを判断し、該当する場合は移行前に影響を定量化できます。

1 つの原則は常に成り立ちます。クライアントネットワークのレイテンシーが下がってアプリケーションパフォーマンスが悪化することはありませんが、必ず改善するわけでもありません。Oracle は SQL*Net のラウンドトリップを減らすためのガイダンスを何十年も前から公開しています。ストアドプロシージャ、配列フェッチ、バルク処理は、処理をサーバー側に移したりまとめて実行したりすることで、クライアントとサーバー間のラウンドトリップ回数を削減します。Oracle 自身の Net Services ドキュメントにも次の記述があります。

「ネットワークを越えるラウンドトリップの回数を減らすようアプリケーションをチューニングすることが、ネットワークパフォーマンスを改善する最善の方法です。」

ただし、そうした最適化を施しても SQL*Net レイテンシーに強く影響されるモジュールがアプリケーションに残っている場合は、本手法で移行前にレイテンシー感度を特定し、定量化できます。

手法の概要

本手法は Oracle の標準的なパフォーマンスツール (Automatic Workload Repository (AWR)、Active Session History、SQL Trace) を使い、次の 3 つのフェーズで構成されます。

1. フェーズ 1: AWR スクリーニングで候補となる SQL 文を特定する。
2. フェーズ 2: フェーズ 1 で挙がった候補の SQL 文を SQL Execution Session Density (SESD) で検証する。
3. フェーズ 3: SQL Trace と Client Request Elapsed Time (CRET) の分析で SQL*Net レイテンシーへの感度を把握する。

手法の詳細

Client Request Elapsed Time (CRET) とは

本手法は、Oracle のアイドル待機イベントを SQL*Net レイテンシー感度の主要な計測手段に使う新しいアプローチです。対象となるアイドル待機は SQL*Net message from client (SNMFC) です。連続する 2 つの SNMFC 待機に挟まれた区間を、本記事では Client Request Elapsed Time (CRET) イベントと呼びます。

クライアントアプリケーションから SQL*Net 経由でデータベースインスタンスに送られる SQL リクエストは、いずれも次の 3 段階のタイムラインをたどります。

1. クライアント時間 + クライアントからサーバーへのネットワーク時間: クライアントアプリケーションは前回の結果を処理し (またはアイドル状態のままとなり)、次の SQL リクエストを SQL*Net 経由でデータベースサーバーへ送信します。クライアント時間には、計算処理、ウェブ層とのやり取り、GUI アプリケーションが人間の入力を待つようなアイドル時間が含まれます。この段階の間、データベースセッションはずっと次のリクエストの到着を待つ SNMFC 待機の状態にあります。
2. データベース処理時間: データベースサーバーがリクエストを受け取り、処理し、応答を準備します。
3. サーバーからクライアントへのネットワーク時間: データベースサーバーが結果セットまたは完了コードを SQL*Net 経由でクライアントアプリケーションへ送信します。送信直後、データベースセッションは再び SNMFC 待機に入ります。

段階 1 と段階 3 の合計が非データベース時間 (Non-Database Time) です。段階 2 は完全にデータベース内部の処理であり、SQL*Net のクライアントネットワークレイテンシーとは無関係です。

CRET = Database Time + Client Time + SQL*Net RTT

図 1: クライアントリクエストのタイムライン。連続する 2 つの message from client 待機が 1 つの CRET イベントを挟む

CRET 手法の紹介

ここからは CRET 手法を、フェーズ 1 (AWR スクリーニング)、フェーズ 2 (SQL Execution Session Density)、フェーズ 3 (SQL Trace と CRET 分析) の 3 つに分けて詳しく見ていきます。

フェーズ 1: AWR スクリーニング (候補となる SQL 文の特定)

まず、レイテンシーに敏感と思われるアプリケーション処理が動いていた期間を含む AWR レポートを用意し、ヘッダーに記載された経過時間を確認します。たとえば次の図は、30 分間を対象とした AWR レポートのヘッダーセクションです。

図 2: 30 分間のスナップショット期間を示す AWR レポートのヘッダー

スクリーニングの目的は、頻繁かつ短時間で実行される SQL 文、つまり毎秒数千回実行されデータベース処理時間がマイクロ秒レベルの SQL 文を特定することです。SQL Ordered by Executions セクションを開き、上位の各 SQL 文について毎秒あたりの実行回数 (総実行回数 ÷ AWR の経過時間 (秒)) と平均データベース処理時間 (総経過時間 ÷ 実行回数) を計算します。データベース処理時間がサブミリ秒で、かつ毎秒数千回実行されている SQL 文がレイテンシー感度の候補です。処理時間が数ミリ秒に及ぶ SQL 文は、1 回の実行あたりのデータベース処理時間が、増加分のネットワーク時間を大きく上回るため、一般に SQL*Net レイテンシーの増加を許容できます。

フェーズ 1 スクリーニングの例

実際の例を見てみます。360 分 (21,600 秒) を対象とした AWR レポートに SQL Ordered by Executions セクションが含まれています。次のスクリーンショットはそのセクションの上位 5 行で、続く表は各行のフェーズ 1 分析結果です。

図 3: 実行回数の多い上位 5 つの SQL 文を示す AWR の SQL ordered by executions セクション

フェーズ 2: SQL Execution Session Density (SESD)

フェーズ 1 では AWR を使い、短時間かつ頻繁に実行される候補の SQL 文を特定します。ただし、SQL Ordered by Executions セクションの実行回数は全セッションを合算したインスタンス全体の集計値です。その実行が 1 セッションによるものか 1,000 セッションによるものかは、AWR からはわかりません。フェーズ 3 に進む前に、候補の SQL 文が 1 つ、あるいはごく少数のセッションから実行されていることを確認します。

考え方はシンプルです。1 回の実行にデータベース処理時間 100µs を要する SQL 文の場合、1 つのセッションが毎秒 10,000 回実行するケースと、100 セッションがそれぞれ毎秒 100 回実行するケースは、AWR 上では区別できません。レイテンシーに敏感なのは前者だけです。少数のセッションに実行が集中している状態は High SESD で、フェーズ 3 の分析対象になります。多数のセッションに実行が分散している状態は Low SESD で、フェーズ 3 は不要です。

SESD は、該当する SQL_ID を実行していたセッションのユニーク数を Active Session History に問い合わせる、V$SQL の USERS_EXECUTING 列を参照する、あるいはアプリケーションの動作を把握しているアプリケーションオーナーに確認する、といった方法で判断できます。High SESD ならフェーズ 3 の分析に進み、Low SESD なら進みません。

SQL Execution Session Density の詳細

先のフェーズ 1 の AWR に出てきた SQL_ID 52cn24qf243rp は、毎秒 5,214 回実行され、平均データベース処理時間は 97µs でした。SESD を評価した結果、この SQL_ID を実行しているセッションがわずか 5 つだったとします。各セッションは毎秒およそ 1,043 回の実行を担うことになり、CRET サイクル 1 回あたりの実行予算は約 959µs です (1,043 × 959µs = 1,000,000µs = 1 秒)。CRET サイクル時間が 959µs と短いため、SQL*Net レイテンシーの変化が相対的なパフォーマンスに大きく影響しかねません。その影響を評価するのがフェーズ 3 です。この SQL 文はフェーズ 3 の分析に最適な候補と言えます。逆に、同じ毎秒 5,214 回の実行が 200 セッションに分散していれば、各セッションの実行間隔はおよそ 38ms となり、フェーズ 3 の分析は不要です。

フェーズ 3: SQL Trace と CRET 分析

ここまでで、フェーズ 1 のスクリーニングで短時間かつ頻繁に実行される SQL 文を特定し、フェーズ 2 の SESD 分析でその実行がごく少数のセッションに集中していることを確認しました。残る作業は、対象セッションの 1 つをトレースし、CRET イベントの分析で実際のレイテンシー感度を定量化することです。

SQL Trace の有効化

候補の SQL 文を実行中のセッションを特定し、待機イベント付きでトレースを有効にします。

EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => &sid, serial_num => &serial#, waits => TRUE, binds => FALSE);

実行の代表的なサンプルが取得できるよう、十分な時間トレースを継続します。トレースが終わったら無効にします。

EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(session_id => &sid, serial_num => &serial#);

CRET パラグラフ: 実例

次の図は、SQL Trace ファイルから抜き出した実際の CRET パラグラフです。連続する 2 つの SNMFC 待機 (赤くハイライトされた部分) がパラグラフを挟んでいます。

図 4: 連続する 2 つの message from client 待機をハイライトした SQL Trace の抜粋

CRET の継続時間は、2 つの SNMFC が示す tim= の差分で、1,297,258,033,879 から 1,297,258,032,801 を引いた 1,078µs です。後ろの SNMFC が示す ela= 値 (947µs) が、この CRET サイクルにおける非データベース時間に相当します。CRET の継続時間から非データベース時間を引くとデータベース時間が求まり、1,078 から 947 を引いた 131µs となります。

CRET 分析ツール

次の 4 つの AWK ワンライナーが CRET 分析ツールを構成します。いずれも処理対象のトレースファイル名を第 1 引数として受け取り、実行には gawk(1) が必要です。ワンライナーは SQL Trace ファイルを直接処理するため、Oracle のクライアントソフトウェアは不要です。4 つのワンライナーが出力する内容は次のとおりです。

1. ワンライナー 1 — CRET サマリー: 総経過時間、CRET 数、CRET レート (CRET/秒)。
2. ワンライナー 2 — SNMFC 経過時間のパーセンタイル: 非データベース時間の分布 (Min、P50、P90、P99、Max)。
3. ワンライナー 3 — CRET 経過時間のパーセンタイル: ラウンドトリップ全体の時間分布 (Min、P50、P90、P99、Max)。
4. ワンライナー 4 — レイテンシー影響の予測: SQL*Net RTT が 100µs、150µs、200µs 増えた場合の実行時間の増加予測。

ワンライナー 1 — CRET サマリー

grep -i 'message from client' $1 | gawk '{p=match($0,/tim=[0-9]+/); t=substr($0,p+4,RLENGTH-4)+0; if(NR==1) s=t; e=t; n++} END{el=(e-s)/1000000; print sprintf("CRET Analysis | Elapsed: %.1f sec (%.2f min) | CRETs: %d | Rate: %.2f/sec", el, el/60, n-1, (n-1)/el)}'

ワンライナー 2 — SNMFC 経過時間のパーセンタイル

grep -i 'message from client' $1 | gawk '{p=match($0,/ela= *[0-9]+/); v=substr($0,p,RLENGTH); sub(/ela= */,"",v); val=v+0; if(NR==1) mn=val; if(val<mn) mn=val; a[NR]=val} END{n=asort(a); p50=a[int(n*0.5+0.5)];p90=a[int(n*0.9+0.5)];p99=a[int(n*0.99+0.5)]; mx=a[n]; print sprintf("SNMFC Elapsed (us): Min: %d | P50: %d | P90: %d | P99: %d | Max: %d", mn, p50, p90, p99, mx)}'

ワンライナー 3 — CRET 経過時間のパーセンタイル

grep -i 'message from client' $1 | gawk '{p=match($0,/tim=[0-9]+/); t=substr($0,p+4,RLENGTH-4)+0; if(NR>1){d=t-prev; if(NR==2) mn=d; if(d<mn) mn=d; c[NR-1]=d} prev=t} END{n=asort(c);p50=c[int(n*0.5+0.5)]; p90=c[int(n*0.9+0.5)];p99=c[int(n*0.99+0.5)]; mx=c[n]; print sprintf("CRET Elapsed (us): Min: %d | P50: %d | P90: %d | P99: %d | Max: %d", mn, p50, p90, p99, mx)}'

ワンライナー 4 — レイテンシー影響の予測

grep -i 'message from client' $1 | gawk '{p=match($0,/tim=[0-9]+/); t=substr($0,p+4,RLENGTH-4)+0; if(NR==1) s=t; e=t; n++}END{crets=n-1; el=(e-s);print sprintf("Latency Impact: +100us: +%.0fs (+%.1f%%) | +150us: +%.0fs (+%.1f%%) | +200us: +%.0fs (+%.1f%%)", crets*100/1000000, (crets*100/el)*100,crets*150/1000000, (crets*150/el)*100,crets*200/1000000, (crets*200/el)*100)}'

実践例: CRET 分析の出力

次のスクリーンショットは、クライアント側の実行パターンがまったく異なる 2 つのトレースファイル (いずれも CRET イベント 10,000 件) に対して、4 つのワンライナーを実行した例です。一方はタイトループ、もう一方はリクエストの合間にクライアント側の処理待ちが大きく入るパターンです。ワンライナーの出力から、それぞれのパターンのレイテンシー感度が定量的にわかります。

図 5: タイトループのトレースとクライアント遅延のトレースに対する 4 つの CRET ワンライナーの出力

クライアントがタイトループするトレース (ora_196424.trc)

このトレースの対象期間は 7.0 秒で、10,000 件の CRET は平均で毎秒 1,430 件でした。1 秒を 1,430 で割ると、単一セッションの実行予算は 699µs になります。SNMFC の P50 である 665µs が非データベース時間で、ここには SQL*Net RTT とクライアント時間の両方が含まれます。単一セッションの実行予算 699µs のうち 665µs を非データベース時間が占めており、SQL*Net RTT を追加する余地はほぼありません。ワンライナー 4 の出力によると、たとえば SQL*Net RTT に 150µs を加えた場合、経過時間 7 秒に対して 2 秒 (+21.5%) 増えます。この SQL 文を処理しているセッションは、SQL*Net RTT レイテンシーの目立った増加を許容できません。

クライアント遅延のあるトレース (ora_255365.trc)

このトレースには 1,557.7 秒の間に生成された 10,000 件の CRET が含まれ、平均は毎秒 6.42 件です。ただしセッションの実行パターンはバースト的で、この平均値は実態を表していません。SNMFC の P99 が 4.17 秒であることから、数秒単位のアイドル期間が短時間の集中的な処理の合間に挟まっており、毎秒平均は実行の密度を測る指標として意味を持たないとわかります。1 秒を 6.42 で割ると、単一セッションの実行予算は CRET 1 回あたり約 156ms になります。SNMFC の P50 である 888µs (0.888ms) が非データベース時間で、SQL*Net RTT とクライアント時間の両方を含みます。156ms の実行予算に対して非データベース時間は 1ms 未満しか占めておらず、SQL*Net RTT の増加は問題になりません。ワンライナー 4 の出力によると、たとえば 10,000 件の CRET イベントそれぞれに SQL*Net RTT を 200µs 追加しても、26 分のトレースに対する増加はわずか 2 秒です。経過時間の増加率は 0.1% です。

CRET 分析: 両者の比較

全体の流れ

Client Request Elapsed Time (CRET) 手法は、3 つのフェーズで段階的に絞り込むスクリーニングプロセスです。フェーズ 1 では AWR を使い、データベース処理時間がサブミリ秒で実行頻度の高い SQL 文を特定します。フェーズ 2 では SQL Execution Session Density (SESD) を評価し、実行が 1 つまたはごく少数のセッションに集中しているかを判断します。多数のセッションに分散していれば、その SQL 文は対象外です。集中している場合はフェーズ 3 に進み、High SESD のセッションをトレースしたうえで、トレースファイルに対して CRET 分析ツールを実行し、SQL*Net RTT がさまざまな幅で増加した場合の実行時間への影響を予測します。

結果の解釈

本手法では、SQL*Net レイテンシーの増加が実行時間に与える影響を予測します。移行の判断にあたっては、次の枠組みを出発点にしてください。

ODB@AWS 移行候補における接続とデプロイの考慮事項

次のステップに沿って進めれば、ワークロードの適合性を評価し、ODB@AWS で SQL*Net レイテンシーを可能な限り低く抑えられます。

1. まず CRET 手法でワークロードをスクリーニングする。アーキテクチャを決める前に、少なくともフェーズ 1 (AWR スクリーニング) を実施し、高速かつ高頻度で、少数のセッションに集中している (High SESD) SQL 文を特定します。この分析によって、ワークロードが ODB@AWS デプロイの有力候補なのか、先にアプリケーション層の最適化が必要なのかを判断できます。
2. アプリケーション層を同一の場所に配置し、直接 ODB Peering を確立する。レイテンシーに敏感なアプリケーションコンポーネントは、ODB ネットワークと同じアベイラビリティゾーンにデプロイし、AZ 間のレイテンシーによる負荷を排除します。アプリケーションの VPC と ODB ネットワークの間には直接 ODB Peering を確立します。直接 Peering により、AWS Transit Gateway や AWS Cloud WAN を経由せず、Exadata データベースまでの最短のネットワーク経路が得られます。接続パターンの詳細は「Oracle Database@AWS ネットワーク接続パターンの実装」を参照してください。
3. ODB@AWS 高性能ネットワーキングを有効にし、レイテンシーを検証する。ODB@AWS 高性能ネットワーキングを有効にすると、同一アベイラビリティゾーン内のアプリケーション層 (EC2、ECS、EKS) と ODB@AWS データベースの間で安定したサブミリ秒の SQL*Net ラウンドトリップレイテンシーを実現できます。高性能ネットワーキングは、自動的にプロビジョニングされる EC2 プレイスメントグループを使い、アプリケーションインスタンスを Exadata インフラストラクチャの物理的に近い位置に配置します。追加料金はかかりません。測定と検証の手順は「Oracle Database@AWS の高性能ネットワーキング入門」の「Measuring Network Latency」セクションを参照してください。

まとめ

本記事では、ワークロードの SQL*Net レイテンシー特性が ODB@AWS のマルチクラウドデプロイアーキテクチャに適合するかどうかを段階的に判断する手法として、CRET 手法を紹介しました。高速かつ高頻度で、少数のセッションに集中して実行される SQL 文を分析すれば、移行前に SQL*Net レイテンシーへの感度を把握できます。

CRET の評価でレイテンシーに敏感と判明したワークロードについては、ODB@AWS アーキテクチャを候補から外す前に、配列フェッチ、バルク処理、ストアドプロシージャを使って SQL*Net のラウンドトリップを減らすことを検討してください。

著者について

この記事は Solutions Architect の 矢木 覚 が翻訳しました。