| Oracle® Database概要 11gリリース2 (11.2) B56306-06 |
|
 前 |
 次 |
この章では、Oracleデータベースの主要な物理データベース構造について説明します。物理構造は、オペレーティング・システム・レベルで表示可能です。
この章の内容は、次のとおりです。
RDBMSの特徴の1つは、表、ビュー、索引などの論理データ構造が物理記憶域構造から独立していることです。物理構造と論理構造は分離されているため、論理構造へのアクセスに影響を与えずに、データの物理記憶域を管理できます。たとえば、データベース・ファイルの名前を変更しても、ファイルに格納されている表の名前は変更されません。
Oracleデータベースは、Oracleデータを永続ディスク記憶域に格納する一連のファイルです。この項では、CREATE DATABASE文を発行したときに生成されるデータベース・ファイルについて説明します。
データファイルと一時ファイル
データファイルはディスク上にOracle Databaseが作成した物理ファイルであり、表や索引などのデータ構造が含まれます。一時ファイルは一時表領域に属するデータファイルです。これらのファイルには、他のプログラムでは読み取ることのできないOracle固有のフォーマットでデータが書き込まれます。
制御ファイル
制御ファイルは、データベースの物理コンポーネントを追跡するためのルート・ファイルです。
オンラインREDOログ・ファイル
オンラインREDOログは、データに対する変更が記録される一連のファイルです。
データベース・インスタンスは、データベース・ファイルを管理する一連のメモリー構造です。図11-1に、インスタンスとインスタンスによって管理されるファイルの間の関係を示します。
|
関連項目:
|
データベース・ファイルの記憶域の割当ておよび管理には、複数のメカニズムを使用できます。一般的なメカニズムは、次のとおりです。
Oracle Automatic Storage Management (Oracle ASM)
Oracle ASMには、Oracle Databaseでのみ使用できるよう設計されたファイルシステムが含まれています。Oracle ASMについては、「Oracle Automatic Storage Management(Oracle ASM)」を参照してください。
オペレーティング・システムのファイルシステム
ほとんどのOracleデータベースでは、ファイルをファイルシステムに格納します(ファイルシステムは、連続するディスク・アドレス空間内に構築されたデータ構造です)。すべてのオペレーティング・システムには、ファイルシステム内でディスク領域のファイルへの割当ておよび割当て解除を実行するファイル・マネージャがあります。
ファイルシステムを使用すると、多数のファイルにディスク領域を割り当てることができます。各ファイルには名前があり、Oracle Databaseなどのアプリケーションに対して連続するアドレス空間として表示されます。データベースでは、ファイルの作成、読取り、書込み、サイズ変更および削除が可能です。
通常、ファイルシステムは、論理ボリューム・マネージャ(LVM)と呼ばれるソフトウェア・パッケージによって作成される論理ボリュームの最上部に構築されます。LVMを使用すると、複数の物理ディスクの断片を単一の連続するアドレス空間に結合し、ソフトウェアの上位レイヤーに対して1つのディスクとして表示できます。
RAWデバイス
RAWデバイスは、ファイルシステムでフォーマットされないディスク・パーティションまたは論理ボリュームです。RAWデバイスの主な利点は、ダイレクトI/Oを実行し、より規模の大きいバッファを記述できることです。ダイレクトI/Oでは、オペレーティング・システムのバッファ・キャッシュを介さず、アプリケーションからストレージ・デバイスへの書込みおよび読取りを直接実行できます。
|
注意: 現在では多くのファイルシステムで、独自のキャッシュを管理するデータベースおよびその他のアプリケーションに対し、ダイレクトI/Oがサポートされるようになりました。以前は、RAWデバイスはダイレクトI/Oを実装するための手段でした。 |
クラスタ・ファイルシステム
クラスタ・ファイルシステムとは、領域割当ておよびファイル内容の一貫性を維持しながら、複数のコンピュータでファイルの記憶域を共有できるようにするソフトウェアです。Oracle RAC環境でクラスタ・ファイルシステムを使用すると、共有記憶域が、クラスタ化環境内の多数のコンピュータによって共有されるファイルシステムとして表示されます。クラスタ・ファイルシステムを使用すると、クラスタ内のいずれかのコンピュータで障害が発生しても、ファイルシステムが使用できなくなることはありません。ただし、オペレーティング・システムのファイルシステムで、NFSなどの方法を使用してファイルを共有するコンピュータに障害が発生した場合、ファイルシステムは使用できません。
データベースでは、これらのストレージ・メカニズムを組み合せて使用します。たとえば、データベースでは、従来のファイルシステムに制御ファイルとオンラインREDOログ・ファイルを、RAWパーティションに一部のユーザー・データファイルを、Oracle ASMに残りのデータファイルを、クラスタ・ファイルシステムにアーカイブREDOログ・ファイルを格納できます。
|
関連項目:
|
Oracle ASMは、高パフォーマンスで管理しやすいOracle Databaseファイルのストレージ・ソリューションです。Oracle ASMはボリューム・マネージャであり、データベースでのみ使用できるよう設計されたファイルシステムが備えられています。
Oracle ASMには、従来のファイルシステムおよびストレージ・マネージャと比較して、次のような利点があります。
データベースの作成およびレイアウトやディスク領域の管理など、ストレージ関連のタスクが簡略化されます。
複数の物理ディスクにわたってデータが配分されるため、ホットスポットがなくなり、ディスク間のパフォーマンスが均一になります。
ストレージ構成が変わると、データのバランスが自動的に再調整されます。
Oracle ASMを使用するには、ストライプ化およびミラー化のプリファレンスを使用して、Oracle Databaseのパーティション化したディスクを割り当てます。Oracle ASMによってディスク領域が管理され、使用可能なすべてのリソースにI/O負荷が配分されるため、I/Oを手動でチューニングしなくてもパフォーマンスが最適化されます。たとえば、データベースを停止しなくても、データベースのディスクのサイズを増加し、データベースの一部を新しいデバイスに移動できます。
Oracle Databaseでは、データファイルをOracle ASMディスク・グループ内のOracle ASMファイルとして格納でき、Oracle ASMディスク・グループとは、1つの単位としてOracle ASMで管理される、ディスクのコレクションのことです。ディスク・グループ内では、各データベース・ファイルに使用するファイルシステム・インタフェースがOracle ASMによって公開されます。
図11-2に、Oracle ASMを使用するデータベース内のストレージ・コンポーネント間の関係を示します。このダイアグラムは、Oracle ASMファイルとデータファイルの間の関係を表していますが、Oracle ASMには他のタイプのファイルも格納できます。線の末端の分岐は、1対多の関係を表しています。
図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によって公開されます。ディスク・グループに格納される各ファイルの内容は均等に配分(つまりストライプ化)されるため、ホットスポットがなくなり、ディスク間のパフォーマンスが均一化されます。このパフォーマンスは、RAWデバイスのパフォーマンスに匹敵します。
Oracle ASMファイル
Oracle ASMファイルは、Oracle ASMディスク・グループに格納されるファイルです。Oracle Databaseは、ファイルに関してOracle ASMと通信します。データベースには、データファイル、制御ファイル、オンラインREDOログ・ファイルなどの様々なファイルをOracle ASMファイルとして格納できます。データベースから要求されると、Oracle ASMによってOracle ASMファイルが作成され、プラス記号(+)の後にディスク・グループ名が続く完全修飾名(+DISK1など)が、このファイルに割り当てられます。
|
注意: Oracle ASMファイルは、RAWディスクやサード・パーティのファイルシステムなど他のストレージ管理オプションと共存できます。この機能により、Oracle ASMを既存の環境に統合する作業が簡素化されます。 |
Oracle ASMエクステント
Oracle ASMエクステントは、Oracle ASMファイルの内容を保持するために使用されるRAWストレージです。1つのOracle ASMファイルは1つ以上のファイル・エクステントで構成されます。それぞれのOracle ASMエクステントは、特定のディスク上にある1つ以上の割当て単位で構成されます。
Oracle ASM割当て単位
割当て単位とは、ディスク・グループ内での割当ての基本単位です。割当て単位は、Oracle ASMによって割り当てられる最小の連続するディスク領域になります。1つ以上の割当て単位によって、1つのOracle ASMエクステントが構成されます。
|
関連項目:
|
Oracle ASMインスタンスは、Oracle ASMディスクを管理する特殊なOracleインスタンスです。ASMインスタンスとデータベース・インスタンスは両方ともASMディスク・グループ内のディスクへの共有アクセスを必要とします。ASMインスタンスはディスク・グループのメタデータを管理し、データベース・インスタンスにファイル・レイアウト情報を提供します。データベース・インスタンスは、ASMインスタンスにアクセスせずに、ASMディスクに対してダイレクトI/Oを実行します。
ASMインスタンスは、データベース・インスタンスと同じテクノロジに基づいて構築されます。たとえば、ASMインスタンスには、データベース・インスタンスと同様のシステム・グローバル領域(SGA)およびバックグラウンド・プロセスがあります。ただし、ASMインスタンスではデータベースをマウントできず、実行されるタスクもデータベース・インスタンスより少なくなります。
図11-3に、Oracle ASMインスタンスが1つとデータベース・インスタンスが2つあり、それぞれが異なる単一インスタンス・データベースに関連付けられている単一ノード構成を示します。このASMインスタンスによってメタデータが管理され、2つのデータベースのデータが格納されているASMファイルの領域が割り当てられます。一方のASMディスク・グループにはASMディスクが4つあり、もう一方には2つあります。いずれのデータベース・インスタンスも、これらのディスク・グループにアクセスできます。
|
関連項目:
|
Oracle Managed Filesとは、ファイル名ではなく、データベース・オブジェクトの観点で操作を指定できるようにするためのファイル命名方法です。たとえば、表領域のデータファイルの名前を指定しなくても、表領域を作成できます。このため、Oracle Managed Filesでは、データベース内のオペレーティング・システム・ファイルを管理者が直接管理する必要がなくなります。Oracle ASMではOracle Managed Filesが必要です。
ユーザー管理ファイルを使用すると、データベース内のオペレーティング・システム・ファイルをユーザーが直接管理できます。ユーザーは、ファイルの構造および名前を決定できます。たとえば、表領域を作成する場合は、表領域データファイルの名前とパスを設定します。
初期化パラメータを使用して、特定タイプのファイルに使用するファイルシステム・ディレクトリを指定します。Oracle Managed Filesの主な役割は、データベースによって一意のファイルが作成され、そのファイルが不要になったら削除されるようにすることです。データベースでは、標準のファイルシステム・インタフェースを内部で使用して、データファイルと一時ファイル、制御ファイル、および高速リカバリ領域に格納されているリカバリ関連ファイルなどのファイルが作成および削除されます。
Oracle Managed Filesを使用しても、既存の機能は削除されません。以前のファイルを手動で管理しながら、新しいファイルを作成できます。このため、データベースにはOracle Managed Filesとユーザー管理ファイルが混在する場合があります。
|
関連項目: Oracle Managed Filesの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Databaseでは、オペレーティング・システム・レベルで、データベース・データがデータファイルに格納されます。すべてのデータベースには、少なくとも1つのデータファイルが必要です。
第IV部「Oracleリレーショナル・データ構造」では、ユーザーがデータを格納する論理構造について説明しましたが、この中で最も重要なデータは表です。パーティション化されていない各スキーマ・オブジェクトと各オブジェクトのパーティションは、それぞれ独自のセグメントに格納されます。
Oracle Databaseでは、管理を容易にするために、セグメントと同様の論理記憶域構造である表領域内のユーザー・データに領域が割り当てられます。各セグメントは、1つの表領域にのみ属します。たとえば、パーティション化されていない表のデータは1つのセグメントに格納され、このセグメントは1つの表領域に格納されます。
Oracle Databaseでは、表領域データがデータファイルに物理的に格納されます。表領域とデータファイルは密接に関連していますが、次のような重要な違いがあります。
各表領域は1つ以上のデータファイルから構成され、このデータファイルはOracle Databaseを実行しているオペレーティング・システムに準拠します。
データベースのデータは、そのデータベースの各表領域内にあるデータファイルにまとめて格納されます。
セグメントは1つ以上のデータファイルにまたがることがありますが、複数の表領域にまたがることはありません。
データベースには、SYSTEM表領域とSYSAUX表領域が必要です。Oracle Databaseでは、データベースの作成時に、データベースの最初のデータファイルがSYSTEM表領域に自動的に割り当てられます。
SYSTEM表領域には、データベースのメタデータを含む一連の表であるデータ・ディクショナリが含まれています。通常、データベースにはUNDO表領域と一時表領域(通常の名前はTEMP)もあります。
図11-4に、表領域、データファイルおよびセグメントの関係を示します。
永続表領域には、永続スキーマ・オブジェクトが含まれています。永続表領域内のオブジェクトはデータファイル内に格納されます。
一時表領域には、セッションの持続時間中のみスキーマ・オブジェクトが存在します。ローカルで管理される一時表領域には、ハッシュやソートなどの操作でデータを格納するための特殊なファイルである(一時ファイル)が含まれています。一時ファイルには、メモリー内の領域が不足したときの結果セットのデータも格納されます。
一時ファイルは永続データファイルと似ていますが、次のような例外があります。
表などの永続データベース・オブジェクトは、一時ファイルには格納されません。
一時ファイルは常にNOLOGGINGモードに設定され、これは、一時ファイルにはREDOが生成されないということを意味します。メディア・リカバリは一時ファイルを認識しません。
一時ファイルを読取り専用にすることはできません。
ALTER DATABASE文では一時ファイルを作成できません。
一時ファイルを作成またはサイズ変更する場合、指定したファイル・サイズのディスク領域が常に保証されるとはかぎりません。LinuxやUNIXなどのファイルシステムでは、一時ファイルはスパース・ファイルとして作成されます。この場合、ディスク・ブロックはファイルの作成時やサイズ変更時ではなく、最初にブロックがアクセスされるときに割り当てられます。
|
注意: スパース・ファイルを使用すると、一時ファイルの作成とサイズ変更が素早く行えますが、一時ファイルにアクセスしたときに、ディスク領域が不足する可能性があります。 |
一時ファイルの情報は、データ・ディクショナリ・ビューDBA_TEMP_FILESと動的パフォーマンス・ビューV$TEMPFILEには表示されますが、DBA_DATA_FILESビューやV$DATAFILEビューには表示されません。
すべてのデータファイルは、オンライン(使用可能)またはオフライン(使用不可能)のいずれかです。個々のデータファイルまたは一時ファイルの可用性は、ファイルをオフラインにするか、オンラインにして変更できます。オフラインのデータファイルには、ファイルが再びオンラインになるまでアクセスできません。
管理者がデータファイルをオフラインにする理由は、オフライン・バックアップの実行、データファイルの名前変更、ブロックの破損など数多くあります。データベースでは、データファイルに書き込めない場合に、ファイルが自動的にオフラインになります。
データファイルと同様に、表領域自体もオフラインまたはオンラインになります。オンラインの表領域にあるデータファイルをオフラインにしても、表領域自体はオンラインのままです。表領域自体をオフラインにすると、表領域のすべてのデータファイルを一時的に使用不可能にできます。
Oracle Databaseでは、表領域のデータファイルを作成する際に、指定されたディスク領域に加えて、データファイル・ヘッダーのオーバーヘッドの領域が割り当てられます。Oracle Databaseを実行するオペレーティング・システムによって、ファイルから古い情報や認可が消去された後、そのファイルがデータベースに割り当てられます。
データファイル・ヘッダーには、サイズやチェックポイントSCNなど、データファイルに関するメタデータが含まれています。各ヘッダーには、絶対ファイル番号と相対ファイル番号が含まれます。絶対ファイル番号は、データベース内でデータファイルを一意に識別します。相対ファイル番号は、表領域内でデータファイルを一意に識別します。
Oracle Databaseでデータファイルが初めて作成されると、割り当てられたディスク領域がフォーマットされますが、ユーザー・データは含まれません。ただし、データベースでは、関連付けられた表領域の将来のセグメントのデータを保持する領域が確保されます。Oracle Databaseでは、表領域内のデータが増加すると、データファイル内の空き領域を使用してセグメントにエクステントを割り当てます。
図11-5に、データファイル内の各種の領域を示します。エクステントは、使用中(セグメント・データが含まれている場合)または空き(再使用が可能な場合)のいずれかです。表領域内のオブジェクトの更新または削除が繰り返されると、単独では新しいデータに再使用できるほど大きくはないものの、孤立した空き領域ができる場合があります。このような空き領域を断片化空き領域と呼びます。
|
関連項目: データファイル情報の表示方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。 |
データベースの制御ファイルは、1つのデータベースのみに関連付けられた小さなバイナリ・ファイルです。各データベースには一意の制御ファイルが1つありますが、複数の同一コピーが保持される場合もあります。
制御ファイルは、データベース・ファイルの検索やデータベース全体の状態の管理にOracle Databaseで使用されるルート・ファイルです。制御ファイルには、次のような情報が含まれています。
データベースを作成したときのタイムスタンプ
データファイル、オンライン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ログ・ファイルを使用すると、Oracle Databaseではまだデータファイルに書き込まれていないコミット済のデータをリカバリできます。
Oracle Databaseでは、すべてのトランザクションがREDOログ・バッファと同期して書き込まれ、その後、REDOログ・バッファがオンラインREDOログに書き込まれます。ログの内容には、コミットされていないトランザクション、UNDOデータ、スキーマおよびオブジェクトの管理文などがあります。
Oracle Databaseでは、オンラインREDOログはリカバリにのみ使用されます。ただし、管理者はOracle LogMinerユーティリティでSQLインタフェースを使用して、オンラインREDOログ・ファイルを問い合せることができます(「Oracle LogMiner」を参照)。REDOログ・ファイルは、データベース・アクティビティに関する履歴情報の入手に役立ちます。
データベース・インスタンスのオンラインREDOログは、REDOスレッドと呼ばれます。単一インスタンス構成では、1つのインスタンスしかデータベースにアクセスできないため、REDOスレッドは1つのみです。ただし、Oracle Real Application Clusters(Oracle RAC)構成では、複数のインスタンスが同時にデータベースにアクセスし、各インスタンスには独自のREDOスレッドがあります。インスタンスごとにREDOスレッドを分けると、オンラインREDOログ・ファイルの1つの集合に対する競合を回避できます。
オンラインREDOログは、複数のオンラインREDOログ・ファイルで構成されています。Oracle Databaseでは、ファイルの1つがアーカイブ中であっても(データベースがARCHIVELOGモードの場合)、もう1つのファイルが常に書込み可能であることを保証するため、少なくとも2つ以上のファイルが必要です。
|
関連項目: Oracle RAC内のオンラインREDOログ・グループの詳細は、『Oracle Database 2日でReal Application Clustersガイド』および『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Databaseでは、オンラインREDOログ・ファイルを一度に1つのみ使用して、REDOログ・バッファから書き込まれるレコードを格納します。ログ・ライター(LGWR)プロセスによる書込みがアクティブなオンラインREDOログ・ファイルは、現行のオンラインREDOログ・ファイルと呼ばれます。
ログ・スイッチは、データベースで1つのオンラインREDOログ・ファイルへの書込みが停止し、別のファイルへの書込みが開始するときに発生します。スイッチは通常、現行のオンラインREDOログ・ファイルがいっぱいになり、さらに書込みを継続する必要があるときに発生します。ただし、ログ・スイッチは、現行のオンラインREDOログ・ファイルがいっぱいになったかどうかに関係なく、定期的にログ・スイッチが発生するように構成し、手動で強制的に実行できます。
ログ・ライターでは、オンラインREDOログ・ファイルが循環的に書き込まれます。ログ・ライター・プロセスは、使用可能な最後のオンラインREDOログ・ファイルがいっぱいになると、最初のログ・ファイルへ書き込み、循環が再び始まります。図11-6に、REDOログの循環書込みを示します。
図11-6の数字は、それぞれのオンラインREDOログ・ファイルへのLGWRによる書込みの順序を示しています。データベースでは、ログ・スイッチが発生し、ログ・ライターが書込みを開始したときに、各ファイルに新しいログ順序番号を割り当てます。データベースでオンラインREDOログ・ファイルが再使用されると、このファイルには次に使用可能なログ順序番号が与えられます。
いっぱいになったオンラインREDOログ・ファイルは、アーカイブ・モードに応じて再利用できます。
アーカイブが無効、つまりデータベースがNOARCHIVELOGモードの場合、ファイルに記録された変更のチェックポイント(書込み)処理がデータベース・ライター(DBW)によってディスクに実行されるまで、いっぱいになったオンラインREDOログ・ファイルを使用できません。
アーカイブが有効、つまりデータベースがARCHIVELOGモードの場合は、変更がデータファイルに書き込まれ、そのファイルがアーカイブされた後、いっぱいになったオンライン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では、異なるグループのメンバーに同時に書き込まれることはありません。
|
注意: オンラインREDOログは、多重化することをお薦めします。ログ・ファイルの損失は、リカバリが必要な場合に壊滅的な被害を招く可能性があります。オンラインREDOログを多重化する場合は、データベースで実行されるI/Oの量が増加します。システムによっては、I/Oをこのように追加すると、データベース全体のパフォーマンスに影響を与える場合があります。 |
|
関連項目: オンラインREDOログ・ファイルの複数コピーを維持する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
アーカイブREDOログ・ファイルとは、オンラインREDOログ・グループ内のいっぱいになったメンバーのコピーです。このファイルはデータベースの一部とはみなされませんが、データベースによって作成されたオンラインREDOログ・ファイルのオフライン・コピーであり、ユーザーが指定した場所に書き込まれます。
アーカイブREDOログ・ファイルは、バックアップおよびリカバリ計画にとって重要です。アーカイブREDOログ・ファイルは、次の目的に使用できます。
データベース・バックアップのリカバリ
スタンバイ・データベースの更新(「コンピュータ障害」を参照)
LogMinerユーティリティの使用によるデータベースの履歴情報の取得(「Oracle LogMiner」を参照)
アーカイブとは、アーカイブREDOログ・ファイルを生成する操作です。アーカイブは自動の場合と手動の場合があり、データベースがARCHIVELOGモードの場合のみ実行可能です。
アーカイブREDOログ・ファイルには、オンラインREDOログ・グループの同一メンバーのREDOエントリ、およびログ順序番号が含まれています。図11-7では、ファイルA_LOG1とB_LOG1がグループ1の同一メンバーです。データベースがARCHIVELOGモードで、自動アーカイブが有効になっている場合は、アーカイバ・プロセス (ARCn)によってこれらのファイルの1つがアーカイブされます。A_LOG1が破損している場合は、B_LOG1をアーカイブできます。アーカイブREDOログには、アーカイブを有効にした後に作成されたすべてのグループのコピーが含まれます。
オンラインREDOログ・ファイルには、REDOレコードが含まれています。REDOレコードは、変更ベクトルのグループで構成され、それぞれの変更ベクトルは、データ・ブロックに対する変更を表します。たとえば、employees表の給与を更新すると、この表のデータ・セグメント・ブロック、UNDOセグメント・データ・ブロックおよびUNDOセグメントのトランザクション表に対する変更を記述するREDOレコードが生成されます。
REDOレコードには、変更に関係するすべてのメタデータが設定されます。たとえば、次のものがあります。
変更のSCNおよびタイムスタンプ
変更が生成されたトランザクションのトランザクションID
トランザクションがコミットされたときのSCNおよびタイムスタンプ(トランザクションがコミットされた場合)
変更を実行した操作のタイプ
変更されたデータ・セグメントの名前およびタイプ
