ディクショナリ管理表領域ディクショナリ管理表領域では、データ・ディクショナリを使用してそのエクステントが管理されます。Databaseでは、エクステントが割り当てられたり、再利用のために解放されるたびに、データ・ディクショナリ内の表が更新されます。表でエクステントが必要な場合は、データ・ディクショナリ表が問い合せられ、空きエクステントが検索されます。領域が見つかると、あるデータ・ディクショナリ表が変更され、別のデータ・ディクショナリ表に行が挿入されます。このようにデータを変更および移動することによって、領域が管理されます。データベース・オブジェクト用の領域を取得するため、データベースでバックグラウンドで実行されるSQLは、再帰的SQLです。データ・ディクショナリへの更新はシリアライズされる必要があるため、再帰的SQLを頻繁に使用するとパフォーマンスに悪影響を与える可能性があります。デフォルトのローカル管理表領域では、このようなパフォーマンス上の問題は回避されます。Databaseでは、データベースのデータファイル内の論理記憶域は、データ・ブロックと呼ばれる単位で管理されます(データ・ブロックは、Oracleブロックまたはページとも呼ばれます)。データ・ブロックは、データベースI/Oの最小単位です。データ・ブロックとオペレーティング・システム・ブロック物理レベルでは、データベースのデータは、オペレーティング・システム・ブロックによって構成されているディスク・ファイル内に格納されます。オペレーティング・システム・ブロックは、オペレーティング・システムが読取りまたは書込みできるデータの最小単位です。Oracleブロックは、論理記憶域構造であり、そのサイズや構造はオペレーティング・システムには認識されません。次の図に、オペレーティング・システム・ブロックのサイズがデータ・ブロックのサイズと異なる場合があることを示します。データベースでは、オペレーティング・システム・ブロックではなく、データ・ブロックの倍数を単位としてデータを要求します。データ・ブロックとオペレーティング・システム・ブロック」の説明データベースがデータ・ブロックを要求すると、オペレーティング・システムは、この操作を永続ストレージ内のデータに対する要求に変換します。データ・ブロックをオペレーティング・システム・ブロックから論理的に分離することは、次のことを意味します。アプリケーションでは、データのディスク上の物理アドレスを特定する必要がありません。データベースのデータは、複数の物理ディスクにストライプ化またはミラー化できます。データベース・ブロック・サイズすべてのデータベースには、データベース・ブロック・サイズがあります。DB_BLOCK_SIZE初期化パラメータでは、データベース作成時のデータ・ブロック・サイズが設定されます。このサイズは、SYSTEM表領域およびSYSAUX表領域に対して設定され、他のすべての表領域のデフォルトとなります。データベース・ブロック・サイズは、データベースを再作成する場合以外は変更できません。DB_BLOCK_SIZEが設定されていない場合、デフォルトのデータ・ブロック・サイズは、オペレーティング・システム固有のサイズになります。データベースの標準的なデータ・ブロック・サイズは、4KBまたは8KBです。データ・ブロックのサイズとオペレーティング・システム・ブロックのサイズが異なる場合、データ・ブロックのサイズは、オペレーティング・システム・ブロックのサイズの倍数である必要があります。表領域ブロック・サイズDB_BLOCK_SIZEの設定とは異なるブロック・サイズの表領域を個別に作成できます。非標準のブロック・サイズは、トランスポータブル表領域を別のプラットフォームに移動する場合に役立ちます。参照してくださいデータ・ブロックの形式すべてのデータ・ブロックには、形式、つまりデータベースでのブロック内のデータや空き領域の追跡を可能にする内部構造があります。この形式は、データ・ブロックに表、索引、表クラスタのいずれのデータが含まれている場合でも同じです。次の図に、非圧縮データ・ブロックの形式を示します。Databaseでは、ブロック・オーバーヘッドを使用してブロック自体を管理します。ブロック・オーバーヘッドには、ユーザー・データは格納できません。「データ・ブロックの形式」に示すように、ブロック・オーバーヘッドには次の構成要素が含まれています。ブロック・ヘッダーブロック・ヘッダーには、ディスク・アドレスやセグメント・タイプなどブロックについての一般的な情報が含まれています。トランザクション管理ブロックの場合、ブロック・ヘッダーにはアクティブなトランザクション情報とトランザクション履歴情報が含まれています。ブロックを更新する各トランザクションには、トランザクション・エントリが必要です。Databaseでは、トランザクション・エントリ用の領域が最初にブロック・ヘッダーに予約されます。トランザクションによる変更をサポートするセグメントに割り当てられたデータ・ブロックでは、ヘッダー領域の空きがなくなると、トランザクション・エントリが空き領域にも保持されます。トランザクション・エントリに必要な領域のサイズは、オペレーティング・システムによって異なります。ほとんどのオペレーティング・システムで、トランザクション・エントリのサイズは約23バイトです。表ディレクトリヒープ構成表では、このディレクトリには、該当するブロックに行を格納する表についてのメタデータが含まれています。表クラスタ内では、複数の表が同じブロック内に行を格納できます。行ディレクトリヒープ構成表では、このディレクトリはブロックのデータ部分内の行の位置を示しています。データベースでは、ブロックの下部の任意の場所に行を配置できます。行アドレスは、行ディレクトリ・ベクターのいずれかのスロットに記録されます。ROWIDは、特定のファイル、ブロックおよび行番号を指します。AAAPecAAFAAAABSAAAでは、最後のAAAは行番号を表します。行番号は、行ディレクトリのエントリへの索引です。行ディレクトリ・エントリには、データ・ブロックの行の位置のポインタが含まれます。データベースがブロック内で移動すると、データベースは行ディレクトリ・エントリを更新してポインタを変更します。ROWIDは一定です。データベースが行ディレクトリに領域を割り当てると、行が削除された後もデータベースはこの領域を再利用しません。したがって、現在は空き状態でも、以前に最大50行が格納されていた場合は、行ディレクトリには100バイトが割り当てられたままになります。データベースがこの領域を再利用するのは、セッションが新しい行をブロックに挿入する場合のみです。一部のブロック・オーバーヘッドはサイズが固定ですが、全体のサイズは可変です。ブロック・オーバーヘッド全体のサイズは、平均で84から107バイトです。行形式ブロックの行データ部分には、表の行や索引キー・エントリなどの実際のデータが格納されます。すべてのデータ・ブロックに内部形式があるように、すべての行に行形式があり、これにより、データベースにおける行のデータ追跡が可能になります。Databaseでは、行は可変長レコードとして格納されます。1つの行は1つ以上のセクションに格納されます。各セクションは、行断片と呼ばれます。各行断片は、行ヘッダーおよび列データで構成されます。次の図に、行の形式を示します。Databaseでは、行ヘッダーを使用して、ブロック内に格納された行断片を管理します。行ヘッダーには、次のような情報が含まれています。Databaseでは、行全体を単一のデータ・ブロックに挿入できる場合、その行は1つの行断片として格納されます。行データのすべてを単一のブロックに挿入できない場合、または行の更新によって既存の行が単一のブロックに収まらなくなった場合には、その行は複数の行断片として格納されます。データ・ブロックには、通常1つの行につき1つの行断片のみが含まれています。表クラスタのクラスタ・キー1つのブロックに完全に収まる行は、最低3バイトの行ヘッダーを持っています。列データ行ヘッダーの後ろにある列データ・セクションに、行の実際のデータが格納されます。TABLE文で指定された順序で列が格納されますが、必ずこの順序であるとはかぎりません。LONG型の列は最後に作成されます。Databaseでは、「行形式」の図に示すように、行断片内の各列の長さとデータが別々に格納されます。必要な領域のサイズは、データ型によって異なります。列のデータ型が可変長である場合、値を保持するために必要な領域は、データの更新によって変動します。各行には、データ・ブロック・ヘッダーの行ディレクトリにスロットがあります。このスロットは行の先頭を指しています。Databaseでは、ROWIDを使用して行が一意に識別されます。内部的には、ROWIDは、データベースが行にアクセスするために必要な情報を保持する構造です。ROWIDは、物理的にはデータベースに格納されませんが、データが格納されているファイルやブロックから推論されます。拡張ROWIDには、データ・オブジェクト番号が含まれています。このROWIDタイプは、各行の物理アドレスをBASE64エンコーディングで表現したものです。エンコーディング文字は、AからZ、aからz、0から9、+および/です。次の例では、ROWID擬似列を問い合せて、employees表にある従業員100の行の拡張ROWIDを表示します。ROWID------------------AAAPecAAFAAAABSAAA次の図に、拡張ROWIDの形式を示します。拡張ROWIDは、OOOOOOFFFBBBBBBRRRという4つの部分から構成される形式で表示されます。各部分の内容は、次のとおりです。OOOOOOセグメントを識別するデータ・オブジェクト番号(問合せの例では、データ・オブジェクトAAAPecです)。データ・オブジェクト番号は、各データベース・セグメントに割り当てられます。同じセグメント内のスキーマ・オブジェクト(表クラスタなど)は、同じデータ・オブジェクト番号を持っています。FFF行を含むデータファイルを識別する表領域関連のデータファイル番号(問合せの例では、ファイルAAFです)。BBBBBB行を含むブロックを識別するデータ・ブロック番号(問合せの例では、ブロックAAAABSです)。ブロック番号は、表領域ではなくデータファイルに対する相対値です。このため、同じブロック番号の行が、同じ表領域の異なるデータファイルに存在することもあります。RRRブロック内の行を識別する行番号(問合せの例では、行AAAです)。特殊な状況では、ROWIDが行断片に割り当てられた後、ROWIDが変更される場合があります。行の移動が可能な場合、ROWIDは、パーティション・キーの更新、フラッシュバック表の操作、表の縮小操作などのために変更される可能性があります。Databaseユーティリティを使用して行をエクスポートおよびインポートした場合にROWIDが変更される可能性があります。注意:内部的には、行の移動は、行が物理的に削除されて再挿入されたものとして実行されます。行の移動は更新であるとみなされ、これはトリガーに影響します。参照してくださいデータ・ブロックの圧縮データベースでは、表の圧縮を使用して、データ・ブロック内の重複値を排除します。この項では、圧縮を使用するデータ・ブロックの形式について説明します。基本表および高度な行圧縮を使用するデータ・ブロックの形式は、基本的には非圧縮ブロックの形式と同じです。相違点は、ブロックの先頭にあるシンボル表に、行および列の重複値が格納されることです。Databaseでは、発生した重複値はシンボル表の短い参照で置き換えられます。次の行が、7列で構成されたsales表のデータ・ブロックに格納されるとします。2190,13770,25-NOV-00,S,9999,23,1612225,15720,28-NOV-00,S,9999,25,145034005,120760,29-NOV-00,P,9999,44,23769425,4750,29-NOV-00,I,9999,11,9791675,46750,29-NOV-00,S,9999,19,1121この表に基本表または高度な行圧縮が適用されると、重複値がシンボル参照に置き換えられます。次の圧縮の概念的な表現では、29-NOV-00がシンボル*、9999が%に置き換えられています。2190,13770,25-NOV-00,S,%,23,1612225,15720,28-NOV-00,S,%,25,145034005,120760,*,P,%,44,23769425,4750,*,I,%,11,9791675,46750,*,S,%,19,1121表12-1は、シンボルを値にマップするシンボル表の概念を示します。Databaseでは、データ・ブロックは下から順に使用されるため、行データとブロック・ヘッダー間の空き領域は減少します。データ・ブロック内の空き領域は、行の末尾のNULL値がNULL以外の値に変更されるときなどの更新の際にも減少します。Databaseでは、パフォーマンスを最適化し、領域を無駄にしないようにするために、データ・ブロック内の空き領域が管理されます。注意:この項では、自動セグメント領域管理の使用を前提としています。SQLパラメータでは、既存の行の更新用に空き領域として予約されるデータ・ブロックの最小の割合を設定します。行の移行を防止し、領域を無駄にしないようにするためにPCTFREEが必要です。ほとんど更新されず、更新される場合でも既存のデータのサイズがほとんど増加しない表を作成するとします。TABLE文内のPCTFREEパラメータを次のように指定します。20;図12-10に、PCTFREEを20に設定した場合の領域管理への影響について示します。時間の経過とともにブロックに行が追加され、行データがブロック・ヘッダーの方向へ上向きに増加し、ブロック・ヘッダー自体も、行データの方向へ下向きに増加します。PCTFREEの設定によって、データ・ブロックの20%以上が空き領域となることが保証されます。行を挿入すると行データとヘッダーの合計がブロック領域全体の90%を占め、空き領域が10%になる場合には、INSERT文は実行できません。注意:この説明は、PCTFREE記憶域パラメータや空きリストを使用しないLOBデータ型については該当しません。空き領域の割合は、PCTFREEよりも小さくなることはありませんが、大きくなることがあります。PCTFREEを20%に設定すると、空き領域の合計がブロックの5%になることはありませんが、50%になることはあります。一部のDML文を使用すると、データ・ブロックの空き領域のサイズが増えます。次の文を使用すると、空き領域のサイズが増えます。高度な行圧縮を使用する表に対するINSERT文INSERT文によってブロックがデータでいっぱいになると、データベースによってブロック圧縮が開始され、ブロックにより多くの空き領域が生じる可能性があります。解放された領域は、次の条件下でINSERT文に使用できます。INSERT文が同じトランザクション内に存在し、領域を解放した文の後にある場合、その文で使用可能になった領域を使用できます。INSERT文が、領域を解放する文とは別のトランザクションに含まれている(別々のユーザーが実行している)場合、その文では、もう一方のトランザクションがコミットされた後で、しかもその領域が必要とされる場合にかぎり、使用可能になった領域を使用できます。解放された領域は、データ・ブロック内の主な空き領域と連続しているとはかぎりません。連続しない空き領域は、断片化領域と呼ばれます。次の図に、連続しない空き領域を含むデータ・ブロックを示します。Databaseでは、次の条件に当てはまる場合にのみ、データ・ブロックの空き領域が自動的かつ透過的に結合されます。INSERT文またはUPDATE文において、新しい行断片を格納するために十分な空き領域のあるブロックの使用が試行された場合。空き領域が断片化されており、行断片をブロック内の連続したセクションに挿入できない場合。結合後の空き領域のサイズは結合前と同じですが、領域は連続的に存在するようになります。図12-12に、領域結合後のデータ・ブロックを示します。Databaseでは、前述の状況でのみ結合が実行されます。それ以外の状況で結合を実行すると、データ・ブロック内の空き領域が連続的に結合されることによって、パフォーマンスが低下する可能性があるためです。Databaseでは、大きすぎる行を1つのブロック内に収まるように管理するため、連鎖と移行が使用されます。次の状況が考えられます。最初に行を挿入するとき、大きすぎて1つのデータ・ブロック内に収まらない場合。Databaseにより、その行のデータは、セグメント用に確保された1つ以上のデータ・ブロックの連鎖に格納されます。多くの場合、行連鎖は、行が大きい場合に発生します。RAWデータ型の列を含む行、または行に含まれる列の数が多すぎる場合があります。そのような場合の行連鎖は、避けられません。1つのデータ・ブロックに収まっていた行が更新されて、行全体の長さが増加したが、更新後の行を保持する十分な空き領域がない場合。Databaseにより、行全体が新しいブロックに収まることを前提として、行全体が新しいデータ・ブロックに移動されます。移行された行の元の行断片には、行の移行先の新しいブロックへのポインタまたは「転送先アドレス」が含まれます。そのため、移動された行のROWIDは変わりません。行に255を超える列が含まれる場合。Databaseでは、1つの行断片に格納できる列数は、255列のみです。したがって、1000列の行を表に挿入すると、データベースでは通常、複数のブロックに連鎖された4つの行断片が作成されます。図12-13に、データ・ブロックへの大きなサイズの行の挿入を示します。Databaseでは行を連鎖し、最初の行断片を左側のブロックに配置し、2つ目の行断片を右側のブロックに配置します。図12-14では、左側のブロックには、更新によってサイズが増大してこのブロックに収まらなくなった行が格納されています。Databaseにより、この行全体が右側のブロックに移動され、この移行後の行へのポインタが左側のブロックに残されます。行が連鎖または移行されると、データの取出しに必要なI/Oが増加します。Databaseが複数のブロックをスキャンする必要があるためです。索引の読取りに対して1回のI/Oを行い、移行されていない表の行を読み取るために1回のI/Oを行う場合、移行された行のデータを取得するために追加のI/Oが必要になります。Databaseコンポーネントであり、手動または自動で実行できます。セグメント・アドバイザを使用すると、多くの空き領域のあるオブジェクト、または多くの連鎖行があるオブジェクトについてのアドバイスを入手できます。関連項目:「行の格納」および「行断片のROWID」。