REDOログの原理と役割

REDOログは、コミットされたトランザクションが失われないようにするためにOracleによって確立されたメカニズムです。実際、REDO LOGの存在は2つのシナリオに対して用意されています。1つはインスタンス回復（INSTANCE RECOVERY）、もう1つはMEDIA RECOVERYです。インスタンス回復の目的は、データベースに障害が発生したときにBUFFER CACHE内のデータが失われないようにし、データベースの不整合を引き起こさないようにすることです。メディアリカバリの目的は、データファイルに障害が発生したときにデータをリカバリすることです。これら2つのリカバリに使用されるメカニズムは似ていますが、2つのタイプのリカバリも非常に異なっています。これは多くのDBAによく混乱しています。

REDO LOGデータはTHREADに従って編成されていますシングルインスタンスシステムの場合、THREADは1つだけですRACシステムの場合、複数のTHREADがある場合があります各データベースインスタンスには別々のREDOのセットがあります。 LOGファイルには個別のLOG BUFFERがあり、インスタンスの変更は独立してTHREAD REDO LOGファイルに記録されます。

メディアリカバリおよびインスタンスリカバリの場合、最初のステップはREDO LOGの情報をロールフォワードすることですロールフォワードを実行するときは、REDO LOGファイルに記録されているデータベース変更ベクトルを渡します（後述）。データベース変更ベクトルCVを詳細に紹介し、SCNの比較に従って関連するデータファイルに送信して、データファイルの状態が前方にスクロールされるようにします。 UNDO表領域の変更もREDO LOGに記録されるため、UNDO表領域に関連するデータファイルもロールフォワードされます。現在使用可能なREDO LOGまたはアーカイブログがロールされると、すべてのデータベース回復の局面が完了します。現時点では、データベースには記録されたすべての変更が含まれており、そのうちのいくつかはコミットされ、いくつかはまだ送信されていません。 UNDO表領域の最新の状態では、コミットされていないトランザクションもいくつかあります。

データベースが次にやるべきことはトランザクションレベルの処理です。データベースの一貫性を保証するためにまだコミットされていないトランザクションをロールバックします。

シングルインスタンスシステムの場合、インスタンスの回復は通常、データベースインスタンスの異常終了後にデータベースが再起動されたとき、またはオペレーティングシステム
、hostなどによってデータベースが再起動されたときに実行されます。その後、ALTER DATABASE OPENを実行すると、自動的にインスタンスのリカバリが行われます。 RAC環境では、インスタンスが停止した場合、またはインスタンスが引き継ぐ場合、インスタンスはインスタンスのリカバリのために復元されます。すべてのインスタンスが麻痺していない限り、ALTER DATABASE OPENの最初のインスタンスがインスタンスの回復を行います。これが、REDO LOGがインスタンス非公開コンポーネントである理由ですが、REDO LOGファイルは共有ストレージに保存する必要があります。

OracleデータベースのCACHEメカニズムはパフォーマンス指向であるため、CACHEメカニズムはデータベースのパフォーマンスを最大限に引き出すため、データファイルに書き込まれる限り、CACHEは常に遅延します。このメカニズムによってデータベースのパフォーマンスは大幅に向上しますが、インスタンスに障害が発生したときにいくつかの問題が発生する可能性があります。

まず第一に、インスタンスに障害が発生した場合、データファイルへの一部のデータ変更がディスクに完全に書き込まれないことがありますトランザクションによってコミットされたデータファイルに関する変更情報がディスクファイルで失われることがあります。次に、まだコミットされていないトランザクションのデータファイルへの変更がディスクファイルに書き込まれている可能性があります。アトムによって変更されたデータの一部がファイルに書き込まれ、一部のデータがまだディスクファイルに書き込まれていない可能性もあります。インスタンスの回復は、ONLINE REDO LOGファイルに記録されている情報を通じて、上記のデータの修復を自動的に完了することです。このプロセスは完全に自動化されており、手動による操作は必要ありません。

このメカニズムには、コミットされたトランザクションが失われないようにする方法と、データベースのパフォーマンスとインスタンスの回復に必要な時間を確保する方法の2つがあります。バランスが取れているため、データベースのパフォーマンスが低下することはなく、インスタンスのリカバリは高速です。

最初の問題の解決は比較的簡単で、OracleにはLog-Force-at-Commit、つまりトランザクションがコミットされたときにCOMMITレコードを含むトランザクションに関連するREDO LOGデータというメカニズムがあります。 REDO LOGファイルはLOG BUFFERから書き込む必要があり、トランザクションが正常にコミットしたというシグナルをユーザープロセスに送信できます。このメカニズムにより、すでに送信されたトランザクションのBUFFER CACHEの一部がデータファイルに書き込まれていない場合でも、インスタンス障害が発生し、インスタンスが復元されたときに、矛盾するデータもREDO LOGの情報を通じて取得できます。ロールフォワード

2番目の問題を解決するために、チェックポイントメカニズムを通じてoracleが実装されています。 Oracleデータベースでは、BUFFER CAHCEの変更操作はフォアグラウンドプロセスによって完了しますが、フォアグラウンドプロセスはデータファイルからデータブロックをBUFFER CACHEに読み込むことのみを担当し、BUFFER CACHE書き込みデータファイルは担当しません。データファイルを書き込むためのBUFFER CACHEの操作は、バックグラウンドプロセスDBWRによって行われます。 DBWRは、システムの負荷状況やデータブロックが他のプロセスによって使用されているかどうかに応じて、データブロックの一部をデータファイルに書き戻すことができます。このメカニズムの下では、データブロックがファイルに書き戻される時間はランダムであり得、そして最初の修正されたデータブロックのうちのいくつかは後でデータファイルに書き込まれ得る。 CHECKPOINTメカニズムはこのメカニズムを効果的に補完するもので、CHECKPOINTが発生すると、CKPTプロセスはDBWRプロセスに、特定のSCNのすべての変更済みブロックをデータファイルに書き戻すように依頼します。そのため、このCHECKPOINTが完了すると、このSCNより前のすべてのデータ変更が保存され、その後にインスタンス障害が発生した場合は、インスタンスの復元時にCHECKPOINTが完了した後に変更を開始するだけで済みます。前の変更は考慮する必要はありません。

これまでのところ、インスタンス回復メカニズムのいくつかの基本原則を学びました。そして、REDO LOGの動作メカニズム一般を理解することができます。しかし、私達はまだもっと深くなる必要があると思います。もう少し詳しいインサイダーを学びましょう。実際、古い白の導入を通して、インスタンスの回復が非常に徹底的であるとすでに感じているかもしれませんが、実際には、私達が解決していない多くの問題があります。データファイルの変更は書き込まれているが、REDO LOG情報がまだLOG BUFFERにあり、REDO LOGが書き込まれていない可能性があります。

ここで我々は名詞を導入しなければなりません：Write-Ahead-Log、これはログの書き込み優先順位です。ログ書き込み優先順位には、アルゴリズムの2つの側面が含まれています1つ目の側面は、BUFFER CACHEの変更された変更ベクトルがREDO LOGファイルに書き込まれない限り、変更されたBUFFER CACHEデータをデータファイルに書き込めないことです。これにより、REDO LOGファイルに記録されていない変更を再データファイルに含めることが不可能になります; 2番目の側面は、特定のデータのUNDO情報の変更ベクトルに対してBUFFER CACHEがREDO LOGに書き込まれないことです。変更内容をデータファイルに書き込むことはできません。

メディアリカバリとインスタンスリカバリのメカニズムは似ていますが、違いは、格納されているデータファイルが失敗したときにメディアリカバリが実行されることです。 datafileコマンドが実装されています。一般に、メディアリカバリはリカバリされたデータファイルからのリカバリであるため、メディアリカバリを実行するときはアーカイブログを使用する必要があります。

白いペリカンから洞窟を再印刷する

概要：

REDOログの役割：1.メディアとしてのデータベースの回復重要なファイル2.データベースを復元するための例として、データベースの一貫性を維持することが重要な役割を果たします。

インスタンスリカバリを実行する場合、一貫性の重要な鍵はREDOログファイルです。ログファイル、データファイルを変更します。データファイルを変更するときは、最初にバッファキャッシュをバッファキャッシュに書き込んでデータファイルをdbwrプロセスに書き込み、半分の停電による不整合を書き込みます。Oracleはchkpプロセスを使用してデータファイルを定期的に書き込みます。 （チェックポイントは前のSCNよりも大きいデータファイルを定期的にリフレッシュして、ライトバック・データファイルを強制します）。

しかし、REDOログは最初にREDOログバッファに書き込まれますが、REDOログバッファがREDOログファイルに書き込まれない場合はどうすればよいですか。 1.変更されたBUFFER CACHEのデータは、BUFFER CACHEの変更された変更ベクトルがREDO LOGファイルに書き込まれない限り、データファイルに書き込むことができません。 2.このBUFFER CACHEの修正は、あるデータのUNDO情報の変更ベクトルがREDO LOGに書き込まれない限り、データファイルに書き込むことができません。
zh-CN"],null,[1],zh-TW"]]]