Home » database » Oracleの内部動作

Oracleの内部動作

チューニングを考える上で内部動作を知っておくことが重要です。

oracle_inner_action

Oracleの内部動作の概要は以下のような流れになります。

SQL解析部分は別途解説します。ここではデータの入出力を中心に解説します。

利用者からSQLが発行されると・・・

1.ユーザープロセスが受付ます

所謂リスナーです。ユーザーからのDBサーバーへの接続要求をリスニングして、DBのサーバープロセスへ接続します

2.サーバプロセスが受け取ります。

専有サーバプロセスと共有サーバプロセスという方式があります。
専有サーバプロセスはその名の通り1ユーザーが1プロセスを専有します。
共有サーバプロセスは複数のユーザーがプロセスを共有して利用します。
ディスパッチャがユーザーをスイッチングして資源を共有します。
よって専有サーバプロセスは共有サーバプロセスより高速ですが、利用者ごとの資源を必要とします。
一般的にオンライン系ユーザーは共有サーバプロセスで、バッチ系ユーザーは専有サーバプロセスを使用します。
資源(主にメモリ)に余裕があればオンライン系であっても専有サーバプロセスを選択します。

3.メモリ上のデータ存在チェック

SGA内のバッファキャッシュ上に要求するデータが存在すれば、そのまま結果を返します。(Logical readが発生します)
最も高速なパターンで、ほとんどがこのパターンであるようにしなければなりません。
バッファキャッシュヒット率といいますが、通常90%以上です。

4.メモリ上にデータが存在しない場合

ディスクから読み込む必要があります。Physical readが発生します。
当然、Logical readより遅くなります。
いかにバッファキャッシュ上のデータを有効に活用できるかがチューニングのポイントの一つです。

5.データ変更の場合

データに変更があるとUNDOログバッファ、REDOログバッファへ書出しが発生します。
UNDOログは更新前情報のログでロールバック時に使用されます。
REDOログは更新後情報のログでロールフォワード時に使用されます。
バッファがいっぱいになると、LGWRにより外部ファイルであるUNDOログファイル、REDOログファイルに書き出されます。

6.アーカイブログファイルへの書き出し

アーカイブログ運用をしている場合、REDOログファイルはARCnバックグラウンドプロセスによってアーカイブログファイルへ書き出されます。
REDOログファイルは障害回復時に最も重要なため、REDOログファイルもアーカイブログファイルも多重化しています。

7.データファイルへの書き出し

ログ書き出し後にDBWRによってバッファキャッシュからデータがデータファイルに書き出されます。

チューニングの観点から整理すると

バッファキャッシュ上にデータが存在する率(バッファキャッシュヒット率という)を上げるために

適切なSGA(バッファキャッシュ)領域の確保
不必要なデータを読まないSQLの作成

などが考えられます。

一般的に処理が遅いSQLの原因は、無駄なデータを読み込んでいる場合が多いです。

また、大量にデータを変更した場合、UNDOログ、REDOログの書き出しがボトルネックになる可能性もあります。

どのように処理されているかをイメージできるということは、問題解決のヒントを見つけ出す手掛かりになります。