ヘッダーをスキップ
Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド
リリース6.0
B25774-01
  目次へ
目次
索引へ
索引

前へ
前へ
次へ
次へ
 

破損したデータ・ストアまたは無効なデータ・ストアを処理する

この項では、データ・ストアが無効であるか、破壊されたことを示すエラーを受け取った場合の対処方法について説明します。

データ・ストアが破損している可能性があることをTimesTenデーモンが検出すると、そのデータ・ストアは無効としてマークされます。共有データ・ストアに接続中のアプリケーションが複数存在し、アプリケーションの1つが予期せず接続を切断すると、データ・ストアは残りのアプリケーションに対して無効になる可能性があります。たとえば、アプリケーションがODBCコール中で、そのODBCコールがなんらかの内部データ・ストアのデータ構造の更新中である場合、そのアプリケーションが予期せず終了することで、データ・ストアに接続している他のアプリケーションに悪影響を与える可能性があります。プロセスが予期せず終了したことがわかった時点で、TimesTenデーモンは、まずそのプロセスが終了時に実行していた処理を確認します。特に、プロセスがデータ・ストアとの接続を予期せず切断したことで、データ構造が破損した状態のままであるかどうかを判断しようとします。内部データ構造の整合性に問題がある場合、データ・ストアは無効としてマークされ、残ったすべてのプロセスは、次にODBCコールを実行したときに、データ・ストアが無効であることを示すエラーを受け取ります。

TimesTen Data Managerの動作については、『Process Recovery in the TimesTen Data Manager』というホワイト・ペーパーを参照してください。このドキュメントでは、アプリケーションでシグナル・ハンドラを実装する必要がある理由と、kill -9でアプリケーションを終了することが許可されていない理由についても説明しています。このドキュメントは、サポート・テクニカル・ライブラリから入手できます。また、『Oracle TimesTen In-Memory Database推奨されたプログラミングの実行』のTimesTenのアーキテクチャとデータ・ストア・リカバリの簡単なチュートリアルに関する項、および予期せぬアプリケーション障害の回避に関する項も参照してください。

この項では、次の処理を行う方法を説明します。

無効なデータ・ストアを検出する

アプリケーションが無効なデータ・ストアに接続されたことを示すTimesTenエラー・コードには、次の2つがあります。

注意: ODBCコールを実行するごとにリターン・コードを確認することが重要です。

また、『Oracle TimesTen In-Memory Database APIおよびSQLリファレンス・ガイド』のSNMPトラップによる診断に関する項で説明するttDSGoingInvalidTrap SNMPトラップによって、無効なデータ・ストアを検出することもできます。

アプリケーションで無効なデータ・ストアを検出した場合、処理を継続する前に、「無効なデータ・ストアをリカバリする」の手順を実行する必要があります。

現在の接続ハンドラに関連付けられたデータ・ストアの無効のステータスは、SQLGetInfoに対する拡張機能であるTimesTen特有のTT_DATA_STORE_INVALID infoタイプを使用して確認できます。

データ・ストアが無効の場合、TimesTenはrgbInfoValueパラメータに値1を返します。有効であれば、値0を返します。

例2.9
#include <timesten.h> 
SQLINTEGER invalid; 
rc = SQLGetInfo(hdbc, TT_DATA_STORE_INVALID, &invalid, 0, NULL); 
if (invalid) 
    /* disconnect */ 
 

通常、TimesTenは、初めて接続不良が検出された場合にエラー・コード994を返します。また、接続不良の状態でさらに操作を試行した場合は、エラー・メッセージ846を返します。これらのTimesTenエラー・コードに関連付けられるSQLの状態は異なる可能性があります。また、データ・ストアが無効な場合でも、別のエラーが返される場合があります。たとえば、AUTO_COMMITが無効な状態でのアプリケーションのトランザクション中にデータ・ストアが無効化された場合、データ・ストアからの切断を試行すると、TimesTenエラー・メッセージ994ではなく、SQLの状態エラー25000が返されます。これは、トランザクションがオープンされた状態での切断は適切でないためです。この場合、リクエストはTimesTenに転送されません。後続のコールでTimesTenエラー・メッセージ846または994が返されます。

無効なデータ・ストアをリカバリする

無効なデータ・ストアに接続しているすべてのプロセスは、データベースの使用を継続する前に、次の手順を実行する必要があります。

  1. データ・ストアの無効化を検出します(「無効なデータ・ストアを検出する」を参照)。
  2. 現在オープンしているトランザクションをロールバックします。
  3. 自動コミット・モードを使用している場合は、すべてのカーソルをクローズします。
  4. データ・ストアとの接続を明示的に切断します。たとえば、ODBCでは、SQLDisconnect()をコールします。
  5. データ・ストアに再接続します。新しいデータ・ストアに接続する最初のプロセスによって、TimesTenサブデーモンが新しい共有メモリー・セグメントを作成します。さらに、最新のチェックポイント・ファイルとデータ・ストア・ログ・ファイルを使用して、その新しい共有メモリー・セグメントにデータ・ストアをリカバリします。
  6. 準備されたすべての文を再準備します。
  7. この5つの手順を完了したら、アプリケーションでデータ・ストアの使用を再開できます。

注意: これらの5つの手順の実装は単純かつ効果的であり、TTClassesで配布されるttMonitor(ファイル名: monitor.cpp)のソース・コードで確認できます。TTClassesの詳細は、オラクル社カスタマ・サポート・センターにお問い合せください。

アプリケーションにデータ・ストア接続のリカバリを実装したら、実装したコードがデータ・ストア接続を適切にリカバリすることを検証します。データ・ストアを強制的に無効にするには、アプリケーションの実行中に、ttIsqlを使用してデータ・ストアに接続し、call invalidate;コマンドを発行します。これによって、データ・ストアは無効としてマークされます。この時点で、アプリケーションでデータ・ストアの無効化が正しく処理されるかどうかを検証できます。

注意: デーモン・ログにエラー・メッセージが記録された場合、またはリカバリが開始されたが完了していないことが示されている場合は、ttBackupユーティリティを使用してデータ・ストアをバックアップしてから、オラクル社カスタマ・サポート・センターに連絡してください。「TimesTenデーモン/イベント・ログを確認する」を参照してください。

追加情報については、『Oracle TimesTen In-Memory Database推奨されたプログラミングの実行』のTimesTenのアーキテクチャとデータ・ストア・リカバリの簡単なチュートリアルに関する項を参照してください。