セッションが次のような条件でアボートされた場合には、データが失なわれることがあります。
- ゲートウェイ制御ユーティリティのDISCONNECT SESSIONコマンドによるアボート
- 性能モニターのABORT SESSIONコマンドによるアボート
- Teradata Databaseが再始動してから20分以上アイドル状態であったセッションへの再接続が開始されないことによるアボート
Teradata Databaseが再始動すると、アクティブ セッションに対しリクエストの送信またはデータの取り出しがBTEQによって行なわれてから、再接続の手続きがCLIにより開始されます。 セッションがアイドル状態の場合は、リクエストの送信やデータの取り出しが行なわれず、CLIは、再接続を実行できません。
20分は、ゲートウェイ構成の仕様におけるデフォルト値です。 この時間は、ローカル システムによって異なる可能性があります。このような場合には、8018(セッションIDが無効である)または8055(セッションは強制切断された)というエラー コードがTeradata DatabaseからBTEQに返されます。 この場合、Teradata SQLの応答は廃棄され、リクエストおよびリクエストが埋め込まれていたトランザクションはアボートされて取り消されます。
- メインフレーム接続システムの場合、BTEQはセッションのアボート後にリクエストを再び送られないため、関連するデータが失なわれる可能性があります。
- ワークステーション接続システムの場合、複数のセッションが実行されていれば、使用可能な後続のセッションを通してリクエストが再び送られます。 ただし、ログオンしているセッションが1つのみで、そのセッションが切断されている場合は、トランザクションがアボートされ、関連するデータも失なわれます。 この時点で、BTEQは終了します。
データが失なわれることの重大度は、セッションがアボートされたときに実行中であったトランザクションの性質によって異なります。
- 挿入リクエストが実行されていた場合は、行データが失なわれる可能性があります。 損失する行数の最大数は、8018エラーを受け取ったセッション数と同じになります。
- 更新または削除リクエストが実行されていた場合は、テーブルの保全性が損なわれる可能性があります。
いずれの場合も、アボートされたリクエストを手動で再び送る必要があります。