| Oracle® Database概要 11gリリース2 (11.2) B56306-06 |
|
 前 |
 次 |
この章では、論理記憶域構造の性質と論理記憶域構造間の関係について説明します。これらの構造は、Oracle Databaseによって作成されて認識されるものであり、オペレーティング・システムでは認識されません。
Oracle Databaseでは、データベース内のすべてのデータに対して論理領域が割り当てられます。データベース領域の論理単位は、データ・ブロック、エクステント、セグメントおよび表領域です。物理レベルでは、データはディスク上のデータファイルに格納されます(第11章「物理記憶域構造」を参照)。データファイル内のデータは、オペレーティング・システムのブロックに格納されます。
図12-1に、物理記憶域と論理記憶域のエンティティ関係ダイアグラムを示します。線の末端の分岐は、1対多の関係を表しています。
図12-2に、表領域内のデータ・ブロック、エクステントおよびセグメント間の関係を示します。この例では、1つのセグメントに対して、異なるデータファイルに格納された2つのエクステントがあります。
Oracle Databaseデータの最小レベルでの格納単位は、データ・ブロックです。1つの論理データ・ブロックは、一定のバイト数(たとえば2KB)の物理ディスク領域に対応します。データ・ブロックは、Oracle Databaseで使用または割当て可能な記憶域の最小単位です。
エクステントとは、論理的に連続する一連のデータ・ブロックで、特定のタイプの情報を格納するために割り当てられます。図12-2では、24KBのエクステントには12のデータ・ブロックが存在し、72KBのエクステントには36のデータ・ブロックが存在しています。
セグメントとは、表などの特定のデータベース・オブジェクトのために割り当てられるエクステントの集合です。たとえば、employees表のデータはそれぞれ専用のデータ・セグメントに格納されており、employeesの各索引はそれぞれ専用の索引セグメントに格納されています。記憶域を使用する各データベース・オブジェクトは、1つのセグメントを構成します。
各セグメントは、1つの表領域にのみ属しています。このため、1つのセグメントのすべてのエクステントは、同じ表領域に格納されます。図12-2に示すように、表領域内のセグメントには、複数のデータファイルのエクステントが含まれている場合があります。たとえば、セグメントのあるエクステントはusers01.dbfに格納され、他のセグメントはusers02.dbfに格納されます。1つのエクステントが複数のデータファイルにまたがることはありません。
Oracle Databaseでは、表領域内でエクステントの追跡および割当てを行うために論理領域管理を使用する必要があります。データベース・オブジェクトでエクステントが必要な場合、データベースには、エクステントを検索および提供する手段が必要です。同様に、オブジェクトでエクステントが不要になった場合、データベースに空きエクステントを使用可能にする手段が必要です。
Oracle Databaseでは、作成する表領域のタイプに基づいて、表領域内の領域が管理されます。次のいずれかのタイプの表領域を作成できます。
ローカル管理表領域(デフォルト)
エクステントの管理に、表領域自体にあるビットマップが使用されます。したがって、ローカル管理表領域の一部には、ビットマップ用の表領域があります。表領域内のセグメントは、自動セグメント領域管理(ASSM)または手動セグメント領域管理(MSSM)を使用して管理できます。
ディクショナリ管理表領域
エクステントの管理に、データ・ディクショナリが使用されます(「データ・ディクショナリの概要」を参照)。
図12-3に、表領域の論理領域管理の方法を示します。
ローカル管理表領域では、データファイル・ヘッダー内に、データファイル本体の空き領域および使用済領域を追跡するためのビットマップが保持されています。各ビットは、1ブロック・グループに対応します。領域が割り当てられるか、解放されると、Oracle Databaseでは、ビットマップの値がブロックの新しい状態を反映する値に変更されます。
ビットマップ管理記憶域を概念的に表現すると、次の図のようになります。ヘッダー内の1は使用済領域を表し、0は空き領域を表します。
ローカル管理表領域には、次のような利点があります。
エクステントの管理にデータ・ディクショナリを使用する必要がありません。
ディクショナリ管理表領域では、エクステント内の領域を使用または解放することにより、データ・ディクショナリ表やUNDOセグメントの領域を使用または解放する他の操作が行われた場合、再帰的な操作が発生することがあります。
隣接する空き領域が自動的に追跡されます。
これにより、データベースで空きエクステントを結合する必要がなくなります。
ローカル管理エクステントのサイズが自動的に決定されます。
また、ローカル管理表領域内では、すべてのエクステントを同じサイズにすることもでき、さらにオブジェクト記憶域オプションがオーバーライドされます。
|
注意: ローカル管理表領域と自動セグメント領域管理を使用することをお薦めします。 |
セグメント領域管理は、セグメントを含む表領域から継承される属性です。ローカル管理表領域内では、セグメントは自動または手動で管理できます。たとえば、表領域users内はセグメントを自動で、表領域tools内のセグメントは手動で管理できます。
ASSM方式では、領域の管理にビットマップが使用されます。ビットマップには、次の利点があります。
管理の簡素化
ASSMでは、多数の記憶域パラメータの設定を手動で厳密に決定する必要がありません。唯一の重要なSQLパラメータPCTFREEによって、領域割当てが制御されます。このパラメータは、将来の更新用にブロック内に予約する領域の割合を指定します(「データ・ブロック内の空き領域の割合」を参照)。
同時実行性の向上
複数のトランザクションで別々の空きデータ・ブロックのリストを検索できるため、競合や待機時間が減少します。多数の標準的なワークロードでは、適切にチューニングされた、MSSMを使用するアプリケーションよりも、ASSMを使用するアプリケーションの方が高いパフォーマンスを示します。
Oracle Real Application Clusters(Oracle RAC)環境における、インスタンスへの領域の動的アフィニティ
ASSMは永続的なローカル管理表領域に対するデフォルトであり、より効率的です。
|
注意: この章では、論理記憶域のすべての説明において、ASSMを使用することを前提としています。 |
従来のMSSM方式では、空きリストと呼ばれるリンク・リストを使用して、セグメントの空き領域が管理されます。空き領域が存在するデータベース・オブジェクトでは、空きリストによって、使用済のセグメント領域と未使用のセグメント領域を分割するラインである最高水位標(HWM)より下のブロックが追跡されます。ブロックが使用済になると、データベースは必要に応じて、空きリストにブロックを登録したり、空きリストからブロックを削除したりします。
MSSMでは、PCTFREE以外にもPCTUSED、FREELISTS、FREELIST GROUPSなどのSQLパラメータを使用して、領域割当てを制御する必要があります。PCTUSEDでは、現在使用されているブロックが空きリストに登録されるためには、どの程度の空き領域が必要なのかの割合を設定します。たとえば、CREATE TABLE文でPCTUSEDを40に設定すると、ブロックの使用済領域の割合が40%未満になるまでは、セグメント内のブロックに行を挿入できません。
例として、表に行を挿入するとします。データベースは表の空きリストを参照し、最初の空き領域がどこなのかをチェックします。行がブロックに格納し切れず、ブロック内の使用済領域がPCTUSED以上になっている場合、そのブロックはリストから除外され、別のブロックが検索されます。ブロックから行を削除した場合は、ブロック内の使用済領域がPCTUSED未満になったかどうかがチェックされます。PCTUSED未満になった場合は、そのブロックが空きリストの先頭に登録されます。
1つのオブジェクトに対して、空きリストを複数にすることもできます。こうしておくと、表に対してDMLを実行している複数のセッションが別々のリストを使用できるため、競合を回避できます。各データベース・セッションがセッション中に使用する空きリストは1つです。
図12-4に示すように、1つ以上の空きリスト・グループ(空きリストの集合)が存在するオブジェクトを1つ作成することもできます。各グループにはマスター空きリストがあり、グループ内の各プロセス空きリストを管理します。空きリストに必要な領域は、特に空きリスト・グループの場合、大きくなることがあります。
セグメント領域を手動で管理する手順は複雑です。行の移行(「行の連鎖と移行」を参照)を少なくし、領域を無駄にしないようにするには、PCTFREEおよびPCTUSEDを調整する必要があります。たとえぱ、セグメント内のどの使用済ブロックも半分の領域がいっぱいになっており、PCTUSEDが40になっている場合は、これらのブロックのいずれにも挿入できません。領域割当てパラメータの詳細なチューニングは難しいため、ASSMの使用をお薦めします。ASSMでは、ブロックに新しい行を挿入可能かどうかを判断するためにPCTFREEが使用されますが、空きリストは使用されず、PCTUSEDは無視されます。
|
関連項目:
|
ディクショナリ管理表領域では、データ・ディクショナリを使用してそのエクステントが管理されます。Oracle Databaseでは、エクステントが割り当てられたり、再利用のために解放されるたびに、データ・ディクショナリ内の表が更新されます。たとえば、表でエクステントが必要な場合は、データ・ディクショナリ表が問い合せられ、空きエクステントが検索されます。領域が見つかると、あるデータ・ディクショナリ表が変更され、別のデータ・ディクショナリ表に行が挿入されます。このようにデータを変更および移動することによって、領域が管理されます。
データベース・オブジェクト用の領域を取得するため、データベースでバックグラウンドで実行されるSQLは、再帰的SQLです。データ・ディクショナリへの更新はシリアライズされる必要があるため、再帰的SQLを頻繁に使用するとパフォーマンスに悪影響を与える可能性があります。デフォルトのローカル管理表領域では、このようなパフォーマンス上の問題は回避されます。
|
関連項目: ディクショナリ管理表領域からローカル管理表領域への移行方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Databaseでは、データベースのデータファイル内の論理記憶域は、データ・ブロックと呼ばれる単位で管理されます(データ・ブロックは、Oracleブロックまたはページとも呼ばれます)。データ・ブロックは、データベースI/Oの最小単位です。
物理レベルでは、データベースのデータは、オペレーティング・システム・ブロックによって構成されているディスク・ファイル内に格納されます。オペレーティング・システム・ブロックは、オペレーティング・システムが読取りまたは書込みできるデータの最小単位です。一方、Oracleブロックは、論理記憶域構造であり、そのサイズや構造はオペレーティング・システムには認識されません。
図12-5に、オペレーティング・システム・ブロックのサイズがデータ・ブロックのサイズと異なる場合があることを示します。データベースでは、オペレーティング・システム・ブロックではなく、データ・ブロックの倍数を単位としてデータを要求します。
データベースがデータ・ブロックを要求すると、オペレーティング・システムは、この操作を永続ストレージ内のデータに対する要求に変換します。データ・ブロックをオペレーティング・システム・ブロックから論理的に分離することは、次のことを意味します。
アプリケーションでは、データのディスク上の物理アドレスを特定する必要がありません。
データベースのデータは、複数の物理ディスクにストライプ化またはミラー化できます。
すべてのデータベースには、データベース・ブロック・サイズがあります。DB_BLOCK_SIZE初期化パラメータでは、データベース作成時のデータ・ブロック・サイズが設定されます。このサイズは、SYSTEM表領域およびSYSAUX表領域に対して設定され、他のすべての表領域のデフォルトとなります。データベース・ブロック・サイズは、データベースを再作成する場合以外は変更できません。
DB_BLOCK_SIZEが設定されていない場合、デフォルトのデータ・ブロック・サイズは、オペレーティング・システム固有のサイズになります。データベースの標準的なデータ・ブロック・サイズは、4KBまたは8KBです。データ・ブロックのサイズとオペレーティング・システム・ブロックのサイズが異なる場合、データ・ブロックのサイズは、オペレーティング・システム・ブロックのサイズの倍数である必要があります。
|
関連項目:
|
DB_BLOCK_SIZEの設定とは異なるブロック・サイズの表領域を個別に作成できます。非標準のブロック・サイズは、トランスポータブル表領域を別のプラットフォームに移動する場合に役立ちます。
|
関連項目: 表領域に非標準のブロック・サイズを指定する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
すべてのデータ・ブロックには、形式、つまりデータベースでのブロック内のデータや空き領域の追跡を可能にする内部構造があります。この形式は、データ・ブロックに表、索引、表クラスタのいずれのデータが含まれている場合でも同じです。図12-6に、非圧縮データ・ブロックの形式を示します(圧縮ブロックについては、「データ・ブロックの圧縮」を参照)。
Oracle Databaseでは、ブロック・オーバーヘッドを使用してブロック自体を管理します。ブロック・オーバーヘッドには、ユーザー・データは格納できません。図12-6に示すように、ブロック・オーバーヘッドには次の構成要素が含まれています。
ブロック・ヘッダーには、ディスク・アドレスやセグメント・タイプなどブロックについての一般的な情報が含まれています。トランザクション管理ブロックの場合、ブロック・ヘッダーにはアクティブなトランザクション情報とトランザクション履歴情報が含まれています。
ブロックを更新する各トランザクションには、トランザクション・エントリが必要です。Oracle Databaseでは、トランザクション・エントリ用の領域が最初にブロック・ヘッダーに予約されます。トランザクションによる変更をサポートするセグメントに割り当てられたデータ・ブロックでは、ヘッダー領域の空きがなくなると、トランザクション・エントリが空き領域にも保持されます。トランザクション・エントリに必要な領域のサイズは、オペレーティング・システムによって異なります。ただし、ほとんどのオペレーティング・システムで、トランザクション・エントリのサイズは約23バイトです。
ヒープ構成表では、このディレクトリには、該当するブロックに行を格納する表についてのメタデータが含まれています。複数の表の行が同じブロックに格納されることもあります。
行ディレクトリ
ヒープ構成表では、このディレクトリはブロックのデータ部分内の行の位置を示しています。
行ディレクトリに領域が割り当てられると、行が削除された後もこの領域は再利用されません。したがって、現在は空き状態でも、以前に最大50行が格納されていた場合は、行ディレクトリには100バイトが割り当てられたままになります。この領域は、ブロックに新しい行が挿入された場合にのみ再利用されます。
一部のブロック・オーバーヘッドはサイズが固定ですが、全体のサイズは可変です。ブロック・オーバーヘッド全体のサイズは、平均で84から107バイトです。
ブロックの行データ部分には、表の行や索引キー・エントリなどの実際のデータが格納されます。すべてのデータ・ブロックに内部形式があるように、すべての行に行形式があり、これにより、データベースにおける行のデータ追跡が可能になります。
Oracle Databaseでは、行は可変長レコードとして格納されます。行は、1つ以上の行断片に含まれています。各行断片は、行ヘッダーおよび列データで構成されます。
図12-7に、行の形式を示します。
Oracle Databaseでは、行ヘッダーを使用して、ブロック内に格納された行断片を管理します。行ヘッダーには、次のような情報が含まれています。
行断片内の列
他のデータ・ブロック内にある行の断片
Oracle Databaseでは、行全体を単一のデータ・ブロックに挿入できる場合、その行は1つの行断片として格納されます。ただし、行データのすべてを単一のブロックに挿入できない場合、または行の更新によって既存の行が単一のブロックに収まらなくなった場合には、その行は複数の行断片として格納されます(「行の連鎖と移行」を参照)。データ・ブロックには、通常1つの行につき1つの行断片のみが含まれています。
表クラスタのクラスタ・キー(「表クラスタの概要」を参照)
1つのブロックに完全に収まる行は、最低3バイトの行ヘッダーを持っています。
行ヘッダーの後ろにある列データ・セクションに、行の実際のデータが格納されます。行断片には通常、CREATE TABLE文で指定された順序で列が格納されますが、必ずこの順序であるとはかぎりません。たとえば、LONG型の列は最後に作成されます。
Oracle Databaseでは、図12-7に示すように、行断片内の各列の長さとデータが別々に格納されます。必要な領域のサイズは、データ型によって異なります。列のデータ型が可変長である場合、値を保持するために必要な領域は、データの更新によって変動します。
各行には、データ・ブロック・ヘッダーの行ディレクトリにスロットがあります。このスロットは行の先頭を指しています。
Oracle Databaseでは、ROWIDを使用して行が一意に識別されます。内部的には、ROWIDは、データベースが行にアクセスするために必要な情報を保持する構造です。ROWIDは、物理的にはデータベースに格納されませんが、データが格納されているファイルやブロックから推論されます。
拡張ROWIDには、データ・オブジェクト番号が含まれています。このROWIDタイプは、各行の物理アドレスをBASE64エンコーディングで表現したものです。エンコーディング文字は、AからZ、aからz、0から9、+および/です。
例12-1では、ROWID擬似列を問い合せて、employees表にある従業員100の行の拡張ROWIDを表示します。
例12-1 ROWID擬似列
SQL> SELECT ROWID FROM employees WHERE employee_id = 100; ROWID ------------------ AAAPecAAFAAAABSAAA
図12-8に、拡張ROWIDの形式を示します。
拡張ROWIDは、OOOOOOFFFBBBBBBRRRという4つの部分から構成される形式で表示されます。各部分の内容は、次のとおりです。
OOOOOO
セグメントを識別するデータ・オブジェクト番号(例12-1では、データ・オブジェクトAAAPecです)。データ・オブジェクト番号は、各データベース・セグメントに割り当てられます。同じセグメント内のスキーマ・オブジェクト(表クラスタなど)は、同じデータ・オブジェクト番号を持っています。
FFF
行を含むデータファイルを識別する表領域関連のデータファイル番号(例12-1では、ファイルAAFです)。
BBBBBB
行を含むブロックを識別するデータ・ブロック番号(例12-1では、ブロックAAAABSです)。ブロック番号は、表領域ではなくデータファイルに対する相対値です。このため、同じブロック番号の行が、同じ表領域の異なるデータファイルに存在することもあります。
RRR
ブロック内の行を識別する行番号(例12-1では、行AAAです)。
特殊な状況では、ROWIDが行断片に割り当てられた後、ROWIDが変更される場合があります。たとえば、行の移動が可能な場合、ROWIDは、パーティション・キーの更新、フラッシュバック表の操作、表の縮小操作などのために変更される可能性があります。行の移動が無効な場合は、Oracle Databaseユーティリティを使用して行をエクスポートおよびインポートした場合にROWIDが変更される可能性があります。
|
注意: 内部的には、行の移動は、行が物理的に削除されて再挿入されたものとして実行されます。ただし、行の移動は更新であるとみなされ、これはトリガーに影響します。 |
データベースでは、表の圧縮を使用して、データ・ブロック内の重複値を排除します(「表の圧縮」を参照)。この項では、圧縮を使用するデータ・ブロックの形式について説明します。
基本および高度な行圧縮を使用するデータ・ブロックの形式は、基本的には非圧縮ブロックの形式と同じです。相違点は、ブロックの先頭にあるシンボル表に、行および列の重複値が格納されることです。Oracle Databaseでは、発生した重複値はシンボル表の短い参照で置き換えられます。
例12-2の行が、7列で構成されたsales表のデータ・ブロックに格納されるとします。
例12-2 sales表の行
2190,13770,25-NOV-00,S,9999,23,161 2225,15720,28-NOV-00,S,9999,25,1450 34005,120760,29-NOV-00,P,9999,44,2376 9425,4750,29-NOV-00,I,9999,11,979 1675,46750,29-NOV-00,S,9999,19,1121
この表に基本または高度な行圧縮が適用されると、重複値がシンボル参照に置き換えられます。例12-3は、圧縮の概念を示しており、29-NOV-00がシンボル*、9999が%に置き換えられています。
例12-3 sales表のOLTP圧縮行
2190,13770,25-NOV-00,S,%,23,161 2225,15720,28-NOV-00,S,%,25,1450 34005,120760,*,P,%,44,2376 9425,4750,*,I,%,11,979 1675,46750,*,S,%,19,1121
表12-1は、シンボルを値にマップするシンボル表の概念を示します。
Oracle Databaseでは、データ・ブロックは下から順に使用されるため、行データとブロック・ヘッダー間の空き領域は減少します。この空き領域は、行の末尾のNULLがNULL以外の値に変更されるときなどの更新の際にも減少します。Oracle Databaseでは、パフォーマンスを最適化し、領域を無駄にしないようにするために、データ・ブロック内の空き領域が管理されます。
|
注意: この項では、自動セグメント領域管理の使用を前提としています。 |
PCTFREE記憶域パラメータは、データベースにおける空き領域の管理にとって不可欠です。このSQLパラメータでは、既存の行の更新用に空き領域として予約される領域の最小の割合を設定します。したがって、行の移行を防止し、領域を無駄にしないようにするためにPCTFREEが必要です。
たとえば、ほとんど更新されず、更新される場合でも既存のデータのサイズがほとんど増加しない表を作成するとします。CREATE TABLE文内のPCTFREEパラメータを次のように指定します。
CREATE TABLE test_table (n NUMBER) PCTFREE 20;
図12-9に、PCTFREEを20に設定した場合の領域管理への影響について示します。時間の経過とともにブロックに行が追加され、行データがブロック・ヘッダーの方向へ上向きに増加し、ブロック・ヘッダー自体も、行データの方向へ下向きに増加します。PCTFREEの設定によって、データ・ブロックの20%以上が空き領域となることが保証されます。たとえば、行を挿入すると行データとヘッダーの合計がブロック領域全体の90%を占め、空き領域が10%になる場合には、INSERT文は実行できません。
|
関連項目: PCTFREEパラメータの構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』 |
空き領域の割合は、PCTFREEよりも小さくなることはありませんが、大きくなることがあります。たとえば、PCTFREEを20%に設定すると、空き領域の合計がブロックの5%になることはありませんが、50%になることはあります。次のSQL文を使用すると、空き領域のサイズが増えます。
DELETE文
既存の値をより小さいサイズの値に更新するか、既存の値をより大きいサイズの値に更新して行の移行を強制するUPDATE文
OLTP圧縮を使用する表に対するINSERT文
挿入によってブロックがデータでいっぱいになると、データベースによってブロック圧縮が開始され、ブロックにより多くの空き領域が生じる可能性があります。
解放された領域は、次の条件下でINSERT文に使用できます。
INSERT文が同じトランザクション内に存在し、領域を解放した文の後にある場合、その文で使用可能になった領域を使用できます。
INSERT文が、領域を解放する文とは別のトランザクションに含まれている(別々のユーザーが実行している)場合、その文では、もう一方のトランザクションがコミットされた後で、しかもその領域が必要とされる場合にかぎり、使用可能になった領域を使用できます。
|
関連項目: OLTP圧縮の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
図12-10に示すように、解放された領域は、データ・ブロック内の主な空き領域と連続しているとはかぎりません。連続しない空き領域は、断片化領域と呼ばれます。
Oracle Databaseでは、次の条件に当てはまる場合にのみ、データ・ブロックの空き領域が自動的かつ透過的に結合されます。
INSERT文またはUPDATE文において、新しい行断片を格納するために十分な空き領域のあるブロックの使用が試行された場合。
空き領域が断片化されており、行断片をブロック内の連続したセクションに挿入できない場合。
結合後の空き領域のサイズは結合前と同じですが、領域は連続的に存在するようになります。図12-11に、領域結合後のデータ・ブロックを示します。
Oracle Databaseでは、前述の状況でのみ結合が実行されます。それ以外の状況で結合を実行すると、データ・ブロック内の空き領域が連続的に結合されることによって、パフォーマンスが低下する可能性があるためです。
データベースでは、索引ブロック内の領域を再利用できます。たとえば、ある列に値を挿入してから削除し、この列に索引が設定されている場合は、この索引が行で必要になったときに、索引スロットを再利用できます。
データベースでは、索引ブロック自体を再利用できます。表ブロックとは異なり、索引ブロックは空になったときにのみ解放されます。空になったブロックは索引構造の空きリスト上に配置され、再利用が可能となります。ただし、Oracle Databaseでは、索引は自動的には圧縮されず、ALTER INDEX REBUILD文またはCOALESCE文を実行する必要があります。
図12-12に、索引結合前のemployees.department_id列の索引を示します。最初の3つのリーフ・ブロックは、グレーの格納ラインで示されているように、まだ満杯ではありません。
図12-13に、図12-12の索引を結合した後の図を示します。最初の2つのリーフ・ブロックは、グレーの格納ラインで示されているように満杯になり、3つ目のリーフ・ブロックは解放されています。
|
関連項目:
|
Oracle Databaseでは、大きすぎる行を1つのブロック内に収まるように管理する必要があります。次の状況が考えられます。
最初に行を挿入するとき、大きすぎて1つのデータ・ブロック内に収まらない場合。
行連鎖では、Oracle Databaseにより、その行のデータは、セグメント用に確保された1つ以上のデータ・ブロックの連鎖に格納されます。多くの場合、行連鎖は、行が大きい場合に発生します。大きい行の例には、LONGまたはLONG RAWデータ型の列を含む行、2KBブロックにVARCHAR2(4000)の列が含まれる行、または行に含まれる列の数が多すぎる場合があります。そのような場合の行連鎖は、避けられません。
1つのデータ・ブロックに収まっていた行が更新されて、行全体の長さが増加したが、更新後の行を保持する十分な空き領域がない場合。
行の移行では、Oracle Databaseにより、行全体が新しいブロックに収まることを前提として、行全体が新しいデータ・ブロックに移動されます。移行された行の元の行断片には、行の移行先の新しいブロックへのポインタまたは「転送先アドレス」が含まれます。そのため、移動された行のROWIDは変わりません。
行に255を超える列が含まれる場合。
Oracle Databaseでは、1つの行断片に格納できる列数は、255列のみです。したがって、1000列の行を表に挿入すると、データベースでは通常、複数のブロックに連鎖された4つの行断片が作成されます。
図12-14に、データ・ブロックへの大きなサイズの行の挿入を示します。この行は左側のブロックには大きすぎて格納し切れないため、Oracle Databaseでは行を連鎖し、最初の行断片を左側のブロックに配置し、2つ目の行断片を右側のブロックに配置します。
図12-15では、左側のブロックには、更新によってサイズが増大してこのブロックに収まらなくなった行が格納されています。Oracle Databaseにより、この行全体が右側のブロックに移動され、この移行後の行へのポインタが左側のブロックに残されます。
行が連鎖または移行されると、データの取出しに必要なI/Oが増加します。これは、その行の情報を取り出す際に、Oracle Databaseが複数のブロックをスキャンする必要があるためです。たとえば、索引の読取りに対して1回のI/Oを行い、移行されていない表の行を読み取るために1回のI/Oを行う場合、移行された行のデータを取得するために追加のI/Oが必要になります。
セグメント・アドバイザは、再利用可能な領域のあるセグメントを特定するOracle Databaseコンポーネントであり、手動または自動で実行できます。セグメント・アドバイザを使用すると、多くの空き領域のあるオブジェクト、または多くの連鎖行があるオブジェクトについてのアドバイスを入手できます。
|
関連項目:
|
エクステントは、複数の連続したデータ・ブロックで構成される、データベース記憶域の割当ての論理単位です。エクステント内のデータ・ブロックは論理的に連続していますが、RAIDのストライプ化やファイルシステムの実装によって、物理的にはディスク上に断続的に存在する可能性があります。
データベースでは、セグメントが作成されたときにデータ・セグメント用の初期エクステントがデフォルトで割り当てられます。エクステントは、常に1つのデータファイルに含まれています。
セグメントにデータが追加されていない場合でも、初期エクステント内にこのセグメント専用のデータ・ブロックが予約されます。各セグメントの最初のデータ・ブロックには、そのセグメント内のエクステントのディレクトリが含まれています。図12-16に、データが含まれていなかったデータファイル内の、セグメントの初期エクステントを示します。
初期エクステントがいっぱいになり、さらに追加の領域が必要になると、データベースによって自動的にこのセグメントの増分エクステントが割り当てられます。増分エクステントは、セグメントに対して後から作成されるエクステントです。
割当てアルゴリズムは、ローカル管理表領域であるか、ディクショナリ管理表領域であるかに応じて異なります。ローカル管理表領域の場合は、データファイルのビットマップで、隣接する空きブロックが検索されます。データファイルに十分な領域がない場合は、他のデータファイルが検索されます。セグメントのエクステントは常に同じ表領域内に存在しますが、異なるデータファイル内に存在する場合もあります。
図12-17に、セグメントのエクステントは表領域内の任意のデータファイル内に割当て可能であることを示します。たとえば、セグメントの初期エクステントをusers01.dbfに、最初の増分エクステントをusers02.dbfに、次のエクステントをusers01.dbfに割り当てることができます。
新しく割り当てられたエクステントのブロックは、空き領域であったブロックですが、古いデータが残っていることがあります。ASSMでは、新たに割り当てられたエクステントの使用開始時に、Oracle Databaseによってそのエクステントのブロックがフォーマットされます(「セグメント領域と最高水位標」を参照)。
|
注意: この項は、1つのサーバー・プロセスによって文を解析して実行する、シリアル操作に適用されます。複数のサーバー・プロセスを必要とするパラレルSQL文では、エクステントは異なる方法で割り当てられます。 |
|
関連項目: 手動でのエクステントの割当て方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
一般的に、ユーザー・セグメントのエクステントは、DROPコマンドを使用してオブジェクトを削除するまでは表領域に戻されません。Oracle Database 11gリリース2(11.2.0.2)では、DBMS_SPACE_ADMINパッケージを使用してセグメントを削除することもできます。たとえば、表の行をすべて削除しても、データベースによりデータ・ブロックが再利用されて表領域内の他のオブジェクトがそれらのブロックを使用できるようになることはありません。
|
注意: UNDOセグメントでは、サイズにOPTIMALが指定されている場合、またはデータベースが自動UNDO管理モードである場合には、Oracle Databaseにより定期的に1つ以上のエクステントの割当てが解除されます(「UNDO表領域」を参照)。 |
領域の割当てを手動で解除できる場合もあります。Oracle Segment Advisorは、オブジェクト内の断片化のレベルに応じて、オブジェクトに再利用可能な領域があるかどうかを判断する際に役立ちます。次の方法でエクステントを解放できます。
オンラインでのセグメントの縮小を使用して、セグメント内の断片化された領域を再利用します。セグメントの縮小は、オンラインのインプレース操作です。一般的に、データ圧縮によって、より効率的にキャッシュを利用できるようになり、全表スキャン時に読み取る必要があるブロック数が少なくなります。
パーティション化されていない表や表パーティションのデータを新しいセグメントに移動し、必要であれば割当て制限を持つ別の表領域に移動できます。
索引を再構築または結合します(「索引領域の再利用」を参照)。
表または表クラスタを切り捨てて、すべての行を削除します。デフォルトで、Oracle Databaseでは、MINEXTENTS記憶域パラメータで指定されたサイズを除き、削除された行で使用していたすべての領域の割当てが解除されます。Oracle Database 11gリリース2(11.2.0.2)では、DROP ALL STORAGEオプションを指定してTRUNCATEを使用すれば、セグメント全体を削除することもできます。
未使用領域の割当てを解除して、データベース・セグメントの最後の最高水位標付近の未使用領域を解放し、表領域内の他のセグメントがその領域を使用できるようにします(「セグメント領域と最高水位標」を参照)。
エクステントが解放されると、Oracle Databaseでは、ローカル管理表領域のデータファイル内のビットマップを変更し、再度取得されたエクステントを使用可能領域として反映します。解放されたエクステントのブロックにあるデータにはアクセスできなくなります。
|
関連項目: セグメント領域の再利用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
各セグメントは、エクステントについての設定である記憶域パラメータによって定義されます。記憶域パラメータにより、Oracle Databaseで特定のセグメントに空き領域がどのように割り当てられるかが制御されます。
記憶域設定は、次に示す優先順位で決定されます。つまり、リストの上位の設定は下位の設定よりも優先されます。
セグメントのSTORAGE句
表領域のSTORAGE句
Oracle Databaseのデフォルト
ローカル管理表領域の場合は、均一のエクステント・サイズでも、システムによって自動的に決定される可変エクステント・サイズでもかまいません。
均一エクステントの場合は、エクステント・サイズを指定するか、デフォルト・サイズである1MBを使用できます。表領域内のすべてのエクステントが指定したサイズになります。ローカル管理一時表領域の場合は、均一サイズの割当てのみ使用できます。
自動割当てエクステントの場合は、追加エクステントの最適サイズがOracle Databaseにより自動的に決定されます。
ローカル管理表領域では、一部の記憶域パラメータは表領域レベルでは指定できません。ただし、これらのパラメータをセグメント・レベルで指定することはできます。この場合、データベースでは、すべてのパラメータをまとめて使用して、セグメントの初期サイズが計算されます。内部のアルゴリズムによって、その後に割り当てられる各エクステントのサイズが決定されます。
|
関連項目:
|
セグメントは、表領域内の特定の論理記憶域構造のデータがすべて入っている、エクステントの集合です。たとえば、Oracle Databaseでは、1つ以上のエクステントを割り当てることによって、表のデータ・セグメントを形成します。データベースでは、表の索引セグメントも、1つ以上のエクステントを割り当てることによって形成します。
「論理領域管理」で説明しているように、Oracle Databaseでは、セグメント領域は自動または手動で管理されます。この項では、ASSMを使用することを前提としています。
データベース内の1つのデータ・セグメントには、1つのユーザー・オブジェクトのデータが格納されます。セグメントには様々なタイプがあります。次に、ユーザー・セグメントの例を示します。
LOBまたはLOBパーティション
索引または索引パーティション
パーティション化されていない各オブジェクトおよび各オブジェクト・パーティションは、それぞれ独自のセグメントに格納されます。たとえば、索引に5つのパーティションがある場合は、5つのセグメントに索引データが格納されます。
デフォルトで、データベースでは遅延セグメント作成により、表や索引を作成する際、データベース・メタデータのみが更新されます。Oracle Database 11gリリース2(11.2.0.2)以降では、パーティションを作成する際に、セグメント作成の遅延も発生します。ユーザーが最初の行を表またはパーティションに挿入するときに、その表またはパーティション、LOB列およびその索引のセグメントが作成されます。
セグメントの作成は遅延するため、データベース・リソースを必要以上に使用しなくて済みます。たとえば、アプリケーションをインストールすると、数千ものオブジェクトが作成されて、ディスク領域を大量に消費する場合があります。このようなオブジェクトの多くは、実際には使用されない可能性があります。
DBMS_SPACE_ADMINパッケージを使用して、空のオブジェクト用のセグメントを管理できます。Oracle Database 11gリリース2(11.2.0.2)以降では、このPL/SQLパッケージを使用して次の操作を行うことができます。
セグメントが作成されていない空の表またはパーティション用のセグメントの手動マテリアライズ
空のセグメントが割り当てられている空の表またはパーティションからのセグメントの削除
オブジェクトの作成とセグメントの作成との関係がわかりやすくなるように、遅延セグメント作成は発生しないものとします。次のような表を作成するとします。
CREATE TABLE test_table (my_column NUMBER);
図12-18に示すように、表のセグメントが1つ作成されます。
主キーまたは一意キーを持つ表を作成する場合は、Oracle Databaseによって、このキーの索引が自動的に作成されます。ここでも、遅延セグメント作成は発生しないものとします。次のような表を作成するとします。
CREATE TABLE lob_table (my_column NUMBER PRIMARY KEY, clob_column CLOB);
図12-19は、lob_tableのデータがあるセグメントに格納され、暗黙的に作成された索引が別のセグメントに格納されることを示しています。また、CLOBデータは、関連付けられたCLOB索引と同様に、専用のセグメントに格納されます(「内部LOB」を参照)。したがって、CREATE TABLE文を実行すると4つの異なるセグメントが作成されます。
|
注意: 表のセグメントとその表の索引のセグメントは、同一の表領域に存在する必要はありません。 |
セグメントが作成されると、1つ以上のエクステントが割り当てられます。オブジェクトの記憶域パラメータによって、各セグメントに対するエクステントの割当て方法が決定されます(「エクステントの記憶域パラメータ」を参照)。これらのパラメータは、オブジェクトに関連するデータ・セグメントのデータ検索と格納の効率に影響を与えます。
|
関連項目:
|
Oracle Databaseでは、問合せの処理中に、SQL文実行の中間段階で、一時作業領域が必要になることがあります。一時セグメントが必要になる一般的な操作には、ソート、ハッシング、ビットマップのマージなどがあります。また、索引の作成中には索引セグメントも一時セグメントに配置され、索引の作成が完了すると、永続セグメントに変換されます。
Oracle Databaseでは、メモリー内で操作が完了する場合、一時セグメントは作成されません。ただし、メモリーを使用できない場合には、ディスク上に一時セグメントが自動的に割り当てられます。
Oracle Databaseでは、ユーザー・セッション中に必要に応じて問合せ用の一時セグメントが割り当てられ、問合せが完了すると削除されます。一時セグメントに対する領域管理操作以外の、一時セグメントに対する変更は、オンラインREDOログに記録されます(「オンラインREDOログの概要」を参照)。
データベースでは、ユーザーに割り当てられた一時表領域に一時セグメントが作成されます。表領域のデフォルトの記憶域特性によって、一時セグメント内のエクステントの特性が決定されます。一時セグメントの割当てと割当て解除は頻繁に発生するため、一時セグメント専用に1つ以上の表領域を作成してください。これにより、I/Oがディスク間で分散され、SYSTEM表領域やその他の一時セグメントがある表領域の断片化が回避されます。
|
注意: SYSTEM表領域がローカル管理の場合は、データベースの作成時にデフォルトの一時表領域を定義する必要があります。ローカル管理のSYSTEM表領域は、デフォルトの一時記憶域として使用できません。 |
|
関連項目:
|
Oracle Databaseでは、一時表およびその索引用に一時セグメントを割り当てることがあります。一時表には、トランザクションまたはセッションの期間中にのみ存在するデータが保持されます。各セッションは、そのセッションに割り当てられたエクステントにのみアクセスし、他のセッションに割り当てられたエクステントにはアクセスできません。
その表への最初のINSERTが発行されるときに、Oracle Databaseにより一時表のセグメントが割り当てられます。この挿入は、明示的に行われたものでも、CREATE TABLE AS SELECTによって行われたものでもかまいません。一時表に対する最初のINSERT文では、表とその索引にセグメントが割り当てられ、索引のルート・ページが作成され、LOBセグメントが割り当てられます。
一時表のセグメントは、現行ユーザーの一時表領域内で割り当てられます。user1に割り当てられた一時表領域がtemp1であり、user2に割り当てられた一時表領域がtemp2であるとします。この場合、user1の一時データはtemp1のセグメントに格納され、user2の一時データはtemp2のセグメントに格納されます。
Oracle Databaseには、UNDOデータと総称されている、トランザクションのアクションのレコードが保持されています。Oracle Databaseでは、次の場合にUNDOデータが使用されます。
アクティブ・トランザクションのロールバック
終了したトランザクションのリカバリ
読取り一貫性の実現
一部の論理フラッシュバック操作の実行
Oracle Databaseでは、UNDOデータは、外部ログではなくデータベース内部に格納されます。UNDOデータが格納されるブロックは、データ・ブロックと同様に更新され、これらのブロックに対する変更によってREDOデータが生成されます。このように、Oracle Databaseでは、外部ログを読み取ることなくUNDOデータに効率的にアクセスできます。
UNDOデータは、UNDO表領域に格納されます。Oracle Databaseには、UNDO表領域内のUNDOセグメントおよび領域を管理するための自動UNDO管理モードと呼ばれる完全に自動化されたメカニズムが提供されています。
トランザクションが開始するときに、そのトランザクションは、現在のUNDO表領域内のUNDOセグメント(トランザクション表)にバインド(割当て)されます。データベース・インスタンスに対し専用のUNDO表領域が割り当てられていない場合は、トランザクションがシステムUNDOセグメントにバインドされます。
複数のアクティブなトランザクションが、同じUNDOセグメントに同時に書き込むこともあれば、別々のセグメントに書き込むこともあります。たとえば、トランザクションT1とT2が両方ともU1というUNDOセグメントに書き込むこともあれば、T1がU1に書き込み、T2がU2というUNDOセグメントに書き込むこともあります。
概念的には、UNDOセグメント内のエクステントは輪のようなものです。トランザクションは、輪に沿って回るように、UNDOエクステントに順に書き込んでいきます。図12-20では、T1とT2という2つのトランザクションを示し、この2つのトランザクションはそれぞれ、UNDOセグメントの3番目のエクステント(E3)から書込みを開始し、4番目のエクステント(E4)まで書込みを進めます。
トランザクションは必ずUNDOセグメント内のエクステントに1つずつ順番に書き込み、その時点で書込み可能なエクステントをトランザクションの現行エクステントと呼びます。複数のアクティブなトランザクションが同時に、同じ現行エクステントに書き込むことも、別々の現行エクステントに書き込むことも可能です。図12-20では、T1とT2のトランザクションがエクステントE3に同時に書き込んでいます。UNDOエクステント内では、各データ・ブロックに格納されるデータは、1つのトランザクションのデータのみです。
現在のUNDOエクステントがいっぱいになると、領域を必要とする最初のトランザクションによって、輪の中にある次の割当てエクステントの空き状況がチェックされます。次のエクステントにアクティブなトランザクションのデータが格納されていない場合は、このエクステントが現行エクステントになります。この時点で、領域を必要としているすべてのトランザクションが、新しい現行エクステントに書込み可能な状態になります。図12-21では、E4がいっぱいになり、T1とT2がE1に書込みを継続し、E1内のアクティブでないUNDOデータを上書きしています。
次のエクステントにアクティブなトランザクションのデータが格納されている場合は、新しいエクステントが割り当てられます。図12-22では、T1とT2はE4に書き込んでいます。E4がいっぱいになっても、E1にはアクティブなUNDOデータが格納されているため、トランザクションはE1に書込みを継続することができません。そこで、このUNDOセグメントに新しいエクステント(E5)が割り当てられます。トランザクションはE5に書込みを継続します。
|
関連項目: UNDOセグメントの管理方法の詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。 |
ROLLBACK文が発行されると、UNDOレコードは、コミットされていないトランザクションによってデータベースに加えられた変更を元に戻すために使用されます。リカバリ中には、オンラインREDOログからデータファイルに適用されたコミットされていないすべての変更が元に戻されます。UNDOレコードでは、あるユーザーによるデータの変更中にそのデータにアクセスしているユーザー用に、そのデータの修正前のイメージを維持することで、読取り一貫性が実現されます。
Oracle Databaseでは、領域を管理するために、セグメント内のブロックの状態を追跡します。最高水位標(HWM)は、セグメント内の位置を指し示し、その位置を超えると、データ・ブロックは未フォーマットであり、使用されていません。
MSSMでは、空きリストを使用してセグメント領域が管理されます。表の作成時には、セグメント内のブロックはフォーマットされていません。セッションが最初に行を表に挿入すると、空きリストが検索され、使用可能なブロックが検出されます。使用可能なブロックが見つからなかった場合には、ブロックのグループが事前にフォーマットされ、それらが空きリストに追加され、ブロックへのデータの挿入が開始されます。MSSMでは、全表スキャンによってHWMより下のすべてのブロックが読み取られます。
ASSMでは空きリストは使用されないため、異なる方法で領域を管理する必要があります。セッションで最初にデータを表に挿入すると、MSSMの場合のようにブロックのグループが事前にフォーマットされるかわりに、1つのビットマップ・ブロックがフォーマットされます。このビットマップでは、セグメント内のブロックの状態が追跡されます(空きリストのかわりとなります)。データベースでは、ビットマップを使用して空きブロックが検索されて、データが格納される前に各ブロックがフォーマットされます。ASSMを使用すると、挿入処理が各ブロックに分散されるため、同時実行性の問題を回避できます。
ASSMセグメント内の各データ・ブロックは、次のいずれかの状態になっています。
HWMより上
これらのブロックは未フォーマットであり、使用されていません。
HWMより下
これらのデータ・ブロックは、次のいずれかの状態になっています。
割当て済ですが、現時点では未フォーマットで使用されていません。
フォーマット済でデータが格納されています。
フォーマット済ですが、データが削除されたため空です。
図12-23に、ブロックを水平方向に並べて表現したASSMのセグメントを示します。表の作成時には、HWMはセグメントの先頭(左端)にあります。まだデータは挿入されていないため、セグメント内のすべてのブロックは未フォーマットで、まだ使用されたことはありません。
トランザクションでセグメントに行が挿入されるとします。Oracle Databaseにより、これらの行を保持するためのブロックのグループが割り当てられます。割り当てられたブロックは、HWMに達していません。データベースでは、このグループ内のビットマップ・ブロックはフォーマットされてメタデータが保持されますが、グループ内の他のブロックは事前にフォーマットされません。
図12-24では、HWMより下のブロックは割り当てられていますが、HWMより上のブロックは割当てもフォーマットも行われません。挿入が行われるときに、データベースは空き領域がある任意のブロックに書き込みます。低い最高水位標(低いHWM)は、この位置より下のすべてのブロックは、データが格納されているか、以前にデータが格納されていたため、フォーマット済であることを示しています。
図12-25に示すように、データベースはHWMと低いHWMの間のブロックを選択し、そのブロックに書き込みます。データベースが書込み対象として選択するブロックは、HWMと低いHWMの間のブロックになることもあれば、低いHWMよりも低い、空き領域のあるブロックになることもあります。図12-25に示すように、新しくいっぱいになったブロックの両側のブロックは、未フォーマットになっています。
全表スキャン時には、低いHWMが重要になります。HWMより下のブロックは使用時にのみフォーマットされるため、図12-25に示すように、いくつかのブロックは未フォーマットのままになる可能性があります。このため、Oracle Databaseでは、低いHWMの位置を取得するためにビットマップ・ブロックが読み取られます。低いHWMまでのブロックはフォーマット済であることが既知であるためすべて読み取られ、次に、低いHWMとHWMの間にあるフォーマット済ブロックのみが選択されて読み取られます。
新しいトランザクションによって表に行が挿入されるときに、HWMより下に十分な空き領域が存在しないことがビットマップから判明したとします。この場合は、図12-26に示すように、HWMが右側に移動されて、未フォーマット・ブロックのグループが新しく割り当てられます。
HWMと低いHWMとの間のブロックに空きがなくなると、HWMが右側に拡張されて、低いHWMも以前のHWMの場所まで拡張されます。データベースにデータが徐々に挿入されるにつれて、HWMは次第に右側へと拡張され、それに伴い、低いHWMもHWMに従って拡張されます。オブジェクトを手動で再構築、切捨てまたは縮小しないかぎり、HWMが縮小することはありません。
|
関連項目:
|
表領域は、セグメントを格納するための論理記憶域コンテナです。セグメントは表や索引などのデータベース・オブジェクトであり、記憶域領域を使用します。物理レベルでは、表領域のデータは、1つ以上のデータファイルまたは一時ファイルに格納されます。
データベースには、SYSTEM表領域とSYSAUX表領域が必要です。図12-27に、一般的なデータベースの表領域を示します。次の各項では、表領域タイプについて説明します。
永続表領域には、永続スキーマ・オブジェクトがまとめられます。永続表領域内のオブジェクトのセグメントは、物理的にはデータファイルに格納されます。
各データベース・ユーザーには、デフォルトの永続表領域が割り当てられます。非常に小規模なデータベースでは、デフォルトのSYSTEM表領域およびSYSAUX表領域のみで十分な場合があります。ただし、ユーザー・データおよびアプリケーション・データを格納するための表領域を1つ以上作成することをお薦めします。表領域を使用して次の目的を達成できます。
データベース・データに対するディスク領域の割当てを制御します。
データベース・ユーザーに割当て制限(領域の許容量または制限)を割り当てます。
データベース全体の可用性に影響を与えることなく、個別の表領域をオンライン化またはオフライン化します。
個別の表領域のバックアップとリカバリを実行します。
Oracle Data Pumpユーティリティを使用することによって、アプリケーション・データをインポートまたはエクスポートします(「Oracle Data Pumpエクスポートおよびインポート」を参照)。
データベース間、またはプラットフォーム間でコピーし、移動できるトランスポータブル表領域を作成します。
表領域を移動する場合は、データファイルをコピーして表領域のメタデータを統合するのみでよいため、この方法によるデータ移動は同じデータをエクスポート/インポートまたはアンロード/ロードするよりも何倍も高速です。表領域を移動する場合は、索引データも移動できます。
|
関連項目:
|
SYSTEM表領域は、データベースの作成時に生成される、必須の管理表領域です。Oracle Databaseでは、データベースの管理にSYSTEMが使用されます。
SYSTEM表領域には、次の情報が含まれています。これらの情報は、すべてSYSユーザーが所有しています。
データ・ディクショナリ
データベースの管理情報を含む表およびビュー
トリガー、プロシージャ、パッケージなどのコンパイル済ストアド・オブジェクト
SYSTEM表領域は、他のすべての表領域と同様に管理されますが、より高いレベルの権限が必要であり、また一部制限事項があります。たとえば、SYSTEM表領域の名前変更や削除はできません。
デフォルトで、Oracle Databaseでは、新しく作成されたすべてのユーザー表領域がローカル管理に設定されます。ローカル管理のSYSTEM表領域を持つデータベースには、ディクショナリ管理表領域を作成できません(非推奨)。ただし、手動でCREATE DATABASE文を実行してデフォルトを受け入れると、SYSTEM表領域はディクショナリ管理になります。既存のディクショナリ管理SYSTEM表領域をローカル管理形式に移行できます。
|
注意: SYSTEM表領域を含むすべての表領域がデフォルトでローカル管理になるように、Database Configuration Assistant(DBCA)を使用して新しいデータベースを作成することをお薦めします。 |
|
関連項目:
|
SYSAUX表領域は、SYSTEM表領域の補助表領域です。SYSAUX表領域は、SYSTEM表領域に常駐しないデータベース・メタデータの集中格納場所となります。これにより、シード・データベースとユーザー定義データベースの両方で、デフォルトで作成される表領域の数が減少します。
Oracle Enterprise ManagerやOracle Streamsなどいくつかのデータベース・コンポーネントでは、デフォルトの記憶域の場所としてSYSAUX表領域が使用されます。そのため、データベースの作成時またはアップグレード時にSYSAUX表領域が自動的に作成されます。
通常のデータベース操作中には、SYSAUX表領域の削除や名前変更は許可されません。SYSAUX表領域が使用できなくなった場合でも、中核となるデータベース機能は利用できます。SYSAUX表領域を使用するデータベース機能は、エラーが発生したり、機能が制限されることがあります。
|
関連項目: SYSAUX表領域の詳細は、『Oracle Database管理者ガイド』 |
UNDO表領域は、システム管理UNDOデータ用に予約されたローカル管理表領域です(「UNDOセグメント」を参照)。他の永続表領域と同様、UNDO表領域にもデータファイルが含まれています。これらのファイル内のUNDOブロックは、エクステントにグループ化されています。
UNDO表領域を使用する場合は、データベースがデフォルトの自動UNDO管理モードにあることが必要です。このモードでは、手動でUNDOセグメントを管理する複雑な作業が不要です。UNDOデータを可能なかぎり最適に保存して、UNDOデータを必要とする長時間実行される問合せに対応できるように、データベース自体が自動的にチューニングされます。
UNDO表領域は、Oracle Databaseを新たにインストールすると、自動的に作成されます。Oracle Databaseの以前のバージョンでは、UNDO表領域が含まれておらず、かわりに手動UNDO管理モードと呼ばれる従来のロールバック・セグメントが使用される場合があります。Oracle Database 11gにアップグレードすると、自動UNDO管理モードを有効にして、UNDO表領域を作成できます。Oracle Databaseには、UNDO環境についてのアドバイスを提供し、UNDO環境の自動化に役立つUNDOアドバイザが含まれています。
データベースに複数のUNDO表領域を含めることができますが、使用中となるのは常に1つのUNDO表領域のみです。インスタンスによってデータベースのオープンが試行されると、Oracle Databaseでは、使用可能な最初のUNDO表領域が自動的に選択されます。使用可能なUNDO表領域がない場合、インスタンスはUNDO表領域なしで起動され、UNDOデータはSYSTEM表領域に格納されます。ただし、SYSTEM表領域にUNDOデータを格納しないことをお薦めします。
|
関連項目:
|
UNDO保存期間とは、Oracle Databaseで古いUNDOセグメントを上書きしないで保存する最低期間のことです。長時間実行される問合せでは、読取り一貫性を実現するためにより古いブロック・イメージが必要になる場合があるため、UNDOデータの保存は重要です。また、一部のOracle Flashback機能は、UNDOデータの可用性に依存しています。
一般的に、古いUNDOデータは可能なかぎり長期間保存することをお薦めします。トランザクションのコミット後、ロールバックやトランザクション・リカバリの目的にはUNDOデータは不要になります。UNDO表領域に新しいトランザクション用の領域がある場合には、古いUNDOデータを保持できます。領域が少なくなると、コミットされたトランザクションのデータによる古いUNDOデータの上書きが開始されます。
Oracle Databaseでは、現行のUNDO表領域で、可能なかぎり最適にUNDOデータが自動的に保存されます。データベースにより、使用統計が収集され、これらの統計およびUNDO表領域サイズに基づいて保存期間がチューニングされます。UNDO表領域がAUTOEXTENDオプションを使用して構成されており、最大サイズが指定されていない場合は、UNDO保存期間は異なる方法でチューニングされます。この場合には、データベースにより、実行時間が最も長い問合せより少し長くなるように、UNDO保存期間がチューニングされます(領域が許す場合)。
|
関連項目: UNDO保存の自動チューニングの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
一時表領域には、セッションの存続期間中のみ保持される一時データが含まれています。永続スキーマ・オブジェクトを一時表領域に格納することはできません。データベースでは、一時表領域データは一時ファイルに格納されます。
一時表領域によって、メモリー内に収まらない複数のソート操作の同時実行性が向上します。また、一時表領域によって、ソート中の領域管理操作の効率も向上します。
SYSTEM表領域がローカル管理表領域の場合は、デフォルトでデータベース作成時にデフォルトの一時表領域が作成されます。ローカル管理のSYSTEM表領域は、デフォルトの一時記憶域として使用できません。
|
注意: デフォルトの一時表領域を永続表領域にすることはできません。 |
CREATE DATABASE文でDEFAULT TEMPORARY TABLESPACE拡張機能を使用すると、データベースの作成時に、ユーザーを限定したデフォルトの一時表領域の作成を指定できます。SYSTEM表領域がディクショナリ管理されており、データベースの作成時にデフォルトの一時表領域を定義しないない場合は、SYSTEMがデフォルトの一時記憶域となります。ただし、アラート・ログに、一時表領域の使用を推奨する警告が書き込まれます。
|
関連項目:
|
表領域モードによって、表領域のアクセス可能性が決まります。
すべての表領域は、書込み可能であるかどうかを指定する書込みモードのうちいずれかのモードになっています。次の相互に排他的なモードがあります。
読取り/書込みモード
ユーザーは、表領域の読取りおよび書込みが可能です。すべての表領域は、最初は読取り/書込みモードで作成されます。SYSTEM表領域とSYSAUX表領域、および一時表領域は永続的に読取り/書込みモードであるため、読取り専用にはできません。
読取り専用モード
表領域内のデータファイルへの書込み操作を行うことができません。読取り専用表領域は、DVDドライブやWORMドライブなどの読取り専用メディア上にのみ存在します。
読取り専用表領域では、データベースの静的な部分を大量にバックアップしたり、リカバリする必要がなくなります。読取り専用表領域は変更されないため、繰り返しバックアップする必要はありません。メディア障害後にデータベースをリカバリする場合、読取り専用表領域はリカバリする必要がありません。
|
関連項目:
|
表領域は、データベースがオープンされているときはいつでも、オンライン(アクセス可能)またはオフライン(アクセス不能)にできます。表領域は通常はオンラインになっており、ユーザーはその表領域内のデータを使用できます。SYSTEM表領域と一時表領域は、オフラインにはできません。
表領域は、自動または手動でオフラインにできます。たとえば、メンテナンスまたはバックアップとリカバリのために表領域をオフラインにできます。データベース・ライター(DBW)プロセスによるデータファイルへの書込みが数回失敗した場合など、特定のエラーが発生した場合には、表領域は自動的にオフラインになります。オフライン表領域にある表にアクセスしようとしたユーザーは、エラーを受け取ります。
表領域がオフラインになると、データベースで次のような処理が実行されます。
データベースでは、表領域がオフラインになると、その表領域内のオブジェクトをDML文で参照できなくなります。Oracle Database以外のユーティリティでは、オフライン表領域の読取りまたは編集はできません。
その表領域内のデータを参照する文が完了しているアクティブなトランザクションは、トランザクション・レベルでは影響を受けません。
これらの完了した文に対応するUNDOデータは、SYSTEM表領域内の遅延UNDOセグメントに保存されます。表領域が再びオンライン化されたとき、必要に応じてUNDOデータが表領域に適用されます。
|
関連項目:
|
表領域には、bigfile表領域と小型ファイル表領域があります。これらの表領域は、データファイルまたは一時ファイルを明示的に参照しないSQL文の実行時には区別できません。これらの表領域の違いは、次のとおりです。
smallfile表領域には、複数のデータファイルや一時ファイルを含むことができますが、bigfile表領域ほど大きなファイルは含むことができません。デフォルトの表領域タイプは、smallfile表領域です。
bigfile表領域には、1つの非常に大きなデータファイルまたは一時ファイルを含むことができます。このタイプの表領域には、次のような利点があります。
データベースの記憶域容量の増加
データベース内のデータファイルの最大数には制限があるため(通常は64KB個)、各データファイルのサイズを増加することによって、全体的な記憶域容量を増加できます。
数多くのデータファイルおよび一時ファイルを管理する負担の軽減
bigfile表領域により、新規ファイルを追加したり複数ファイルを取り扱う必要がなくなり、Oracle Managed Filesと自動ストレージ管理(Oracle ASM)によるファイル管理が簡素化されます。
個々のファイルではなく表領域に対する操作の実行
bigfile表領域では、表領域はディスク領域の管理、バックアップおよびリカバリなどの主要単位となります。
bigfile表領域がサポートされるのは、ASSMを使用するローカル管理表領域の場合のみです。ただし、ローカル管理のUNDO表領域と一時表領域は、セグメントが手動管理される場合にもbigfile表領域として使用できます。
