自動チューニングと手動チューニングを使いこなそう！
Oracle Databaseにおける断片化のひとつとして挙げられる、共有プールの断片化に悩まされたDBエンジニアの方も多いのではないでしょうか？
最終的にアプリケーションに対してORA-4031が発生するというトラブルは有名ですね。共有プールの断片化を防ぐため、特に9i以前の過去のバージョンでは共有プールのフラッシュを定期的に行う、といった運用を行っているシステムもあるのではないかと思います。
Oracle Database 10g以降では、共有プールの自動管理機能が加わり、また近年物理メモリの容量も増えているため、断片化の対応も行いやすくなっています。メモリの自動管理機能については、以下をご参照ください。
Oracleの自動メモリ管理機能～見積り、割当て設定、チューニングが容易に！
しかし、自動管理を用いても「共有プール不足を完全に防げる」というわけではありません。
インフラからの観点では、負荷テスト時のStatspackレポートやAWRレポートからの共有プールアドバイザを確認し、少なくともどのくらいのメモリが共有プールに必要か？を見極めることが重要です。
そして、ある程度必要なメモリ量の目処がついたら、以下のように、SGAの自動管理機能と、Oracle9i以前で使用されていた固定パラメータを併用することで、各メモリ領域の「下限値」設定を行うことが可能です。
sga_max_size = 2560M
sga_target = 2048M
db_cache_size = 512M
shared_pool_size = 512M
例：SGA自動管理機能と、メモリパラメータの固定指定を併用
こういったテクニックを使い、安定したシステム運用を提供することがDBエンジニアにとっては非常に重要ですね。
また、アプリケーションの観点では共有プールの断片化を防ぐため、リテラルSQL記述を使わずにバインド変数を使う、といったアプリケーションの考慮も重要です。
詳しくは、以下の記事をご覧ください。
Oracle Databaseの持つ自動管理機能を活用しつつ、安定したシステム運用を実践していきましょう。
9月はどんな記事が人気になるでしょうか？次回も、皆様が"使える"ネタを提供していきたいと思います。
「好奇心が、エンジニア人生を豊かにする。」＞＞ oracletech.jp
