| 1 つ以上の DB2 EEE パーティション サーバーの開始に失敗する | db2nodes.cfg ファイルのポート番号が /etc/services ファイルで設定されている範囲を超えている可能性があります。 db2nodes.cfg ファイルで設定されているポート番号を調べて、 /etc/services のポート番号の範囲におさまっているか確認します。 |
| LifeKeeperの “In- Service” または “Out-of- Service” 操作でハングする | DB2 の環境変数 DB2_NUM_FAILOVER_NODES が適切に設定されていない可能性があります。設定内のすべてのサーバについて、この環境変数を、インスタンス内のパーティション総数と同じ値に設定します。 例： db2set DB2_NUM_FAILOVER_NODES =<インスタンス内のパーティション数> |
| LifeKeeperの “In- Service” 操作がハングする | DB2 管理サーバーで dasupdt コマンドが実行されていない可能性があります。 DB2 管理サーバーで dasupdt コマンドが正常に実行されたことを確認します。 |
| LifeKeeper の最初のスイッチオーバー操作が失敗する | DB2 Fenced ユーザーがバックアップ サーバー上に作成されていない可能性があります。 指定されたインスタンスの DB2 Fenced User が、プライマリーと同じユーザーおよびグループ ID で存在することを確認してください。 保護されたインスタンスが管理サーバーグループのメンバーでもあることを確認します。 |
| 既存の DB2 リソース階層に新しいノードを追加する必要がある | 既存の LifeKeeper DB2 リソース階層に新しいノードを追加する方法の詳細については、ノードユーティリティのマニュアルページを参照してください。 |
| 管理サーバーが起動しない | 別の管理サーバーが、指定されたポートで既に実行されていないか確認します。 |
| DB2 リソース階層の作成に時間がかかる | 大規模な DB を持つ DB2 インスタンスを保護するには、リソースの作成に時間がかかる場合があります。 リソースを作成する前にアクティブ化してください。 データベースを起動するコマンド: db2 activate db <db_name>. 以下の考慮事項を参照してください。 |
| スイッチオーバー後に DB2 データベースがアクティブにならない | DB2 Kit は、フェイルオーバー後にデータベースの暗黙的なアクティブ化を使用します。 これはパフォーマンス上の理由から、フェイルオーバーのスイッチオーバー中にキットが各データベースを明示的にアクティブ化しないことを意味します。 代わりに、データベースへの最初の接続でそのデータベースがアクティブ化されます。 |
考慮事項
注記: このキットはもともと implicit activation 用に設計されました。 これは、データベースへの最初の接続がそのデータベースをアクティブにすることを意味します。 スイッチオーバーまたはフェールオーバーの一部として explicit activation が必要な場合は、必要に応じてデータベースをアクティブ化するための Generic Application リソースを作成できます。 リソースを作成する前に明示的なアクティブ化を使用すると、DB2 リソースおよび関連するファイル システムの依存関係を作成するのに必要な時間が短縮されることが示されています。
データベースを暗黙的(implicitly)にアクティブ化するコマンドは次のとおりです。
- db2 “connect to <dbname>”.
Generic Application リソース内でデータベースを検索/アクティブ化するには、次のコマンドを使用してください。
- su – db2user -c ‘db2 activate db ${dbname}’
この情報は、IBM サポート ページから取得したものです。 db2 の使用法について詳しくは、IBM サポートを参照してください。
エラーメッセージ
DB2 Kit の使用中に発生する可能性のあるすべてのメッセージのリストについては、DB2 Recovery Kit メッセージカタログ を参照してください。
このトピックへフィードバック