- ログ・ファイル分析
- netstat
- ps
- kill
- svrmgrl または sqlplus
- telnet
- jar
- tar
- gunzip
- Web サーバーおよびアプリケーション・サーバーへのスーパー・ユーザー・アクセスは、しばしば不可欠なものになります。
環境に関する問題
アプリケーション・サーバー上の WebSphere Product Center の擬似ユーザーは、WebSphere Product Center を始動する前に、以下の環境変数を構成していなければなりません。
- TOP: WebSphere Product Center インストールの上位ディレクトリー
- DB2_HOME: DB2 クライアント・バイナリーに必要
- JAVA_HOME: JDK に必要
- PATH: $DB2_HOME/bin および $JAVA_HOME/bin が含まれている必要がある
さらに、WebSphere Product Center を始動する前に、シェル・スクリプト init_ccd_vars.sh をソース化する必要があります。これは通常、ユーザーの .bashrc ファイル内で行われます。
CLASSPATH 環境変数は、init_ccd_vars.sh がソース化された後に変更しないでください。
構成ファイル設定の一般的な誤り
- common.properties
最も一般的なエラーは、common.properties 内のデータベース指定子が誤っているというものです。誤って構成されたデータベースには、以下の徴候があります。
appsvr、eventprocessor、queuemanager、scheduler、および workflowengine が始動しない
ログ・ファイル logs/db_pool および logs/svc/ 内のエラー
smtp_address。Smtp_address は、localhost 上の sendmail である SMTP リレー、あるいは組織外から E メールを送信できる別のシステムのいずれかを指している必要があります。
- ライセンス・ファイル
ライセンス・ファイル (WPC_license.xml) が欠落していたり誤っている場合、サービスは開始しません。このエラーは、logs/svc の下のログ・ファイルに反映されます。
アプリケーション・サーバーが応答しない
シナリオ
アプリケーション・サーバーの反応が極端に低下します。サーバーを ping することは可能ですが、ユーザーは環境にログインできず、管理者もアプリケーション・サーバーにログインできなくなります。
以下の点を点検します。
ユーザーが最近非常に大きなジョブを起動したかどうかを調べます。そのジョブが意図したものであった場合、ジョブによって使用されたスクリプトをチェックします。
1. データのエクスポート / インポート時の文字変換
2. データベースのスペース割り振りに関する問題
3. データ・ブロックの破損および索引の破損に関する問題
4. 長い時間ステータス・バーに変更を加えないとインポートまたはエクスポートがハングする
5. 実行中のジョブを kill した後にアプリケーションがとても遅くなる
6. ログの切り替えの再実行に関する問題
7. WebSphere Product Center ミドルウェアが停止し、GUI がフリーズする
8. スキーマ・ジョブの停止を分析する
9. SQL 接続が自動的に再始動する
1. データのエクスポート / インポート時の文字変換
問題
データベースのエクスポート / インポート時に、データベースのコピーを使用してテスト環境を作成すると、使用した文字セットに関するエラー・メッセージが表示されます。
症状
たとえば、文字セット US7ASCII を使用するデータベースをエクスポートすると、以下のエラー・メッセージがエクスポート・ログに表示されます。
US7ASCII 文字セットおよび UTF8 NCHAR 文字セットでエクスポートが完了しました。サーバーは UTF8 文字セット (可能な文字セット変換) を使用します。(Export done in US7ASCII character set and UTF8 NCHAR character set server uses UTF8 character set (possible charset conversion))
解決方法
データベースのエクスポート / インポートの際には常に、NLS_LANG パラメーターを設定して、文字セット american_america.utf8 を使用します。
2. データベースのスペース割り振りに関する問題
問題
時折、テーブル、索引、ロールバック・セグメントおよび一時セグメントに割り振られたスペースが不十分であるため、ジョブのインポートおよびエクスポートに失敗します。
症状
ロールバック・セグメントがいっぱいになるか、ロールバック・セグメントのテーブル・スペースがいっぱいになると、アラート・ログ・ファイルに以下のようなエラー・メッセージが表示されます。
ORA-1650: テーブル・スペース RBS 内でロールバック・セグメント RBS8 を 512 だけ拡張することができません。(unable to extend rollback segment RBS8 by 512 in tablespace RBS)
設定されているロールバック・セグメント 9 が状態 1650 の FULL 状況のためにロールバック・セグメントの拡張に失敗しました。
解決方法
- テーブル・スペース内に十分な空きスペースがあることを確認してください。より大きいジョブでは、ロールバック・セグメントおよび一時セグメントに、より多くのスペースが必要になる場合があります。
- データベース内のスペースの問題に関連してエラーが生成されたかどうかを調べるために、データベースのアラート・ログ・ファイルを毎日チェックします。
3. 実行中のジョブを kill すると WebSphere Product Center の動作が遅くなる
問題
ジョブを kill する場合は常に、インポートまたはエクスポートのように、データベース・システムは完全なトランザクションをロールバックして、データベースを整合性のある状態にする必要があります。このロールバック処理は、CPU 時間およびメモリーなどのシステム・リソースを最大限使用します。
症状
実行中のジョブを kill すると WebSphere Product Center ミドルウェアの動作が遅くなります。
解決方法
ロールバックが完了するまで待機すると、システムは通常の状態に戻ります。必要でないかぎり、実行中のジョブを kill しないでください。
4. ログの切り替えの再実行に関する問題
問題
ログ・ファイルの数またはサイズが不適切であるため、データベース・システムがログの切り替えの際に長い時間待機する可能性があります。
症状
すべての再実行ログ・ファイルがアクティブである場合、データベース・システムは、ログの切り替えの際に非常に長い時間待機中になります。
解決方法
- ログ・ファイルの数を増やします。
- 再実行ログ・ファイルのサイズを増やします。
5. WebSphere Product Center ミドルウェアが停止し、GUI がフリーズする
問題
WebSphere Product Center ミドルウェアへのアクセス中にエラーが現れると、データベースへの接続が失われることがあります。
症状
WebSphere Product Center ミドルウェアがフリーズするか、常に待機状態になります。WebSphere Product Center ミドルウェアにアクセスしようとするとエラーが現れます。
解決方法
- リスナー・プロセスの状況をチェックします。
- データベースまたは WebSphere Product Center ミドルウェア画面への接続を確立できない場合は常に、データベースの状況をチェックします。
6. スキーマ・ジョブの停止を分析する
問題
大量のデータをデータベースにロードしたり、データベース内のテーブルをパージする場合に、時々スキーマを分析することをお勧めします。
分析スキーマを実行する前に WebSphere Product Center ミドルウェアを停止する必要があります。ミドルウェアを停止しないと、テーブルがミドルウェアによって使用されているため、分析スキーマのジョブがハングしてしまう場合があります。
症状
分析スキーマを実行すると WebSphere Product Center がハングします。
解決方法
分析スキーマがハングする場合、分析ジョブを kill し、WebSphere Product Center ミドルウェアを停止して、スキーマを再度分析してから WebSphere Product Center を始動します。
定期的な間隔でスキーマを分析し、データベース内のデータ分布に関する最新の統計を収集します。
システム・ログ・ファイルをモニターして検討することは、多くの問題を診断して解決するのに役立ちます。
注: この章は次バージョンの資料で拡張される予定です。 ログ・ファイルの使用およびトラブルシューティングの技法についての詳細な情報が提供されます。
HTTP ポスト・エラー
HTTP ポスト・エラーが発生した場合、以下の点を考慮してください。
1. WebSphere Product Center ボックスにターゲット宛先を表示することができるか?
- "Lynx" などの Linux / Unix HTTP ブラウザーを使用し、WebSphere Product Center ミドルウェアの URL を入力して、ターゲットにアクセス可能かどうかを調べます。
- ブラウザーが WebSphere Product Center サーバーから使用できない場合、宛先のポート 80 に Telnet を試みます。たとえば、宛先 URL が http://myserver/>urlname< の場合、"telnet myserver 80" と入力します (ポート 80 は、ほとんどの Web サーバーのデフォルトの HTTP ポートです)。
2. WebSphere Product Center に宛先を表示できる場合、WebSphere Product Center Distributor は正常に作動しているか?
- $TOP/public_html/created_files/distributor の下の新規ファイルが存在するかどうかチェックします。ファイルをプッシュした時刻に関するおおよそのタイム・スタンプがファイルに含まれているかどうかを調べます。
- runaway スクリプトが正しくない出力ファイルを生成した可能性があります。ファイル・サイズをチェックします。ファイル・サイズは予期したものに対応していますか? ファイルが XML であるかその他の読み取り可能なファイルである場合、そのファイルを表示してみます。そのファイルには、予期していた正しい情報が含まれていますか?
3. ファイルが存在する場合、転送が進行しているか?
- さまざまなツールを使用して、実際の転送が進行中であるかどうかを調べることができます。最低限のこととして、"netstat" および "snoop" (Solaris の場合) あるいは "tcpdump" (Linux の場合) の組み合わせを使用する必要があります。
- 期待が現実的であるかどうかを考慮します。ファイル・サイズが 300 MB であり、それがインターネットを介して URL にポストされている場合、そのファイルはインターネット接続の最高速度でのみ転送することができます。
FTP フェッチ・エラー
WebSphere Product Center がターゲット FTP サーバーにログインしようとして、 指定したディレクトリーの検索に失敗すると、 「リモート・ディレクトリーに変更することができません。(Unable to change to remote directory.)」 というエラーが発生します。
このエラーには以下の 2 つの理由があります。
- ターゲット FTP アドレスが WebSphere Product Center サーバーからアクセスできない。WebSphere Product Center サーバーから、FTP でファイルをターゲット FTP に直接転送して、ファイル転送が正常に行われるかどうかを検証してください。
- 使用されているファイル名が正しくない可能性がある。大文字になっていないかどうか、またスペルの間違いがないかどうかをチェックしてください。
Java 接続のテスト
JDBC URL はファイル common.properties で定義されます。WebSphere Product Center ミドルウェアから JDBC URL への Java 接続をテストするには、以下のスクリプトを使用します。
$TOP/bin/test_java_db.sh
スクリプトはデータベースに接続を試み、簡単な 'select count(*) from dual' を実行します。接続が確立されると、テスト・スクリプトからの結果が表示されます。
WebSphere Product Center の停止および再始動
Linux / Solaris で通常の停止スクリプトを使用した際の問題が報告されています。WebSphere Product Center が正常またはスムーズに停止しないようです。このような場合には、以下のステップを使用して WebSphere Product Center を停止して始動します。
1. 以下のスクリプトを実行して WebSphere Product Center を停止します。
$TOP/bin/go/stop_local.sh
2. 約 1 分待機してから、以下のコマンドを入力します。
ps –u (括弧なしでユーザー名を指定)
3. アクティブな Java プロセスがある場合、スケジュールされたジョブが進行中である可能性があります。必要であれば、ジョブを完了してください。そうでない場合は以下のスクリプトを使用してジョブを手動で停止してください。
$TOP/bin/go/abort_local.sh
4. 約 30 秒待機してから、以下のコマンドを入力します。
ps –u (括弧なしでユーザー名を指定)
5. 依然としてアクティブな Java プロセスが存在する場合、JVM は破損していると思われます。以下のコマンドを使用して、Java プロセスを手動で kill する必要があります。
kill `ps -u (括弧なしでユーザー名を指定)
| grep java | cut -b10-15`注: java のプロセスが何かまだ残っている場合には、 システムを再始動する必要がある場合があります。
6. Java プロセスをすべて kill したら、以下のスクリプトを使用して WebSphere Product Center を再始動します。
$TOP/bin/go/start_local.sh
7. 約 1 分待機して、WebSphere Product Center が正常に始動したかどうかを検証します。スクリプト $TOP/bin/go/rmi_status.sh を実行するか、WebSphere Product Center 環境にログインします。