DB2/Informix とオープン・ソース: 腹黒い政治的策略に対するデータベースの防御

キャリア強化のためのデータベース・リアルタイム監視

システム管理者にとって、システム・ダウンは最もストレスの多い出来事の 1 つです。この記事では、データベースのリアルタイム・モニターを作成する方法を紹介します。これにより、問題の発生時にアラートを受けられるようにするとともに、データベース・サーバーのステータスに関する貴重な情報を人々に提供できるようになります。焦点となるのは、責任を追及することではなく、問題を解消することです。リアルタイム・モニターは、アプリケーション管理者とネットワーク管理者にとって、システムの機能停止の原因を迅速に診断するための資産にもなります。データベース・ステータスを公開するための PHP ページを含め、監視用の完全なソース・コードが用意されています。

Marty Lurie (lurie@us.ibm.com), Information Technology Specialist, IBM

Photo: Marty LurieMarty Lurie のコンピューターのキャリアは、IBM 1130 で Fortran のコードを紙テープにパンチしていた時代にまでさかのぼります。普段は IBM の WebSphere システムのエンジニアリングに携わっていることになっていますが、問い詰められれば、実はほとんどコンピューターで遊んでいるだけだと白状するでしょう。彼のお気に入りのプログラムは、自分のラップトップにエクササイズ機器の Nordic Track を接続するために書いたプログラムです (そのおかげで、ラップトップは 2 ポンドの減量と 20% のコレステロール値の減少に成功しました)。彼は、IBM 認定の上級 WebSphere アドミニストレーター、DB2 データベース・アドミニストレーター、そしてビジネス・インテリジェンス・ソリューション・プロフェッショナルの資格を持っています。さらに、飼い犬にはバスケットボールをプレイするように訓練しました。連絡先は、lurie@us.ibm.com です。


developerWorks 貢献著者レベル

Aron Y. Lurie (aron.lurie@gmail.com), 10th grader/webmaster, Newton South High School/Hebrew College

Aron Y. LurieAron Lurieは、この記事の執筆時点では、9年生(中学3年生)でした。4年間にわたってWeb開発事業に関わり、4年生の頃から新しい言語の習得に取り組んでいます。ヘブライ大学をメインのクライアントとし、そこでハイスクールのWebマスターを務めています。また、最近自分が通っている学校の校内新聞のWebマスターを任され、地元USY(United Synagogue Youth)支部のWebマスターも務めています。Newton Southスキー・レース・チームに所属し、余暇はスキーを楽しんでいます。残念ながら、スキーをコンピュータで制御する方法はまだ見つけることはできないようです。



2006年 12月 21日

せっかちな人のためのクイック・スタート

  1. 「ダウンロード」セクションに記載されているサンプル・コードをダウンロードして解凍します。
  2. 監視対象のデータベースを指定するように ODBC (Open Database Connectivity) を設定します。
  3. JpGraph パッケージを使用してグラフを作成する PHP を構成します。
  4. ご使用の環境に合わせて「goqc」スクリプトを変更します。
  5. JMeter または Rational® Performance テスターを使ってデータベースに負荷をかけます。
  6. ローカル接続のパフォーマンスとネットワーク・パフォーマンスとを対比させるリモート・エージェントを構成します。

腹黒い政治的策略: 責任のなすり合い

データベース管理者 (DBA) は、組織に信頼性の高いデータベース・サービスを提供することに誇りをもっています。だからこそ、パフォーマンスの問題やアプリケーションの機能停止がデータベースの責任にされると、かなりのストレスを感じるのも不思議ではありません。この記事では、データベース・ステータスのリアルタイム・グラフ (図 1 を参照) を提供して言われのない非難を減らすとともに、問題を特定して迅速に解決する方法を紹介します。

図 1. リアルタイムのデータベース・ステータス
リアルタイムのデータベース・ステータス

X 軸は時間で、左側の Y 軸は秒単位の応答時間、右側の Y 軸はユーザー接続数です。図 1 で明らかなのは、300 人近くのユーザー数という大きな負荷になっても、データベースが 1.5 秒未満という素早い応答時間を維持しているということです。このシミュレーションはディスクが 1 つしかない単一のラップトップで実行されているため、パフォーマンスは抜群です。このようなグラフが組織で利用できれば、データベースには何の問題もないことが明らかになります。逆に、何かが壊れている場合はより早い段階に知ることできるため、根本原因の究明にかかる時間も短縮できます。


データベースの品質管理と統計的サンプリング

図 1 のグラフを作成するには、サーバーのステータスに関するデータが必要になります。データを収集し、Web ページで使用可能にするのは統計的プロセス管理 (Statistical Process Control) では簡単なステップです。統計的プロセス管理についての詳細は、「参考文献」セクションを参照してください。Dr. Demming が擁護するこの品質向上プロセスは、「メイド・イン・ジャパン」を粗悪な品質から今日の卓越したレベルにまで推し上げました。

データを収集する際には、以下の 2 つの落とし穴があります。

ナイキスト定理によると、例えば 20 秒ごとに発生するイベントの正確なサンプルを取るには、10 秒ごとにサンプルを測定しなければなりません。つまり、毎分のデータベース障害率を測定するには、30 秒ごとにサンプリングを行う必要があるということです。記載したスクリプト例では、サンプリング・レートは 2 秒ごとなのでフィードバックは即座に得られますが、生成されるサンプル・データは短時間でかなりの量になってしまいます。

一方、サンプルを取ることによってどのような影響が出るでしょうか。私が車のキーの正確な運動量を計算しても、ハイゼンベルグの不確定性原理では、キーは宇宙のどこにでも位置する可能性があることを示唆しています。ハイゼンベルグが論じていたのは実際には素粒子の位置と運動量ですが、その考えは同じです。データベース・サーバーの処理速度が落ちると、人々がテストやトラブルシューティングのためにログインすることにより作業負荷が増し、事態はいとも簡単に悪化します。上記の例のインスツルメンテーションは、Web ページでのステータス表示の負荷を別のサーバーに負担させます。このアーキテクチャーは「見物人」をデータベース・サーバーから遠ざけ、すでに存在する問題を悪化させずに彼らがステータスを見られるようにします。


品質管理サンプリング・エージェント

品質管理サンプリング・エージェントは単純なタスクでデータベースのステータスを測定し、そのデータをデータベース表に記録します。DB2® 表の関数のとても豊富な機能や Informix® の sysmaster データベースを使えば、データベース・サーバーに関するほとんどすべてのデータを取得できます。

図 2 に、このエージェントで採用されたアーキテクチャーを示します。オプションにはローカル・エージェントとリモート・エージェントの両方がありますが、サンプル・コードでは単一のエージェントが実装されます。2 つのエージェントをデプロイするには、スキーマとコードを変更する必要があります。

図 2. サンプリング・エージェントで採用されたアーキテクチャー
サンプリング・エージェントで採用されたアーキテクチャー

なぜローカル・エージェントとリモート・エージェントを使って、ネットワークで通信するのでしょうか。ここでは責任を追及するためではなく、問題を修正するために、障害を切り分けようとしているので、ローカル・エージェントとリモート・エージェントの応答時間の差によって、すぐさまネットワークの減速を特定できます。DBA が連絡して問題の特定を手伝えば、ネットワーク・チームがどれほど感謝するか想像してみてください。

ダウンロード・ファイルには 2 通りのエージェント実装が含まれています。1 つは Informix ディレクトリーにあるネイティブ esql/c エージェントです。そしてもう 1 つは ODBC ディレクトリーにある DB2 実装で、移植性を最大限にするために PHP で作成されています。

プログラムは以下のステップを実行します。

  1. タイマーを起動する。
  2. データベースに接続する。
  3. データベースに接続するまでの時間を測定する。
  4. transtimes 表に、タイムスタンプ、固有キー、接続時間が含まれる新しい行を作成する。
  5. 対象データベースについて関心のある統計値を収集し、単純なトランザクションをシミュレートする。
  6. ステップ 4 で作成した行を更新し、ステップ 5 で収集した統計情報とステップ 5 の所要時間を記録する。

図 1 のグラフには、接続数、接続時間、そして挿入/更新時間が示されています。このエージェントの Informix ポートで使用された表の実際のスキーマ (リスト 1) には、仮想メモリーの割り当て量と使用量が含まれます。このスキーマを見ると、サーバーのインスツルメンテーションに Informix sysmaster または DB2 表の関数がいかに簡単なインターフェースを提供しているかがわかります。大量の onstat や snapshot のデータで sed、awk、grep、perl を実行する必要はありません。

上記のステップ 5 には、システムの標準的な作業負荷を表す単純なトランザクションのシミュレーションが含まれています。この単純なトランザクションは、システムを使用する一般ユーザーが体験するであろう内容のデータ・サンプルを作成します。電話注文を受ける OLTP (Online Transaction Processing System) の場合は、シミュレート対象の相互作用or対話動作はカスタマー検索となるはずです。監視しているデータベース・システムが意思決定支援 (DSS) 用で、クエリーが長くて複雑な場合は、品質管理 (QC) エージェントに大きなクエリーを実行させないでください。上記のハイゼンベルグ不確定性原理の説明によると、QC エージェントによる大きな DSS クエリーはサイクルを浪費して他のすべてのユーザーの処理速度を落とすだけです

リスト 1. Informix esqlc バージョンの QC エージェント用スキーマ
--  (c)2006 copyright Martin Lurie, sample code, not supported
create database oltpqc;
database oltpqc;
drop table transtimes;

-- the DB2 identity datatype is similar to Informix serial
-- in the php version of the code a simple integer was used and
-- php increments the transkey, this gives maximum portability
create table transtimes ( transkey serial primary key,
			timestamp	datetime year to second,
			connect_time	float,
			session_count	integer,
			vblkused		integer,
			vblkfree		integer ,
			query_insert_time	float
);

リスト 2 は、PHPエージェントと併せて使用した DB2 スキーマです。

リスト 2. DB2 PHP バージョンの QC エージェント用スキーマ
--  (c)2006 copyright Martin Lurie, sample code, not supported
create database oltpqc;
connect to  oltpqc;
drop table transtimes;

create table transtimes ( transkey int primary key,
			timestamp	date,
			connect_time	float,
			session_count	integer,
			query_insert_time	float
);

データの収集は、何もこのスキーマに限られるわけではありません。エージェントでのインスツルメンテーションのために選択したものが何であれ、データ・サンプル表に含めることはできます。このプロジェクトの発端となったのは、アプリケーション開発者とデータベース管理者との「責任のなすり合い」です。ユーザー数と合計メモリー消費量のインスツルメンテーションによってメモリー消費の直線関係が示されたため、言い争いに終止符が打たれました。アプリケーションは、応答時間の低下が検出された場合にはデータベースへの新規接続を行わないように変更されました。

リスト 3 に、DB2 の接続ユーザー数を検出する表の関数を示します。その他の DB2 表の関数機能を使用する方法、そして Informix の sysmaster データベースを使用する方法については、「参考文献」セクションを参照してください。

リスト 3. 同時ユーザー数を取得するための DB2 表の関数によるクエリー
--  (c)2006 copyright Martin Lurie, sample code, not supported

 select local_cons +rem_cons_in from table (snapshot_dbm (-1))as snapshot_dbm

Informix では表の関数の代わりに sysmaster データベースを使用してサーバー・ステータスに関する情報を提供します。ユーザー数取得のための Informix クエリーについては、リスト 4 を参照してください。

リスト 4. 同時ユーザー数を取得するための Informix sysmaster によるクエリー
/* this sql is from the esqlc program, so the result set is
stored in a host variable.   */
        select count(*) 
           into :sessioncount
           from sysmaster:syssessions;

エージェント・コードは単純明快なものです。PHP プラットフォームに依存しないバージョンの ODBC デーベースに接続するための「秘密のソース」は odbc.ini ファイルです。PHP で ODBC 接続をするための資料はさまざまなところから入手できます (「参考文献」セクションを参照)。リスト 5 とリスト 6 は、それぞれ DB2 と Informix の場合の odbc.ini ファイルです。時間をつぎ込むことができるのなら、ODBC の代わりにダイレクト・ドライバーを使用して PHP を作成することもできます。この例には ODBC のパフォーマンスで十分なので、クライアントとしてだけでなく、応答時間の結果をグラフにするためのデータの収集にも使用します。

リスト 5. Linux での ODBC 構成に対応した DB2 の odbc.ini ファイル
[ODBC Data Sources]
SAMPLE=IBM DB2 ODBC DRIVER

[SAMPLE]
Driver=/home/db2inst1/sqllib/lib32/libdb2.so
Description=DB2 Sample database
リスト 6. Linux での ODBC 構成に対応した Informix の odbc.ini ファイル
[ODBC Data Sources]
SAMPLE=INFORMIX DB2 ODBC DRIVER

Driver=/home/db2inst1/sqllib/lib32/libdb2.so
Description=Informix smaple odbc.ini


[ODBC Data Sources]
Infdrv1=IBM INFORMIX ODBC DRIVER
Infdrv2=IBM INFORMIX ODBC DRIVER

;
; Define ODBC Database Driver's Below - Driver Configuration Section
;
[Infdrv1]
Driver=/home/informix/lib/cli/iclit09b.so
Description=IBM INFORMIX ODBC DRIVER
Database=stores_demo
LogonID=odbc
pwd=odbc
Servername=ids_server1

[Infdrv2]
Driver=/home/informix/lib/cli/iclit09b.so
Description=IBM INFORMIX ODBC DRIVER
Database=oltpqc
LogonID=informix
pwd=useYourOwnPassword
Servername=k_ids
Trace=0
TraceFile=/tmp/odbctrace.out
InstallDir=/home/informix

早期警告システム: アラートの生成

応答時間が遅いときは、オペレーション・センターから連絡を受けるより前に DBA がそれを知ることが得策です。これは問題の発生を把握するという責任とプライドにかかわることで、問題がある場合には早期に知りたいと思うはずです。責任のなすり合いとは関係なく、高品質のデータベース・サービスを提供するためです。

oltpqc コードには、アラームのしきい値としてコマンド・ラインに定位置パラメーターが必要です。この値はミリ秒単位で、応答がこの時間より遅いと、Unix/Linux スクリプトが起動されます。リスト 7 とリスト 8 はそれぞれ esqlc と PHP の場合のアラートの実装です。

リスト 7. 応答時間がしきい値を超えたときにアラームを生成する ESQLC コード
/* code to capture the positional paramter from the command line */

 if (argc == 2 ) {
        thresholdms = atoi ( argv[1] ); 

#ifdef PRTDIAG
        printf( "argv[1] %s  thresholdms %d \n", argv[1], thresholdms );
#endif
        printf( "(c)copyright 2005 - alarm %d milli-seconds \n", thresholdms );
        }
        else
        {
        printf( 
		"(c)copyright 2005 - USAGE: %s threshold_millisec\n", argv[0] );
        printf( "example:  %s 1500\n" , argv[0] );
        printf( "generates an alarm when response time is over 1.5 seconds\n" );
        return -1 ;
        }


/* ... lines deleted .... */

/* logic to run a shell script and pass in the response time data 

to the shell script */
	 asprintf ( &alarmstring , "./slowalarm.sh %f %f " , 
                elapsed_con, elapsed_wrk );


 	if ( ( elapsed_wrk+elapsed_con ) > (float)thresholdms/(float)1000 ) 
                system ( alarmstring); 
#ifdef PRTDIAG
        printf ( "times elapsed_wrk %f , elapsed_con %f , thres  %f \n", 
        elapsed_wrk,elapsed_con, ( (float)thresholdms/(float)1000 ) );

#endif
リスト 8. 応答時間がしきい値を超えたときにアラームを生成する PHP コード
//check to see if alarm should be sounded
if (($third_time - $first_time)*1000 > $thresholdms)
{
        echo "DATABASE SLOW ALERT - CONNECT AND QUERY TIMES" ;
        echo "GREATER THAN $thresholdms MILISECONDS\n\n";
        system ("alert.sh");
}

サンプリング結果の公開とスプレッドシートの制約

このプロジェクトでは、データを Web ページで公開することが強く求められます。サンプル・データを報告および配布しなければ、その価値はほとんどないからです。スプレッドシート技術では、リアルタイムでグラフを作成するまでしか実現しません。ステータスのスプレッドシートを E メールで配布するのはかなり面倒です。その一方で、スプレッドシートを動的にリフレッシュしてデータベースに再接続するように構成するという案は、データベースを監視するすべてのデスクトップからの情報でスプレッドシートがリフレッシュされるたびにデータベース・サイクルが発生するため、費用が高くつきます。図 3 に、ユーザー数と応答時間のスプレッドシート分析を示しますが、これは説明のために記載するのであって推奨はされません。

図 3. スプレッドシートによる品質サンプルのグラフ作成 (Y 軸のログ目盛りに注目)
スプレッドシートによる品質サンプルのグラフ作成 (Y 軸のログ目盛りに注目)

Web サイトでの公開

品質管理エージェントで収集したステータス情報を公開するのに最適な技術は Web サイトです。図 4 のグラフは JpGraph パッケージに基づいています (詳細は、「参考文献」セクションを参照)。この PHP コードは実に素晴らしいグラフ作成ツールのセットです。gd および php-gd をはじめ、必要なものをいくつかインストールする必要がありますが、DB2 データに対して Informix をグラフにするのは、接続ステートメントを変更するのと同じくらい簡単でした。これは PHP と、データベースとの ODBC 接続を使用して移植性を実現するという、実に洗練された使い方です。

図 4. JpGraph、PHP グラフ作成パッケージを使用したサンプル・データベース・ステータス

Database status graph

注目すべき点は、JpGraph パッケージではグラフの背景に jpg 画像を配置できるということです。図 4 では、背景に Informix が後援するレース・カーが表示されています。

このステータス・グラフは自動リフレッシュを実行します。リアルタイムのステータスを表示するページがリフレッシュしなければ意味がありません。このページは AJAX のような凝ったものを使用しているわけではなく、単純な HTML です。リスト 9 と 10 を見て、なぜ一方が良くて、もう一方が悪いかわかりますか? リスト 9 では、cron ジョブが定期的に実行されて、php qcgraph.php > foo.jpg が行われるという前提となっています。

リスト 9. 自動リフレッシュのための「良い」HTML ページ
<META >-EQUIV=Refresh CONTENT="3; URL=index.html">
<h1>Database Real Time Status</h1>
Click the refresh button if the graph does not appear below.
<hr>
<img src="foo.jpg">
<hr>
<!-- this page assumes a cron job is running periodically that 
performs the following: php qcgraph.php > foo.jpg -->
リスト 10. 自動リフレッシュ・ページの「悪い」リスト (機能しますが、この方法は使わないでください)
<META HTTP-EQUIV=Refresh CONTENT="10; URL=auto.html">
<h1>Database Real Time Status</h1>
<img src="qcgraph.php">
<hr>

もうおわかりだと思いますが、「悪い」自動リフレッシュ・コードでは、多数のユーザーがステータスを表示するとサーバーに大幅な作業負荷がかかります。これはマーフィーの法則と連携したハイゼンベルグの不確定性原理です。データベースのステータスを測定するとデータベースでの作業が増えることになり、そして何かしらが「不調」になった場合、好奇心の強い人々がサーバーを調べようとブラウザーを起動して、問題が悪化します。

一方、リスト 9 の「良い」実装は、データベースの作業負荷を最小限にします。ステータス・グラフの jpg 画像はすべての詮索好きな人たちで共有されるため、ステータスの調査員をサポートするための作業負荷は Web サーバーで分離できます。Web サーバーがデータベースと同じマシンに常駐していなければならないという条件さえありません。JpGraph の .jpg 出力を定期的にリフレッシュする必要はありますが、これは cron でスケジュールできます。記載したサンプル・コードでは、Linux の watch コマンドを使用しています。


サーバー・パフォーマンスの特性評価: Apache JMeter による負荷テスト

それではここで、すべてをまとめて 1 つのスクリプトにしてみましょう。興味深いグラフを表示して、グラフが期待通りの内容を報告することを検証するには、データベースに負荷をかける必要があります。それには Apache の JMeter が使用できます。もちろん IBM の Rational Performance Tester であれば高度な機能を提供してくれますが、この記事に記載したすべてのグラフでは「テスト・ハーネス」としても知られる負荷生成プログラムとして JMeter を使用しています。

テスト・ハーネスを作成してデータベースの負荷テストを行います。パフォーマンス監視、あるいはグラフ作成を行わない場合でも、負荷テストは行ってください。読者がこの記事から採用するのが唯一、アプリケーションを実動に移す前に負荷テストを行うことだけだったとしても、記事を書いた甲斐があります。

サーバーが壊れるところまで負荷テストを行うと、システムのパフォーマンス・エンベロープがわかります。アプリケーションについて、ユーザー数、クエリーまたはトランザクションの複雑度、そしてその他の特徴が明確になるはずです。サーバー作業負荷の増加傾向を追跡するとともにパフォーマンス・エンベロープ・グラフを備えることにより、重大な危機に遭遇する前にサーバーをアップグレードするという戦いに勝利を収めることができます。

リスト 11 のスクリプトは、パフォーマンス監視のすべての要素と負荷テスト環境を起動します。入力ミスと「勘違い」を極力少なくするため、複雑な起動シーケンスにはシェル・スクリプトを使用することを是非お勧めします。

多くの人々にとってはショックかもしれませんが、このスクリプトには各ステップを説明するコメントを入れてあります。

リスト 11. 自動負荷テストによる仕上げ
# (c)copyright 2006 Martin Lurie   Sample code, not supported
echo must run as root... so we can restart the httpd and informix 
# read foo just makes the script pause till you hit enter
# todo: automate a user id check instead of this prompt
read foo
#  everyone tails the server log on the screen, right ?
xterm -exec tail -f /opt/informix/online.log &
. /opt/informix/iunset
# pick up the ids v10 env
 . /opt/informix/ifx_env 
# stop the server in case it is active
 su informix -c "onmode -yuk"
# start the server
 su informix -c oninit
# now pick up the csdk 2.8x environment - better yet - get 
# the bug fixed version of the 2.9 csdk
. /opt/informix/iunset
 . /home/informix/ifx_env 
 /etc/init.d/httpd restart
# must install php graph libraries 
cd /var/www/html/
xterm -exec watch -d -n4 "php ./qcgraph.php > foo.jpg" &
mozilla http://karmiel/index.html&
 cd /home/lurie/edrive/src/esql/oltpqc
 xterm &
 xterm -exec watch -d -n 5 ./oltpqc 1500 &
cd /home/lurie/tmp/jakarta-jmeter-2.2/bin/
./gojm &

図 5 は JDBC 要求を処理中の JMeter です。このグラフでは、平均応答時間が 573 ミリ秒であることが示されています。この応答時間で満足なユーザーもいるでしょうが、796 ミリ秒という標準偏差には平均応答時間ほどには満足いかないかもしれません。良い知らせは、赤い線が示す標準偏差が下降傾向にあるということです。応答時間の変動が減少しつつあるので、ユーザーが Enter キーを押したときの応答のばらつきが少なくなります。黒い点線が示す作業負荷の平均をよく見てみると、このサーバーは起動時の過渡状態であることがわかります。JMeter の接続プールが確立されれば、サーバーの作業負荷に対する応答性はより安定したものになります。

図 5. JMeter の負荷生成とグラフによる結果ページ
JMeter の負荷生成とグラフによる結果ページ

トラブルシューティングの例

図 6 に、断続的に長くなる接続時間を示します。ほとんどの DBA は、チェックポイントに時間がかかっていると思い込みますが、意外なことに、online.log ではすべてのチェックポイントは 0 秒となっています。では、何が問題なのでしょう。

図 6. 断続的に長くなる応答時間の問題
断続的に長くなる応答時間の問題

ここでの問題は、データベースとは無関係であることが判明しました。システムが約 8 秒間から 10 秒間「停止」したように見えて、その後しばらくは正常に動作する場合は常に、DNS ネットワークの問題が最も可能性の高い原因の 1 つとして挙げられます。この断続的な接続時間の増加は、一時的な DNS の問題を修正することによって解消されました (この場合の修正は、ラップトップ・コンピューターを LAN に再接続して DNS サーバーにアクセスできるようにするのと同じくらい単純です)。


次に進むステップ

これまで、データベース監視を行うための技術を説明してきました。これらの手法には、標準 API (ODBC) を使用したコード移植性、そして JpGraph による Web 公開を対象とした結果のグラフ作成があります。テスト・ハーネスによる環境のパフォーマンス評価は、サーバーに操られるのではなく、自分でサーバーを管理する上で非常に重要です。

常に付きまとうのは、作成するか、購入するかの選択です。この記事に記載したリアルタイム監視機能を作成するのは気後れするという場合は、IBM Tivoli® Monitorを調べてみてください。事前定義された多数のエージェントと、個別の問題を掘り下げられるコンソールが備わっています。図 7 は、Tivoli Monitoring の一例です。

図 7. Tivoli Monitoring (作成するより購入するほうを選ぶ場合)
Tivoli Monitoring (作成するより購入するほうを選ぶ場合)

多数の拡張機能があるので、サンプル・コードを実装する際には役立つはずです。ネットワークまたはデータベースが停止しても、oltpqc クライアントが引き続き応答を待機します。待機時間を制限して、エラーの戻りコードでアラートを送信する機能を追加するのも非常に有益です。

サーバーやネットワークの問題が見つかった場合は、問題を診断して根本的原因を突き止めるために使用できる多彩なツールがあります。オペレーティング・システム・レベルで、sar、vmstat、そして top といったコマンドを使用して、まずは基本的なシステムの正常性を検証するところから始めるのが有効です。パフォーマンスを台無しにする過剰な CPU 使用率とメモリー・ページングまたはスワッピングを探してください。また、ping、netstat、nmap、および ethereal ユーティリティーは、ネットワーク問題を把握するための豊富な機能を提供します。

オペレーティング・システムが良好であれば、Informix onstat および DB2 snapshot ユーティリティーを使用してデータベース固有の診断情報を調べることができます。インターネットには、これらのユーティリティーに関する多くの説明と例があります。google による単純な照会で豊富な資料が見つかるはずです。

この記事があなたの役に立って、より正確に問題を切り分けられるようになることを期待します。データベースを非難して時間を無駄にする意味はありません。リアルタイムのデータベース・ステータス報告機能を利用すれば、本当の問題を判別できます。


ダウンロード

内容ファイル名サイズ
Source code for monitoroltpqc.zip10KB

参考文献

学ぶために

製品や技術を入手するために

  • IBM 製品の評価版をダウンロードして、DB2®、Informix、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。
  • 次期開発プロジェクトの構築に、developerWorks から直接ダウンロードできるIBM の試用版ソフトウェアをご利用ください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management, Open source
ArticleID=273197
ArticleTitle=DB2/Informix とオープン・ソース: 腹黒い政治的策略に対するデータベースの防御
publish-date=12212006