本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。(編集局)
第5回までの記事では、Oracleの表へのアクセス方法や、SQLトレースの取得方法や実行計画の確認方法といった、SQLチューニングを行ううえで必ず知っておくべきことを説明してきました。これまでの情報収集で実際にSQLチューニングを始める準備は整いましたので、今回から洗い出したSQLに目を向けていきたいと思います。
今回は、効率がよくパフォーマンスに優れたSQLの記述方法について、SQLの処理ステップも交えて説明していきます。
本連載ではこれまでに、SQLチューニングの過程で読み込みブロック数が多い、もしくは処理時間の長いSQLをチューニング対象として洗い出しを行いました。これらのSQLは、データへのアクセス方法が適切でないことが原因の大半であるといえますが、SQLの記述方法については見落とされがちではないでしょうか。
チューニング対象になっているアプリケーションや、バッチ処理などで特に処理に時間がかかっているSQLを発見できなかった場合でも、データベースで処理されているSQL全体に目を向け、WHERE条件のみ異なる類似SQLが数多く実行されていないかどうかを調査します。例えば、OLTP系の処理などで、実行されるたびに条件の値(リテラル)が異なるSQLを実行しているアプリケーションでは、リテラル値部分を変数化(バインド変数化)し、SQLの記述を統一すべきです。
SQLの記述を統一することによるメリットを理解するためには、先にOracleにおけるSQLの処理ステップを理解する必要があります。
OracleがSQLを実行する際のステップは、大きく
の3つに分類できます。
解析処理(以下、PARSE)は、表1のような構文チェック、SQLの最適化などを行うステップです。JavaやC言語などでいう「コンパイル」に相当する処理と考えてください。一度解析されたSQLは、実行計画とともにSGA内の一部である共有プールのライブラリキャッシュ領域に、キャッシュされます。
PARSE完了後、実際にSQLの実行処理(以下、EXECUTE)が行われます。挿入、更新、削除処理はこのEXECUTEでSQLが完了します。
SQLがSELECT文の場合には、対象データが存在する場合、データを取り出す処理(以下、FETCH)が行われます。
処理順序 | 処理内容 |
---|---|
1 | 構文のチェック |
2 | 表、列の定義チェック |
3 | アクセスするオブジェクトへの権限チェック |
4 | 実行計画の生成 |
5 | 共有プール上に実行計画を含め解析結果をキャッシュ |
表1 OracleがSQLを実行する際のステップ |
SQLが発行されると、Oracleはライブラリキャッシュをチェックし、同一のSQLの解析結果がキャッシュされていないか確認します。キャッシュされていた場合、残りの解析処理をスキップし、キャッシュされていた実行計画を使用してSQLを実行することができます。このときの動作をSOFT PARSEと呼びます。
同一の解析結果がライブラリキャッシュ上に存在しない場合、データディクショナリに対して多くのリカーシブコール(再帰SQL)を発行し、表1のような処理を実行します。この動作をHARD PARSEと呼びます。HARD PARSEは比較的重い処理であるため、大量に発生するとデータベース全体の処理パフォーマンスに影響を与えます。
共有SQL機能を有効に利用し、HARD PARSEを回避することで、解析処理によるCPU使用率の低減、共有プールのメモリ使用量削減などを実現できます。その結果、データベースのスループットを向上させることにつながります。
【まとめ】
HARD PARSE:共有プールに解析済みの同一のSQL文が存在しない場合に実行される解析処理
SOFT PARSE:共有プールにすでに解析済みの同一のSQL文が存在した場合に、それを再実行する処理
Copyright © ITmedia, Inc. All Rights Reserved.