WebSphere Product Center のモニターは、 rootadmin の使用、 rmi_status スクリプトまたは GUI を使用して行うことができます。WebSphere Product Center では、独立型のモニター・ツールは提供されません。
モニター・ツールの作成は、この文書では紹介されません。ただし、以下に簡単なアイデアについて言及しておきます。
- アプリケーション・サーバーに仮想ホストを作成するか、おそらく個別のモニター用サーバーを作成します。 rmi_status および rootadmin.sh ではシステム負荷が発生するので、多くの環境では、モニター用のサーバーを別にすることをお勧めします。
- Perl などのスクリプト言語を使用して、サービスの状況を制御したり、表示したりする rootadmin.sh の CGI ラッパーを作成します。
- Web サーバーに、ログ・ファイルのブラウズを容易にする $TOP/logs を指す別名を作成します。
- 例外やその他のエラーがないかどうか $TOP/logs 内のログを解析し、 オプションでサービス状況をチェックするユーティリティーを作成します。このユーティリティーは、E メールを送信したり、エラーが発生した場合には管理者用の他の幾つかの通知方法を提供することができます。このユーティリティーは cron から実行します。
サービスの簡略状況を入手するには、以下のパラメーターを渡します。
-cmd=check -svc=<service name>
簡略状況には次のものがあります。
実行中 サービスが実行中であり、ハートビート機能に応答しています。 見つかりません サービスが見つかりませんでした。サービスが開始されていなかったか、または破損していることなどが考えられます。 見つかりましたが、応答していません サービスが RMI レジストリーに登録されたものとして見つかりましたが、ハートビート機能に応答しません。サービスを再始動する必要があるかもしれません。
サービスの詳細状況を入手するには、以下のパラメーターを rootadmin.sh に渡します。
-cmd=status -svc=<service name>
HTML ファイルが作成されるので、任意のブラウザーを使用して参照することができます。 ターミナルでは、Lynx (または同様のツール) を使用して出力をフォーマットします。
この詳細状況は、サービス内で実行されている異なるスレッドの概要に加え、サービスが現在採用しているデータベース接続の状況も示します。
例:
スケジューラーの状況を入手するには以下のようにします。
rootadmin.sh -cmd=status -svc=scheduler > /tmp/sch_status.html; lynx /tmp/sch_status.html
または、以下の方法もあります。
rootadmin.sh -cmd=status -svc=scheduler > /tmp/sch_status.html; lynx -dump /tmp/sch_status.html
注: 上記の例で使用している「>」は、 状況の詳細情報を出力ファイルに書き出します。
リレーショナル・データベースは、大量の製品情報コンテンツの主要なストレージであるため、パフォーマンスの低下や損失を避ける管理アクションを提供することは重要です。
WebSphere Product Center でアラートを設定することにより、 発生する可能性のある問題に関して通知が行われ、問題が手におえなくなる前に解決できる場合があります。 モニタリング・システムをインプリメントして、WebSphere Product Center データベースを常にモニターする必要もあります。
以下のタスクは、定期的に実行されなければなりません。
- 必要に応じてより多くのスペースを割り振る
- 必要に応じてフィックス・パック / パッチを適用する
- 必要に応じて、データベース・マネージャー、データベース、他のサービスを始動したりシャットダウンしたりする
- より良いパフォーマンスを得るために、必要に応じてデータベース・スキーマを分析し、統計を収集する
- より良いパフォーマンスを得るために、定期的にテーブルや索引を再編成する
- スケジュール済みのバックアップ・ジョブの状況をチェックする
- 必要に応じて、データベースをリストアしたりリカバリーしたりする
- データベースのパフォーマンスを調整する
1. 必要に応じてより多くのスペースを割り振る
スペース管理は、管理者にとって継続的なタスクとなります。完全な静的データベースを持っている場合を除き、 テーブルおよび索引は、サイズが定期的に増加したり縮小したりします。継続的な処理が中断することなく行われるように、 使用可能な十分のスペースがあることを確認する必要があります。また、 スペースが効率よく使用されているかどうか確認する必要があります。 必要な場合には、DB2 コントロール・センターを使用してスペースを割り振ります。 コマンド行インターフェースを使用して、同じタスクを完了することもできます。
2. フィックス・パック / パッチを適用する
フィックスパック / パッチは、製品の修正で、データベース・システム・ベンダーが定期的に配信しています。 バグの修正を目的としているため、新規の機能は含まれていません。したがって、ターゲット・システムでの認証は必要ありません。 データベース・システムに関する既知の問題を回避するために、フィックスパック / パッチが提供されている場合には、 これらを適用することは重要です。修正情報について詳しくは、データベース・システムのベンダーに連絡してください。
3. データベース・マネージャー、データベースを始動したりシャットダウンしたりする
フィックスの適用 (サーバーから別のサーバーへデータベースを移動するなど) の一環として、 データベース・マネージャー / データベースをシャットダウンする必要があります。必要に応じて、データベースを始動およびシャットダウンする必要があります。
4. データベース・スキーマを分析し、統計を収集する
データベース・スキーマは分析され、データベース内のテーブルおよび索引に関する最新の統計を収集します。コスト・ベースの最適化手法では、統計を使用して、それぞれの実行プランのコストの見積もりを判別します。統計は定期的に収集され、スキーマ・オブジェクトに関する最良の情報をオプティマイザーに提供します。たとえば、かなりの行数がテーブルにロードされた場合には、テーブルの新規の統計を収集する必要があります。
データベース・スキーマを分析するには、$TOP/src/db/schema/util ディレクトリーにあるシェル・スクリプト analyze_schema.sh を実行します。
5. テーブルや索引を再編成する
より良いパフォーマンスを得るために、定期的にテーブルや索引を再編成することをお勧めします。
今日のデータベースは以前に比べて急速に拡大しているため、DBA は、 最適なパフォーマンスを達成するためのスペース管理や再編成に膨大な時間を費やす必要があります。
最適なパフォーマンスとは、最適な応答時間のことを意味します。 しかし、膨大なスペース管理の問題ゆえに、パフォーマンスが低下する可能性があります。 これらの問題の大半は、3 つの主要な領域、つまり、テーブルに関する問題、索引の分断化、I/O バランスとデータの分割化などに分けられます。
テーブルに関する問題については、ほとんどの DBA がよく通じています。 これらの問題には、テーブル・ブロック内の十分に活用されていないスペース、チェーニングされた行、 データ近接性の低さ、フラグメント化された (拡張しすぎた) テーブルなどが含まれます。
パフォーマンスの課題に関する 2 番目の問題は、大きくなってしまい、データが散在している索引です。
これによって、索引範囲スキャンのパフォーマンスが大幅に低下する可能性があります。 また、大量のディスク・スペースを浪費する可能性があります。
パフォーマンスの課題に関する 3 番目の主要な問題は、I/O バランスおよびデータの分割化です。 頻繁にアクセスされるオブジェクトが同じデータ・ファイルに常駐している場合、I/O ボトルネックが生じる可能性があります。 DB2 での reorgchk のようなツールは、再編成する必要があるオブジェクトに関する情報を明らかにします。 データベース・オブジェクトを再編成するのに使用可能なメソッドおよびツールは数多く存在します。 これらについては、テーブルや索引の再編成に関する、データベース・システム・ベンダーの特定の資料をご一読ください。
6. スケジュール済みのバックアップ・ジョブの状況をチェックする
バックアップは、リストアおよびリカバリー処理における重要な部分です。 すべてのバックアップ・ジョブの状況を検証して、これらのジョブがスケジュール通りに実行していることを確認してください。
バックアップの状況のチェックは、バックアップ手順の定義方法およびバックアップを行うのに使用するツールによって異なります。詳しくは、ベンダー・データベース・システムのバックアップに関するベンダー固有の資料を参照してください。
7. データベースをリストアしたりリカバリーしたりする
データベースに障害が発生した場合、障害のタイプおよび程度を判別します。 この分析により、システムをリカバリーするために実行するステップが示されます。 IT サポート・グループによって定義されたとおりにリストアおよびリカバリー処理を使用します。
物理的なバックアップのリストアとは、データベースを再構築し、それをデータベース・サーバーで使用可能にすることを意味します。 リストア済みのデータ・ファイルのリカバリーとは、再実行レコード、 つまりバックアップを取った後にデータベースに加えられた変更のレコードを使用して、データベースを更新することです。
8. データベースのパフォーマンスを調整する
DBA が担う最大の責任の 1 つは、データベースが正しく調整されているかどうか確認することです。 RDBMS は、幅広い調整が可能であり、データベースがそのパフォーマンスを向上させるためにモニターおよび調整することができます。
パフォーマンス調整を行わなければならない理由として、以下の点が挙げられます。
- 計算の速度によって、貴重な人的時間 (ユーザーが応答を待機する) が浪費される可能性があります。
- 以下のようにして、ご使用のシステムがビジネスが行われるスピードに追いつくことができるようにします。
ハードウェアの使用法を最適化し、コストを削減します (会社はハードウェアに多額のコストを費やしています)。
データベースのパフォーマンスを調整するのに使用可能な各種の方法について詳しくは、DB2 製品に付属している製品資料を参照してください。