 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| 設計アドバイザー | ||||||||||
|
DB2 9のオプティマイザーがアクセスプランを決定するにあたって重要なことが2つあります。 1つは「統計情報」です。表や索引の定義情報だけでなく、実際に何件入っていて、どれ位データの並び順がよいのか、といった統計情報を基にアクセスプランを決定します。つまり、実際のデータと統計情報の内容に乖離があると、正しいと思ったアクセスプランでも実際にはパフォーマンスがでないという事態が発生します。 そのため、運用フェーズでの統計情報の維持が性能上必要です。DB2 9では、Runstatsユーティリティという統計情報取得用のコマンドを提供しています。いつ行うかは運用設計で決めてもいいですし、DB2 9の自動保守機能を利用しても簡単です。 もう1つは「索引の存在」です。索引がなければ、オプティマイザーは選択しようがないので、索引を事前に作っておかなければなりません。こんな時に活躍するのが設計アドイバイザーです（図3）。  図3：設計アドバイザー （画像をクリックすると別ウィンドウに拡大図を表示します） 設計アドバイザーに実際に稼動しているSQLを入力すると、最適な索引を推奨してくれます。また、一緒にCreate Index文も生成してくれますので、そのままコマンドを実行することも可能です。設計アドバイザーはオプティマイザーに「索引が有効かどうか」を問い合わせるので、実行する際も統計情報を最新にしておくことをお勧めします。 このように、DB2 9のオートノミック機能には、構築や運用時になるべくデータべース管理者の負荷を軽減し、デーやベース管理者のいないシステムでも快適に稼動できるための工夫がこらされています。 逆に、トランザクション負荷が高い、データ容量が大きい、性能要件がよりシビアなミッションクリティカルなシステムでは、データベース管理者の方が設計・チューニングすることもできます。このようなチューニングの際も、オートノミック機能を利用して調整値の決定や索引を作成するヒントにすることで、システムの品質を向上することが可能です。 つまり、なるべく簡単に構築・運用ができるように設計されていながらも、必要に応じて設計・チューニングをすることも可能で、どんなシステムでも使えるような汎用的なRDBMSであることがDB2 9の特徴の1つともいえます。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
