共有プール・バッファキャッシュのクリア

ORACLEを使用しているパフォーマンス関連のテストで気をつける事があります。
それは、SQLの解析結果や実行計画、データがメモリ上に展開されている状態でテストしてしまうことで、本来よりも短い処理時間・応答時間となり問題が表面化しないということです。
本記事ではそれを避けるための、共有プールとバッファキャッシュのクリアについてまとめました。

メモリをクリアするSQL

メモリのクリアには、共有プールのクリアとバッファキャッシュのクリアがあります。

共有プールは、ライブラリキャッシュやディクショナリキャッシュ等が含まれているメモリ領域で、SQLの解析結果や実行計画はこちらに含まれています。
バッファキャッシュは、データファイルから読み取られたデータを保持しているメモリ領域です。

実行するには、SYSDBA権限、または、「ALTER SYSTEM」システム権限が必要です。

また、ORACLEを再起動することで、メモリをクリアする事も出来ますが、上記SQL実行の方が、処理時間も短く手続きも簡易です。

参考
ライブラリキャッシュ
：SQLの解析結果や実行計画等を保持

ディクショナリキャッシュ
：ユーザー情報やテーブルスペース情報、順序情報等を保持

1回目より2回目の方が実行時間が短い

ORACLEは、例えば検索SQLを実行すると、そのSQLを解析し、どのような方法で対象データを検索するかを検討し（＝実行計画）、HDD等に保存されているデータファイルからデータを取得、それを実行者に渡すという動きをとります。

その際に、ORACLEは次回の実行に備えて、SQLの解析結果や実行計画、取得したデータをメモリ上に展開したままにしておきます。もちろん、別のSQLが実行されることを繰り返せば、メモリ上に保持しきれなかったデータはメモリから追い出されますが、ORACLEはなるべく保持するようにしています。

そういった本番運用時の処理効率UPの仕組みが、パフォーマンステスト時に問題となることがあります。
例えば、1度実行し処理時間等を計測した後に、再計測のため再度実行した場合、メモリ上に必要なデータがほぼ揃っているため、処理時間が短くなることがほとんどです。

ただし、それは本番運用時の想定とは異なった状況なので、その2回目のパフォーマンス計測の結果は誤ったものになります。（そのような状況下でのテストということであれば、問題ありませんが。）

それを回避するために、メモリのクリアが必要となります。

本番環境で使用する事も

共有プールのクリアですが、本番環境で使用するケースもあります。

24時間稼働システムでは、再起動が間隔があきます。そのような環境では共有プールのメモリ断片化が発生します。それを上記SQLをタイミングをみて実行する事で解消する事が出来ます。

実行する際の注意点

共有プールのクリアは、順序（シーケンス）のキャッシュもクリアされるので、順序（シーケンス）を利用して採番している項目に欠番が発生するので注意が必要です。

バッファキャッシュのクリアは、並行して問い合わせが行われている場合に、その問い合わせは正しい結果を戻せなくなることがあるので注意が必要です。

まとめ

パフォーマンス関連のテストは、時間がかかることも多く、やり直しには大きなコストがかかります。
そうしたことにならないために、ORACLEのメモリクリアの必要性・方法を覚えておきましょう。