データ・ストアのライフサイクル
メッセージング・エンジンの開始または削除は、 データ・ストアのライフサイクルに 影響します。データ・ストアに対しては適切なアクションを実行する必要があります。
メッセージング・エンジンの開始
開始時に、メッセージング・エンジンは、 データ・ストアを構成する テーブルの検査を行い、それらが適切であるかどうかを判断します。テーブルが存在せず 、メッセージング・エンジンの構成時に「テーブルの作成」オプションを選択した場合 、メッセージング・エンジンはテーブルを作成しようとします。 このオプションを選択していない場合は、データベース管理者は、sibDDLGenerator コマンドで 生成されるデータ定義言語 (DDL) ステートメントを使用して、事前にテーブルを作成しておく必要があります。
- メッセージング・エンジンがスタンドアロン・アプリケーション・サーバーによってホスティングされている場合は、 メッセージング・エンジンは停止状態に入ることがあります。その場合は、 アプリケーション・サーバーを再始動してメッセージング・エンジンを開始する必要があります。
- メッセージング・エンジンがクラスター・メンバーによってホスティングされている場合、 そのクラスター・メンバーでは高可用性が使用できなくなります。HA マネージャーは、 適格な別のサーバー上のメッセージング・エンジンを開始しようとします。 データベースが引き続き使用できない場合、メッセージング・エンジンは再開できないため、 そのサーバーでは高可用性が使用できなくなり、HA マネージャーは、 適格な別のサーバー上のメッセージング・エンジンを開始しようとします。 このようにして、クラスターのすべてのメンバーで高可用性が使用不可になる場合があります。 その場合は、サーバーを再始動するか、管理コンソールを使用して、 サーバーの高可用性を手動で再度使用可能にする必要があります。 詳しくは、メッセージング・エンジンが始動できないときの高可用性の管理を参照してください。
データベースの停止
データ・ストアが含まれるデータベースを停止する場合は、 まずメッセージング・エンジンが停止済みであることを確認します。 メッセージング・エンジンが稼働していて、データ・ストアに対する排他ロックを備えている場合は、 データベースを停止すると、メッセージング・エンジンが不整合状態になることがあります。メッセージング・エンジンが稼働を続けて作業を受け入れるためです。 メッセージング・エンジンの稼働中にデータベースに障害が発生した場合にも、同じ振る舞いが見られます。
メッセージング・エンジンとそのホスティング・サーバーは、 データベース接続が切断された場合にはシャットダウン後に再始動して、そのような不整合を防ぐように構成することができます。 この振る舞いを構成するには、メッセージング・エンジン上で、sib.msgstore.jdbcFailoverOnDBConnectionLoss カスタム・プロパティーを設定します。 また、システムを調整して、データベースが使用可能になる前にメッセージング・エンジンの開始に失敗する可能性を少なくすることもできます。
メッセージング・エンジンの除去
メッセージング・エンジンを除去しても、 WebSphere® Application Server (基本) が自動的にデータ・ストア・テーブルを削除するわけではありません。同じメッセージング・エンジンを再作成したい場合は、 まず以前のテーブルのセットを削除します。既存のテーブルを使用してメッセージング・エンジンを作成する場合、メッセージング・エンジンが正しく作動するには、そのテーブルは空でなければなりません。 テーブルの削除方法については、 選択したリレーショナル・データベース管理システム (RDBMS) の資料を参照してください。ただし、デフォルト設定値を使用してデータ・ストアを作成した場合、前のテーブルを削除する必要はありません。