ORACLEの内部動作を理解する

データベースのチューニングやデータベース設計を行う上で、内部動作を理解することは大変重要です。インスタンスとはORACLEが実際に動いている実態のことです。メモリの動作と考えて問題ないでしょう。メインのメモリはシステムグローバル領域（SGA）になります。その中でも重要なのがデータベースバッファキャッシュです。データのやり取りをするメモリです。この領域が少なくなるとパフォーマンスが悪化します。データベースの性能の問題はメモリとの闘いと言っても過言ではありません。内部動作を理解することはデータベースチューニングや設計の第一歩です

 

ORACLEの内部動作の概要

ORACLEの内部動作の概要は以下のような流れになります。SQL解析部分は別途解説します。ここではデータの入出力を中心に解説します。利用者からSQLが発行されると以下の順に処理されます

 

１．ユーザープロセスが受付ます

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

２．サーバプロセスが受け取ります。

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

３．メモリ上のデータ存在チェック

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

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

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

５．データ変更の場合

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

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

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

７．データファイルへの書き出し

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

 

チューニングのポイント

チューニングの観点から整理するとバッファキャッシュ上にデータが存在する率（バッファキャッシュヒット率という）を上げるために、適切なSGA（バッファキャッシュ）領域の確保、不必要なデータを読まないSQLの作成、などが考えられます。一般的に処理が遅いSQLの原因は、無駄なデータを読み込んでいる場合が多いです。また、大量にデータを変更した場合、UNDOログ、REDOログの書き出しがボトルネックになる可能性もあります。どのように処理されているかをイメージできるということは、問題解決のヒントを見つけ出す手掛かりになります。