エラー処理

エラーのチェック

アプリケーションでは、コールのたびにエラーおよび警告をチェックする必要があります。これによって、開発およびデバッグ時に時間および労力が大幅に節約されます。TimesTenに付属のサンプル・アプリケーションには、エラー・チェックの例が含まれています。

「TimesTenクイック・スタートおよびサンプル・アプリケーションについて」を参照してください。

エラーは、installation_dir/include/tt_errCode.hファイルで定義されているTimesTenエラー・コード(エラー番号)またはエラー文字列のどちらかを使用してチェックできます。エントリの書式は次のとおりです。

#define tt_ErrMemoryLock             712

『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のエラーおよび警告のリストを参照してください。

ODBC関数をコールした後、リターン・コードを確認します。リターン・コードがSQL_SUCCESSでない場合は、ODBC関数SQLErrorをコールするエラー処理ルーチンを使用して、関連するODBCハンドルのエラーを取得します。1回のODBCコールで、複数のエラーが返される場合もあります。アプリケーションは、すべてのエラーがエラー・スタックから読み取られるまでSQLError関数を繰り返しコールしてすべてのエラーを返すように記述されている必要があります。リターン・コードがSQL_NO_DATA_FOUNDになるまで、SQLErrorをコールし続けます。(SQL_NO_DATA_FOUNDは、sqlext.h (timesten.hに含まれています)に定義されています。)

次の例では、SQLAllocConnectをコールした後にエラー状態を確認できることが示されています。エラーが見つかった場合、エラー・メッセージが表示され、プログラムの実行は終了します。

rc = SQLAllocConnect(henv, &hdbc);

if (rc != SQL_SUCCESS) {
  handleError(rc, henv, hdbc, hstmt, err_buf, &native_error);
  fprintf(stderr,
          "Unable to allocate a connection handle:\n%s\n",
          err_buf);
  exit(-1);
}

SQLError関数およびその引数の詳細は、ODBC APIのリファレンス・マニュアルを参照してください。

『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のエラーおよび警告の取得を参照してください。

エラーおよび警告のレベル

操作が完全には成功していない場合に、TimesTenによって返される可能性があるエラーのタイプがいくつかあります。

ノート:

プロセス障害などの異常終了の場合、エラーは返されませんが、TimesTenによって、障害が発生したプロセスのトランザクションが自動的にロール・バックされます。

致命的なエラー

致命的なエラーとは、エラー・リカバリが終わるまでデータベースにアクセスできなくなるエラーのことです。

致命的なエラーが発生すると、すべてのデータベースの接続を切断する必要があります。それ以後の処理は完了されません。致命的なエラーは、TimesTenのエラー・コード846および994で示されます。これらのエラーの処理は、標準的なエラーの処理とは異なります。特に、アプリケーションのエラー処理コードは、現行のトランザクションをロールバックし、データベースから切断する必要があります。

「致命的なエラーからのリカバリ」も参照してください。

致命的ではないエラー

致命的ではないエラーとしては、一意制約に違反しているINSERT文などのエラーがあります。また、一部のアプリケーション障害およびプロセス障害も、致命的ではないエラーに含まれます。

TimesTenは、標準のエラー処理プロセスを介して、致命的ではないエラーを返します。アプリケーションは、エラーがないか確認し、これらを適切に処理する必要があります。

致命的ではないエラーによってデータベースに影響が出た場合、エラーが返されることがあり、アプリケーションで適切に対処する必要があります。

アプリケーションでは、その処理を変更するか、または障害が発生した1つ以上のトランザクションをロールバックすることによって、致命的ではないエラーに対処できます。

警告

予期しない状態が発生した場合、TimesTenは警告を返します。

次のイベントが発生した場合、TimesTenは警告を発行します。

チェックポイントの障害
非推奨の機能の使用
一部のデータの切捨て
接続時のリカバリ処理の実行
レプリケーションがRETURN RECEIPTの場合のタイムアウト

アプリケーション開発者は、アプリケーションの問題を指摘することができるように、警告をチェックするコードを含める必要があります。

致命的なエラーからのリカバリ

致命的なエラーが発生した場合は、TimesTenによって、完全なクリーン・アップおよびリカバリの手順が実行されます。

データベースに対するすべての接続を無効化します。サーバーでのメモリー不足状態を回避するには、無効になったデータベースからアプリケーションを切断する必要があります。古いTimesTenインスタンスの共有メモリーは、エラー発生時にアクティブだったすべての接続が切断されるまで解放されません。古いTimesTenインスタンスに依然として接続されている非アクティブなアプリケーションは、手動で終了する必要があることがあります。
その後の最初の初期接続時に、チェックポイント・ファイルおよびトランザクション・ログ・ファイルからデータベースをリカバリします。
リカバリされたデータベースには、永続コミットされたすべてのトランザクションの状態が反映されます。また、非永続的にコミットされた一部のトランザクションも反映されます。
コミットされていないトランザクションまたはロールバックされたトランザクションは反映されません。

一時的なエラー(ODBC)

TimesTenではほとんどの一時的エラーは自動的に解決されますが(これはTimesTen Scaleoutにおいてとりわけ重要です)、アプリケーションで次のSQLSTATE値が検出された場合は、現在のトランザクションを再試行することをお薦めします。

TT005: Transient transaction failure due to unavailability of resource.Roll back the transaction and try it again.

ノート:

再試行が適しているかどうかを判断する前に、エラー・スタック全体を検索して、これらのSQLの状態を返すエラーがないか確認してください。
「フェイルオーバーの遅延および再試行の設定の実装」内の例では、一時的なエラーの場合の再試行方法も示しています。

ODBC 3.5では、SQLSTATEはSQLGetDiagRec関数によって返されるか、SQLGetDiagField関数のSQL_DIAG_SQLSTATEフィールドに示されます。ODBC 2.5では、SQLSTATEはSQLError関数によって返されます。このSQLSTATEは、次のいずれかの関数で発生する可能性があります。特に指定しないかぎり、これらの関数はODBC 2.5またはODBC 3.5に適用されます。

カタログ関数(SQLTablesやSQLColumnsなど)
SQLCancel
SQLCloseCursor (ODBC 3.5)
SQLDisconnect
SQLExecDirect
SQLExecute
SQLFetch
SQLFetchScroll (ODBC 3.5)
SQLFreeStmt (ODBC 2.5)
SQLGetData
SQLGetInfo
SQLPrepare
SQLPutData
SQLEndTran (ODBC 3.5)
SQLTransact (ODBC 2.5)