索引ブロックは、領域を表ブロックとは異なる方法で管理する特殊なタイプのデータ・ブロックです。Databaseでは、索引ブロックを使用して、索引の論理記憶域を管理します。索引ブロックのタイプ索引には、ルート・ブロック、ブランチ・ブロックおよびリーフ・ブロックが含まれています。ブロック・タイプは次のように定義されています。ルート・ブロックこのブロックは、索引へのエントリ・ポイントを識別します。ブランチ・ブロックデータベースでは、索引キーを検索する際、ブランチ・ブロックを検索します。リーフ・ブロックこれらのブロックには、関連行を指す索引付きキー値の行IDが含まれています。リーフ・ブロックにはキー値がソート順に格納され、データベースではキー値の範囲内のすべての行を効率的に検索できます。索引エントリは、表の行がデータ・ブロックに格納されるのと同じように、索引ブロックに格納されます。ブロック部分の索引エントリはバイナリの順序ではなく、ヒープで格納されます。データベースは、データ・ブロックのディレクトリとは異なる索引ブロックの行ディレクトリを管理します。行ディレクトリのエントリ(索引ブロックの本体のエントリではない)は、キー値で順序付けられます。行ディレクトリでは、索引キー000000のディレクトリ・エントリは、索引キー111111のディレクトリ・エントリよりも優先されます。行ディレクトリのエントリの順序は、索引スキャンの効率を改善します。レンジ・スキャンでは、データベースはレンジに指定されたすべての索引キーを読み取る必要があります。データベースは、ブランチ・ブロックを横断して、最初のキーを含むリーフ・ブロックを特定します。行ディレクトリのエントリがソートされるため、データベースは、バイナリ検索を使用してレンジ内の最初のキーを検索し、最後のキーが見つかるまで行ディレクトリのエントリを順に検索します。このようにして、データベースはリーフ・ブロック本体のすべてのキーを読み取らないようにできます。索引ブロック内のスロットの再利用データベースでは、索引ブロック内の領域を再利用できます。アプリケーションはある値を列に挿入してから、その値を削除する場合があります。行に領域が必要な場合、データベースでは、削除された値によって以前専有されていた索引スロットを再利用できます。索引ブロックには通常、ヒープ構成表ブロックより多くの行があります。単一の索引ブロックに多数の行を格納する機能により、新規データ格納のための頻繁なブロック分割が避けられることから、データベースでの索引の管理が容易になります。INDEX文により、手動で結合できます。列に1から500000の値を移入し、その後偶数を含む行を削除した場合、索引には250000の空のスロットが含まれます。データベースでは、空のスロットを含む索引ブロックに適合するデータを挿入できる場合のみ、スロットを再利用します。索引の結合は、既存の索引データを所定の位置で圧縮し、再編成によりブロックが解放された場合、空きブロックをその索引構造に残します。したがって、結合により索引ブロックは他のユーザーには解放されず、その索引ではブロックが再割当てされます。INDEX文を実行する必要があります。図12-15に、索引結合前のemployees.department_id列の索引を示します。最初の3つのリーフ・ブロックは、グレーの格納ラインで示されているように、まだ満杯ではありません。図12-16に、図12-15の索引の結合後を示します。最初の2つのリーフ・ブロックは、グレーの格納ラインで示されているように満杯になり、3つ目のリーフ・ブロックは解放されています。参照してくださいエクステントの概要エクステントは、連続したデータ・ブロックで論理的に構成される、データベース記憶域のユニットです。データ・ブロックは、RAIDのストライプ化やファイルシステムの実装によって、物理的にはディスク上に断続的に存在する可能性があります。エクステントの割当てデータベースでは、セグメントが作成されたときにデータ・セグメント用の初期エクステントがデフォルトで割り当てられます。エクステントは、常に1つのデータファイルに含まれています。セグメントにデータが追加されていない場合でも、初期エクステント内にこのセグメント専用のデータ・ブロックが予約されます。各セグメントの最初のデータ・ブロックには、そのセグメント内のエクステントのディレクトリが含まれています。図12-17に、データが含まれていなかったデータファイル内の、セグメントの初期エクステントを示します。初期エクステントがいっぱいになり、さらに追加の領域が必要になると、データベースによって自動的にこのセグメントの増分エクステントが割り当てられます。増分エクステントは、セグメントに対して後から作成されるエクステントです。割当てアルゴリズムは、ローカル管理表領域であるか、ディクショナリ管理表領域であるかに応じて異なります。ローカル管理表領域の場合は、データファイルのビットマップで、隣接する空きブロックが検索されます。データファイルに十分な領域がない場合は、他のデータファイルが検索されます。セグメントのエクステントは常に同じ表領域内に存在しますが、異なるデータファイル内に存在する場合もあります。図12-18に、セグメントのエクステントは表領域内の任意のデータファイル内に割当て可能であることを示します。セグメントの初期エクステントをusers01.dbfに、最初の増分エクステントをusers02.dbfに、次のエクステントをusers01.dbfに割り当てることができます。新しく割り当てられたエクステントのブロックは、空き領域であったブロックですが、古いデータが残っていることがあります。Databaseによってそのエクステントのブロックがフォーマットされます(ただし、必要な場合のみ)。注意:この項は、1つのサーバー・プロセスによって文を解析して実行する、シリアル操作に適用されます。複数のサーバー・プロセスを必要とするパラレルSQL文では、エクステントは異なる方法で割り当てられます。一般的に、ユーザー・セグメントのエクステントは、DROP文を使用してオブジェクトを削除するまでは表領域に戻されません。表の行をすべて削除しても、データベースによりデータ・ブロックが再利用されて表領域内の他のオブジェクトがそれらのブロックを使用できるようになることはありません。セグメントは、DBMS_SPACE_ADMINパッケージを使用して削除することもできます。Databaseにより定期的に1つ以上のエクステントの割当てが解除されます。領域の割当てを手動で解除できる場合もあります。Advisorは、オブジェクト内の断片化のレベルに応じて、オブジェクトに再利用可能な領域があるかどうかを判断する際に役立ちます。次の方法でエクステントを解放できます。オンラインでのセグメントの縮小を使用すると、セグメント内の断片化領域を再利用します。セグメントの縮小は、オンラインのインプレース操作です。一般的に、データ圧縮によって、より効率的にキャッシュを利用できるようになり、全表スキャン時に読み取る必要があるブロック数が少なくなります。パーティション化されていない表や表パーティションのデータを新しいセグメントに移動し、必要であれば割当て制限を持つ別の表領域に移動します。索引を再作成または結合します。表または表クラスタを切り捨てて、すべての行を削除します。Databaseでは、MINEXTENTS記憶域パラメータで指定されたサイズを除き、削除された行で使用していたすべての領域の割当てが解除されます。STORAGEオプションを指定してTRUNCATEを使用すれば、セグメント全体を削除することもできます。未使用領域の割当てを解除すると、データベース・セグメントの最高水位標の最後で未使用領域を解放して、表領域の他のセグメントで領域を使用できるようにします。Databaseでは、ローカル管理表領域のデータファイル内のビットマップを変更し、再度取得されたエクステントを使用可能領域として反映します。解放されたエクステントのブロックにあるデータにはアクセスできなくなります。参照してくださいエクステントの記憶域パラメータ各セグメントは、エクステントについての設定である記憶域パラメータによって定義されます。Databaseで特定のセグメントに空き領域がどのように割り当てられるかが制御されます。記憶域設定は、次に示す優先順位で決定されます。リストの上位の設定は下位の設定よりも優先されます。Databaseのデフォルトローカル管理表領域の場合は、均一のエクステント・サイズでも、システムによって自動的に決定される可変エクステント・サイズでもかまいません。均一エクステントの場合は、エクステント・サイズを指定するか、デフォルト・サイズである1MBを使用できます。表領域内のすべてのエクステントが指定したサイズになります。ローカル管理一時表領域の場合は、均一サイズの割当てのみ使用できます。Databaseにより自動的に決定されます。ローカル管理表領域では、一部の記憶域パラメータは表領域レベルでは指定できません。これらのパラメータをセグメント・レベルで指定することはできます。この場合、データベースでは、すべてのパラメータをまとめて使用して、セグメントの初期サイズが計算されます。内部のアルゴリズムによって、その後に割り当てられる各エクステントのサイズが決定されます。参照してくださいセグメントの概要セグメントは、表領域内の特定の論理記憶域構造のデータがすべて入っている、エクステントの集合です。Databaseでは、1つ以上のエクステントを割り当てることによって、表のデータ・セグメントを形成します。データベースでは、表の索引の索引セグメントも、1つ以上のエクステントを割り当てることによって形成します。Databaseにより、自動または手動でセグメント領域が管理されます。この項では、ASSMを使用することを前提としています。参照ユーザー・セグメントデータベース内の1つのデータ・セグメントには、1つのユーザー・オブジェクトのデータが格納されます。セグメントには様々なタイプがあります。次に、ユーザー・セグメントの例を示します。表、表パーティションまたは表クラスタLOBまたはLOBパーティション索引または索引パーティションパーティション化されていない各オブジェクトおよび各オブジェクト・パーティションは、それぞれ独自のセグメントに格納されます。索引に5つのパーティションがある場合は、5つのセグメントに索引データが格納されます。ユーザー・セグメントの作成デフォルトで、データベースでは遅延セグメント作成により、表、索引およびパーティションを作成する際、データベース・メタデータのみが更新されます。ユーザーが最初の行を表またはパーティションに挿入するときに、その表またはパーティション、LOB列およびその索引のセグメントが作成されます。遅延セグメント作成が発生すると、データベース・リソースが必要以上に使用されなくなります。アプリケーションをインストールすると、数千ものオブジェクトが作成されて、ディスク領域を大量に消費する場合があります。このようなオブジェクトの多くは、実際には使用されない可能性があります。DBMS_SPACE_ADMINパッケージは、空のオブジェクト用のセグメントを管理します。このPL/SQLパッケージを使用すれば、次のことができます。セグメントが作成されていない空の表またはパーティション用のセグメントの手動マテリアライズ空のセグメントが割り当てられている空の表またはパーティションからのセグメントの削除オブジェクトの作成とセグメントの作成との関係がわかりやすくなるように、遅延セグメント作成は発生しないものとします。次のような表を作成するとします。NUMBER);図12-19に示すように、表のセグメントが1つ作成されます。Databaseによって、このキーの索引が自動的に作成されます。ここでも、遅延セグメント作成は発生しないものとします。次のような表を作成するとします。CLOB);図12-20は、lob_tableのデータがあるセグメントに格納され、暗黙的に作成された索引が別のセグメントに格納されることを示しています。CLOBデータは、関連付けられたCLOB索引と同様に、専用のセグメントに格納されます。TABLE文を実行すると4つの異なるセグメントが作成されます。注意:表のセグメントとその表の索引のセグメントは、同一の表領域に存在する必要はありません。セグメントが作成されると、1つ以上のエクステントが割り当てられます。オブジェクトの記憶域パラメータにより、各セグメントのエクステントが割り当てられる方法が決定します。これらのパラメータは、オブジェクトに関連するデータ・セグメントのデータ検索と格納の効率に影響を与えます。Databaseでは、問合せの処理中に、SQL文実行の中間段階で、一時作業領域が必要になることがあります。一時セグメントが必要になる一般的な操作には、ソート、ハッシング、ビットマップのマージなどがあります。索引の作成中には索引セグメントも一時セグメントに配置され、索引の作成が完了すると、永続セグメントに変換されます。Databaseでは、メモリー内で操作が完了する場合、一時セグメントは作成されません。メモリーを使用できない場合には、ディスク上に一時セグメントが自動的に割り当てられます。Databaseでは、ユーザー・セッション中に必要に応じて問合せ用の一時セグメントを割り当て、問合せが完了するとセグメントを削除します。一時セグメントに対する領域管理操作以外の、一時セグメントに対する変更は、オンラインREDOログに記録されません。データベースでは、ユーザーに割り当てられた一時表領域に一時セグメントが作成されます。表領域のデフォルトの記憶域特性によって、一時セグメント内のエクステントの特性が決定されます。一時セグメントの割当てと割当て解除は頻繁に発生するため、一時セグメント専用に1つ以上の表領域を作成してください。これにより、I/Oがディスク間で分散され、SYSTEM表領域やその他の一時セグメントがある表領域の断片化が回避されます。注意:SYSTEM表領域がローカル管理の場合は、データベースの作成時にデフォルトの一時表領域を定義する必要があります。ローカル管理のSYSTEM表領域は、デフォルトの一時記憶域として使用できません。Database管理者ガイド』を参照してください。SQL言語リファレンス』を参照してください。Databaseは、一時表およびその索引用の一時セグメントを割り当てることができます。一時表には、トランザクションまたはセッションの期間中にのみ存在するデータが保持されます。各セッションは、それ自体に割り当てられたエクステントにのみアクセスし、他のセッションに割り当てられたエクステントにはアクセスできません。Databaseが一時表に対してセグメントを割り当てるのは、グローバル一時表の場合は表への最初のINSERTが発生したときに、プライベート一時表の場合は必要に応じてです。SELECTによって行われたものでもかまいません。データベースは、表とその索引にセグメントを割り当て、索引のルート・ページを作成し、LOBセグメントを割り当てます。現行ユーザーの一時表領域は、一時表のセグメントを割り当てます。user1に割り当てられた一時表領域がtemp1であり、user2に割り当てられた一時表領域がtemp2であるとします。この場合、user1の一時データはtemp1のセグメントに格納され、user2の一時データはtemp2のセグメントに格納されます。Databaseには、UNDOデータと総称されている、トランザクションのアクションのレコードが保持されています。Databaseでは、次の場合にUNDOデータが使用されます。Databaseでは、UNDOデータは、外部ログではなくデータベース内部に格納されます。UNDOデータが格納されるブロックは、データ・ブロックと同様に更新され、これらのブロックに対する変更によってREDOレコードが生成されます。Databaseでは、外部ログを読み取ることなくUNDOデータに効率的にアクセスできます。永続オブジェクトのUNDOデータは、UNDO表領域に格納されます。Databaseには、UNDO表領域内のUNDOセグメントおよび領域を管理するための自動UNDO管理モードと呼ばれる完全に自動化されたメカニズムが提供されています。データベースでは、UNDOデータを2つのストリームに分けます。一時UNDOストリームでは、一時オブジェクトへの変更によって生成されたUNDOレコードのみをカプセル化するのに対して、永続UNDOストリームでは、永続オブジェクトのUNDOレコードのみをカプセル化します。データベースでは、一時および永続UNDOを別々に管理します。UNDOの分離により記憶域が減り、次のことを行うことでパフォーマンスが向上します。永続および一時表に最適の永続およびUNDO表領域のサイズを構成できるようにします。オンラインREDOログに書き込まれたREDOのサイズを縮小します。一時UNDOデータのバックアップの必要を回避します。Guardインスタンスでは、グローバル一時表のDMLで、UNDOが一時UNDOセグメントに生成される必要があります。参照してくださいUNDOセグメントとトランザクショントランザクションが開始するときに、そのトランザクションは、現在のUNDO表領域内のUNDOセグメント(トランザクション表)にバインド(割当て)されます。データベース・インスタンスに対し専用のUNDO表領域が割り当てられていない場合は、トランザクションがシステムUNDOセグメントにバインドされます。複数のアクティブなトランザクションが、同じUNDOセグメントに同時に書き込むこともあれば、別々のセグメントに書き込むこともあります。トランザクションT1とT2が両方ともU1というUNDOセグメントに書き込むこともあれば、T1がU1に書き込み、T2がU2というUNDOセグメントに書き込むこともあります。概念的には、UNDOセグメント内のエクステントは輪のようなものです。トランザクションは、輪に沿って回るように、UNDOエクステントに順に書き込んでいきます。図12-21では、T1とT2という2つのトランザクションを示し、この2つのトランザクションはそれぞれ、UNDOセグメントの3番目のエクステント(E3)から書込みを開始し、4番目のエクステント(E4)まで書込みを進めます。UNDOセグメントに円環状に割り当てられたエクステント」の説明トランザクションは必ずUNDOセグメント内のエクステントに1つずつ順番に書き込み、その時点で書込み可能なエクステントをトランザクションの現行エクステントと呼びます。複数のアクティブなトランザクションが同時に、同じ現行エクステントに書き込むことも、別々の現行エクステントに書き込むことも可能です。図12-21では、T1とT2のトランザクションがエクステントE3に同時に書き込んでいます。UNDOエクステント内では、各データ・ブロックに格納されるデータは、1つのトランザクションのデータのみです。現在のUNDOエクステントがいっぱいになると、領域を必要とする最初のトランザクションによって、輪の中にある次の割当てエクステントの空き状況がチェックされます。次のエクステントにアクティブなトランザクションのデータが格納されていない場合は、このエクステントが現行エクステントになります。この時点で、領域を必要としているすべてのトランザクションが、新しい現行エクステントに書込み可能な状態になります。図12-22では、E4がいっぱいになり、T1とT2がE1に書込みを継続し、E1内のアクティブでないUNDOデータを上書きしています。次のエクステントにアクティブなトランザクションのデータが格納されている場合は、新しいエクステントが割り当てられます。図12-23では、T1とT2はE4に書き込んでいます。E4がいっぱいになっても、E1にはアクティブなUNDOデータが格納されているため、トランザクションはE1に書込みを継続することができません。そこで、このUNDOセグメントに新しいエクステント(E5)が割り当てられます。トランザクションはE5に書込みを継続します。参照してくださいトランザクションのロールバックROLLBACK文が発行されると、UNDOレコードは、コミットされていないトランザクションによってデータベースに加えられた変更を元に戻すために使用されます。リカバリ中には、オンラインREDOログからデータファイルに適用されたコミットされていないすべての変更が元に戻されます。UNDOレコードでは、あるユーザーによるデータの変更中にそのデータにアクセスしているユーザー用に、そのデータの修正前のイメージを維持することで、読取り一貫性が実現されます。一時UNDOセグメント一時UNDOセグメントは、一時UNDOデータ専用のオプションの領域管理コンテナです。一時表への変更のUNDOレコードは、セッション固有であるとともに、読取りの一貫性とトランザクション・ロールバックに対してのみ役立ちます。12cまでは、データベースではこれらのレコードをいつでもオンラインREDOログに格納していました。一時オブジェクトに対する変更はオンラインREDOログに記録されないため、一時オブジェクトのUNDOを一時UNDOセグメントに書き込むと、オンラインREDOログおよびアーカイブ済のREDOログ・ファイルで領域が節約されます。データベースでは、UNDOへの変更、または一時表への変更は記録されないため、パフォーマンスが向上します。TEMP_UNDO_ENABLED初期化パラメータを設定すれば、一時表でUNDOデータを一時UNDOセグメントに格納できます。このパラメータがTRUEの場合、データベースでは一時表領域から一時UNDOセグメントを割り当てます。Databaseでは、領域を管理するために、セグメント内のブロックの状態を追跡します。最高水位標(HWM)は、セグメント内の位置を指し示し、その位置を超えると、データ・ブロックは未フォーマットであり、使用されていません。MSSMでは、空きリストを使用してセグメント領域が管理されます。表の作成時には、セグメント内のブロックはフォーマットされていません。セッションが最初に行を表に挿入すると、空きリストが検索され、使用可能なブロックが検出されます。使用可能なブロックが見つからなかった場合には、ブロックのグループが事前にフォーマットされ、それらが空きリストに追加され、ブロックへのデータの挿入が開始されます。MSSMでは、全表スキャンによってHWMより下のすべてのブロックが読み取られます。ASSMでは空きリストは使用されないため、異なる方法で領域を管理する必要があります。セッションで最初にデータを表に挿入すると、MSSMの場合のようにブロックのグループが事前にフォーマットされるかわりに、1つのビットマップ・ブロックがフォーマットされます。このビットマップでは、セグメント内のブロックの状態が追跡されます(空きリストのかわりとなります)。データベースでは、ビットマップを使用して空きブロックが検索されて、データが格納される前に各ブロックがフォーマットされます。ASSMを使用すると、挿入処理が各ブロックに分散されるため、同時実行性の問題を回避できます。ASSMセグメント内の各データ・ブロックは、次のいずれかの状態になっています。HWMより上これらのブロックは未フォーマットであり、使用されていません。HWMより下これらのデータ・ブロックは、次のいずれかの状態になっています。割当て済ですが、現時点では未フォーマットで使用されていません。フォーマット済でデータが格納されています。フォーマット済ですが、データが削除されたため空です。図12-24に、ブロックを水平方向に並べて表現したASSMのセグメントを示します。表の作成時には、HWMはセグメントの先頭(左端)にあります。データは挿入されていないため、セグメント内のすべてのブロックは未フォーマットで、まだ使用されたことはありません。表作成時のHWM」の説明トランザクションでセグメントに行が挿入されるとします。Databaseにより、これらの行を保持するためのブロックのグループが割り当てられます。割り当てられたブロックは、HWMに達していません。データベースでは、このグループ内のビットマップ・ブロックはフォーマットされてメタデータが保持されますが、グループ内の他のブロックは事前にフォーマットされません。図12-25では、HWMより下のブロックは割り当てられていますが、HWMより上のブロックは割当てもフォーマットも行われません。挿入が行われるときに、データベースは空き領域がある任意のブロックに書き込みます。低い最高水位標(低いHWM)は、この位置より下のすべてのブロックは、データが格納されているか、以前にデータが格納されていたため、フォーマット済であることを示しています。図12-26に示すように、データベースはHWMと低いHWMの間のブロックを選択し、そのブロックに書き込みます。データベースが書込み対象として選択するブロックは、HWMと低いHWMの間のブロックになることもあれば、低いHWMよりも低い、空き領域のあるブロックになることもあります。図12-26に示すように、新しくいっぱいになったブロックの両側のブロックは、未フォーマットになっています。全表スキャン時には、低いHWMが重要になります。HWMより下のブロックは使用時にのみフォーマットされるため、図12-26に示すように、いくつかのブロックは未フォーマットのままになる可能性があります。Databaseでは、低いHWMの位置を取得するためにビットマップ・ブロックが読み取られます。低いHWMまでのブロックはフォーマット済であることが既知であるためすべて読み取られ、次に、低いHWMとHWMの間にあるフォーマット済ブロックのみが選択されて読み取られます。新しいトランザクションによって表に行が挿入されるときに、HWMより下に十分な空き領域が存在しないことがビットマップから判明したとします。この場合は、図12-27に示すように、HWMが右側に移動されて、未フォーマット・ブロックのグループが新しく割り当てられます。HWMと低いHWMの拡張」の説明HWMと低いHWMとの間のブロックに空きがなくなると、HWMが右側に拡張されて、低いHWMも以前のHWMの場所まで拡張されます。データベースにデータが徐々に挿入されるにつれて、HWMは次第に右側へと拡張され、それに伴い、低いHWMもHWMに従って拡張されます。オブジェクトを手動で再構築、切捨てまたは縮小しないかぎり、HWMが縮小することはありません。表領域は、セグメントを格納するための論理記憶域コンテナです。セグメントは表や索引などのデータベース・オブジェクトであり、記憶域領域を使用します。物理レベルでは、表領域のデータは、1つ以上のデータファイルまたは一時ファイルに格納されます。データベースには、SYSTEM表領域とSYSAUX表領域が必要です。次の図に、一般的なデータベースの表領域を示します。次の各項では、表領域タイプについて説明します。永続スキーマ・オブジェクトがまとめられます。永続表領域内のオブジェクトのセグメントは、物理的にはデータファイルに格納されます。各データベース・ユーザーには、デフォルトの永続表領域が割り当てられます。非常に小規模なデータベースでは、デフォルトのSYSTEM表領域およびSYSAUX表領域のみで十分な場合があります。ユーザー・データおよびアプリケーション・データを格納するための表領域を1つ以上作成することをお薦めします。表領域を使用して次の目的を達成できます。データベース・データに対するディスク領域の割当てを制御します。データベース・ユーザーに割当て制限(領域の許容量または制限)を割り当てます。データベース全体の可用性に影響を与えることなく、個別の表領域をオンライン化またはオフライン化します。個別の表領域のバックアップとリカバリを実行します。Pumpユーティリティを使用したアプリケーション・データのインポートまたはエクスポートデータベース間、またはプラットフォーム間でコピーし、移動できるトランスポータブル表領域を作成します。表領域を移動する場合は、データファイルをコピーして表領域のメタデータを統合するのみでよいため、この方法によるデータ移動は同じデータをエクスポート/インポートまたはアンロード/ロードするよりも何倍も高速です。表領域を移動する場合は、索引データも移動できます。