物理ストレージ構造

Oracle Databaseの物理データベース構造は、オペレーティング・システム・レベルで表示可能です。

物理記憶域構造の概要

RDBMSの特徴の1つは、表、ビュー、索引など、論理データ構造がファイルなどの物理記憶域構造から独立していることです。

物理構造の構造と論理構造は分離されているため、論理構造へのアクセスに影響を与えずに、データの物理記憶域を管理できます。たとえば、データベース・ファイルの名前を変更しても、ファイルに格納されている表の名前は変更されません。

Oracleデータベースは、Oracleデータを永続記憶域に格納する一連のファイルです。Oracle Database 21cから、マルチテナント・コンテナ・データベース(CDB)がサポート対象の唯一のアーキテクチャになりました。CDBには、1つ以上のPDBが含まれています。

この項では、CREATE DATABASE文を発行してCDBを作成するときに生成されるデータベース・ファイルについて説明します。

データベース・インスタンスは、CDB内のデータベース・ファイルを管理する一連のメモリー構造です。次の図に、インスタンスとインスタンスによって管理されるファイルの間の関係を示します。

図1: データベース・インスタンスとデータベース・ファイル

画像cncpt223.gifの説明

関連情報:

データベース・ファイル格納のメカニズム

データベース・ファイルの記憶域の割当ておよび管理には、複数のメカニズムを使用できます。

次のメカニズムがあります。

データベースでは、前述の記憶域メカニズムを組み合せて使用できます。たとえば、データベースではサーバー・パラメータ・ファイルが従来のファイル・システムに格納され、データベース・ファイルがPMEMのファイルストアに格納されてから、REDOログ・ファイルをクラスタ・ファイル・システムにアーカイブできます。

関連情報:

Oracle Managed Filesおよびユーザー管理ファイル

Oracle Managed Filesとは、ファイル名ではなく、データベース・オブジェクトの観点で操作を指定できるようにするためのファイル命名方法のことです。たとえば、表領域のデータファイルの名前を指定しなくても、表領域を作成できます。

Oracle Managed Filesでは、データベース内のオペレーティング・システム・ファイルを管理者が直接管理する必要がなくなります。Oracle ASMではOracle Managed Filesが必要です。

ノート:この機能は、トレース・ファイル、監査ファイル、アラート・ログなどの管理ファイルの作成または命名にも影響を与えません。

ユーザー管理ファイルを使用すると、データベース内のオペレーティング・システム・ファイルをユーザーが直接管理できます。ユーザーは、ファイルの構造および名前を決定できます。たとえば、表領域を作成する場合は、表領域データファイルの名前とパスを設定します。

初期化パラメータを使用して、特定タイプのファイルに使用するファイル・システム・ディレクトリを指定します。Oracle Managed Filesの主な役割は、データベースによって一意のファイルが作成され、そのファイルが不要になったら削除されるようにすることです。データベースでは、標準のファイル・システム・インタフェースを内部で使用して、データファイルと一時ファイルのファイル、制御ファイル、および高速リカバリ領域に格納されているリカバリ関連ファイルなどのファイルが作成および削除されます。

Oracle Managed Filesを使用しても、既存の機能は削除されません。以前のファイルを手動で管理しながら、新しいファイルを作成できます。このため、データベースにはOracle Managed Filesとユーザー管理ファイルが混在する場合があります。

関連情報:

Oracle Automatic Storage Management(Oracle ASM)

Oracle ASMは、Oracle AI Databaseファイル用の高パフォーマンス、管理しやすいストレージ・ソリューションである。Oracle ASMはボリューム・マネージャで、データベース専用に設計されたファイル・システムを提供します。

Oracle ASMには、従来のファイル・システムおよびストレージ・マネージャと比較して、次のような利点があります。

Oracle ASMを使用するには、ストライプ化およびミラー化のプリファレンスを設定して、Oracle AI Databaseのパーティション化されたディスクを割り当てます。Oracle ASMは、I/Oロードを使用可能なすべてのリソースにI/O負荷が分散されるため、I/Oの手動チューニングが不要になり、パフォーマンスを最適化します。たとえば、データベースをシャットダウンすることなくデータベース用のディスクのサイズを増やしたり、データベースの一部を新しいデバイスに移動したりできます。

Oracle ASMのストレージ・コンポーネント

Oracle AI Databaseでは、データファイルをOracle ASMファイルとしてOracle ASMディスク・グループ内に格納できます。ディスク・グループ内では、各データベース・ファイルに使用するファイル・システム・インタフェースがOracle ASMによって公開されます。

次の図に、Oracle ASMを使用するデータベース内のストレージ・コンポーネント間の関係を示します。このダイアグラムは、Oracle ASMファイルとデータファイルの間の関係を表していますが、Oracle ASMには他のタイプのファイル も格納できます。クロウの足の表記は、1対多の関係を表しています。

図2: Oracle ASMのコンポーネント

画像cncpt267.gifの説明

図14-2は、次のOracle ASMの概念を示しています。

関連項目: Oracle ASMについてさらに学習するには、Oracle Automatic Storage Management管理者ガイドを参照してください。

Oracle ASMインスタンス

Oracle ASMインスタンスは、Oracle ASMディスクを管理する特殊なOracleインスタンスである。

Oracle ASMインスタンスとデータベース・インスタンスのどちらにも、Oracle ASMディスク・グループのディスクへの共有アクセスが必要です。Oracle ASMインスタンスはディスク・グループのメタデータを管理して、ファイルのレイアウト情報をデータベース・インスタンスに提供します。データベース・インスタンスによって、Oracle ASMインスタンスを経由せずに、I/OがOracle ASMディスクに転送されます。

Oracle ASMインスタンスは、データベース・インスタンスと同じテクノロジに基づいています。たとえば、Oracle ASMインスタンスには、データベース・インスタンスおよび同様のシステム・グローバル領域の(SGA)およびバックグラウンド・プロセスがあります。ただし、Oracle ASMインスタンスではデータベースをマウントできず、実行されるタスクもデータベース・インスタンスより少なくなります。図14-3に、Oracle ASMインスタンスは1つとデータベース·インスタンスが2つある、それぞれが異なる単一インスタンス・データベースに関連付けられている単一ノード構成を示します。このOracle ASMインスタンスによってメタデータが管理され、2つのデータベースのデータが格納されているOracle ASMファイルの領域が割り当てられます。一方のOracle ASMディスク・グループには4つのOracle ASMディスクがあり、もう一方には2つのディスクがあります。いずれのデータベース・インスタンスも、これらのディスク・グループにアクセスできます。

図3: Oracle ASMインスタンスとデータベース・インスタンス

画像cncpt266.gifの説明

関連項目: Oracle ASMについてさらに学習するには、Oracle Automatic Storage Management管理者ガイドを参照してください。

Oracle永続メモリー・ファイルストア(PMEMファイルストア)

PMEMは、バイトアドレス指定可能な永続メモリーです。Oracle永続メモリー・ファイルストア(PMEMファイルストア)には、データ・ファイル、オンラインREDOログ・ファイルおよび制御ファイルを格納できます。

問合せは、最初にブロックをデータベース・バッファ・キャッシュに移行せずに、PMEMからバイトを直接読み取ることができます。この高パフォーマンスのメカニズムにより、データの重複と不要なI/Oを回避できます。ノート: PMEMファイルストアには、トレース・ファイル、監査ファイルまたはサーバー・パラメータ・ファイルを格納できません。PMEMでサポートされているファイル・タイプは、Oracle ASMのタイプに似ています。

直接マップされたバッファ・キャッシュ

従来のストレージのピラミッドでは、非永続的DRAMと永続的(非揮発性)なフラッシュとの間にPMEMが存在しています。

図4: ストレージのピラミッド

画像pmem.pngの説明

データベース・バッファ・キャッシュはDRAM内にあります。Oracleプロセスには、データベース・バッファ・キャッシュにマップされた、PMEMファイルストア内のブロックにバイトアドレスを指定可能なアクセス権があります。マッピング・メカニズムは、データ・ファイルをPMEMファイルストアに置くと自動的に起動されます。

Oracle AI Databaseでは、内部アルゴリズムを使用して、データ・ブロックのPMEMファイルストアからDRAMに移行するかどうかを決定します。移行する一般的な理由には、DMLの変更、読取りの一貫性、ホット・データ・ブロックに対するアクセスの高速化が含まれます。

関連項目: 「DRAMおよびPMEMバッファ」

PMEMファイルストアのファイル・システム・インタフェース

PMEMファイルストアでは、Filesystem in Userspace (FUSE)というプロトコルを実装します。

FUSEでは、Oracle AI Databaseソフトウェア所有者などの権限のないオペレーティング・システム・ユーザーが、ファイル・システム、ディレクトリ、およびそれに含まれるファイルを作成および管理できます。たとえば、cp、rm、およびlsコマンドを使用できます。

一般的なファイル・システムでは、RAWストレージをそのバッキング・ストアとして使用し、PMEMファイルストアがPMEM DAXファイル・システムのネイティブ・オペレーティング・システム・ファイルからストレージを取得します。このファイルはバッキング・ファイルと呼ばれ、オペレーティング・システム内のファイルとして表示されます。PMEMファイルストアはバッキング・ファイル内でストレージを分割し、それをローカル・ファイル・システムとして提示します。

関連情報:

PMEMファイルストアのユーザー・インタフェース

PMEMファイル・ストアを作成するには、CREATE PMEM FILESTOREコマンドを使用します。

PMEMファイルストアは、作成後に自動的にマウントされます。PMEMファイルストアは、指定したマウント・ポイントの下にネイティブ・ファイル・システムであるかのように表示されます。

PMEM_FILESTORE初期化パラメータは、データベース・インスタンスが起動時に自動的にマウントするPMEMファイルストアを指定します。パラメータは、順序付けられた文字列のペアに設定されます。パラメータ値リストの最初の文字列は、PMEMファイルストアがマウントされるディレクトリです。2番目の文字列は、バッキング・ファイルです。

V$PMEM_FILESTOREは、PMEMファイルストアに関するメタデータを表示します。たとえば、マウント・ポイントのディレクトリ・パス、バッキング・ファイルのファイル・パス、およびファイルストア・サイズを表示できます。

関連項目: PMEMファイルストアの作成および管理の方法を学習するには、『Oracle AI Database管理者ガイド』を参照してください

データファイルの概要

オペレーティング・システム・レベルで、Oracle AI Databaseでは、データファイルと呼ばれる構造にデータが格納されます。CDBまたはPDBのどちらでも、すべてのOracleデータベースには、少なくとも1つのデータ・ファイルが必要です。

データファイルの使用

Oracle AI Databaseでは、表領域データがデータファイルに物理的に格納されます。

パーティション化されていないそれぞれのスキーマ・オブジェクトとオブジェクトの各パーティションは、独自のセグメント(1つの表領域のみに属している)に格納されます。たとえば、パーティション化されていない表のデータは1つのセグメントに格納され、このセグメントは1つの表領域に格納されます。表領域とデータファイルは密接に関連していますが、次のような重要な違いがあります。

次の図に、表領域、データファイルおよびセグメントの関係を示します。

図5: データファイルと表領域

画像cncpt037.gifの説明

関連情報:

永続データファイルと一時データファイル

永続表領域には、永続スキーマ・オブジェクトが含まれています。永続表領域内のオブジェクトは、データファイルに格納されます。

一時表領域には、セッションの存続時間のみのスキーマ・オブジェクトが含まれます。ローカルで管理される一時表領域には、ハッシュやソートなどの操作でデータを格納するための特殊なファイルである一時的なファイル(一時ファイル)が含まれています。一時ファイルには、メモリー内の領域が不足したときの結果セットのデータも格納されます。

一時ファイルは永続データファイルと似ていますが、次のような例外があります。

関連情報:

オンライン・データファイルとオフライン・データファイル

すべてのデータファイルは、オンライン(使用可能)またはオフライン(使用不可能)のいずれかです。

個々のデータファイルまたはテンポラリファイルの可用性は、ファイルをオフラインにするか、オンラインにすることにより変更できます。データベースでは、オフライン・データファイルには、それらがオンラインになるまでアクセスできません。

データファイルをオフラインにする理由は、オフライン・バックアップの実行やブロックの破損など数多くあります。データベースでは、データファイルに書き込めない場合に、ファイルが自動的にオフラインになります。

データファイルと同様に、表領域自体もオフラインまたはオンラインになります。オンラインの表領域にあるデータファイルをオフラインにしても、表領域自体はオンラインのままです。表領域の自体をオフラインにすると、表領域のすべてのデータファイルを一時的に使用不可能にできます。

Oracle Database 12c以降、ALTER DATABASE MOVE DATAFILE文を使用して、データベースをオープンした状態でファイルにアクセスしている間に、複数の物理ファイルに対してオンライン・データ・ファイルを移動できます。この手法を使用すれば、次の目的を達成できます。

関連情報:

データファイルの構造

Oracle AI Databaseでは、表領域のデータファイルを作成するには、指定されたディスク領域に加えて、データファイル・ヘッダーのオーバーヘッドを割り当てます。Oracle AI Databaseを実行するオペレーティング・システムによって、ファイルから古い情報や認可がクリアされた後に、そのファイルがデータベースに割り当てられています。

データファイル・ヘッダーには、サイズやチェックポイントSCNなど、データファイルに関するメタデータが含まれています。それぞれのヘッダーには、データベース内でデータファイルを一意に識別する絶対ファイル番号と、表領域内でデータファイルを一意に識別する相対ファイル番号が含まれます。

Oracle AI Databaseでデータファイルが初めて作成されると、割り当てられたディスク領域がフォーマットされますが、ユーザー・データは含まれません。ただし、データベースでは、関連付けられた表領域の将来のセグメントのデータを保持する領域が確保されます。Oracle AI Databaseでは、表領域内のデータが増加すると、データファイル内の空き領域を使用してセグメントにエクステントを割り当てます。

次の図に、データファイル内の各種の領域を示します。エクステントは、使用中(セグメント・データが含まれている場合)または空き(再使用が可能な場合)のいずれかです。表領域内のオブジェクトの更新または削除が繰り返されると、単独では新しいデータに再使用できるほど大きくはないものの、孤立した空き領域ができる場合があります。このような空き領域は、断片化空き領域と呼ばれます。

図6: データファイル内の領域

画像cncpt273.gifの説明

関連項目:データファイル情報の表示方法を学習するには、『Oracle AI Database管理者ガイド』を参照してください

制御ファイルの概要

データベースの制御ファイルは、1つのCDBのみに関連付けられた小さなバイナリ・ファイルです。

各CDBには一意の制御ファイルが1つあります(ただし、複数の同一コピーも使用できます)。PDBには、別個の制御ファイルがありません。

制御ファイルの使用

Oracle AI Databaseでは、データベース・ファイルを見つけるために、データベースの状態を大まか管理するために、制御ファイルが使用されます。

制御ファイルには、次のような情報が含まれています。

制御ファイルは、次のような目的で使用されます。

Oracle AI Databaseは、データベースの使用中に制御ファイルの読取りと書込みを絶えず実行するため、データベースがオープンしているときは、常に書込み可能であることが必要です。たとえば、データベースのリカバリには、データベースに含まれているすべてのデータファイルの名前を制御ファイルから読み取る必要があります。データファイルの追加など他の操作を実行すると、制御ファイルに格納された情報が更新されます。

関連情報:

多重制御ファイル

Oracle AI Databaseでは、同一の制御ファイルを同時に複数オープンし、同じデータベースに書き込むことができます。1つの制御ファイルを複数のディスク上で多重化することにより、データベースの冗長性が実現されるため、シングル・ポイント障害を回避できます。ノート: Oracleでは、それぞれ異なるディスク上に複数の制御ファイルのコピーを保持することをお薦めします。

制御ファイルが使用不可能になると、データベース・インスタンスから破損した制御ファイルへのアクセスが試行されたときに、インスタンスが失敗します。現在の制御ファイルのコピーが他にある場合は、メディア・リカバリを実行してなくても、データベースを再マウントしてオープンできます。ただし、データベースのすべての制御ファイルが失われた場合は、データベース・インスタンスが失敗し、メディア・リカバリが必要になります。現行の制御ファイルを使用できず、制御ファイルの古いバックアップを使用する場合、メディア・リカバリは容易ではありません。

関連情報:

制御ファイルの構造

データベースに関する情報は、制御ファイルの異なるセクションに格納されます。各セクションは、データベースの特定の側面に関するレコードの集合です。

たとえば、制御ファイルの1つのセクションではデータファイルが追跡され、レコードの集合がデータファイルごとに1つ含まれています。各セクションは、複数の論理的な制御ファイル・ブロックに格納されます。レコードは、1つのセクション内のブロックにまたがることができる場合があります。

制御ファイルには、次のようなレコードが含まれています。

動的パフォーマンス・ビュー(V$ビューとも呼ばれる)を問い合せて、制御ファイルに格納されている情報を表示できます。たとえば、V$DATABASEを問い合せると、データベース名およびDBIDを取得できます。ただし、制御ファイルの情報を変更できるのは、そのデータベースのみです。

制御ファイル・ブロックの読取りおよび書込みは、データ・ブロックの場合とは異なります。制御ファイルの場合は、Oracle AI Databaseによって、ディスクからプログラム・グローバル領域(PGA)への読取りおよび書込みが行われます。各プロセスでは、そのPGAメモリーの一定量が制御ファイル・ブロックに割り当てられます。

関連情報:

オンラインREDOログの概要

リカバリにとって最も重要な構造がオンラインREDOログであり、このアーカイブは、データベースへの変更が発生したときにその変更が格納される、事前に割り当てられた複数のファイルで構成されます。オンラインREDOログには、データファイルに対する変更が記録されます。

オンラインREDOログの使用

データベースでは、オンラインREDOログ・ファイルを維持してデータ損失から保護します。特に、インスタンス障害の後は、オンラインREDOログ・ファイルを使用すると、Oracle AI Databaseではまだデータファイルに書き込まれていないコミット済のデータをリカバリできるようになります。

サーバー・プロセスは、すべてのトランザクションをREDOログ・バッファに同期的に書き込みます。REDOログ・バッファは、LGWRプロセスがオンラインREDOログに書き込みます。オンラインREDOログの内容には、コミットされていないトランザクションや、スキーマおよびオブジェクトの管理文などが含まれます。

データベースでUNDOセグメントに変更を加えると、変更内容はオンラインREDOログにも書き込まれます。その結果、オンラインREDOログには常に永続オブジェクトのUNDOデータが含まれます。一時UNDOセグメントにある一時オブジェクトのすべてのUNDOデータを格納するようにデータベースを構成でき、これによって領域が節約されパフォーマンスが向上するか、またはデータベースで永続および一時の両方のUNDOデータをオンラインREDOログに格納できるようになります。

Oracle AI Databaseは、リカバリのためにのみオンラインREDOログを使用します。ただし、管理者はOracle LogMinerユーティリティでSQLインタフェースを使用して、オンラインREDOログ・ファイルを問い合せることができます。REDOログ・ファイルは、データベース・アクティビティに関する履歴情報の入手に役立ちます。

関連情報:

Oracle AI DatabaseでのオンラインREDOログの書込み方法

データベース・インスタンスのオンラインREDOログは、REDOスレッドと呼ばれます。

単一インスタンス構成では、1つのインスタンスしかデータベースにアクセスできないため、REDOスレッドは1つのみです。ただし、Oracle Real Application Clusters (Oracle RAC)構成では、複数のインスタンスが同時にデータベースにアクセスし、各インスタンスには独自のREDOスレッドがあります。インスタンスごとにREDOスレッドを分けると、オンラインREDOログ・ファイルの1つの集合に対する競合を回避できます。

オンラインREDOログは、複数のオンラインREDOログ・ファイルで構成されています。Oracle AI Databaseでは、ファイルの1つがクリア中またはアーカイブ中の場合に、もう1つのファイルが常に書込み可能であることを保証するため、少なくとも2つのファイルが必要です。

関連項目: Oracle RACのオンラインREDOログ・グループについて学習するには、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

オンラインREDOログ・スイッチ

Oracle AI Databaseでは、REDOログ・バッファから書き込まれたレコードを格納するために、一度に1つのオンラインREDOログ・ファイルのみが使用されます。

ログ・ライター・プロセス(LGWR)による書込みがアクティブであるオンラインREDOログのファイルは、現行のオンラインREDOログのファイルと呼ばれます。

ログ・スイッチは、データベースで、1つのオンラインREDOログ・ファイルに書込みが停止し、別のファイルへの書込みが開始するときに発生します。スイッチは通常、現行のオンラインREDOログ・ファイルがいっぱいになり、さらに書込みを継続する必要があるときに発生します。ただし、ログ・スイッチは、現行のオンラインREDOログ・ファイルがいっぱいになったかどうかに関係なく、定期的にログ・スイッチが発生するように構成し、手動で強制的に実行できます。

ログ・ライターでは、オンラインREDOログ・ファイルが循環的に書き込まれます。ログ・ライター・プロセスは、使用可能な最後のオンラインREDOログ・ファイルがいっぱいになると、最初のログ・ファイルへ書き込み、循環が再び始まります。図14-7に、REDOログの循環書込みを示します。

図7: オンラインREDOログ・ファイルの再使用

画像admin054.gifの説明

図14-7の数字は、それぞれのオンラインREDOログ・ファイルへのLGWRによる書込みの順序を示しています。データベースでは、ログ・スイッチおよびログ・ライターが書込みを開始したときに、各ファイルに新しいログ順序番号を割り当てます。データベースでオンラインREDOログ・ファイルが再利用されると、このファイルには次に使用可能なログ順序番号が与えられる。

いっぱいになったオンラインREDOログ・ファイルは、アーカイブ・モードに応じて再利用できます。

状況によっては、既存のオンラインREDOログ・ファイルをログ・ライターで再利用できない場合もあります。インスタンス・リカバリにはアクティブなオンラインREDOログ・ファイルが必要です。この場合、アクティブではないオンラインREDOログ・ファイルはインスタンスのリカバリには必要ありません。また、オンラインREDOログ・ファイルがクリア・プロセスの途中である場合もあります。

関連情報:

オンラインREDOログ・ファイルの複数コピー

Oracle AI Databaseでは、オンラインREDOログの複数の同一コピーを別々の場所で自動的に維持できます。

オンラインREDOログ・グループは、オンラインREDOログ・ファイルとその冗長コピーで構成されています。それぞれの同一コピーは、オンラインREDOログ・グループのメンバーです。各グループはグループ1、グループ2のように番号で定義されます。

オンラインREDOログ・グループの複数のメンバーを維持すると、REDOログの損失を防ぐことができます。メンバーの場所を別個のディスクに配置し、1つのディスクで障害が発生してもオンラインREDOログ全体が失われないようにすることが理想的です。

図14-8では、A_LOG1とB_LOG1はグループ1の同一のメンバーであり、A_LOG2とB_LOG2はグループ2の同一のメンバーです。同じグループの各メンバーは同じサイズである必要があります。LGWRは、グループ1(メンバーA_LOG1とB_LOG1)への書込みを同時に実行した後、グループ2(メンバーA_LOG2とB_LOG2)への書込みを同時に実行し、次にグループ1への書込みを実行します。LGWRでは、異なるグループのメンバーに同時に書き込まれることはありません。

図8: オンラインREDOログ・ファイルの複数コピー

画像cncpt270.gifの説明

注意: Oracleでは、オンラインREDOログを多重化することをお薦めします。ログ・ファイルの損失は、リカバリが必要な場合に壊滅的な被害を招く可能性があります。オンラインREDOログを多重化し、データベースで実行するI/Oの量を増やす必要があります。システムによっては、I/Oをこのように追加すると、データベース全体のパフォーマンスに影響を与える場合があります。

関連情報:

アーカイブREDOログ・ファイル

アーカイブREDOログ・ファイルとは、オンラインREDOログ・グループ内で一杯になったメンバーのコピーのことです。

アーカイブREDOログ・ファイルはデータベースの一部とはみなされません。そうではなく、データベースによって作成されたオンラインREDOログ・ファイルのオフライン・コピーであり、ユーザーが指定した場所に書き込まれます。

アーカイブREDOログ・ファイルは、バックアップおよびリカバリ計画にとって重要です。アーカイブREDOログ・ファイルは、次の目的に使用できます。

アーカイブREDOログ・ファイルを生成する操作をアーカイブといいます。この操作は、自動または手動のいずれかです。これは、データベースがARCHIVELOGモードの場合にのみ実行できます。

アーカイブREDOログ・ファイルには、オンラインREDOログ・グループの同一メンバーのREDOエントリ、およびログ順序番号が含まれています。「オンラインREDOログ・ファイルの複数コピー」では、ファイルA_LOG1とB_LOG1がグループ1の同一メンバーです。データベースがARCHIVELOGモードで、自動アーカイブが有効になっている場合は、アーカイバ・プロセス(ARCn)によってこれらのファイルの1つがアーカイブされます。A_LOG1が破損している場合は、B_LOG1をアーカイブできます。アーカイブREDOログには、アーカイブを有効にしたときから存在したすべてのREDOログ・グループのコピーが含まれます。

関連情報:

オンラインREDOログの構造

オンラインREDOログ・ファイルには、REDOレコードが含まれています。

REDOレコードは、変更ベクトルのグループで構成され、それぞれがデータ・ブロックに対する変更を記述します。たとえば、employees表の給与を更新すると、この表のデータ・セグメント・ブロック、UNDOセグメント・データ・ブロックおよびUNDOセグメントのトランザクション表に対する変更を記述するREDOレコードが生成されます。

REDOレコードには、変更に関係するすべてのメタデータが設定されます。たとえば、次のものがあります。

関連項目: 「データ・ブロックの概要」