一時エラーからのリカバリ
グリッドは複数のホストにまたがるため、複数のタイプの障害が発生する可能性があり、その多くは一時エラーである可能性があります。ほとんどの場合、TimesTen Scaleoutによって一時エラーを検出し、迅速に対応できます。
グリッドのエラーのほとんどは、エラー・コードにTransientと示される一時エラーで、これは特定のAPI、SQL文またはトランザクションの失敗の原因となる可能性があります。ほとんどの場合、アプリケーションはまったく同じ操作を正常に再試行できます。
一時エラーにより生じる可能性がある影響は、次のとおりです。
-
特定の文の実行が失敗します。アプリケーションがその文を再実行する必要があります。
-
特定のトランザクションの実行に失敗します。アプリケーションがトランザクションをロールバックし、トランザクションの操作を再度実行する必要があります。
-
データ・インスタンスへの接続に失敗します。クライアント/サーバー接続を使用している場合は、TimesTen Scaleoutによって、別のアクティブ・データ・インスタンスに接続が転送されます。「クライアント接続のフェイルオーバー」を参照してください。
次の各項では、TimesTen Scaleoutによる、より一般的な一時エラーからの要素のリカバリ方法について説明しています。
一時エラーの再試行
TimesTen Scaleoutは、ほとんどの一時エラーの原因を自動処理しますが、アプリケーションはトランザクション全体を再試行できます。
具体的には、表13-1に示すエラーのいずれかを受信すると、アプリケーションでトランザクション全体を再試行できます。
表13-1 一時エラーの後に再試行するSQLSTATEおよびORAエラー
| SQLSTATE | ORAエラー | PL/SQLの例外 | エラー・メッセージ |
|---|---|---|---|
|
|
|
例外 |
Transient transaction failure due to unavailability of a grid resource.Roll back the transaction and then retry the transaction. |
アプリケーションでは、次のように一時エラーをチェックできます。
-
ODBCまたはJDBCアプリケーションでは、
SQLSTATE TT005エラーがないかを確認して、アプリケーションがトランザクションを再試行する必要があるかどうかを決定します。『Oracle TimesTen In-Memory Database C開発者ガイド』の一時エラー(ODBC)および『Oracle TimesTen In-Memory Database Java開発者ガイド』の一時エラー後の再試行(JDBC)を参照してください。 -
OCIおよびPro*Cアプリケーションでは、
ORA-57005エラーがないかを確認して、アプリケーションがSQL文またはトランザクションを再試行する必要があるかどうかを決定します。『Oracle TimesTen In-Memory Database C開発者ガイド』の一時エラー(OCI)を参照してください。 -
PL/SQLアプリケーションでは、
-57005PL/SQL例外がないかを確認して、アプリケーションがトランザクションを再試行する必要があるかどうかを決定します。『Oracle TimesTen In-Memory Database PL/SQL開発者ガイド』の一時エラー後の再試行(PL/SQL)を参照してください。
通信エラー
データ・インスタンス間、またはデータ・インスタンスとZooKeeperメンバーシップ・サーバー間で、要素間の通信が失敗することがあります。
次に、障害が発生する可能性のある通信のタイプについて説明します。
-
要素間の通信: 必要に応じて、要素間のトランザクションおよびストリーム・データ内でSQL文を実行するために使用されます。アプリケーションがトランザクションを実行中に通信エラーが発生した場合は、トランザクションをロールバックする必要があります。トランザクションを再試行すると、通信が再作成され、作業が続行されます。
-
データ・インスタンスの間の通信: 通信の作成およびリカバリ・メッセージの送受信のために、データ・インスタンスは相互に通信します。データ・インスタンス間の通信が遮断された場合、操作を再試行すると、通信が自動的にリカバリされます。
-
データ・インスタンスおよびZooKeeperメンバーシップ・サーバー間の通信: 各データ・インスタンスが、定義されたZooKeeperサーバーのいずれかを使用して、ZooKeeperメンバーシップ・サービスと通信します。データ・インスタンスと通信相手のZooKeeperサーバーとの間の通信に障害が発生した場合、データ・インスタンスは別のZooKeeperサーバーとの接続を試みます。データ・インスタンスがどのZooKeeperサーバーにも接続できない場合、データ・インスタンスはそれ自体を停止しているとみなします。
データ・インスタンスが停止している場合の対処方法の詳細は、「データ・インスタンスが停止している場合のリカバリ」を参照してください。
ソフトウェア・エラー
ソフトウェア・エラーが原因で要素がアンロードされた場合、アクティブなアプリケーションに対してエラーが返されます。トランザクションのロールバック後、各レプリカ・セットで要素が1つオープンしているかぎり、アプリケーションはトランザクションの実行を継続できます。
TimesTen Scaleoutは、要素の再ロードを試行します。オープンした要素は、再度トランザクションを受け入れられるようになります。
ノート:
ttGridAdmin dbloadコマンドを使用してデータベースを再ロードすることで、要素の再ロードを手動で開始できます。要素ステータスがload failedの場合は、要素のロードが失敗した原因を修正してから、ttGridAdmin dbloadコマンドを使用して要素を再ロードしてください。『Oracle TimesTen In-Memory Databaseリファレンス』のメモリーへのデータベースのロード(dbLoad)を参照してください。
ホストまたはデータ・インスタンスの障害
データ・インスタンスを含むホストがクラッシュした場合またはデータ・インスタンスがクラッシュした場合は、アクティブなアプリケーションに対してエラーが返されます。
データ・インスタンスが停止しているため、要素ステータスにはdownと表示されます。データ・インスタンスが再起動すると(自動リカバリまたは手動操作のいずれの場合も)、データ・インスタンス内の要素はほとんどの場合、リカバリされます。ttGridAdmin dbStatusコマンドを使用して要素のステータスをモニターし、要素がリカバリされたかどうかを確認します。
ノート:
「要素ステータスに基づくトラブルシューティング」および「データ・インスタンスが停止している場合のリカバリ」を参照してください。