トランザクションの完了。銀行カード取引とは何ですか。操作の禁止。 SELECTコマンドの実行

トランザクションは、単一のエンティティ（all-or-nothing）として実行され、データベースを1つの一貫した状態（つまり、データベースに定義されたすべての整合性制約が満たされている状態）から別の状態に移動する一連のデータ操作ステートメントです。。状態。情報システムの利用者にとっては、トランザクション全体が実行されるか、何らかの理由でトランザクションのアクションの1つが実行不可能であるか、システムの誤動作があった場合、データベースは以前の元の状態に戻ります。トランザクションの開始（トランザクションはロールバックされます）。

トランザクションは、マルチユーザーシステムとシングルユーザーシステムの両方で重要です。シングルユーザーシステムでは、トランザクションはデータベースを一貫した状態に保つ論理的な作業単位です。トランザクションは、障害後のデータ回復の単位でもあります。回復時に、システムは、ソフトウェアまたはハードウェアの障害の結果として正常に完了する時間がなかったトランザクションの痕跡を排除します。さらに、マルチユーザーシステムでは、トランザクションは個々のユーザーの分離された作業を保証するのに役立ちます。同じデータベースを同時に操作するクライアントは、シングルユーザーシステムのように機能し、相互に干渉しません。

トランザクションプロパティ

すべてのトランザクションには、次の4つのプロパティ（ASIDプロパティと呼ばれる）が必要です。

原子性トランザクションは、操作の結果を修正するか、すべてを元の場所に戻します。トランザクションが成功すると、トランザクションの結果がコミットされます。何らかの理由でトランザクションが失敗した場合、操作が実行されたオブジェクトは元の状態に戻ります。たとえば、オブジェクトの名前を変更すると、古い名前を消去して新しい名前を設定するか、オブジェクトの名前を変更しないでおく必要があります。

ちなみに、原子性（相互依存）は私たちの日常生活に欠かせないものです。たとえば、結婚式の最中に、司祭は最初に新郎新婦に「この人をあなたの配偶者として連れて行きたいですか？」と尋ねます。一方と他方の両方が「はい」と答えた後でのみ、司祭は「私はあなたに夫と妻を宣言します」と言うことができ、こうしてある状態から別の状態への移行を修正します。言い換えれば、取引の枠組みの中で、取引のいくつかの独立した当事者は、取引が完了する前に、すべての人に共通の合意に達する必要があります。いずれかの当事者が反対した場合、各参加者はそれぞれの当事者に留まります。

一貫性トランザクションは、その状態を維持しながら、システムの正しい変換を引き起こします。たとえば、二重にリンクされたリストへの1つのアイテムのトランザクション追加の一部として、一方と他方への4つのポインターすべてが同時に更新されます。

隔離。同時トランザクションは、保留中のトランザクションの影響から分離されています。この特性は、直列化可能性とも呼ばれます。たとえば、二重リンクリストを通過するトランザクションは、現時点では前のトランザクションによって変更されており、初期化前にすでに行われた変更のみが表示されます。このトランザクションの開始後に前のトランザクションによって行われた変更は、もはやそれに影響を与えることはできません。

異なるレベルの分離で競合するトランザクションを同時に実行する機能により、アプリケーション開発者はシステム効率を向上させることができます。分離のレベルが低いと、データの状態がぼやけたり一貫性がなくなったりするリスクを犠牲にして、同時トランザクションの数を増やすことができます。一部のトランザクションは最高の分離レベル（純粋な直列化可能性）で実行されますが、より低い分離レベルでの同時実行トランザクションは並行して実行され、以前にトランザクションによって読み取られたコミットされていないデータまたは古いデータを操作できます。もちろん、より低い分離レベルで実行されているトランザクションは、結果として誤ったデータを生成する可能性があります。アプリケーション開発者は、高い分離レベルのトランザクションで無効なデータが使用された場合に、このようなエラーが伝播することに注意する必要があります。

耐久性または安定性（耐久性）。トランザクションが成功すると、その結果がコミットされて保存されます。また、この場合、システム障害の危険性があっても結果は保持されます。トランザクションのASIDのプロパティが完全に実行されるとは限らないことに注意してください。これは、プロパティI（分離）に特に当てはまります。理想的には、異なるユーザーのトランザクションが互いに干渉しないようにする必要があります。これらは、ユーザーがシステム内で一人でいるような錯覚を抱くような方法で実行する必要があります。完全な分離を実現する最も簡単な方法は、トランザクションをキューに入れ、厳密に次々に実行することです。明らかに、この場合、システムの効率は失われます。したがって、実際には、複数のトランザクションが同時に実行されます。

トランザクション分離にはいくつかのレベルがあります。分離の最低レベルでは、トランザクションは実際に相互に干渉する可能性があります。最高レベルでは、トランザクションは完全に分離されています。トランザクション分離が大きくなると、システムオーバーヘッドが高くなり、パフォーマンスが低下します。ユーザーまたはシステム管理者は、独自の裁量ですべてまたは個々のトランザクションのさまざまなレベルを設定できます。

プロパティD（耐久性）も絶対的なプロパティではありません。一部のシステムでは、ネストされたトランザクションが許可されています。トランザクションBがトランザクションA内で開始され、トランザクションBに対してCOMMIT WORKコマンドが発行された場合、トランザクションBのデータのコミットは条件付きです。外部トランザクションAはロールバックできます。内部トランザクションBの結果は、外部トランザクションAがコミットされた場合にのみ永続的にコミットされます。

開始と終了

トランザクションは通常、ユーザーがDBMSに接続すると自動的に開始され（通常、常にではありません。たとえば、VisualFoxProは新しいトランザクションを開始するために明示的なBEGINTRANSACTIONを必要とします）、次のいずれかが発生するまで続きます。

コマンドCOMMITWORKが発行されました。

ROLLBACKWORKコマンドが発行されました。

ユーザーがDBMSから切断しました。

システムに障害が発生しました。

COMMIT WORKコマンドは、現在のトランザクションを終了し、新しいトランザクションを自動的に開始します。この場合、完了したトランザクションの結果が記録されることが保証されます。データベースに保存されます。 ROLLBACK WORKコマンドを使用すると、現在のトランザクションによって行われたすべての変更がロールバックされます。まったく存在しなかったかのようにキャンセルされます。これにより、新しいトランザクションが自動的に開始されます。ユーザーがDBMSから切断されると、トランザクションは自動的にコミットされます。

システムがクラッシュすると、より複雑なプロセスが発生します。それらの本質は、システムの次の起動時に、障害が発生する前に実行されたトランザクションの分析という事実に要約されます。 COMMIT WORKコマンドが発行されたが、結果がデータベースに入力されなかったトランザクションは、再度実行（ロール）されます。 COMMITWORKコマンドが発行されなかったトランザクションはロールバックされます。

並行作業

最新のDBMSは、マルチユーザーシステムです。多数のユーザーの並行同時作業を可能にします。同時に、ユーザーは互いに干渉してはなりません。なぜならユーザーの論理作業単位がトランザクションである場合、DBMSの作業は、ユーザーが自分のトランザクションが他のユーザーのトランザクションとは独立して実行されているという印象を与えるように編成する必要があります。

このような錯覚をユーザーに提供する最も簡単で明白な方法は、すべての着信トランザクションを1つのキューに並べて、厳密に順番に実行することです。この方法は明らかな理由で適切ではありません-並列作業の利点が失われます。したがって、トランザクションは同時に実行する必要がありますが、結果はトランザクションが順番に実行された場合と同じになります。特別な措置を講じないと、最初のユーザーのトランザクションが終了する前に、あるユーザーによって変更されたデータが別のユーザーのトランザクションによって変更される可能性があるという事実に問題があります。その結果、トランザクションの終了時に、最初のユーザーには作業の結果は表示されませんが、誰が何を知っているかがわかります。

異なるユーザーのトランザクションはどのように相互に干渉できますか？ 3つの主要な並行性の問題があります。

更新結果が失われる問題。

コミットされていない依存関係の問題（「ダーティ」データの読み取り、ずさんな読み取り）。

互換性のない分析の問題。

複数のトランザクションの独立した並列操作を保証する方法の1つは、ロック方法です。

3つの同時実行の問題に加えて、同時アクセスの競合を区別するのが一般的です。トランザクションが時間的に重複し、同じデータにアクセスする場合、トランザクションは並行トランザクションと呼ばれます。トランザクション間のデータ競合の結果として、データアクセスの競合が発生します。

W-W（記録-記録）。最初のトランザクションはオブジェクトを変更し、終了しませんでした。 2番目のトランザクションは、このオブジェクトを変更しようとします。その結果、更新が失われます。

R-W（読み取り-書き込み）。最初のトランザクションはオブジェクトを読み取り、完了しませんでした。 2番目のトランザクションは、このオブジェクトを変更しようとします。結果は互換性のない分析です（繰り返し不可能な読み取り）。

W-R（書き込み-読み取り）。最初のトランザクションはオブジェクトを変更し、終了しませんでした。 2番目のトランザクションは、このオブジェクトを読み取ろうとします。その結果、ダーティデータが読み取られます。

R-R（読み取り-読み取り）の競合はありません。読み取り中にデータは変更されません。

他の並行性の問題は、より複雑です。それらの根本的な違いは、1つのオブジェクトを操作するときに発生しないことです。これらの問題では、トランザクションがデータセット全体を操作する必要があります。

トラブルシューティング：ブロック

ロックの主な考え方は、特定のトランザクションを実行するために、このトランザクションの知識がなくてもオブジェクトが変更されないようにする必要がある場合、このオブジェクトをロックする必要があるということです。他のトランザクションからのこのオブジェクトへのアクセスは、ロックの原因となったトランザクションの間制限されます。

排他的ロック（Xロック、排他的ロック）-相互アクセスのないロック（書き込みロック）。対照的に、共有ロック（Sロック）は相互アクセスロック（読み取りロック）です。トランザクションAがXロックでオブジェクトをロックすると、他のトランザクションからそのオブジェクトへのすべてのアクセスが拒否されます。トランザクションAがSロックを使用してオブジェクトをロックすると、このオブジェクトのXロックに対する他のトランザクションからの要求は拒否され、このオブジェクトのSロックに対する他のトランザクションからの要求は受け入れられます。

行き止まり

ロックのあるトランザクションを処理する場合、デッドロック状態が発生する可能性があります。両方のトランザクションが互いに待機していて、続行できない状況。行き詰まりから抜け出すための「通常の」（自動）方法がないことは明らかであるため、そのような状況を認識して排除する必要があります。デッドロック解決方法は、トランザクションの1つ（ビクティムトランザクション）をロールバックして、他のトランザクションが作業を続行できるようにすることです。デッドロックが解決された後、被害者として選択されたトランザクションを再試行できます。

デッドロックの検出と被害者のトランザクションの選択には、2つの主要なアプローチがあります。DBMSはデッドロックを監視しません。トランザクション自体が被害者になるかどうかを決定します。このアプローチは、いわゆるデスクトップDBMS（FoxProなど）で一般的です。この方法はより単純で、追加のシステムリソースを必要としません。トランザクションの場合、トランザクションが目的のロックを取得しようとするタイムアウト（または試行回数）を指定します。指定された時間内（または指定された試行回数の後）にロックが正常に完了しなかった場合、トランザクションはロールバックされます（またはエラー状態が生成されます）。この方法の単純さの代償は、犠牲者のトランザクションが、一般的に言えば、ランダムに選択されることです。その結果、1つの単純なトランザクションのために、非常に高価なトランザクションをロールバックできます。その実行には、すでに多くの時間とシステムリソースが費やされています。

デッドロック検出の2番目のアプローチは、DBMS自体がデッドロックの発生を監視し、どのトランザクションを犠牲にするかを決定することです。この方法は、産業用DBMS（ORACLE、MS SQL Serverなど）で一般的です。この場合、システム自体が、トランザクション待機グラフ（トランザクションに対応するノードとキャプチャオブジェクトに対応するノードの2種類のノードがある有向2部グラフ）を作成（または常に維持）することにより、デッドロック状況の発生を監視します。。デッドロックは、トランザクション待機グラフに少なくとも1つのサイクルがある場合に発生します。サイクルでキャッチされたトランザクションの1つをロールバックする必要があり、システム自体がいくつかのコストの考慮事項（たとえば、最短または最低の優先度など）に従ってこのトランザクションを選択できます。

産業用アプリケーションでのトランザクション

トランザクションは、産業規模のアプリケーションを構築するための重要な概念です。すでに述べたように、ユーザーにとって、トランザクションは、アクションが実行されたか、実行されなかったかを示すシグナルです。一方、開発者にとって、トランザクションは、分散コンピューティングに参加できる独立したモジュールを作成できるプログラミングスタイルです。たとえば、顧客は普通預金口座から当座預金口座にお金の一部を送金する必要があります。この操作で最も重要なのは、トランザクションが成功した場合に両方のアカウントの状態を同時に変更すること、または送金が失敗した場合にアカウントの状態を同じ形式で維持することです。お金があるアカウントを離れて別のアカウントに到達しない場合、あなたがそれを好きになる可能性は低いです。この条件は、この目的のアプリケーションにとって自明の要件ですが、トランザクションの管理や制御を一切導入せずに分散システムでこの操作を実行することは非常に問題があるようです。コンピューターに障害が発生し、メッセージがどこかで失われる可能性があります。

トランザクションは、分散アプリケーションのバックボーンです。さらに、モジュール式のプログラム実行を提供するのはトランザクションです。これは、プログラミングにおけるコンポーネントテクノロジの本質です。

Eコマース：トランザクションの保護

決済システムにおけるキャッシュレス取引は、取引と呼ばれます。決済システムは、購入、銀行支店での現金引き出し、ATMからの現金引き出し、顧客の口座の残高に関する情報の取得など、さまざまなタイプのトランザクションをサポートします。

トランザクションは、カード情報が支払いシステムに提示される方法も異なります。電子取引（カードに関する情報は磁気ストライプ/チップから読み取られます）と音声認証取引（紙ベース）があります。

通常、オンラインショッピングのプロセスは次のとおりです。クライアントは、インターネットに接続されたパーソナルコンピュータ（または他のデバイス）を使用して、アウトレットのWebサイト上の商品の仮想ショーケースで関心のある商品を選択します。商品の選択と費用の合意を確認した後、クライアントは、プラスチックカードを使用して購入の支払いを希望することをアウトレットに通知します。

さらに、アウトレットとカード所有者の間で対話が行われ、その目的は、標準の承認要求の形式でネットワークに提示するための購入者のカードの詳細を取得することです。この対話の間に、商人と買い手は時々お互いを認証する機会があり、それは取引の安全を保証します。電子商取引の黎明期から、従来の取引で使用されていたカード所有者の識別方法は、電子商取引では不十分であることが明らかになった。

実際、実店舗で購入取引を行う場合、売り手は、支払いシステムの要件に準拠しているかどうかを計算するために提示されたプラスチックカードを調べる権利があります（特に、ホログラム、特別な秘密の記号の存在を確認し、確認します）パネルの署名や領収書など）..。さらに、売り手は買い手に彼の身元を証明する文書を提供するように要求するかもしれません。これらすべてが、不正なカード詐欺を高額な事業にします。電子商取引の場合、詐欺師に必要なのはカードの詳細に関する知識だけです。この場合、偽造物理カードの製造に関連する費用は必要ありません。

磁気ストライプのあるプラスチックカードの場合、トランザクションを詐欺から保護するための最も信頼できる方法は、PINコードを使用して、発行銀行によってカード所有者を識別することです。カード所有者が所有する秘密情報はPINコードです。これは、カード所有者とその発行銀行だけが知っている4〜12桁のシーケンスです。 PINコードは、ATMでカード所有者に現金を発行する場合など、リスクの高い取引を行うときに常に使用されます。 ATMでの現金の引き出しは、サービス銀行の代表者の立ち会いなしで行われます（状況はeコマーストランザクションに似ています）。したがって、「ATMでの現金引き出し」の操作を保護するための通常のカードの詳細では不十分であり、秘密の追加情報（PINコード）が使用されます。

このような識別子を使用するとセキュリティの問題を解決できるように思われますが、そうではありません。残念ながら、eコマースへの適用では、この方法は古典的な形式では適用できません。

PINコードの使用は、この秘密のパラメーターがトランザクション処理のすべての段階で暗号化されたままになるように行う必要があります（カード所有者と銀行だけが知っている必要があります）。

従来のスキームは、カード所有者のPINコードを加盟店の公開鍵で暗号化する非対称アルゴリズムを使用して実装できます。ただし、PINコードを支払いネットワークに提示するには、すべての支払いシステムで一般的であるように、対称鍵を使用して暗号化する必要があります。

PINコードを使用するための別の非古典的な解決策があります。たとえば、カード所有者のコンピュータのPINコードに加えて、発行者とカード所有者だけが知っているキーでトランザクションごとに動的に変化するデータを暗号化することができます。このアプローチでは、秘密鍵の配布の問題を解決する必要があります。このタスクは非常に難しく（各カード所有者が独自の個別のキーを持っている必要があることは明らかです）、すでに解決されている場合は、チェックよりも効果的なカード所有者の他の認証方法にそのソリューションを使用するのが理にかなっていますPINコード。

分析の結果、決済システムは、eコマースでトランザクションを実行するためのスキームの基本要件を「形成」しました。これにより、必要なレベルのセキュリティが確保されます。

1.購入参加者（購入者、小売店、およびそのサービス銀行）の認証。買い手（売り手）の認証とは、特定のカード所有者が実際にこの支払いシステムの特定の発行者参加者（サービス銀行参加者）のクライアントであるという事実を（既知の暗号アルゴリズムの信頼性のレベルで）証明する手順を意味します。サービス銀行の認証は、銀行がこの支払いシステムのメンバーであるという事実を証明します。

2.トランザクションで使用される支払いカードの詳細（カード番号、有効期限、CVC2 / CVV2など）は、マーチャントの機密情報である必要があります。

3.トランザクションのすべての参加者のトランザクションをキャンセルすることは不可能です。つまり、すべての参加者は、購入（注文または支払い）を行ったという事実の議論の余地のない証拠を持っています。

4.電子購入のためのマーチャントへの支払いの保証-マーチャントは注文が完了したことを証明します。

InterBaseでのトランザクション

最後に、トランザクションが存在する2つの環境について説明します。つまり、InterBaseでのトランザクションの実装と、EnterpriseJavaBeansテクノロジの「Javaトランザクションサービス」についてです。

InterBaseでトランザクションを管理するには、次の3つの式があります。

SET TRANSACTION-トランザクションを開始し、その動作を定義します。

COMMIT-トランザクションによって行われた変更をデータベースに保存し、トランザクションを終了します。

ROLLBACK-トランザクションによって行われた変更をロールバックし、トランザクションを終了します。

1.トランザクションの開始

トランザクションを開始するには、次のSQLコマンドを実行する必要があります。

トランザクションの設定

式「SETTRANSACTION」
式と同等です
「SETTRANSACTIONREAD WRITE WAIT ISOLATIONLEVELSNAPSHOT」

アクセスモード-データアクセスのタイプを定義します。次の2つの値を取ることができます。

読み取り専用-トランザクションがデータの読み取りのみを実行でき、データを変更できないことを示します。

READWRITE-トランザクションがデータを読み取って変更できることを示します。これがデフォルトです。

分離レベル-このトランザクションとこのデータベース内の他のトランザクションとの相互作用の順序を決定します。値を取ることができます：

SNAPSHOTがデフォルトです。トランザクション内では、データはトランザクションが開始されたときの状態で利用可能になります。途中で、他の完了したトランザクションによって行われた変更がデータベースに表示される場合、このトランザクションにはそれらが表示されません。このようなレコードを変更しようとすると、競合メッセージが表示されます。

SNAPSHOT TABLESTABILITY-トランザクションが使用するテーブルへの排他的アクセスを許可します。他のトランザクションは、それらからデータを読み取ることしかできません。

READCOMMITTED-トランザクションがデータベースの現在の状態を確認できるようにします。

レコードロックの競合は、次の2つの場合に発生します。

トランザクションは、開始後に変更または削除されたレコードを変更しようとしています。 READ COMMITTEDトランザクションは、完了後に他のトランザクションによって変更されたレコードに変更を加えることができます。

トランザクションは、SNAPSHOT TABLESTABILITYタイプの別のトランザクションによってロックされているテーブルを更新しようとしています。

ロック解決-ロックの競合が検出されたときのイベントのコースを決定します。次の2つの値を取ることができます。

WAITがデフォルトです。必要なエントリのロックが解除されるのを待っています。その後、作業を継続しようとします。

NOWAIT-書き込みロックエラーをすぐに返します。

テーブル予約-トランザクションが、指定されたテーブルへの必要なレベルへのアクセスを保証できるようにします。 4つのアクセスレベルがあります。

PROTECTED READ-他のトランザクションがテーブルを更新するのを防ぎますが、テーブルからデータをフェッチすることはできます。

PROTECTEDWRITE-他のトランザクションによるテーブルの更新を禁止します。SNAPSHOTまたはREADCOMMITTEDトランザクションのみがテーブルからデータを読み取ることができます。

SHAREDREADは最もリベラルなレベルです。誰でも読み取り、変更できます-READWRITEトランザクション。

SHAREDWRITE-SNAPSHOTまたはREADCOMMITTED READ WRITEトランザクションはテーブルを変更でき、残りはデータをフェッチすることしかできません。

2.取引の完了

トランザクションを構成するすべてのアクションが正常に完了した場合、またはエラーが発生した場合、データベースを整合性のある状態にするには、トランザクションを完了する必要があります。これにはSQLステートメントがあります。

COMMIT-トランザクションによって行われた変更をデータベースに保存します。これは、トランザクションが正常に完了したことを意味します。

ROLLBACK-トランザクションのロールバック。トランザクションは終了し、データベースは変更されません。この操作は、操作中にエラーが発生した場合（たとえば、レコードを更新できない場合）に実行されます。

Javaトランザクションサービス

EJB（Server Bean Technology、Enterprise JavaBeans）アーキテクチャーは、トランザクションコーディネーターとしてJava Transaction Service（JTS）を使用します。 JTSの用語では、このコーディネーターはトランザクションマネージャーと呼ばれます。リレーショナルデータベースなどのトランザクションで保護されたリソースを実装するトランザクションの参加者は、リソースマネージャーと呼ばれます。アプリケーションがトランザクションを開始すると、そのトランザクションを表すオブジェクトが作成されます。次に、アプリケーションはリソースマネージャーを呼び出して操作を実行します。トランザクションの実行中、各トランザクションマネージャーは、トランザクションで指定された各リソースマネージャーの作業を監視します。

アプリケーションが各リソースマネージャーを最初に呼び出すと、現在のトランザクションが決まります。たとえば、アプリケーションがリレーショナルデータベースを使用する場合、アプリケーションはJava Database Connectivity（JDBC）インターフェイスを呼び出します。このインターフェイスは、トランザクションオブジェクトをデータベースに関連付けます。これ以降、この接続を介して行われるすべての呼び出しは、トランザクションが完了するまで、データベース自体のトランザクションに代わって行われます。

アプリケーションは、xa_commit（）メソッドを呼び出してトランザクションの結果をコミットし、トランザクションが正常に完了したことを報告します。何らかの理由でアプリケーションがトランザクションを完了できない場合、アプリケーションはxa_rollback（）メソッドを呼び出して、加えられた変更を元に戻します。アプリケーションがトランザクションを完了できない場合、JTSはタスクをドロップします。トランザクション操作が成功すると、アプリケーションはJTSを呼び出して結果を保存します。次に、JTSは2フェーズコミットプロトコルを実行して、トランザクションで指定されたリソースマネージャーにジョブを送信します。

2フェーズコミットプロトコルは、トランザクションの結果が保存されるか、ジョブがキャンセルされることを保証するために使用されます。最初のフェーズでは、JTSは各リソースマネージャーの準備を確立します。それぞれが準備ができていることを確認すると、第2フェーズで、JTSはそれぞれに結果を示すメッセージを送信します。いずれかのマネージャーが要求に応答しないか、否定的な回答をした場合、JTSは他のマネージャーにトランザクションがキャンセルされたことを通知します。

トランザクションの構造、トランザクション内の同時実行性、期間など、さまざまなプロパティに基づいて分類できるトランザクションのさまざまなモデルがあります。

現在、次のタイプのトランザクションが区別されています：フラットまたはクラシックトランザクション、チェーントランザクション、ネストされたトランザクション。

フラットまたは従来のトランザクションは、原子性、一貫性、分離、耐久性（強度）-ACID（原子性、一貫性、分離、耐久性）の4つの古典的なプロパティによって特徴付けられます。従来のトランザクションは、ACIDトランザクションと呼ばれることもあります。上記のプロパティは、次のことを意味します。

· 原子性特性（Atomicity）は、トランザクションが全体として完了するか、まったく完了しないかで表されます。

· 整合性プロパティ（一貫性）は、トランザクションが進行するにつれて、データが1つの一貫性のある状態から別の状態に移行することを保証します-トランザクションはデータの相互の一貫性を壊しません。

· 分離特性（分離）とは、データベースへのアクセスをめぐって競合するトランザクションが物理的に順番に処理され、互いに分離されていることを意味しますが、ユーザーには並列に実行されているように見えます。

· 耐久性（耐久性）は次のように解釈されます。トランザクションが正常に完了した場合、トランザクションによって行われたデータの変更は、どのような状況でも（後続のエラーが発生した場合でも）失われることはありません。

トランザクションを完了するには2つのオプションがあります。すべてのステートメントが成功し、トランザクション中にハードウェアまたはソフトウェアの障害が発生しなかった場合、トランザクションはコミットされます。

トランザクションのコミットとは、トランザクションの実行中に行われたデータベースへの変更をディスクに書き込む行為です。

トランザクションがコミットされるまで、これらの変更をロールバックし、データベースをトランザクション開始時の状態に復元することができます。トランザクションをコミットするということは、トランザクションのすべての結果が永続的であることを意味します。それらは、現在のトランザクションがコミットされた後にのみ、他のトランザクションに表示されます。この時点まで、トランザクションの影響を受けるすべてのデータは、現在のトランザクションの開始時にユーザーに「表示」されます。

トランザクションの実行中に何かが発生して正常に完了できなくなった場合は、データベースを元の状態に戻す必要があります。トランザクションロールバックは、SQLステートメントによって行われたすべてのデータ変更を現在の保留中のトランザクションの本体にロールバックするアクションです。

トランザクション内の各ステートメントは作業の一部を実行しますが、作業全体を正常に完了するには、すべてのステートメントを無条件に完了する必要があります。トランザクション内のステートメントのグループ化は、グループ全体を全体として実行する必要があり、そのような実行は自動的にサポートされる必要があることをDBMSに通知します。

ANSI / ISO SQL標準は、トランザクションモデルとCOMMITおよびROLLBACKステートメントの機能を定義します。この標準では、トランザクションは、データベースの現在の状態を変更する、ユーザーによって開始された、またはプログラムに含まれている最初のSQLステートメントで始まると指定されています。後続のすべてのSQLステートメントは、トランザクションの本体を構成します。トランザクションは、次の4つの方法のいずれかで終了します（図11.1）。

1.ステートメントCOMMITは、トランザクションが正常に完了したことを意味します。これを使用すると、現在のトランザクション内でデータベースに加えられた変更が永続的になります。

2. ROLLBACKステートメントはトランザクションを中止し、このトランザクションの一部としてデータベースに加えられた変更をキャンセルします。 ROLLBACKを使用した直後に新しいトランザクションが開始されます。

3.現在のトランザクションが開始されたプログラムが正常に完了したということは、トランザクションが正常に完了したことを意味します（COMMITステートメントが使用されたかのように）。

4.誤ったプログラム終了は、トランザクションを中止します（ROLLBACKステートメントが使用されたかのように）。

このモデルでは、データベースの状態を変更する各ステートメントはトランザクションと見なされるため、このステートメントが正常に完了すると、データベースは新しい安定した状態になります。

商用DBMSの最初のバージョンは、ANSI / ISOトランザクションモデルを実装しました。その後、拡張トランザクションモデルがSYBASE DBMSに実装されました。これには、いくつかの追加操作が含まれています。 SYBASEモデルは、次の4つの演算子を使用します。

・BEGIN TRANSACTIONステートメントは、トランザクションの開始を示します。トランザクションの開始が最初のデータ変更ステートメントによって暗黙的に指定されるANSI / ISOモデルとは異なり、SYBASEモデルでは、トランザクションの開始はトランザクションの開始ステートメントを使用して明示的に指定されます。

・COMMIT TRANSACTIONステートメントは、トランザクションが正常に完了したことを報告します。これは、ANSI / ISO標準モデルのCOMMITステートメントと同等です。この演算子は、COMMIT演算子と同様に、トランザクションの実行中にデータベースに加えられたすべての変更をコミットします。

・SAVE TRANSACTIONステートメントは、このステートメントの実行時に保存されたデータベースの中間状態に対応するセーブポイントをトランザクション内に作成します。 SAVE TRANSACTIONステートメントには、セーブポイントの名前を含めることができます。したがって、トランザクションの実行中に、いくつかの中間状態に対応するいくつかのセーブポイントが格納される場合があります。

・ROLLBACK演算子には2つの変更があります。このステートメントを追加のパラメーターなしで使用すると、トランザクション全体のロールバックステートメントとして解釈されます。つまり、この場合、ANSI / ISOモデルのROLLBACKステートメントと同等です。ロールバックステートメントにパラメータがあり、ROLLBACK Bとして記述されている場合、それはセーブポイントBへの部分的なトランザクションロールバックステートメントとして解釈されます。

図。 11.1。ANSI / ISOトランザクションモデル

拡張トランザクションモデルでトランザクションを実行する原理を図に示します。 11.2。この図では、オペレーターに番号が付けられているため、考えられるすべてのケースでトランザクションの進行状況を追跡するのに便利です。

図。 11.2。拡張モデルでトランザクションを実行する例

トランザクションは、トランザクションの開始の明示的な演算子で始まります。これは、スキームの番号1です。次は、検索演算子であり、データベースの現在の状態を変更しない演算子2と、次の演算子3および4です。データベースを新しい状態に転送します。ステートメント5は、データベースのこの新しい中間状態を保存し、ポイントAで中間状態としてマークします。次に、ステートメント6と7が続き、データベースを新しい状態に転送します。そして、オペレーター8は、この状態をポイントBの中間状態として保存します。オペレーター9は新しいデータ入力を実行し、オペレーター10は条件1のチェックを実行します。条件1が満たされると、ステートメント11が実行され、トランザクションが中間状態Bにロールバックされます。これは、ステートメント9のアクションの結果が消去されたように見え、データベースが中間状態Bに戻ることを意味します。ステートメント9の実行は、すでに新しい状態でした。そして、トランザクションのロールバック後、状態から以前に実行されたステートメント9の代わりに、データベースでは、新しいデータを入力するステートメント13が実行され、制御がステートメント14に移されます。ステートメント14は再び条件をチェックしますが、すでにいくつか新しい条件2; 条件が満たされた場合、制御はオペレーター15に移され、オペレーター15はトランザクションを中間状態Aにロールバックします。つまり、データベースを変更した6から13で終わるすべてのオペレーターは、満たされていないものと見なされます。、実行結果が消え、再び状態になります。そして、演算子4を実行した後と同様に、次に、制御が演算子17に移され、データベースの内容が更新された後、制御が演算子18に移されます。はチェック条件3に関連付けられています。チェックは、トランザクションをコミットするオペレーター20に制御を移すことによって終了し、データベースは新しい1つの定常状態になり、現在のトランザクション内で変更することはできません。または、制御がオペレーター19に移された場合、トランザクションは最初にロールバックされ、データベースは初期状態に戻ります。ここではすべての中間状態がすでにチェックされており、これらの中間状態へのロールバック操作を実行することはできません。演算子19を実行した後の状態。

もちろん、SYBASEの拡張トランザクションモデルは、はるかに柔軟なトランザクション実行メカニズムをサポートしています。セーブポイントを使用すると、トランザクション内でマーカーを設定できるため、トランザクションで実行された作業の一部のみを元に戻すことができます。特定のステートメントを元に戻すことができるように、長くて複雑なトランザクションでセーブポイントを使用することをお勧めします。ただし、これはシステムリソースの追加コストにつながります。オペレーターが作業を実行し、変更がキャンセルされます。通常、処理ロジックの改善がより良い解決策になる場合があります。

トランザクションログ

中間状態の保持、トランザクションの確認またはロールバックの原則のDBMSでの実装は、特定のシステム構造が作成されることをサポートするための特別なメカニズムによって提供されます。 トランザクションログ。

ただし、トランザクションログの目的ははるかに広いです。データベースに信頼性の高いデータストレージを提供するように設計されています。

そして、この要件は、特に、あらゆる種類のハードウェアおよびソフトウェアの障害後にデータベースの一貫した状態を復元する機能を意味します。明らかに、復元を実行するにはいくつかの追加情報が必要です。最新のリレーショナルDBMSの大部分では、このような冗長な追加情報は、データベース変更ログの形式で維持されます。 トランザクションログ。

したがって、データベースの変更をログに記録する全体的な目標は、障害が発生した後でもデータベースを一貫した状態に復元できるようにすることです。データベースの一貫性のある状態を維持するための基礎はトランザクションメカニズムであるため、ロギングとリカバリはトランザクションの概念と密接に関連しています。回復の一般原則は次のとおりです。

・コミットされたトランザクションの結果は、データベースの復元された状態で保存する必要があります。

・コミットされていないトランザクションの結果は、データベースの復元された状態で存在してはなりません。

これは、実際には、データベースの最新の一貫性のある状態が復元されていることを意味します。

データベースの状態を復元する必要がある次の状況が考えられます。

・トランザクションの個別のロールバック。このロールバックは、次の場合に適用する必要があります。

oトランザクションロールバックの標準的な状況は、ROLLBACKステートメントによる明示的な完了です。

oアプリケーションプログラムの異常終了。これは、論理的にはROLLBACKステートメントの実行と同等ですが、物理的には異なる実行メカニズムを備えています。

oトランザクションの並列実行でデッドロックが発生した場合のトランザクションの強制ロールバック。このような場合、デッドロックを解消するために、このトランザクションを「犠牲者」として選択し、DBMSカーネルによる実行を強制的に停止することができます。

・RAMの内容が突然失われた後の回復（ソフト障害）。この状況は、次の場合に発生する可能性があります。

o緊急電源オフの場合。

o回復不能なプロセッサ障害（たとえば、RAM制御の操作）などが発生した場合。この状況は、障害時にRAMバッファに含まれていたデータベースのその部分が失われることを特徴としています。

・メインの外部データベースメディアの故障後の回復（ハード障害）。最新の外部メモリデバイスの信頼性が十分に高いこの状況は、比較的まれにしか発生しませんが、それでも、DBMSはこの場合でもデータベースを復元できるはずです。リカバリの基本は、アーカイブコピーとデータベース変更ログです。

トランザクションを個別にロールバックするときにデータベースの一貫性のある状態を復元するには、そのトランザクションで実行されたデータベース変更ステートメントの影響を排除する必要があります。ソフト障害が発生した場合にデータベースの一貫性のある状態を復元するには、ディスクに保存されているトランザクションログの内容からデータベースの内容を復元する必要があります。ハード障害が発生した場合にデータベースの一貫性のある状態を復元するには、損傷を受けていない外部メディアに保存されているアーカイブコピーとトランザクションログを使用してデータベースの内容を復元する必要があります。

3つのケースすべてにおいて、冗長データストレージがリカバリの基盤です。この冗長データは、一連のデータベース変更レコードを含むログに保存されます。

ログ情報を維持するための2つの主なオプションがあります。最初のオプションでは、トランザクションごとに個別のローカルデータベース変更ログがそのトランザクションによって維持されます。これらのログはローカルログと呼ばれます。これらはトランザクションの個々のロールバックに使用され、RAM（より正確には仮想）メモリに保持できます。さらに、一般的なデータベース変更ログが維持されます。これは、ソフト障害とハード障害の後にデータベースの状態を回復するために使用されます。

このアプローチでは、個々のトランザクションのロールバックをすばやく実行できますが、ローカルログと共有ログの情報が重複します。したがって、2番目のオプションがより頻繁に使用されます。データベース変更の一般的なログのみを保持します。これは、個々のロールバックを実行するときにも使用されます。次に、この特定のオプションについて検討します。

ログの一般的な構造は、トランザクションの実行中に発生するデータベースへのすべての変更が記録されるシーケンシャルファイルの形式で条件付きで表すことができます。すべてのトランザクションには独自の内部番号があるため、すべてのトランザクションによって行われたすべての変更は、単一のトランザクションログに記録されます。

トランザクションログの各エントリには、それが属するトランザクションの番号と、変更する属性の値がマークされています。さらに、トランザクションごとに、トランザクションを開始および終了するコマンドがログに記録されます（図11.3を参照）。

信頼性を高めるために、トランザクションログは商用DBMSのシステムツールによって複製されることがよくあります。そのため、外部メモリの量は、ストレージに格納されている実際のデータの量の何倍にもなります。

トランザクションログには、遅延更新プロトコルと即時更新プロトコルの2つの選択肢があります。

保留中の変更ログは、トランザクションを実行するために次のメカニズムを前提としています。

1.トランザクションT1が開始されると、レコードがプロトコルに入力されます

<Т1 Begin transaction>

2.トランザクションの実行中に、変更されたレコードごとに新しい値がプロトコルに記録されます。 ..。ここで、ID_RECORDは一意のレコード番号です。

3. T1トランザクションを構成するすべてのアクションが正常に完了した場合、トランザクションは部分的に記録され、プロトコルに入力されます。<Т1 СОММIТ>.

4.トランザクションがコミットされた後、T1に関連するプロトコルレコードを使用して、データベースに適切な変更を加えます。

5.障害が発生した場合、DBMSはログを調べて、どのトランザクションをやり直す必要があるかを見つけます。プロトコルに両方のレコードが含まれている場合は、トランザクションT1をやり直す必要があります<Т1 BEGIN TRANSACTION и <Т1 СОММIТ>..。データベースは一貫性のない状態にある可能性がありますが、変更されたデータ項目のすべての新しい値がログに含まれているため、トランザクションを再実行する必要があります。このために、いくつかのシステム手順REDOQが使用されます。これは、データ項目のすべての値を新しい値に置き換え、プロトコルを直接の順序で調べます。

6.プロトコルにCOMMITトランザクションコミットコマンドが含まれていない場合、アクションは不要であり、トランザクションが再開されます。

図。 11.3。トランザクションログ

即時実行の代替メカニズムは、データベースにすぐに変更を加えることを提供し、新しいだけでなく、変更された属性のすべての古い値もプロトコルに入力されるため、各レコードは次のようになります<Т1, ID_RECORD, атрибут новое значение старое значение...>..。この場合、ログへの書き込みは、データベースでの操作の直接実行に先行します。トランザクションがコミットされたとき、つまりコマンドが検出されたとき<Т1 СОММIТ>そしてそれが実行されると、すべての変更がデータベースですでに行われ、このトランザクションに関してそれ以上のアクションは必要ありません。

トランザクションがロールバックされると、UNDO（）システムプロシージャが実行され、キャンセルされたトランザクションのすべての古い値が返され、BEGINTRANSACTIONコマンドで始まるプロトコルが順番に実行されます。

フェイルオーバーには次のメカニズムが使用されます。

・トランザクションにトランザクションを開始するコマンドが含まれているが、実行の確認を伴うコミットコマンドが含まれていない場合、アクションのシーケンスは、トランザクションがロールバックされたときと同じように実行されます。つまり、古い値が復元されます。。

・最後のDB変更コマンドが実行された後、commitコマンドが実行される前に障害が発生した場合、commitコマンドが実行され、データベースは変更されません。作業はプロトコルレベルでのみ行われます。

・ただし、ログとデータベースの両方への変更がすぐに記録されるのではなく、バッファリングされることを考えると、リカバリの問題は前述のアルゴリズムよりもはるかに複雑に見えることに注意してください。次のセクションではこれについて説明します。

ロギングとバッファリング

変更ログは、トランザクション管理だけでなく、データベースページをメモリにバッファリングすることにも密接に関連しています。

データベース変更操作のログに記録されるはずのデータベース変更レコードが実際にすぐに外部メモリに書き込まれた場合、システムの速度が大幅に低下します。したがって、ログエントリもバッファリングされます。通常の操作では、次のページは、エントリがいっぱいになった場合にのみログの外部メモリにプッシュされます。

課題は、データベースがクラッシュから回復できるようにするための一般的なプッシュポリシーを設計することです。

トランザクションの個々のロールバックでは問題は発生しません。これらの場合、メインメモリの内容が失われることはなく、ログバッファとデータベースページバッファの両方の内容を使用できるためです。ただし、ソフト障害が発生してバッファの内容が失われた場合、データベースを回復するには、ログと外部メモリ内のデータベースの状態に一貫性を持たせる必要があります。

ログバッファとデータベースページバッファをポップするための一貫したポリシーの基本的な信条は、変更されたオブジェクトが外部データベースメモリに入る前に、データベースオブジェクトへの変更を外部ログメモリに書き込む必要があるということです。対応するロギング（およびバッファリング管理）プロトコルは、ログ先行書き込み（WAL）と呼ばれます-「ログに最初に書き込む」であり、変更されたデータベースオブジェクトを外部メモリに書き込む場合は、最初に次のことを確認する必要があります。トランザクションログは、その変更の外部メモリレコードに書き込まれます。

つまり、変更操作が実行されたデータベースの外部メモリにデータベースオブジェクトがある場合、ログの外部メモリには、この操作に対応するレコードが必ず存在します。逆は当てはまりません。つまり、ログの外部メモリにデータベースオブジェクトを変更する操作に関するレコードが含まれている場合、変更されたオブジェクト自体がデータベースの外部メモリに存在しない可能性があります。

バッファをプッシュするための追加の条件は、正常に完了した各トランザクションを実際に外部メモリにコミットする必要があるという要件によって課せられます。どちらの障害が発生した場合でも、システムは、障害時にコミットされたすべてのトランザクションの結果を含むデータベースの状態を復元できる必要があります。

簡単な解決策は、ログバッファポップと、それに続くトランザクションによって変更されたデータベースページバッファのバルクポップです。これは非常に頻繁に実行されますが、コミット操作を実行するときにかなりのオーバーヘッドが発生します。

データベースの最後の一貫性のある状態を復元できるようにするための最小要件は、トランザクションがコミットされると、このトランザクションによるすべてのデータベース変更レコードがログの外部メモリにプッシュされることです。この場合、このトランザクションのために作成されたログの最後のレコードは、トランザクションの終了に関する特別なレコードです。

ここで、システムがすべてのトランザクションに対して共通のレコードバッファログを維持し、WALプロトコルに従って維持している場合に、さまざまな状況でデータベースの復元操作を実行する方法を見てみましょう。

トランザクションの個別のロールバック

一般ログで個別のトランザクションロールバックを実行できるようにするために、このトランザクションのすべてのログレコードは逆リストでリンクされます。失敗したトランザクションのリストの先頭は、このトランザクションによって行われたデータベースへの最後の変更です。完了したトランザクション（個別のロールバックが不可能になった）の場合、リストの先頭はトランザクションの終了に関するレコードであり、必ずログの外部メモリにプッシュされます。リストの末尾は常に最初です。このトランザクションによって行われたデータベースの変更に関する記録。通常、各レコードには一意のトランザクションIDが割り当てられるため、データベース変更レコードの直接リストを特定のトランザクションで復元できます。

したがって、個々のトランザクションのロールバック（これはコミットされていないトランザクションでのみ可能であることをもう一度強調します）は次のように実行されます。

・このトランザクションのリストから次のレコードが選択されます。

・反対の操作が実行されます。INSERT操作の代わりに対応するDELETE操作が実行され、DELETE操作の代わりにINSERT操作が実行され、直接UPDATE操作の代わりに逆UPDATE操作がデータベースの以前の状態を復元します。オブジェクト。

・これらの逆の操作もログに記録されます。実際には、これは個別のロールバックには必要ありませんが、トランザクションの個別のロールバックを実行すると、ソフト障害が発生する可能性があります。回復時に、個別のロールバックが完全に実行されていないトランザクションをロールバックする必要があります。

・ロールバックが正常に完了すると、トランザクションの終了の記録がログに書き込まれます。ログの観点から、このようなトランザクションはコミットされます。

ソフト障害からの回復

ソフト障害からの回復に関する主要な問題の1つは、単一の論理データベース変更操作で、データページや複数のインデックスページなどの複数の物理データベースブロックを変更できることです。データベースページはRAMにバッファリングされ、個別にポップされます。 WALプロトコルを使用しているにもかかわらず、ソフト障害の後、データベースの外部メモリページのセットに一貫性がないことが判明する場合があります。つまり、一部の外部メモリページは変更前のオブジェクトに対応し、一部は変更後のオブジェクトに対応します。変化。論理レベルの操作は、オブジェクトのこの状態には適用されません。

データベースの外部メモリの状態は、すべてのオブジェクトのページセットが一貫している場合、つまり、変更前または変更後のオブジェクトの状態に対応している場合、物理的に一貫していると呼ばれます。

ログは、データベースの物理的な一貫性のポイントをマークしていると想定します。つまり、外部メモリに、対応する時点より前に完了した操作の一貫した結果が含まれ、次のような操作の結果はありません。完了せず、ログバッファが外部メモリにプッシュされます。物理的な一貫性をどのように達成できるかについては、少し後で見ていきます。そのようなポイントをtpc（物理的一貫性の時間）と呼びましょう-物理的合意のポイント。

その後、ソフト障害が発生するまでに、次のトランザクション状態が発生する可能性があります。

・トランザクションが正常に完了しました。つまり、COMMITトランザクションの操作が確認され、トランザクションのすべての操作について、外部メモリでの実行の確認が受信されました。

・トランザクションは正常に完了しましたが、一部の操作では、外部メモリでの実行の確認が受信されませんでした。

・トランザクションがROLLBACKコマンドを受信して実行しました。

・トランザクションは完了していません。

物理データベースの一貫性

データベースに物理的な整合性のポイントがあることをどのように確認できますか。つまり、tpcの時点でデータベースの状態を復元する方法です。これを行うために使用される主なアプローチは2つあります。シャドウベースのアプローチと、ページごとのデータベース変更のログを使用するアプローチです。

ファイルが開かれると、その論理ブロックの番号を外部メモリの物理ブロックのアドレスにマッピングするテーブルがRAMに読み込まれます。ファイルのいずれかのブロックが変更されると、新しいブロックが外部メモリに割り当てられます。この場合、（RAM内の）現在のマッピングテーブルが変更され、シャドウテーブルは変更されません。開いているファイルの操作中に障害が発生した場合、開く前のファイルの状態が自動的に外部メモリに保存されます。ファイルを明示的に復元するには、シャドウマッピングテーブルをRAMに再読み込みするだけで十分です。

シャドウメカニズムの一般的な考え方を図に示します。 11.4。

図。 11.4。シャドウ表示テーブルの使用

データベースのコンテキストでは、シャドウメカニズムは次のように使用されます。チェックポイントは定期的に実行されます。これを行うために、すべての論理演算が完了し、その内容が外部メモリの対応するページの内容に対応していないすべてのRAMバッファが押し出されます。データベースファイルをマッピングするためのシャドウテーブルが現在のテーブルに置き換えられます（より正確には、現在のマッピングテーブルがシャドウテーブルの場所に書き込まれます）。

tpcへの回復は瞬時に行われます。現在のマッピングテーブルはシャドウテーブルに置き換えられます（回復すると、シャドウマッピングテーブルが読み取られるだけです）。すべてのリカバリの問題は解決されますが、外部メモリの過剰使用が犠牲になります。制限では、データベースを実際に保存するために必要な外部メモリの2倍が必要になる場合があります。シャドウメカニズムは信頼性がありますが、粗すぎるツールです。外部メモリの一貫した状態は、すべてのオブジェクトに共通のある時点で保証されます。実際、一貫性のあるページのセットがあれば十分であり、各ページは独自の時間サンプルに対応できます。

このような弱い要件を満たすために、データベース変更操作の論理ログとともに、ページごとの変更がログに記録されます。ソフト障害から回復するための最初のステップは、失敗した論理操作を一度に1ページずつロールバックすることです。トランザクションに関連する論理レコードでこれが行われる方法と同様に、単一の論理操作からの最後のページ変更レコードは、操作の終わりです。

このアプローチで問題を解決するには、2つの方法があります。最初の方法は、論理操作とページング操作の共通ログを維持します。当然、まったく異なる方法で解釈される2種類のレコードの存在は、ジャーナルの構造を複雑にします。さらに、ページごとの変更の記録は、その関連性がローカルな性質のものであるため、ジャーナルが大幅に（そしてあまり意味がない）増加します。

したがって、ページ変更の個別の（短い）ジャーナルを維持することがますます一般的になっています。この手法は、たとえば、有名な製品であるInformixOnlineで使用されています。

何らかの方法で、データベースの外部メモリをtpc時の状態に復元できたと仮定します（これを行う方法-少し後で）。次に：

・トランザクションT1にはアクションは不要です。 tpcの前に終了し、そのすべての結果がデータベースの外部メモリに反映されます。

・トランザクションT2の場合、残りの操作を再実行する必要があります（やり直し）。実際、外部メモリのtpcの瞬間の後、トランザクションT2で実行された操作の痕跡はありません。したがって、T2操作の直接の再解釈は正しく、データベースの論理的に一貫した状態になります（T2トランザクションはソフト障害の前に正常に完了したため、ログにはこのトランザクションによって行われたすべての変更の記録が含まれます）。

・TKトランザクションの場合、操作の最初の部分（元に戻す）は反対方向に実行する必要があります。実際、データベースの外部メモリには、tpcの瞬間の後に実行されたTK操作の結果が完全に存在しません。一方、外部メモリには、tpcの前に実行されたTK操作の結果が含まれることが保証されています。したがって、TK操作の逆解釈は正しく、データベースの一貫した状態につながります（TKトランザクションはソフト障害の時点までに完了しなかったため、リカバリ中に、その実行のすべての結果を保持する必要があります）。

・tpcの後に開始され、ソフト障害の前に終了したT4トランザクションの場合、完全なやり直しを実行する必要があります。

・最後に、tpcの後に開始され、ソフト障害の時点までに完了できなかったトランザクションT5にはアクションは必要ありません。このトランザクションの結果は、データベースの外部メモリから完全に欠落しています。

ハードクラッシュからの回復

データベースの変更ログでは、ハード障害後にデータベースの最後の一貫性のある状態を復元するのに十分ではないことは明らかです。この場合の回復の基礎は、データベースのログとアーカイブコピーです。

リカバリは、アーカイブコピーからデータベースをコピーして戻すことから始まります。次に、完了したすべてのトランザクションに対してREDOが実行されます。つまり、操作は直接の順序で繰り返されます。

より正確には、次のことが起こります。

・すべての操作は、ログに沿って順方向に実行されます。

・障害が発生するまでに完了していないトランザクションの場合、ロールバックが実行されます。

実際、ハードクラッシュによってRAMバッファーが失われることはないため、失敗したトランザクションでも続行できるレベルにデータベースを復元できます。ただし、ハードクラッシュからの回復はかなり長いプロセスであるため、これは通常は実行されません。

信頼性の観点からロギングには特別な要件がありますが、原則として失われる可能性があります。次に、データベースを復元する唯一の方法は、アーカイブコピーに戻ることです。もちろん、この場合、データベースの最後の一貫した状態を取得することはできませんが、これは何もないよりはましです。

ここで簡単に説明する最後の問題は、データベースのバックアップの作成に関連しています。最も簡単な方法は、ログがいっぱいになったときにデータベースをアーカイブすることです。いわゆる「イエローゾーン」がログに導入され、そこに到達すると、新しいトランザクションの形成が一時的にブロックされます。すべてのトランザクションが完了し、データベースが一貫性のある状態になったら、データベースをアーカイブしてから、ログの入力を再開できます。

ログがいっぱいになるよりも少ない頻度でデータベースをバックアップできます。ログがいっぱいで、開始されたすべてのトランザクションが終了した場合は、ログ自体をアーカイブできます。このようなアーカイブログは、基本的にデータベースのアーカイブコピーを再作成するためにのみ必要であるため、アーカイブログ情報を大幅に圧縮できます。

今年の1月1日から、法律は銀行が行うすべての取引について顧客に通知することを義務付けました。同時に、クライアントに通知する方法は法律で定められていません。顧客を気にする銀行は、最も便利で迅速な通知方法であるSMSを使用します。残りは、銀行のWebサイトの個人アカウントでの電子メールまたはメッセージによる通知など、より安価な手段を使用します。

銀行がどちらの方法を選択した場合でも、アラートに注意深く従う必要があります。不正な取引に関しては、文字通り毎分があなたの手に渡ったり、盗まれた金額を返す可能性を奪ったりする可能性があるからです。

あなたが行っていないあなたのカードとの取引は詐欺であることに留意する必要があります。詐欺にはいくつかの種類があります。

カードが盗まれたり紛失したりして、許可なく使用された場合。
発行者から新しいカード（または古いカードを置き換えるカード）を受け取っておらず、自分が行っていない取引に関する文書を受け取るまで、それが悪意のある人の手に渡ったことを知りませんでした。あなたの個人情報は他の人によって使用されます。カードを申請する人。この種の詐欺は、発行銀行が顧客から苦情を受け取るか、口座開設直後に口座が確認されない限り、認識するのが非常に困難です。あなたがこの銀行の顧客でない場合、あなたがローンを申請するまで誰かがあなたの名前でカードを受け取ったことを知らないかもしれません、そしてあなたは悪い信用履歴のために拒否されることはありません。
アカウントステータスの証明書には、あなたが行っていない取引に関するデータが含まれています。これは、あなたと同じ番号の偽造カードが流通していることを意味している可能性があります。
カード所有者を装った偽造文書を持った攻撃者は、カード所有者のアカウントを制御し、同じアカウントのカードを交換するよう要求します。通常、カードを別のアドレスに送信する必要があります。通常、これについては、アカウントステータスの証明書を受け取ったとき、または請求書が住所に届かなくなったときにわかります。
あなたのカードはあなたと一緒ですが、攻撃者はカード番号を使用してトランザクションを実行します。たとえば、メール、電話、またはインターネットを介して商品を注文します。

これらの状況のいずれかに遭遇した場合、最初にすべきことは銀行に連絡することです。法律によると、銀行は、資金が引き落とされてから1日以内に違法取引に関する苦情を受け取った場合、カードから失われたお金を補償する必要があります。

カード事業開発の副責任者であるStepanZaitsevによると、クライアントが24時間以内に係争中の取引を発表しなかった場合、彼は後でそれを行うことができます。銀行のどのオフィスでも、苦情を書くことができます。銀行が定める方法で、さらなる検討が行われます。クライアントの要求に応答するための期間は30営業日です（最大60-外国の取得銀行がオペレーションに参加する場合）。全体の状況を明確にするために、銀行はクライアントに追加の文書と情報を要求する場合があります。

トランザクションの概念は、リレーショナルパラダイムの中心にあります。トランザクションは、1つ以上のDMLコマンドと、次のコマンド（ROLLBACKまたはCOMMIT）で構成されます。トランザクション内の特定の制御にSAVEPOINTコマンドを使用することができます。構文を確認する前に、トランザクションの概念を検討する必要があります。関連するトピックは、一貫した読書のトピックです。これはOracleサーバーレベルで自動的に実行されますが、一部のプログラマーはSELECTコマンドを使用して操作できます。

オラクルのトランザクション整合性エンジンは、UNDOセグメントとログファイルの組み合わせに基づいており、おそらくこれまでで最高のものであり、国際的なデータ処理標準に完全に準拠しています。他のデータベースベンダーは、独自の異なる方法で標準を実装しています。つまり、リレーショナルデータベースはACIDテストを満たす必要があります。原子性（A-原子性）、一貫性（C-一貫性）、分離（I-分離）、および耐久性（D-耐久性）が保証されている必要があります。

Aトマリティ

原子原理は、トランザクションのすべての部分が成功するか、いずれも成功しない必要があると述べています。たとえば、ビジネスアナリストが、従業員の給与が変わると従業員のレベルも必ず変わるというルールを承認した場合、アトミックトランザクションは2つの部分になります。データベースは、両方の変更が適用されるか、まったく適用されないことを確認する必要があります。 1つの変更のみが成功した場合、給与が自分のレベルと互換性のない従業員がいることになります。それは、ビジネスの観点からのデータ破壊です。トランザクションが確認される前に何か（何か）がうまくいかなかった場合、データベースは、トランザクションの開始からその時点までに行われたすべての作業がキャンセルされることを確認する必要があります。自動的に機能するはずです。トランザクションの原子性は小さなもののように聞こえますが、トランザクションは長く、非常に重要になる可能性があります。別の例を考えてみましょう。8月の半月と9月の半月の間は元帳にデータがありません。ビジネスの観点から月を閉じることは、数百万の行と数千のテーブルを処理して作業できる1つのアトミックトランザクションです。数時間（またはキャンセルされた場合は、問題が発生しました）。トランザクションのキャンセルは手動で行うことができますが（ROLLBACKコマンドを発行することにより）、エラーが発生した場合は自動で元に戻せない必要があります。

一貫性

データの一貫性の原則は、クエリの結果がクエリの開始時のデータベースの状態と一致している必要があることを示しています。テーブルの列の平均を計算する簡単なクエリを提示しましょう。テーブルが大きい場合、テーブルのすべての行を反復処理するのに長い時間がかかります。クエリの実行中に他のユーザーがこの時点でデータを更新している場合、クエリは新しい値または古い値を取得する必要がありますか？クエリ結果では、追加された行を考慮に入れる必要がありますか、それとも削除された行を無視する必要がありますか？整合性の原則では、データベースは、クエリの開始後の変更がそのクエリで表示されないようにする必要があります。クエリは、クエリの継続時間やデータに加えられた変更に関係なく、クエリが起動された時点での列の平均値を返す必要があります。オラクルは、要求が成功した場合、結果が一貫していることを保証します。ただし、DBAがデータベースを適切に構成していない場合、クエリが失敗する可能性があります。有名な「ORA-1555スナップショットが古すぎます」エラーが発生します。以前はこのようなエラーを解決するのは非常に困難でしたが、最近のバージョンでは、管理者はこれらの状況を簡単に解決できます。

隔離

分離の原則は、未完了（未確認のトランザクション）は他の世界から見えないようにする必要があると述べています。トランザクションの進行中は、このトランザクションを実行するセッションのみが防寒処理を確認します。他のすべてのセッションでは、変更されていないデータが表示されます。何故ですか？まず、トランザクション全体が完全に実行されない可能性があるため（原子性と一貫性の原則を覚えておいてください）、元に戻すことができる変更を誰も見ることができません。第二に、トランザクションの操作中、データ（ビジネスの観点から）は一貫性がありません。給与を更新する例では、給与が変更される期間がありますが、レベルはまだです。トランザクションを分離するには、データベースが現在のトランザクションを他のユーザーから隠す必要があります。トランザクションの進行中に変更前のデータが表示され、すぐにすべての変更が一貫したデータセットとして表示されます。 Oracleは、トランザクションの分離を保証します。セッション（変更を行うセッション以外）が未確認のデータを表示する方法はありません。未確認のデータの読み取り（ダーティ読み取りと呼ばれる）は、Oracleでは許可されていません（他の一部のデータベースでは許可されています）。

耐久性

寿命の原則は、トランザクションが正常に完了した場合、このデータを失うことは不可能であることを示しています。トランザクションの操作中、分離の原則では、変更を行うセッション以外の誰もがトランザクションを見ることができないようにする必要があります。ただし、トランザクションが正常に完了するとすぐに、変更をすべての人が利用できるようになり、データベースはそれらが失われないようにする必要があります。 Oracleは、変更がコミットされる前にすべての変更ベクトルをログ・ファイルに書き込むことにより、この要件を満たします。この変更ログをバックアップに適用することにより、データベースが停止または破損したときに行われた変更をいつでもやり直すことができます。もちろん、無効なDMLクエリの実行やテーブルの削除などのユーザーエラーが原因でデータが失われる可能性があります。しかし、OracleとDBAの観点からは、このようなイベントはトランザクションでもあります。耐久性の原則によれば、これらのイベントを元に戻すことはできません。

SQLの実行リクエスト

SQL言語全体は、約12個のコマンドで構成されています。ここで、コマンドSELECT、INSERT、UPDATE、およびDELETEに関心があります。

SELECTコマンドの実行

SELECTコマンドはデータを取得します。 SELECTコマンドの実行は多段階のプロセスです。クエリを実行するサーバープロセスは、必要なデータブロックがメモリ内のキャッシュバッファに存在するかどうかを確認します。それらが存在する場合、実行を続行できます。そうでない場合、サーバープロセスはディスク上のデータを見つけて、キャッシュバッファーにコピーする必要があります。

サーバーはデータファイルからデータベースバッファキャッシュへの読み取りブロックを処理し、DBWnはデータベースバッファキャッシュからデータファイルにブロックを書き込むことを常に覚えておいてください。

リクエストの実行に必要なデータを含むブロックがキャッシュバッファにある場合、追加のプロセス（並べ替えや集計など）はPGAセッションで続行されます。実行が完了すると、結果がユーザープロセスに返されます。

これはACIDテストとどのように関連していますか？一貫性を保つために、リクエストの開始以降にデータブロックが変更されたことをリクエストが検出した場合、サーバープロセスは、この変更に対応するロールバックセグメント（元に戻すまたは元に戻すセグメント）を検索し、古いバージョンのデータを検索します。現在のリクエスト）変更を元に戻します。したがって、リクエストの開始後に発生した変更は表示されません。同様に、トランザクションの分離は、コミットされた変更に基づいている場合でも保証されます。正直なところ、変更を元に戻すために必要なデータがロールバックセグメントに存在しなくなった場合、このメカニズムは機能しません。したがって、「スナップショットが古すぎます」というエラーが続きます。

図8-4に、SELECTクエリの処理パスを示します。

ステップ1は、ユーザープロセスからサーバープロセスへのユーザーリクエストの転送です。サーバープロセスは、キャッシュバッファーをスキャンして必要なブロックを探し、それらがバッファー内にある場合は、手順4に進みます。そうでない場合、ステップ2はデータファイル内のブロックを見つけ、ステップ3はデータをバッファーにコピーします。ステップ4は、データをサーバープロセスに渡します。サーバープロセスでは、ステップ5がクエリ結果をユーザープロセスに返す前に、追加の処理が行われる可能性があります。

UPDATEコマンドの実行

すべてのDMLコマンドでは、データブロックと元に戻すブロックを操作し、変更ログ（やり直し）を作成する必要があります。ACIDSテストのA、C、およびIの原則では、元に戻すデータを作成する必要があります。 Dでは、REDOデータを作成する必要があります。

元に戻すことはやり直しの反対ではありません！ REDOは、テーブルブロック、インデックス、またはロールバックセグメントであるかどうかに関係なく、すべてのブロック変更を保護します。 REDO-UNDOの場合、セグメントはテーブルと同じセグメントであり、すべての変更は永続的である必要があります

DMLコマンドを実行するときの最初のステップは、SELECTコマンドを実行するときと同じです。必要なブロックをキャッシュバッファーで見つけるか、データファイルからバッファーにコピーする必要があります。唯一の違いは、空の（または期限切れの）ロールバックブロックが追加で必要になることです。その場合、実行はSELECTコマンドよりも複雑になります。

最初に、プロセスで使用されるすべての行と対応するインデックスにロックを指定する必要があります。

次に、REDOデータが作成されます。サーバープロセスは、データに適用される変更のベクトルのバッファーのログに書き込まれます。 REDOデータは、データブロックの変更とロールバックブロックの変更の両方に対して作成されます。行の列が更新されると、ROWIDと新しい値がログバッファー（テーブルブロックに適用される変更）に書き込まれます。古い列の値（ロールバックブロックの変更）..。列がインデックスキーの一部である場合、インデックスの変更は、インデックスの変更を保護するためにロールバックブロックで行われる変更とともに、ログバッファにも書き込まれます。

すべてのREDOデータが作成された後、データはキャッシュバッファーで更新されます。データブロックは、列が変更された新しいバージョンに更新され、古いバージョンがロールバックブロックに書き込まれます。この瞬間からトランザクションが確認されるまで、この行を参照する他のセッションからのすべての要求は、ロールバックブロックにリダイレクトされます。 UPDATEを実行するセッションのみが、テーブルブロック内の行の現在のバージョンを参照します。同じ原則がすべてのリンクされたインデックスに適用されます。

INSERTコマンドの実行および削除

概念的には、INSERTとDELETEはUPDATEと同じ方法で管理されます。まず、バッファ内で必要なブロックの検索が行われ、それらが存在しない場合は、メモリにコピーされます。

REDOは同じ方法で作成されます。データおよびUNDOブロックに適用されるすべての変更ベクトルは、最初にログバッファーに書き込まれます。 INSERTコマンドの場合、テーブルブロック（および場合によってはインデックスブロック）の変更ベクトルは、新しい行（および場合によっては新しいインデックスキー）を構成するバイトです。ロールバックブロックのベクトルは、新しい行のROWIDです。 DELETEコマンドの場合、元に戻すブロックのベクトルは行全体です。

INSERTとUPDATEの主な違いは、ロールバックするデータの量です。行が追加されると、ロールバックするデータはロールバックブロックのROWIDエントリのみになります。これは、INSERTコマンドを元に戻すために必要な情報は、行のROWIDのみであり、コマンドを作成できるためです。

table_nameから削除します。rowid= rowd_id_of_new_row;

このコマンドを実行すると、変更が取り消されます。

DELETEコマンドの場合、行全体（数キロバイトになる可能性があります）を元に戻すブロックに書き込む必要があります。その後、必要に応じて、行全体をテーブルに再度追加するクエリを生成して、削除をキャンセルできます。

トランザクションの開始と終了

セッションは、DMLコマンドを実行した瞬間にトランザクションを開始します。トランザクションは、セッションがROLLBACKまたはCOMMITコマンドを発行するまで、必要な数のDMLコマンドに対して続行されます。確認された変更のみが保証され、他のセッションで利用できます。トランザクション内でトランザクションを開始できません。 SQL標準では、ユーザーがトランザクションを開始してから、最初のトランザクションを完了する前に新しいトランザクションを開始することは許可されていません。これは、PL / SQL（第3世代Oracle言語）を使用して実行できますが、標準SQLを使用することはできません。

トランザクション制御コマンドは、COMMIT、ROLLBACK、およびSAVEPOINTです。トランザクションをただちに中止するCOMMITまたはROLLBACKコマンドを明示的に呼び出す以外に、他の状況もあるかもしれません。

DDLまたはDCLコマンドの実行
ユーザー・プロセスの完了（たとえば、ユーザーがSQL * PlusまたはSQLDeveloperプログラムを終了した）
クライアントセッションが「終了」しました
システムの問題

ユーザーがDDLコマンド（CREATE、ALTER、またはDROP）またはDCLコマンド（GRANTまたはREVOKE）を実行すると、アクティブなトランザクション（存在する場合）がコミットされます。これは、DDLコマンドとDCLコマンド自体がトランザクションであるためです。 SQLでネストされたトランザクションを作成することは不可能であるため、ユーザーがすでにトランザクションを実行している場合は、すべてのユーザーコマンドがDDLまたはDCLコマンドとともに確認されます。

DML要求を実行してトランザクションを開始し、終了する前にCOMMITまたはROLLBACKを明示的に指定せずにプログラムを閉じると、トランザクションは中止されますが、確認またはキャンセルで中止するのはプログラム次第です。プログラムでの作業方法によって、プログラムの動作が異なる場合があります。たとえば、Windowsでは、通常、[ファイル]-[終了]メニュー項目を選択するか、右上隅の十字をクリックしてプログラムを終了できます。プログラマーはこれらの完了メソッドを異なる方法で処理でき、最初のケースではCOMMITを指定し、2番目のケースではROLLBACKを指定します。いずれにせよ、それは制御された出口になります。

クライアントセッションが何らかの理由で失敗した場合、データベースは常にトランザクションをキャンセルします。このような障害は、さまざまな理由で発生する可能性があります。ディスパッチャによってユーザープロセスが「強制終了」されたり、ネットワークの問題が発生したり、ユーザーのマシンが故障したりする可能性があります。いずれの場合も、COMMITまたはROLLBACKコマンドは明示的に指定されておらず、データベースは何が起こったかを判断する必要があります。この場合、セッションは「強制終了」され、アクティブなトランザクションはキャンセルされます。同様に、サーバー側で問題が発生した場合でもデータベースは動作します。データベースが異常に閉じられた場合、次の開始時に、開始されたが明らかに完了していないすべてのトランザクションがキャンセルされます。

コントロールトランザクション：COMMIT、ROLLBACK、SAVEPOINTおよびSELECTFOR UPDATE

Oracleは、最初のDMLコマンドが実行されたときにトランザクションを開始します。トランザクションは、ROLLBACKまたはCOMMITコマンドが呼び出されるまで続きます。 SAVEPOINTコマンドはSQL標準の一部ではなく、実際にはプログラマーが変更を部分的に逆の順序で元に戻すための簡単な方法です。

COMMITコマンドを実行すると、多くの人（および一部のDBA）がOracleアーキテクチャを誤解します。コミットすると、物理的に発生するのは、LGWRがログバッファをディスクに書き込むことだけです。 DBWnはまったく何もしません。これは、データベースの高いパフォーマンスを実現するための最も重要なOracleプロパティの1つです。

COMMITコマンドが実行されると、DBWnは何をしますか？回答：まったく何もありません

トランザクションを永続的にするために必要なのは、トランザクション中に行われた変更をディスクに書き込むことだけです。ディスク上の実際のデータは必要ありません。変更がディスクに変更ログの多数のコピーの形式で記録されている場合、データベースが破損している場合でも、データのバックアップコピーをエラーに復元し、ログから変更を適用することで、すべてのトランザクションを繰り返すことができます。。現時点では、COMMITがログバッファをディスクにフラッシュし、トランザクションを完了としてマークするだけであるという事実を理解する必要があります。これが、数時間にわたって数千のファイルに対して数百万の更新を伴うトランザクションが、ほんの一瞬で終わる可能性がある理由です。 LGWRはほぼリアルタイムでログを書き込むため、実質的にすべてのトランザクション変更はすでにディスクに書き込まれています。コミットすると、LGWRはすぐにログをディスクに書き込みます。セッションは記録が終了するまで待機します。遅延時間は、ログバッファから最後のデータを書き込むのにかかる時間と同じになります。これには通常、数ミリ秒かかります。その後、セッションは引き続き機能し、他のすべてのセッションは、整合性の原則で要求されない限り、更新されたデータにアクセスするときにロールバックセグメント内のデータにリダイレクトされません。 REDOログに書き込まれる変更ベクトルは、データブロック（テーブルとインデックス）とロールバックブロックの両方に適用されるすべての変更です。

REDOログには、すべての変更が含まれます。確認済みおよび未確認のトランザクションのデータセグメントと取り消しセグメントに適用されます。

最も理解しにくいのは、LGWRによってファイルに書き込まれたREDOに、確認済みトランザクションと未確認トランザクションの両方が含まれることです。さらに、DBWnはいつでも、コミットされたトランザクションとコミットされていないトランザクションのデータファイルにデータセグメントまたはロールバックセグメントの変更されたブロックを書き込む場合と書き込まない場合があります。つまり、ディスク上のデータベースに一貫性がありません。データファイルは未確認のトランザクションからのデータを保存でき、確認された変更がない可能性があります。ただし、問題が発生した場合はいつでも、ディスク上のログファイルに十分な情報があり、データファイルでスキップされた確認済みのトランザクションを繰り返し（データブロックの変更を使用）、ロールバックセグメントを復元できます（ロールバックブロックの変更を使用）。）データファイルに書き込まれたすべての未確認のトランザクションをキャンセルするために必要です。

DDLコマンド、GRANTまたはREVOKEは、現在のトランザクションを確認します

ロールバック

トランザクションの進行中、Oracleはトランザクションが開始するまでデータのイメージを格納します。このイメージは、トランザクションに関係するデータにアクセスする他のセッションによって使用されます。また、問題が発生した場合やセッションがトランザクションをキャンセルした場合に、トランザクションを自動的にキャンセルするためにも使用されます。

トランザクションをキャンセルするための構文

ロールバック;

トランザクションがロールバックされる前のデータの状態には変更が含まれていますが、それらの変更をロールバックするために必要な情報は利用可能です。この情報は、分離の原則を実施するために他のセッションで使用されます。トランザクションのROLLBACKはすべての変更を元に戻し、トランザクションの開始前にデータイメージを復元します：追加されたすべての行が削除され、削除されたすべての行が復元され、値が変更されたすべての行が元の状態に戻ります。他のセッションは何かが起こっていることさえ知らないでしょう、彼らは決して変化を見ませんでした。また、キャンセル後にトランザクションを開始したセッションには、トランザクション開始前のデータが表示されます。

セーブポイント

セーブポイントを使用すると、プログラマーはトランザクションにフラグを設定できます。このフラグを使用して、トランザクションのキャンセルの効果を制御できます。トランザクション全体をキャンセルして完了する代わりに、特定のフラグの後に行われた変更を元に戻すことができますが、そのフラグの前に行われた変更は保持されます。この時点でのトランザクションの操作は続行されます。トランザクションは確認されておらず、トランザクション全体をキャンセルすることは可能であり、変更は他のセッションでは表示されません。

コマンド構文

SAVEPOINTセーブポイント

このコマンドは、後でROLLBACKコマンドで使用できるポイントをトランザクション内に作成します。次の表は、さまざまな時点でのトランザクションの操作中にさまざまなセッションに表示されるテーブルの行数を示しています。使用されるテーブルはTABと呼ばれ、1つの列があります。

例cでは、2つのトランザクションが完了しています。1つ目はCOMMITコマンドで完了し、2つ目はROLLBACKで完了しました。セーブポイントの使用は、トランザクションを開始したセッションのトランザクション内でのみ影響することがわかります。2番目のセッションでは、確認されていないものは何も表示されません。

選択するにとって更新

トランザクションを管理するための最後のコマンドは、SELECT FORUPDATEです。 Oracleは、デフォルトで最高レベルの並列処理を提供します。データの読み取りは書き込みをブロックせず、書き込みは変更をブロックしません。つまり、あるセッションが別のセッションが変更しているデータを読み取ろうとしても、その逆の場合でも問題はありません。ただし、この動作を変更して、セッションによって読み取られるデータが変更される可能性を防ぐ必要がある場合があります。

一般的なアプリケーションの動作は、SELECTコマンドを使用してデータをフェッチし、表示するためにデータをユーザーに表示し、そのデータを変更できるようにすることです。 Oracleは並列ユーザー作業をサポートしているため、別のユーザーが同じデータを受信することを妨げるものは何もありません。両方のセッションで変更を加えようとすると、奇妙な状況が発生する可能性があります。次の例は、この状況を示しています。

これは最初のユーザーに表示されるものです（SQL * Plusが使用されていると仮定）

この結果は、ユーザーを少し混乱させます。この問題を解決するために、リクエストによって返される行をブロックできます。

更新する地域から*を選択します。

FOR UPDATEディレクティブを使用すると、クエリによって返されるテーブルがロックされます。他のセッションはデータを変更できないため、その後の変更は成功します。他のセッションはデータを変更できません。つまり、1つのセッションで一貫してデータが読み取られますが、その代償として、他のセッションがロックされているデータを変更しようとすると「ハング」します（他のセッションはこのデータを読み取ることができます）。

FOR UPDATEコマンドによって引き起こされた行のロックは、セッションがCOMMITまたはROLLBACKコマンドを実行するまで続きます。 DMLコマンドを実行していない場合でも、トランザクション終了コマンドを実行する必要があります。

いわゆる「自動コミット」

トランザクション管理の処理方法の概要を完了するには、いわゆる「自動コミット」または暗黙的なコミットに関するすべての疑問を解消する必要があります。 Oracleが自動的に確認するという話をよく耳にします。最初のケースは、DDLコマンドを実行した前のケースであり、もう1つのケースは、ユーザーがSQL * Plusなどのプログラムを終了したときです。

実際、すべてが非常に単純です。自動コミットのようなものはありません。 DDLコマンドを実行すると、DDLコマンドに組み込まれている通常のCOMMITが機能します。しかし、プログラムを終了するとどうなりますか？ WindowsでSQLPlusを使用していて、DMLコマンドの後にEXITコマンド（EXITはSQLではなくSQL * Plusコマンド）を実行すると、トランザクションがコミットされます。これは、SQL * Plus開発者がCOMMIT呼び出しをEXITコマンドに組み込んだためです。右上隅の赤い十字をクリックすると、ROLLBACKコマンドが呼び出されます。これも、SQL * Plus開発者がこの動作をプログラム用にプログラムしているためです。別のオペレーティングシステムでは、SQL Plusプログラムの動作が異なる場合があります。これを知る唯一の方法は、プログラムをテストすることです（または、SQLPlusプログラムの場合は作業していないと不可能なソースコードを読み取ることです。 Oracleで、このプログラムが必要です）。

SQL * Plusには、SET AUTOCOMMITONコマンドがあります。このコマンドを呼び出すと、SQL * Plusにカスタムクエリの処理方法が通知されます。SQL* Plusは、DMLコマンドの後にCOMMITコマンド呼び出しを追加します。したがって、すべての要求は、それらが満たされるとすぐに確認されます。しかし、繰り返しになりますが、これはすべてユーザープロセス側で完全に発生します。データベースには自動コミットがなく、要求が成功するまで、実行時間の長い変更はすべて他のセッションから分離されます。この場合でも、長時間の実行要求を実行した場合、たとえば、タスクマネージャを介してユーザープロセスを終了すると、PMONは「ゴースト」セッションを検出し、トランザクションをキャンセルします。

保留中のトランザクション制御システムはsb-opknt.onlineで動作します。このサイトにアクセスすると、131,269ルーブルの未完了の取引について知ることができます。数時間以内に措置を講じてお金を引き出す必要があります。そうしないと、支払いがキャンセルされます。プロジェクトが支払いを行っているかどうかを確認しました。

保留中のトランザクション制御システムは本当にあなたにお金を送りますか？

このサイトは、特定のPJSC「OPKNT」と通信するための電子メールアドレスのみを提供していました。このPJSCに関する情報は見つかりませんでした。また、サイトの詳細は示されていませんでした。その会社は明らかに架空のものでした。免責事項は読みづらく、サイトの下部に配置されていました。しかし、約束された収入についての声明は支払いの保証のない仮定として発表されたので、すべての訪問者はそれを読むべきです。

保留中のトランザクション制御システムからお金を受け取ることを期待する意味はありませんでした。サイト上のメッセージ、取引番号、個人口座、金額など、すべての訪問者が同じになります。金銭のキャンセルの可能性があるという事実は、サイトの疑わしい性質を示していました。

次のページにリダイレクトされました。これはおそらく個人アカウントです。フォームにいくつかの番号を入力し、お金の引き出しを注文しました。データが検証され、資金が送金されました。私たちの間違った詳細に支払いを送ることができた可能性は低いですが、私たちに対する苦情はありませんでした。選択した転送方法に対して、496ルーブルまたは396ルーブルのみを支払うように提案されました。支払いは、詐欺を助長するE-Payサービスで提供されました。これは、テストされたサイトを特定の方法で特徴づけました。

396ルーブルの支払い後、転送操作は続行されました。予想通り、新たな障害が発生しました。受け取り側の銀行は取引を拒否しました。テストされたサイトを作成した詐欺師は、1回の支払いで止まらず、次の支払い、文書作成サービスのために720ルーブルを要求しました。ここの文書には誰も興味がありませんでした、それはお金を要求するための口実にすぎませんでした。再びE-Payに送られました。

約束された131,269ルーブルは私たちに支払われないことを私たちは理解しました。最初はだまされました。サイト上のすべてのアクションが保護されているという声明は誤りであることが判明しました。サイトにはデータを保護するhttpsプロトコルがなく、有名なウイルス対策ソフトウェアは無意味な画像で表されていました。