はじめに
前回までのパートで、オラクルDBで出てくる登場人物はおおむね出揃いました。
今回はこれらのDB構成要素がどのように作用してSQLの実行をしているのかを簡単に解析していきます。そして、バックグラウンドプロセスの役割やREDO・UNDOについての理解を深めていきます。
SELECT文の解析
まずはSQLの基本となるSELECT文がどのように実行されているかを見てみましょう。SELECT文の実行順序は以下の図のようになります。
図が複雑なので段階的に順序を追っていきましょう！
1. SELECT文発行
ユーザプロセスがSELECT文を発行します。
2. SQLを解析する（Parse）
サーバプロセスが発行されたSELECT文の解析を行います。この解析のことをparseといいます。図中ではサーバプロセスが2人存在しているように見えますが、本来これらは同一プロセス（一人）です。
parseは、上司が仕事についての計画を立てるような感覚に近いと思います。つまり上司であるサーバプロセスが仕事であるSQLについて解析や実行手順の計画を行う感じです。
3. 解析結果を共有
サーバプロセスのSQL解析結果をSGAへ格納します。ここで新しい単語が出てきました。DBバッファと共有プールです！この2つについて簡単に説明します。
- 共有プール：SQLの解析結果を共有する場所
- DBバッファ：データベース内のデータを共有する場所
SQL解析結果はこの2つのうち、共有プールに格納されます。上司が建てた仕事の計画を格納する場所が共有プールということですね！
共有プールに格納されたSQLの解析結果は、再び同じSQLのタスクが来た際に再利用されます。このように、共有プールにはSQLの実行効率を向上させるメリットがあります。
4. データブロックを読み出す
解析結果の共有まで終了したら、サーバプロセスは実際のデータの読み出しを行います。このとき、サーバプロセスは毎回データベースまでデータを撮りにいくのが面倒で仕方ありません。そのため、極力楽にデータの読み出しを行おうとします。このときに活用されるのがDBバッファです！
まず、サーバプロセスはDBバッファに読み出したいデータがあるかを確認します。ここで、欲しいデータが存在する場合には、そのデータを取得してデータの読み出しは終了です。もしも、DBバッファにデータが存在しない場合には、サーバプロセスはデータベースまでデータを取りに出かけます。そして、データベースから欲しかったデータのデータブロックを取得したあと（オラクルDBのデータの最小単位はデータブロックでしたね！Part4参照）、そのデータを再度取りに出かけなくていいようにDBバッファに格納します。このようにして、データ取得の効率を上げているわけです。
このように考えると、SGAのDBバッファが大きければ大きいほどサーバプロセスの無駄な移動はなくなり、効率よく仕事ができそうですね！しかし、作業台であるSGAを大きくすればそれだけ工場の面積を圧迫することになるので、そのあたりは加減を考えてSGAの大きさを設計する必要があります。
5. SQLの結果を返す（Fetch）
データが読み出されると、一度そのデータはサーバプロセスの作業机であるPGAに格納されます。ここで、そのデータの最終確認が行われ、必要であればソート処理などを行います。最終確認が完了するとその結果データはクライアントへ納品されます。この動作のことをfetchといいます。
SELECT文の動作は以上です！お疲れ様でした！
では、最後に動作手順をまとめましょう！！！
まとめ
SELECT文は以下の手順で実行されます。
- ユーザプロセスがSELECT文を発行する
- サーバプロセスがSQLを受け取り、解析（parse）を行う
- SQLの解析結果をSGA内部の共有プールに格納する
- DBバッファかPDBからデータを読み出す
- PGAで最終確認を行い、納品する(fetch)
記事が長くなりそうなので、一旦ここまでにします！
Part5-2では、UPDATE文の解析を行う予定ですが、その前にPart6で別の話題を扱うと思います！