1. データベース概要
  2. Oracleデータベース記憶域構造
  3. 物理記憶域構造

11 物理記憶域構造

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

この章の構成は、次のとおりです。

物理記憶域構造の概要

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

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

Oracleデータベースは、Oracleデータを永続ディスク記憶域に格納する一連のファイルです。この項では、CREATE DATABASE文を発行したときに生成されるデータベース・ファイルについて説明します。

  • データファイルと一時ファイル

    データファイルはディスク上にOracle Databaseが作成した物理ファイルであり、表や索引などのデータ構造が含まれます。一時ファイルは一時表領域に属するデータファイルです。データベースでは、他のプログラムでは読み取れないOracle独自の形式で、データをこれらのファイルに書き込みます。

  • 制御ファイル

    制御ファイルは、データベースの物理コンポーネントを追跡するためのルート・ファイルです。

  • オンラインREDOログ・ファイル

    オンラインREDOログは、データに対する変更が記録される一連のファイルです。

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

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

図11-1の説明が続きます
「図11-1 データベース・インスタンスとデータベース・ファイル」の説明

関連項目:

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

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

一般的なメカニズムは、次のとおりです。

  • Oracle Automatic Storage Management(Oracle ASM)

    Oracle ASMには、Oracle Databaseでのみ使用できるよう設計されたファイルシステムが含まれています。

  • オペレーティング・システムのファイルシステム

    ほとんどのOracleデータベースでは、ファイルをファイル・システムに格納します(ファイル・システムは、連続するディスク・アドレス空間内に構築されたデータ構造です)。すべてのオペレーティング・システムには、ファイルシステム内でディスク領域のファイルへの割当ておよび割当て解除を実行するファイル・マネージャがあります。

    ファイルシステムを使用すると、多数のファイルにディスク領域を割り当てることができます。各ファイルには名前があり、Oracle Databaseなどのアプリケーションに対して連続するアドレス空間として表示されます。データベースでは、ファイルの作成、読取り、書込み、サイズ変更および削除が可能です。

    通常、ファイル・システムは、論理ボリューム・マネージャ(LVM)と呼ばれるソフトウェア・パッケージによって作成された論理ボリュームの最上部に構築されます。LVMを使用すると、複数の物理ディスクの断片を単一の連続するアドレス空間に結合し、ソフトウェアの上位レイヤーに対して1つのディスクとして表示できます。

  • クラスタ・ファイル・システム

    クラスタ・ファイル・システムとは、連携して高パフォーマンスのサービスをクライアントに提供するサーバーのクラスタによる分散ファイル・システムです。Oracle RAC環境でクラスタ・ファイルシステムを使用すると、共有記憶域が、クラスタ化環境内の多数のコンピュータによって共有されるファイルシステムとして表示されます。クラスタ・ファイルシステムを使用すると、クラスタ内のいずれかのコンピュータで障害が発生しても、ファイルシステムが使用できなくなることはありません。ただし、オペレーティング・システムのファイルシステムで、NFSなどの方法を使用してファイルを共有するコンピュータに障害が発生した場合、ファイルシステムは使用できません。

データベースでは、これらのストレージ・メカニズムを組み合せて使用します。たとえば、データベースでは、従来のファイルシステムに制御ファイルとオンラインREDOログ・ファイルを、RAWパーティションに一部のユーザー・データファイルを、Oracle ASMに残りのデータファイルを、クラスタ・ファイルシステムにアーカイブREDOログ・ファイルを格納できます。

関連項目:

Oracle Automatic Storage Management(Oracle ASM)

Oracle ASMは、高パフォーマンスで管理しやすいOracle Databaseファイルのストレージ・ソリューションです。Oracle ASMはボリューム・マネージャであり、データベースでのみ使用できるよう設計されたファイルシステムが備えられています。

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

  • データベースの作成およびレイアウトやディスク領域の管理など、ストレージ関連のタスクが簡略化されます。

  • 複数の物理ディスクにわたってデータが配分されるため、ホットスポットがなくなり、ディスク間のパフォーマンスが均一になります。

  • ストレージ構成が変わると、データのバランスが自動的に再調整されます。

Oracle ASMを使用するには、ストライプ化およびミラー化のプリファレンスを使用して、Oracle Databaseのパーティション化したディスクを割り当てます。Oracle ASMによってディスク領域が管理され、使用可能なすべてのリソースにI/O負荷が配分されるため、I/Oを手動でチューニングしなくてもパフォーマンスが最適化されます。たとえば、データベースを停止しなくても、データベースのディスクのサイズを増加し、データベースの一部を新しいデバイスに移動できます。

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

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

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

図11-2 Oracle ASMのコンポーネント

図11-2の説明が続きます
「図11-2 Oracle ASMのコンポーネント」の説明

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

  • Oracle ASMディスク

    Oracle ASMディスクは、Oracle ASMディスク・グループにプロビジョニングされるストレージ・デバイスです。Oracle ASMディスクは、物理ディスクまたはパーティション、ストレージ・アレイからの論理ユニット番号(LUN)、論理ボリュームまたはネットワーク接続ファイルのいずれでもかまいません。

    Oracle ASMディスク・グループ内のOracle ASMディスクは、データベースの稼働中に追加または削除できます。ディスクをディスク・グループに追加するときは、ディスク名を割り当てます(割り当てない場合は、Oracle ASMディスク名が自動的に指定されます)。

  • Oracle ASMディスク・グループ

    Oracle ASMディスク・グループは、1つの論理単位として管理されるOracle ASMディスクのコレクションです。ディスク・グループのデータ構造は自己完結型で、ディスク・グループの一部のディスク領域を使用します。

    ディスク・グループ内では、各Oracleデータベース・ファイルに使用するファイルシステム・インタフェースがOracle ASMによって公開されます。ディスク・グループに格納される各ファイルの内容は均等に配分(つまりストライプ化)されるため、ホットスポットがなくなり、ディスク間のパフォーマンスが均一化されます。

  • Oracle ASMファイル

    Oracle ASMファイルは、Oracle ASMディスク・グループに格納されるファイルです。Oracle Databaseは、ファイルに関してOracle ASMと通信します。データベースには、データファイル、制御ファイル、オンラインREDOログ・ファイルなどの様々なファイルをOracle ASMファイルとして格納できます。データベースから要求されると、Oracle ASMによってOracle ASMファイルが作成され、プラス記号(+)の後にディスク・グループ名が続く名前(+DISK1など)が、このファイルに割り当てられます。

    注意:

    Oracle ASMファイルは、サード・パーティ製ファイル・システムなどの他のストレージ管理オプションと共存させることができます。この機能により、Oracle ASMを既存の環境に統合する作業が簡素化されます。

  • Oracle ASMエクステント

    Oracle ASMエクステントは、Oracle ASMファイル内のセクションです。1つのOracle ASMファイルは1つ以上のファイル・エクステントで構成されます。それぞれのOracle ASMエクステントは、特定のディスク上にある1つ以上の割当て単位で構成されます。

    注意:

    Oracle ASMエクステントは、データをセグメントに格納するために使用されるエクステントとは異なります。

  • Oracle ASM割当て単位

    Oracle ASM割当て単位は、ディスク・グループ内の割当ての基本単位です。割当て単位は、Oracle ASMによって割り当てられる最小の連続するディスク領域になります。1つ以上の割当て単位によって、1つの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インスタンスではデータベースをマウントできず、実行されるタスクもデータベース・インスタンスより少なくなります。

図11-3に、Oracle ASMインスタンスが1つとデータベース・インスタンスが2つあり、それぞれが異なる単一インスタンス・データベースに関連付けられている単一ノード構成を示します。このOracle ASMインスタンスによってメタデータが管理され、2つのデータベースのデータが格納されているOracle ASMファイルの領域が割り当てられます。一方のOracle ASMディスク・グループには4つのOracle ASMディスクがあり、もう一方には2つのディスクがあります。いずれのデータベース・インスタンスも、これらのディスク・グループにアクセスできます。

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

図11-3の説明が続きます
「図11-3 Oracle ASMインスタンスとデータベース・インスタンス」の説明

関連項目:

Oracle ASMの詳細は、Oracle Automatic Storage Management管理者ガイドを参照してください

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

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

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

注意:

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

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

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

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

関連項目:

データファイルの概要

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

データファイルの使用

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

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

  • 各表領域は1つ以上のデータファイルから構成され、このデータファイルはOracle Databaseを実行しているオペレーティング・システムに準拠します。

  • データベースのデータは、そのデータベースの各表領域内にあるデータファイルにまとめて格納されます。

  • セグメントは1つ以上のデータファイルにまたがることがありますが、複数の表領域にまたがることはありません。

  • データベースには、SYSTEM表領域とSYSAUX表領域が必要です。Oracle Databaseでは、データベースの作成時に、データベースの最初のデータファイルがSYSTEM表領域に自動的に割り当てられます。

    SYSTEM表領域には、データベースのメタデータを含む一連の表であるデータ・ディクショナリが含まれています。通常、データベースにはUNDO表領域と一時表領域(通常の名前はTEMP)もあります。

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

図11-4 データファイルと表領域

図11-4の説明が続きます
「図11-4 データファイルと表領域」の説明

関連項目:

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

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

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

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

  • 表などの永続データベース・オブジェクトは、一時ファイルには格納されません。

  • 一時ファイルは常にNOLOGGINGモードに設定され、これは、一時ファイルにはREDOが生成されないということを意味します。メディア・リカバリは一時ファイルを認識しません。

  • 一時ファイルを読取り専用にすることはできません。

  • ALTER DATABASE文では一時ファイルを作成できません。

  • 一時ファイルを作成またはサイズ変更する場合、指定したファイル・サイズのディスク領域が常に保証されるとはかぎりません。LinuxやUNIXなどのファイルシステムでは、一時ファイルはスパース・ファイルとして作成されます。この場合、ディスク・ブロックはファイルの作成時やサイズ変更時ではなく、最初にブロックがアクセスされるときに割り当てられます。

    注意:

    スパース・ファイルを使用すると、一時ファイルの作成とサイズ変更が素早く行えますが、一時ファイルにアクセスしたときに、ディスク領域が不足する可能性があります。

  • 一時ファイルの情報は、データ・ディクショナリ・ビューDBA_TEMP_FILESと動的パフォーマンス・ビューV$TEMPFILEには表示されますが、DBA_DATA_FILESビューやV$DATAFILEビューには表示されません。

関連項目:

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

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

個々のデータファイルまたは一時ファイルの可用性は、ファイルをオフラインにするか、オンラインにして変更できます。データベースでは、オフライン・データファイルには、それらがオンラインになるまでアクセスできません。

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

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

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

  • 異なる種類のストレージ間での表領域の移動

  • 頻繁にアクセスしないデータファイルを、より低コストの記憶域に移動します。

  • 表領域を読取り専用にし、そのデータ・ファイルを1回のみ書込み可能なストレージ(WORM (write once read many)ドライブなど)に移動

  • データベースをOracle ASMに移動

関連項目:

データファイルの構造

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

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

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

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

図11-5 データファイル内の領域

図11-5の説明が続きます
「図11-5 データファイル内の領域」の説明

関連項目:

データファイル情報の表示方法の詳細は、『Oracle Database管理者ガイド』を参照してください

制御ファイルの概要

データベースの制御ファイルは、1つのデータベースのみに関連付けられた小さなバイナリ・ファイルです。各データベースには一意の制御ファイルが1つあります(ただし、複数の同一コピーも使用できます)。

制御ファイルの使用

Oracle Databaseでは制御ファイルを使用して、データベース・ファイルを検索し、データベース全体の状態を管理します。

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

  • データベース名およびデータベースの一意の識別子(DBID)

  • データベースを作成したときのタイムスタンプ

  • データファイル、オンラインREDOログ・ファイルおよびアーカイブREDOログ・ファイルに関する情報

  • 表領域情報

  • RMANバックアップ

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

  • データベースをオープンするために必要となるデータファイル、およびオンラインREDOログ・ファイルなどに関する情報を格納します。

    制御ファイルは、データベースに対する構造上の変更を追跡します。たとえば、管理者がデータファイルやオンラインREDOログ・ファイルの追加、名前変更または削除を実行すると、データベースで制御ファイルが更新され、変更が反映されます。

  • データベースがオープンしていないときにアクセスする必要があるメタデータを格納します。

    制御ファイルには、チェックポイントなどデータベースのリカバリに必要な情報などが含まれています。チェックポイントは、インスタンス・リカバリを開始する必要があるREDOストリーム内のSCNを示します。チェックポイントSCNの前にコミットされたすべての変更は、データファイルのディスクに保存されることが保証されます。チェックポイント・プロセスは、オンラインREDOログ内のチェックポイント位置に関する情報を、少なくとも3秒ごとに制御ファイルに記録します。

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

関連項目:

多重制御ファイル

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

注意:

多重制御ファイルのコピーをそれぞれ異なるディスクで維持することをお薦めします。

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

関連項目:

制御ファイルの構造

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

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

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

  • 循環再利用レコード

    循環再利用レコードには、必要に応じて上書き可能な、重要度が低い情報が含まれます。使用可能なレコード・スロットがすべて使用されると、データベースは、制御ファイルを拡張して新規レコード用の領域を作成するか、または最も古いレコードを上書きします。たとえば、アーカイブREDOログ・ファイルやRMANバックアップのレコードなどです。

  • 非循環再利用レコード

    非循環再利用レコードには、頻繁には変更されず、上書きできない重要な情報が含まれます。たとえば、表領域、データファイル、オンラインREDOログ・ファイル、REDOスレッドなどの情報です。Oracle Databaseでは、対応するオブジェクトが表領域から削除されないかぎり、これらのレコードを再使用しません。

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

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

関連項目:

オンラインREDOログの概要

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

オンラインREDOログの使用

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

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

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

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

関連項目:

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

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

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

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

関連項目:

Oracle RAC内のオンラインREDOログ・グループの詳細は、『Oracle Database 2日でReal Application Clustersガイド』および『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください

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

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

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

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

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

図11-6 オンラインREDOログ・ファイルの再使用

図11-6の説明が続きます
「図11-6 オンラインREDOログ・ファイルの再使用」の説明

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

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

  • アーカイブが無効、つまりデータベースがNOARCHIVELOGモードの場合、ファイルに記録された変更のチェックポイント(書込み)処理がデータベース・ライター(DBW)によってディスクに実行されるまで、一杯になったオンラインREDOログ・ファイルを使用できません。

  • アーカイブが有効、つまりデータベースがARCHIVELOGモードの場合は、変更がデータファイルに書き込まれ、そのファイルがアーカイブされた後、いっぱいになったオンラインREDOログ・ファイルをログ・ライターで使用できるようになります。

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

関連項目:

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

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

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

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

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

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

図11-7の説明が続きます
「図11-7 オンラインREDOログ・ファイルの複数コピー」の説明

注意:

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

関連項目:

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

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

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

  • データベース・バックアップのリカバリ

  • スタンバイ・データベースの更新

  • Oracle LogMinerユーティリティを使用したデータベースの履歴情報の取得

アーカイブ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レコードには、変更に関係するすべてのメタデータが設定されます。たとえば、次のものがあります。

  • 変更のSCNおよびタイムスタンプ

  • 変更が生成されたトランザクションのトランザクションID

  • トランザクションがコミットされたときのSCNおよびタイムスタンプ(トランザクションがコミットされた場合)

  • 変更を実行した操作のタイプ

  • 変更されたデータ・セグメントの名前およびタイプ

関連項目:

「データ・ブロックの概要」