消費時間をチェックする自己診断エンジン

表1●ADDMで検出される主な問題

　ADDMは，アドバイザ・フレームワークの最上位に位置し，問題を診断し，根本的な原因を突き止める。ADDMは，AWR内に取得されたデータを調べ，分析を実行してシステムの主な問題を事前に判別し，解決策を提案する。ADDMは，時間を基準にシステム・パフォーマンスを分析する。ADDMの目標は，DB時間を最も多く消費する要因を見つけることにある。ADDMでは，ドリルダウンで問題の症状だけでなく根本的な原因を見つけ，問題がシステム全体に与える影響をレポートする。推奨事項を作成する場合，ADDMは予想される効果を時間の観点からレポートする。すべてにおいて時間が使用されるので，複数の問題または推奨事項の影響を比較できる。

修正方法も示すアラート機能

図5●しきい値が設定されているときのServer Generated Alertsの仕組み 管理バックグラウンド・プロセスMMONがSGAから収集した情報と事前に設定しておくしきい値を基準にアラート・メッセージを生成する。アラート・メッセージには，問題の説明だけでなく修正方法に対するアドバイスが記載される。配信されたアラートに基づいてDBAは問題に対処できる

　Server Generated Alertsは，イベントまたはオブジェクトの状態に関するメッセージで，急を要する問題があれば効率的かつタイムリーに修正アクションの提案と共にDBAに通知する。DBAへの通知はOracle Enterprise Manager 10g上で確認できるが，リアルタイム性を高めるため，電子メールや携帯電話のメールなどをあて先に指定できる。

　Server Generated Alertsによって生成されたアラートは，問題の通知だけでなく，問題の解決方法も推奨する。実際に何が起こっているのかを診断する作業は通知された段階でデータベース自身によって終了している。通知を受け取ったDBAは，Oracle Enterprise Manager 10g上からウイザード形式で提案された対処方法に従い，問題を解決できる＊3。

　Server Generated Alertsは，Oracle Database 10gから採用された新しいバックグラウンド・プロセスであるMMONによって実現される。MMONは，サーバー内のすべての自動管理を処理する専用の管理バックグラウンド・プロセスであり，データベース・サーバーの各コンポーネントは，MMONを使用して監視アクションを定期的に実行する。問題を検出したコンポーネントは，サーバーによって自動的に修正アクションが実行されるようにスケジュールするか，ユーザーがアクションを実行するようにアラート・メッセージを生成する仕組みになっている。同様に，サーバー・プロセスの異常な状況を発見した場合も，MMONが実行する緊急アクションを起動できる。

　監視はデータベースの通常の操作と同時に実行されるため，監視しているリソースのオーバーヘッドをさらに削減し，無視できる程度になっている。また，MMONは測定値（システムによって収集された統計の導出値）をAWRに定期的にフラッシュし，それらの値の履歴を保持する仕組みも併せ持つ。

診断結果を自動実行するコンポーネント

　ADDMが分析した結果，オプティマイザ統計のリフレッシュや索引再作成などの更新タスクを日課として実行する必要があることが認識できたら，自動更新タスク・インフラストラクチャを使用してOracleデータベースが自動的にその作業を実行する。このコンポーネントは，Oracle Database 10gに導入されたスケジュール機能＊4を使用する。Oracle Enterprise Manager 10gの「更新ウィンドウ」でタスクを実行する機能である。

図6●Oracle Database 10gが備える主なアドバイザ機能 10gではデータベースのパフォーマンスを最適化するために，新たに3つのアドバイザ機能が実装された。稼働後だけでなく，新たにデータベースを構築する際に，領域のサイズを指定してくれたり，推奨事項を指示してくれたりする

ADDMより詳細なアドバイザ機能

　Oracle Database 10gは，サブ・システムごとに多数のアドバイザを備えており，それにより各サブ・コンポーネントの動作をさらに最適化する方法を自動的に判別可能である（図6[拡大表示]）。SQLチューニング・アドバイザおよびSQLアクセス・アドバイザは，SQL文を高速実行するための推奨事項を提供する。セグメント・アドバイザは，無駄な領域の再生の推奨，新規表および索引のサイズの予測，および成長傾向の分析など領域関連のあらゆる問題を扱う。UNDOアドバイザは，UNDO表領域のサイズ指定を支援する。

図7●パフォーマンス問題の解決方法の違い 10gでは，ADDMをうまく活用することで問題解決に至るまでの時間を短縮できる。また，複雑なコマンドを覚えたり，そのコマンドから得られる情報を多角的に分析したりする必要もなくなった

　パフォーマンス問題の原因は，アプリケーション設計であることが最も多い。しかし，開発者，DBAおよびシステム管理者が持つチューニングに関する知恵を結集しても，アプリケーションのアーキテクチャや設計の不備によるボトルネックの修正は難しい。

　クエリー・オプティマイザ＊6はクエリーのパフォーマンスに大きな影響を与える。Oracleデータベースが備えるクエリー最適化技術は，多くの場合，管理者の介入なしにアプリケーションのクエリー・パフォーマンスを高めることができる。しかし，場合によっては，アプリケーションの性質またはデータ配分の一意性が原因となって特定のSQL文が常にシステム・リソース全体に対して高い割合を占めることがある。

　こうした問題を解決するためには，Oracle9i Databaseまでは，3つの基本的な手順でSQLチューニング・プロセスを行っていた。まず第1に，アプリケーション・ワークロードおよびシステム・リソースの大量共有の原因となる高負荷または上位SQL文を識別するため，システムに残されている過去のSQL実行履歴を調査する＊7。次に，クエリー・オプティマイザによって生成された実行計画で，これらの文が無理なく実行されるかどうかを調査する。そして最後に，パフォーマンスの悪いSQL文に対してより良い実行計画が生成されるように修正する。

　DBAはこの3つの手順をパフォーマンスが満足のいくレベルまで繰り返す作業が必要であった。このSQLチューニング・プロセスは，膨大な時間を要する上に高い専門的な知識が欠かせない。アプリケーションとデータベース・システムを熟知していないと，このタスクを実行することは難しい。

自動チューニングでパフォーマンス問題を解決

図8●自動チューニング・オプティマイザの機能 高負荷なSQL文を自動的に抽出した後，SQL文の最適なチューニング方法を示す新しい自動化機能

　自動SQLチューニングは，1つ以上のSQL文を取得し，適切にチューニングされた実行計画とアドバイスを作成する。そのためDBAは，自動SQLチューニングを起動するだけで，オプティマイザによって問題のSQL文が分析され，解決策が推奨されるため，その指示に従うだけでよくなる。

　SQLプロファイリングはパッケージとして提供されるアプリケーションで有効な機能である。パッケージ・アプリケーションのSQL文にパフォーマンスの問題を抱えていても，バージョンアップされない限り，エンドユーザーは何もできない。この機能を使用すればこうした条件下であっても，パッケージ・アプリケーションが効率の悪いSQL文を実行する場合，SQLプロファイリングが提示するチューニングされた実行計画に差し替えることができる。そのため，パッケージ・アプリケーションのバージョンアップを待つことなくパフォーマンスの改善ができる。

　SQLアクセス・アドバイザも，Oracle Database 10gの管理に関する拡張機能の1つであり，このアドバイザは，スキーマ設計のワークロードを自動的に分析し，ワークロードに適した索引およびマテリアライズド・ビューの作成，保持または削除を推奨する。推奨事項を作成する時，SQLアクセス・アドバイザは，新しい索引およびマテリアライズド・ビューの追加によって挿入，更新および削除などのデータ操作アクティビティが受ける影響とそれによって改善されるクエリーのパフォーマンスも考慮する。

　自動チューニング・オプティマイザが分析する内容は4つある（表2）。アクセス・パス分析とSQL構造分析は，開発中のアプリケーションまたは自社開発の本番アプリケーションのパフォーマンスをチューニングする際に利用する機能である。