テーブルの読み取り専用操作の結果に絶対的な確実性が必要な財務、注文入力、在庫管理などの基幹業務アプリケーションと違い、カスタマー リレーションシップ マネージメント(CRM)などのアプリケーションは、スナップショット、つまりデータベースの現在の状態の「統計的な」全体像のみが必要なので、Teradata Databaseから取得するデータに同じレベルの絶対的な確実性は必要ありません。
このため、CRM およびその他の類似アプリケーションではダーティ読み取り操作を許容できるので、データベース読み取り操作における正確性の低下と引き替えに、トランザクション並列性を高めることができます(詳細は、<Teradata Vantage™- SQLリクエストおよびトランザクション処理、B035-1142>を参照)。
ダーティ読み取りとは、トランザクションによってデータベースに書き込まれ、まだコミットされていないデータを読み取る可能性がある操作のことです。どんなトランザクションでも何らかの理由で失敗することがあり、失敗するとシステムはそのトランザクションが行なった更新をすべてロールバックします。こうした更新の中に他の並行実行中のトランザクションが読み取ったデータがあった場合、データベースに関する限りそのデータは存在しなかったことになるので、その読取りはダーティーであったといいます。トラ ンザクションの整合性およびそれによって緩和できる問題の詳細については、<Teradata Vantage™- SQLリクエストおよびトランザクション処理、B035-1142>を参照してください。
ロックをリクエスト単位に低下させる(負荷が大きくなり得る)よりも、ダーティー読取りを許容するデフォルトのセッション全体のロッキング レベルを指定できる方が、ダーティー読取りが許されるアプリケーションのパフォーマンスには良い影響がある場合があります。トランザクション並列性を高めることにより、ACCESSレベルのロッキングはREADレベルのロッキングよりもパフォーマンスが良くなります。
これはとても重要な考慮事項であり、軽く考えるべき点ではありません。読取り専用操作のデフォルトをACCESSレベル ロッキングにするかどうかを決定する前に、セッション全体の質的な作業負荷を注意深く検討しなければなりません。例えば、MultiLoad IMPORTジョブが実行中のセッションを考えてみましょう。MultiLoadが取得フェーズの際にテーブルの行を更新するときに(<Teradata® MultiLoadリファレンス、B035-2409>を参照)、取得フェーズ中にACCESSロックを使用してMultiLoadジョブのターゲット テーブルでクエリーを行なうと、非常に不正確な結果セットが生成されることがあります。この場合、結果はおそらくテーブル データの適切な内容とは言えないものになってしまいます。
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL文は、現在のセッション内の特定の-読取り専用SELECT操作のREADロックを間接的にACCESSロックに置き換えるためのメカニズムを備えています(ただし、DELETE、INSERT、UPDATEのいずれかのリクエストに埋め込まれているSELECTSubquery の場合に限られます)。セッションの初期のデフォルトはSERIALIZABLE(つまりREADレベル強度のロッキング)のままになりますが、読取り専用ロッキング強度をREAD UNCOMMITTED(つまりACCESSレベル強度のロッキング)に対話的にあるいはもっと持続的にアプリケーション コード内で切り替えることができます。