ヘッダーをスキップ

Oracle Database 管理者ガイド
11gリリース1(11.1)

E05760-03
目次
目次
索引
索引

戻る 次へ

18 表の管理

この章の内容は次のとおりです。

表の概要

表は、Oracle Databaseのデータ記憶域の基本単位です。データは、行および列に格納されます。表は、employeesなどの表名と一連の列で定義します。各列には列名(employee_idlast_namejob_idなど)、データ型(VARCHAR2DATENUMBERなど)および幅を指定します。幅は、データ型(DATEなど)によって事前に決まる場合があります。NUMBERデータ型の列の場合は、幅ではなく、精度および位取りを定義します。行は、単一のレコードに対応する列情報の集合です。

表の各列にはルールを指定できます。これらのルールは整合性制約と呼ばれています。NOT NULLは、整合性制約の1つです。これは、各行の列に値を指定することを強制する制約です。

透過的データ暗号化を起動して、データを暗号化してから格納できます。ユーザーが、オペレーティング・システムのツールを使用してOracleデータファイルの内容を直接参照することによって、データベース・アクセス制御メカニズムを迂回しようとした場合でも、暗号化によって、このようなユーザーが機密データを参照できないようにします。

表には仮想列を含めることもできます。仮想列は表の他の列とほぼ同じですが、値が式を評価して導出される点が異なります。式に使用できるのは、同じ表の列、定数、SQLファンクションおよびユーザー定義のPL/SQLファンクションです。仮想列に明示的に書き込むことはできません。

列の型には、LOB、VARRAYおよびネストした表のように専用セグメントに格納されるものがあります。 LOBとVARRAYはLOBセグメントに格納されますが、ネストした表は記憶表に格納されます。これらのセグメントに対してSTORAGE句を指定し、表レベルで指定した記憶域パラメータを上書きできます。

表を作成した後は、SQL文またはOracleのバルク・ロード・ユーティリティを使用してデータ行を挿入します。表データは、SQLを使用して問合せ、削除または更新できます。

関連項目:

  • 表の概要については、『Oracle Database概要』を参照してください。

  • Oracle Databaseのデータ型の説明は、『Oracle Database SQLリファレンス』を参照してください。

  • 表の領域を管理するためのガイドラインは、第17章「スキーマ・オブジェクトの領域の管理」を参照してください。

  • 整合性制約の指定や表の分析など、表の管理に関するその他の情報については、第16章「スキーマ・オブジェクトの管理」を参照してください。

  • 透過的データ暗号化については、『Oracle Database Advanced Security管理者ガイド』を参照してください。

 

表を管理するためのガイドライン

ここでは、表を管理するときに従うべきガイドラインについて説明します。これらのガイドラインに従うことで、表の作成や表データのロード、更新および問合せを行うときに、表の管理が容易になり、パフォーマンスの向上にもつながります。

この項の内容は、次のとおりです。

作成前の表の設計

通常、アプリケーション開発者は、表などのアプリケーションの要素を設計する必要があります。データベース管理者は、アプリケーション表を保持する、基礎となる表領域に対する属性の設定を担当します。DBAまたはアプリケーション開発者は(あるいは双方が協力して)、サイトの業務に基づいて実際の表の作成を担当します。

表を設計する場合は、アプリケーション開発者と協力し、次のガイドラインを考慮してください。

表を作成する前に、整合性制約の使用についても判断します。表の列に整合性制約を定義することによって、データベースのビジネス・ルールを自動的に徹底できます。

作成する表のタイプに関するオプションの考慮

作成する表のタイプを決定します。次のタイプがあります。

表のタイプ  説明 

通常の(ヒープ構成)表 

この章の主な説明の対象でもある基本的で多目的な表です。この表のデータは、順序付けされていないコレクション(ヒープ)として格納されます。 

クラスタ化表 

クラスタ化表は、クラスタの一部となっている表です。クラスタとは、同じデータ・ブロックを共有する表のグループです。グループ化されるのは、これらの表が共通の列を共有し、多くの場合まとめて使用されるためです。

クラスタとクラスタ化表については、第20章「クラスタの管理」を参照してください。 

索引構成表 

通常の(ヒープ構成)表とは異なり、索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納されます。Bツリーの各索引エントリには、索引構成表の行の主キー列値以外に、非キー列値も格納されます。

索引構成表については、「索引構成表の管理」を参照してください。 

パーティション表 

パーティション表では、データをパーティションと呼ばれる管理が容易な単位に分割し、さらにそれをサブパーティションに分割できます。各パーティションは個々に管理でき、他のパーティションとは無関係に操作できます。これによって、可用性やパフォーマンスを考慮して適切にチューニング可能な構造を用意できます。

パーティション表については、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 

各表の位置の指定

新しい表を格納する表領域を識別するには、CREATE TABLE文にTABLESPACE句を指定します。使用する表領域に対する適切なシステム権限と割当て権限があることを確認してください。CREATE TABLE文で表領域を指定しない場合は、作成したユーザーのデフォルト表領域内に表が作成されます。

新しい表を含む表領域を指定するときは、その選択が意味することを確実に理解しておいてください。各表の作成時に表領域を適切に指定することによって、データベース・システムのパフォーマンスが向上し、データベース管理に必要な時間を短縮できます。

次のように、表領域を指定しない場合や不適切な表領域を指定した場合は、パフォーマンスに影響を与えます。

表作成のパラレル化

CREATE TABLE文で副問合せ(AS SELECT)を使用して表を作成する際は、パラレル実行を利用できます。複数のプロセスが同時に動作して表を作成するため、表を作成するときのパフォーマンスが向上します。

表作成のパラレル化については、「表作成のパラレル化」を参照してください。

表作成時のNOLOGGINGの使用

表を最も効率よく作成するには、CREATE TABLE...AS SELECT文でNOLOGGING句を使用します。NOLOGGING句を指定すると、表の作成中に最小限のREDO情報しか生成されません。これには、次のような利点があります。

また、NOLOGGING句を指定することで、SQL*Loaderを使用した後続のダイレクト・ロードおよびダイレクト・ロードINSERT操作がロギングされなくなります。後続のデータ操作文(DML)文(UPDATEDELETEおよび従来型パスの挿入)は、表のNOLOGGING属性の影響を受けず、REDOを生成します。

表の作成後にその表の損失(たとえば、表の作成に使用したデータにアクセスできなくなるなど)を避ける必要がある場合は、作成直後に表のバックアップを取得してください。一時的に使用するために作成する表など、そのような予防策が不要な場合もあります。

一般に、NOLOGGINGを指定して表を作成するときは、小規模な表より大規模な表のほうが相対的にパフォーマンスの向上が大きくなります。小規模な表の場合は、NOLOGGINGを指定しても、表作成に要する時間にほとんど影響はありません。 一方、大規模な表では、特に表作成をパラレル化したときにパフォーマンスが著しく向上します。

表圧縮の使用

データベースがGBまたはTB以上に大きくなる場合は、表圧縮の使用を検討してください。表圧縮を使用すると、ディスク領域が節約され、バッファ・キャッシュのメモリー使用が削減されます。また、読込み中の問合せ実行速度も向上します。ただし、データのロードやDMLについてはCPUオーバーヘッドがかかります。表圧縮はアプリケーションに対して完全に透過的です。長い読取り専用操作が実行されるオンライン分析処理(OLAP)システムで特に有効ですが、オンライン・トランザクション処理(OLTP)システムでも使用できます。

表圧縮の指定には、CREATE TABLE文のCOMPRESS句を使用します。既存の表に対して圧縮を使用可能にするには、この句をALTER TABLE文で使用します。この場合、圧縮されるデータは、圧縮を使用可能にした後で挿入または更新されたデータのみです。同様に、ALTER TABLE...NOCOMPRESS文を使用すると、既存の圧縮表に対する表圧縮を使用禁止にできます。この場合、圧縮済のデータはすべて圧縮されたままになり、新規データは圧縮されずに挿入されます。

圧縮はすべての表操作に対して使用可能にするか、またはダイレクト・パス・インサートに対してのみ使用可能にできます。すべての操作に対して暗号化が使用可能な場合、圧縮は、すべてのDML文中、およびバルク(ダイレクト・パス)挿入操作でデータが挿入される場合に実行されます。従来のDMLに対して圧縮を使用可能にするには、COMPATIBLE初期化パラメータを11.1.0以上に設定する必要があります。

すべての操作に対して圧縮を使用可能にするには、COMPRESS FOR ALL OPERATIONS句を使用する必要があります。ダイレクト・パス・インサートに対してのみ圧縮を使用可能にするには、COMPRESS FOR DIRECT_LOAD OPERATIONS句を使用します。キーワードCOMPRESSは、単独でCOMPRESS FOR DIRECT_LOAD OPERATIONS句と同じであり、以前のデータベース・リリースと同じ圧縮動作が起動されます。

圧縮表の列の追加と削除

表のすべての操作で圧縮が使用可能なときには、表の列の追加および削除ができます。ダイレクト・パス・インサートに対してのみ圧縮が使用可能な場合は、列を削除できず、デフォルト値を指定しない場合にのみ列を追加できます。

次の例では、OLTPアプリケーションで使用される表transactionのすべての操作に対して圧縮が使用可能になります。

CREATE TABLE transaction ( ... ) COMPRESS FOR ALL OPERATIONS;

次の2つの例では、データ・ウェアハウスのファクト表であるsales_history表のダイレクト・パス・インサートに対してのみ圧縮が使用可能になります。

CREATE TABLE sales_history ( ... ) COMPRESS FOR DIRECT_LOAD OPERATIONS;

CREATE TABLE sales_history ( ... ) COMPRESS;
圧縮とパーティション表

圧縮はパーティション・レベルで使用可能または使用禁止にできます。したがって、圧縮パーティションと非圧縮パーティションの両方を含む表を作成できます。表に対する圧縮の設定とそのパーティションに対する設定が一致しない場合、パーティションについてはパーティションの設定が優先されます。次の例では、northeastパーティション以外のすべてのパーティションが圧縮されます。

CREATE TABLE sales
      (saleskey number,
       quarter number,
       product number,
       salesperson number,
       amount number(12, 2),
       region varchar2(10)) COMPRESS
   PARTITION BY LIST (region)
      (PARTITION northwest VALUES ('NORTHWEST'),
       PARTITION southwest VALUES ('SOUTHWEST'),
       PARTITION northeast VALUES  ('NORTHEAST') NOCOMPRESS,
       PARTITION southeast VALUES ('SOUTHEAST'),
       PARTITION western VALUES ('WESTERN'));
表が圧縮されているかどうかの判別

圧縮表の場合は、*_TABLESデータ・ディクショナリ・ビューのCOMPRESSION列にENABLEDと表示されます。パーティション表の場合はこの列がNULLで、*_TAB_PARTITIONSデータ・ディクショナリ・ビューのCOMPRESSION列に、圧縮されているパーティションが示されます。さらに、COMPRESS_FOR列に、表の圧縮対象がFOR ALL OPERATIONS(すべての操作)かDIRECT LOAD ONLY(ダイレクト・ロードのみ)かが表示されます。

SQL> SELECT table_name, compression, compress_for FROM user_tables;
 
TABLE_NAME       COMPRESS COMPRESS_FOR
---------------- -------- ------------------
T1               DISABLED
T2               ENABLED  DIRECT LOAD ONLY
T3               ENABLED  FOR ALL OPERATIONS

関連項目:

 

機密データを格納する列の暗号化

機密データを格納する個々の表の列を暗号化できます。機密データには、社会保障番号、クレジット・カード番号、医療記録などがあります。列の暗号化は、アプリケーションに対して完全に透過的ですが、いくつか制限事項があります。

暗号化は、セキュリティの問題をすべて解決するわけではありませんが、ユーザーがデータベースのセキュリティ機能を迂回して、オペレーティング・システムのファイル・システムから直接データベース・ファイルにアクセスしようとした場合に、そのユーザーからデータを保護します。

列の暗号化ではOracle Databaseの透過的データ暗号化が使用されます。この機能を使用するには、データベースのマスター暗号化キーを格納するためのOracleウォレットを作成する必要があります。暗号化列を含む表を作成する場合、および暗号化データを格納または取得する場合は、ウォレットがオープンしている必要があります。ウォレットは、オープンするとすべてのセッションで使用可能になり、明示的にクローズするか、データベースが停止されるまではオープンしたままになります。

透過的データ暗号化では、次に示すAdvanced Encryption Standard(AES)アルゴリズムやTriple Data Encryption Standard(3DES)アルゴリズムなど、業界標準の暗号化アルゴリズムがサポートされています。

使用するアルゴリズムは表の作成時に選択します。表のすべての暗号化列で同じアルゴリズムが使用されます。デフォルトはAES192です。暗号化キーの長さはアルゴリズム名で示されています。たとえば、AES128アルゴリズムでは128ビットのキーが使用されます。

1つ以上の表にある多数の列を暗号化する場合は、かわりに表領域全体を暗号化してその表領域にこれらの表を格納することも考慮できます。表領域の暗号化でも同様に透過的データ暗号化機能が使用されますが、物理的なブロック・レベルで暗号化されるため、多数の列を暗号化するよりパフォーマンスが向上します。表領域レベルで暗号化する別の理由は、列暗号化の次の制限事項に対処するためです。

表サイズの見積りと見積りに応じた計画

表を作成する前に表のサイズを見積ります。見積りは、なるべくデータベース計画の一部として実行します。データベース表のサイズと用途を確認することは、データベース計画の重要な部分です。

表の見積りサイズの合計と、索引、UNDO領域およびREDOログ・ファイルの見積りを使用して、作成するデータベースを格納するために必要なディスク容量を決定できます。この見積りによって、適切なハードウェアを購入できます。

見積ったサイズと個々の表サイズの増加率を使用すると、作成する表に最適な表領域の属性とその基礎となるデータファイルを適格に判断できます。これによって、表のディスク領域の管理が容易になり、表を使用するアプリケーションのI/Oパフォーマンスが向上します。

表作成時の制限事項

表の計画と使用に影響を与える可能性のある制限事項がいくつかあります。

表の作成

自分のスキーマに新しい表を作成するには、CREATE TABLEシステム権限が必要です。別のユーザーのスキーマに表を作成するには、CREATE ANY TABLEシステム権限が必要です。また、表の所有者には、その表を含む表領域に対する割当て制限またはUNLIMITED TABLESPACEシステム権限が必要です。

表はSQL文CREATE TABLEを使用して作成します。

この項の内容は、次のとおりです。

例: 表の作成

次の文を発行すると、表admin_emphrスキーマに作成され、admin_tbs表領域に格納されます。

CREATE TABLE hr.admin_emp (
         empno      NUMBER(5) PRIMARY KEY,
         ename      VARCHAR2(15) NOT NULL,
         ssn        NUMBER(9) ENCRYPT,
         job        VARCHAR2(10),
         mgr        NUMBER(5),
         hiredate   DATE DEFAULT (sysdate),
         photo      BLOB,
         sal        NUMBER(7,2),
         hrly_rate  NUMBER(7,2) GENERATED ALWAYS AS (sal/2080),
         comm       NUMBER(7,2),
         deptno     NUMBER(3) NOT NULL
                     CONSTRAINT admin_dept_fkey REFERENCES hr.departments
                     (department_id))
   TABLESPACE admin_tbs
   STORAGE ( INITIAL 50K);

COMMENT ON TABLE hr.admin_emp IS 'Enhanced employee table';

次に、この例について説明します。

一時表の作成

一時表は、複数のDML操作の実行によって作成されるため、結果セットがバッファリング(一時的に保存)されるアプリケーションに有用です。たとえば、次のような場合を考えてみます。

Webベースの航空予約アプリケーションでは、顧客がオプションの旅程を複数作成できます。各旅程は一時表の行で表されます。アプリケーションは、旅程への変更を反映するように行を更新します。使用する旅程を顧客が決定すると、アプリケーションは、該当する旅程の行を永続表に移動します。

セッションの開始時から終了時まで旅程データはプライベートです。セッションの終了時に、オプションの旅程は削除されます。

一時表の定義はすべてのセッションで参照できますが、一時表内のデータを参照できるのは、そのデータを表に挿入するセッションのみです。

一時表を作成するには、CREATE GLOBAL TEMPORARY TABLE文を使用します。ON COMMIT句は、表のデータがトランザクション固有(デフォルト)であるか、セッション固有であるかを示します。各オプションが表す意味は、次のとおりです。

ON COMMIT設定  意味 

DELETE ROWS  

トランザクション固有の一時表を作成します。セッションは、表に最初に挿入するトランザクションを持つ一時表に対するバインドになります。バインドは、トランザクション終了時に消失します。表は、各コミット後に切捨て(すべての行を削除)が行われます。 

PRESERVE ROWS  

セッション固有の一時表を作成します。セッションは、セッション内で表に最初に挿入される一時表に対するバインドになります。このバインドは、セッションの最後で、またはセッション内で表に対するTRUNCATEが発行されることによって消去されます。表は、セッション終了時に切り捨てられます。 

次の文では、トランザクション固有の一時表を作成しています。

CREATE GLOBAL TEMPORARY TABLE admin_work_area
        (startdate DATE,
         enddate DATE,
         class CHAR(20))
      ON COMMIT DELETE ROWS;

一時表には索引を作成できます。この索引も一時索引であり、索引内のデータのセッションまたはトランザクションの有効範囲は、基礎となる表のデータと同じです。

デフォルトで、一時表の行は、作成したユーザーのデフォルトの一時表領域に格納されます。ただし、一時表の作成時にCREATE GLOBAL TEMPORARY TABLETABLESPACE句を使用すると、一時表を別の表領域に割り当てることができます。この機能を使用すると、一時表で使用される領域を節約できます。たとえば、小規模な一時表の操作を多数実行する必要があるとします。このとき、デフォルトの一時表領域はソート操作用に構成されているためにエクステント・サイズが大きい場合、これらの小規模な操作では不要なディスク領域が大量に消費されます。この場合は、エクステント・サイズの小さい第2の一時表領域を割り当てることをお薦めします。

次の2つの文では、エクステント・サイズが64KBで一時表領域が作成され、その表領域に新規の一時表が作成されます。

CREATE TEMPORARY TABLESPACE tbs_t1 
    TEMPFILE 'tbs_t1.f' SIZE 50m REUSE AUTOEXTEND ON
    MAXSIZE UNLIMITED
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K;

CREATE GLOBAL TEMPORARY TABLE admin_work_area
        (startdate DATE,
         enddate DATE,
         class CHAR(20))
      ON COMMIT DELETE ROWS
      TABLESPACE tbs_t1;


関連項目:

「一時表領域」 


永続表とは異なり、一時表とその索引には、作成時にセグメントが自動的に割り当てられません。かわりに、最初にINSERT(またはCREATE TABLE AS SELECT)が実行されると、セグメントが割り当てられます。これは、最初のINSERTの前に、SELECTUPDATEまたはDELETEが実行されると、表が空に見えることを意味します。

既存の一時表でDDL操作(TRUNCATEを除く)が許可されるのは、その一時表にバインドされているセッションがない場合のみです。

トランザクションをロールバックすると、入力したデータは消失しますが、表定義はそのまま残ります。

トランザクション固有の一時表では、1回に1トランザクションのみが許可されます。単一のトランザクションに複数の自律型トランザクションがある場合、各自律型トランザクションは、直前のトランザクションのコミット直後にのみ表を使用できます。

一時表のデータは、その定義どおり一時的なため、一時表データのバックアップとリカバリはシステム障害のイベントでは使用できません。このような障害に備えて、一時表データを保存する代替方法を用意してください。

表作成のパラレル化

表の作成にAS SELECT句を指定して、別の表からデータを移入すると、パラレル実行を利用できます。CREATE TABLE...AS SELECT文には、CREATE部分(DDL)とSELECT部分(問合せ)の2つの部分があります。Oracle Databaseでは、この文の両方の部分をパラレル化できます。 次の条件が1つでも成り立つ場合は、CREATE部分がパラレル化されます。

次の条件がすべて成り立つ場合は、問合せ部分がパラレル化されます。

表の作成をパラレル化した場合、その表には対応付けられたパラレル宣言(PARALLEL句)が付きます。表に対するその後のすべてのDMLまたは問合せでは、パラレル化が可能な場合、パラレル実行の使用が試みられます。

表の作成をパラレル化し、表圧縮を使用して圧縮形式で結果を格納する簡単な文を次に示します。

CREATE TABLE hr.admin_emp_dept
     PARALLEL COMPRESS
     AS SELECT * FROM hr.employees
     WHERE department_id = 10;

この場合のPARALLEL句は、表の作成時に最適な数のパラレル実行サーバーを選択することをデータベースに指示しています。

関連項目:

 

表のロード

表にデータを挿入または初期ロードするには、いくつかの方法があります。最も一般的に使用される方法は、次のとおりです。

方法  説明 

SQL*Loader 

これは、外部ファイルからOracle Databaseの表にデータをロードするOracleのユーティリティ・プログラムです。

SQL*Loaderの詳細は、『Oracle Databaseユーティリティ』を参照してください。 

CREATE TABLE ...AS SELECT文(CTAS) 

このSQL文を使用すると、表を作成し、別の既存の表から選択したデータを移入できます。 

INSERT文 

INSERT文を使用すると、列値を指定するか、または別の既存の表からデータを選択する副問合せを指定することによって、行を表に追加できます。 

MERGE文 

MERGE文を使用すると、別の既存の表から行を選択することによって、行を表に挿入するか、または表の行を更新できます。新しいデータの行が、表にすでに存在している項目に対応している場合はUPDATEが実行され、対応する項目がない場合はINSERTが実行されます。 

CREATE TABLE ... AS SELECTINSERTおよびMERGE文の詳細は、『Oracle Database SQLリファレンス』を参照してください。

DMLエラー・ロギングを使用したデータの挿入

副問合せでINSERT文を使用して表をロードすると、エラーが発生した場合は文が終了して文全体がロールバックされます。これは、時間とシステム・リソースを無駄に消費することになります。このようなINSERT文の場合は、DMLエラー・ロギング機能を使用することで、この状況を回避できます。

DMLエラー・ロギングを使用するには、エラー・ロギング表の名前を指定する句を文に追加します。データベースは、このエラー・ロギング表にDML操作の過程で発生したエラーを記録します。このエラー・ロギング句をINSERT文に追加すると、特定の種類のエラーでは、文が終了してロールバックされることがなくなります。かわりに、各エラーが記録され、文は続行されます。エラーが発生した行については、後で訂正処理を実行します。

DMLエラー・ロギングは、INSERTUPDATEMERGEおよびDELETE文で機能します。ここでは、特にINSERT文について説明します。

DMLエラー・ロギングを使用してデータを挿入する手順は、次のとおりです。

  1. エラー・ロギング表を作成します(オプション)。

    表は、手動で作成するか、またはDBMS_ERRLOGパッケージを使用して自動的に作成できます。詳細は、「エラー・ロギング表の作成」を参照してください。

  2. エラー・ロギング句を指定してINSERT文を実行します。この句は、次のように動作します。

    • 必要に応じて、作成したエラー・ロギング表を参照します。エラー・ロギング表名を指定しない場合、データベースは、デフォルトの名前のエラー・ロギング表に記録します。デフォルトのエラー・ロギング表名は、ERR$_の後に、挿入対象となる表名の最初の25文字を付加した名前です。

    • 必要に応じて、タグ(カッコで囲まれた数値または文字列リテラル)を指定します。このタグはエラー・ログに追加され、エラーの原因となった文の識別に役立ちます。タグを省略した場合は、NULL値が使用されます。

    • 必要に応じて、REJECT LIMIT副次句を指定します。

      この副次句は、許容可能なエラーの最大発生数を示します。この最大数を超えると、INSERT文が終了してロールバックされます。UNLIMITEDを指定することもできます。デフォルトの拒否の上限は0(ゼロ)です。これは、最初のエラーが発生した時点でエラーが記録され、文がロールバックされることを意味します。パラレルDML操作では、この拒否の上限が各パラレル・サーバーに対して適用されます。


      注意:

      拒否の上限を超えて文がロールバックされた場合、エラー・ロギング表には、その時点までに記録されたログ・エントリが保持されます。 


    エラー・ロギング句の構文については、『Oracle Database SQLリファレンス』を参照してください。

  3. エラー・ロギング表を問い合せ、エラーの原因となった行に対する訂正処理を実行します。

    エラー・ロギング表の構造については、後述の「エラー・ロギング表の書式」を参照してください。

次の文は、DW_EMPL表に行を挿入し、ERR_EMPL表にエラーを記録します。タグ'daily_load'は、各ログ・エントリにコピーされます。エラー数が25を超えると、文が終了してロールバックされます。

INSERT INTO dw_empl
  SELECT employee_id, first_name, last_name, hire_date, salary, department_id 
  FROM employees
  WHERE hire_date > sysdate - 7
  LOG ERRORS INTO err_empl ('daily_load') REJECT LIMIT 25

エラー・ロギングのその他の例については、『Oracle Database SQLリファレンス』および『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

エラー・ロギング表の書式

エラー・ロギング表は、次の2つの部分で構成されます。

エラー・ロギング表の作成

エラー・ロギング表は手動で作成できます。または、PL/SQLパッケージを使用して自動的に作成できます。

エラー・ロギング表の自動作成

エラー・ロギング表を自動作成するには、DBMS_ERRLOGパッケージを使用します。CREATE_ERROR_LOGプロシージャは、エラーを説明するための必須列および指定されたDML表の列をすべて備えたエラー・ロギング表を作成し、表18-2に示したデータ型マッピングを実行します。

次の文は、前述の例で使用したエラー・ロギング表を作成します。

EXECUTE DBMS_ERRLOG.CREATE_ERROR_LOG('DW_EMPL', 'ERR_EMPL');

DBMS_ERRLOGの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

手動によるエラー・ロギング表の作成

エラー・ロギング表を手動で作成するには、標準DDLを使用します。表の構造に関する要件は、「エラー・ロギング表の書式」を参照してください。エラーを説明するための必須列はすべて挿入する必要があります。列は順不同にできますが、必須列は表の最初の方の列に指定する必要があります。

エラー・ロギングの制限事項と注意

Oracle Databaseは、DML操作中に次のエラーを記録します。

一部のエラーは記録されずに、DML操作の終了およびロールバックが実施されます。これらのエラーの一覧とDMLロギングの他の制約については、『Oracle Database SQLリファレンス』のINSERTに関する項でerror_logging_clauseの説明を参照してください。

領域に関する考慮事項

DMLエラー・ロギングを使用するには、その前に領域の要件について考慮する必要があります。挿入する表の領域のみでなく、エラー・ロギング表の領域も必要です。

セキュリティ

DMLエラー・ロギングを指定したINSERT文を発行するユーザーには、エラー・ロギング表に対するINSERT権限が必要です。

関連項目:

DMLエラー・ロギングの例は、『Oracle Database SQLリファレンス』および『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 

ダイレクト・パス・インサートを使用したデータの表への挿入

Oracle Databaseでは、次の2つのいずれかの方法でデータが挿入されます。

さらに、シリアルまたはパラレルのいずれかのモードでデータを挿入できます。シリアル・モードでは、単一のプロセスが文を実行し、パラレル・モードでは、複数のプロセスが1つのSQL文を実行するために協調して同時に動作します。後者は、パラレル実行と呼ばれます。

ここでは、表へのデータの挿入について、1つの方法を中心に説明します。具体的には、INSERT文のダイレクト・パス形式を使用します。この章の内容は、次のとおりです。

ダイレクト・パス・インサートを使用する利点

ダイレクト・パスINSERTのパフォーマンス上の利点は、次のとおりです。

ダイレクト・パス・インサートの使用可能化

ダイレクト・パスINSERT文を使用してパラレル・モードでデータを挿入することによって、またはOracleのSQL*Loaderユーティリティをダイレクト・パス・モードで使用することによって、ダイレクト・パスINSERT処理を実装できます。ダイレクト・パス・インサートは、シリアル・モードまたはパラレル・モードで実行できます。

シリアル・モードでダイレクト・パスINSERTをアクティブにするには、INSERTキーワードの直後またはINSERT文の副問合せのSELECTキーワードの直後にある各INSERT文にAPPENDヒントを指定する必要があります。

パラレルDMLモードで挿入する場合は、ダイレクト・パスINSERTがデフォルトです。パラレルDMLモードで実行するには、次の要件を満たす必要があります。

ダイレクト・パスINSERTを使用禁止にするには、各INSERT文にNOAPPENDヒントを指定します。この指定によって、パラレルDMLモードが無視されます。


注意:

  • ダイレクト・パスINSERTがサポートするのは、INSERT文の副問合せ構文でのみで、VALUES句はサポートされません。 INSERT文の副問合せ構文の詳細は、『Oracle Database SQLリファレンス』を参照してください。

  • ダイレクト・パスINSERTの使用については、他の制限事項があります。 詳細は、『Oracle Database SQLリファレンス』を参照してください。

 

関連項目:

ヒントの使用の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 

ダイレクト・パス・インサートの動作

ダイレクト・パスINSERTは、パーティション表と非パーティション表の両方で使用できます。

パーティション表または非パーティション表へのシリアル・ダイレクト・パス・インサート

シングル・プロセスでは、表セグメントまたは各パーティション・セグメントの現在の最高水位標の上にデータが挿入されます(最高水位標とは、データを受け取るためにブロックがフォーマットされないレベルです)。COMMITを実行すると、最高水位標が新しい値に更新され、ユーザーにデータが表示されます。

パーティション表へのパラレル・ダイレクト・パス・インサート

この状況は、シリアル・ダイレクト・パスINSERTと類似しています。各パラレル実行サーバーには、1つ以上のパーティションが割り当てられます。単一のパーティションで実行するプロセスは1つのみです。各パラレル実行サーバーでは、割り当てられたパーティション・セグメントの現在の最高水位標の上にデータを挿入します。COMMITを実行すると、各パーティション・セグメントの最高水位標が新しい値に更新され、ユーザーにデータが表示されます。

非パーティション表へのパラレル・ダイレクト・パス・インサート

各パラレル実行サーバーは、新しい一時セグメントを割り当て、その一時セグメントにデータを挿入します。COMMITを実行すると、パラレル実行コーディネータが新しい一時セグメントをプライマリ表セグメントにマージし、ユーザーにデータが表示されます。

ダイレクト・パス・インサートのロギング・モードの指定

ダイレクト・パスINSERTでは、インサート処理のREDOおよびロールバック情報を記録するかどうかを選択できます。

ロギング付きダイレクト・パス・インサート

このモードでは、Oracle Databaseによってインスタンスの完全なREDOロギングおよびメディア・リカバリが実行されます。データベースがARCHIVELOGモードの場合は、REDOログをテープにアーカイブできます。データベースがNOARCHIVELOG モードの場合、インスタンスのクラッシュはリカバリできますが、ディスク障害はリカバリできません。

ロギングなしダイレクト・パス・インサート

このモードでは、Oracle DatabaseによってREDOまたはUNDOロギングなしでデータが挿入されます(新規エクステントに無効のマークを付けるために最小限のロギングが行われ、データ・ディクショナリの変更は常にロギングされます)。このモードによって、パフォーマンスが改善します。ただし、後でメディア・リカバリを実行する必要がある場合は、REDOデータがロギングされていないため、エクステント無効化レコードによって一連のブロックに論理的破損のマークが付きます。したがって、このようなインサート処理の後にはデータをバックアップすることが重要です。

ダイレクト・パス・インサートのその他の考慮事項

ダイレクト・パスINSERTを使用する際には、さらに次の考慮事項があります。

圧縮表

表の作成にCOMPRESSまたはCOMPRESS FOR DIRECT_LOAD OPERATIONS句を使用する場合、ダイレクト・パスINSERTを使用して表のデータをロード時に圧縮できます。 表の作成にCOMPRESS FOR ALL OPERATIONS句を使用する場合、従来型INSERTまたはダイレクト・パスINSERTを使用して表のデータをロード時に圧縮できます。

詳細は、「表圧縮の使用」を参照してください。

ダイレクト・パス・インサートでの索引メンテナンス

索引がある(パーティションまたは非パーティション)表では、ダイレクト・パスINSERT処理の終了時に、Oracle Databaseが索引メンテナンスを実行します。この索引メンテナンスは、パラレル・ダイレクト・パスINSERTに対してはパラレル実行サーバーで、シリアル・ダイレクト・パスINSERTに対してはシングル・プロセスで実行されます。INSERT処理の前に索引を削除し、後で再作成することによって、索引メンテナンスでのパフォーマンスへの影響を回避できます。

ダイレクト・パス・インサートでの領域に関する考慮事項

ダイレクト・パスINSERTは、従来型パスINSERTよりも多くの領域を必要とします。

すべてのシリアル・ダイレクト・パスINSERT処理では、パーティション表へのパラレル・ダイレクト・パスINSERTと同様に、影響を受けるセグメントの最高水位標の上にデータが挿入されます。このため、追加の領域が必要となります。

非パーティション表へのパラレル・ダイレクト・パスINSERTは、各並列度ごとに一時セグメントを作成するため、より多くの領域を必要とします。非パーティション表が自動セグメント領域管理モードのローカル管理表領域にない場合は、NEXTおよびPCTINCREASE記憶域パラメータ、およびMINIMUM EXTENT表領域パラメータの値を変更して、一時セグメントに十分な(かつ過剰ではない)記憶域を用意してください。次の事項を考慮に入れ、これらのパラメータに値を選択します。

これらのパラメータは、ダイレクト・パスINSERT処理の完了後に、シリアル処理に適した設定に再設定できます。

ダイレクト・パス・インサートでのロックに関する考慮事項

ダイレクト・パスINSERTでは、表(またはパーティション表のすべてのパーティション)の排他ロックが取得されます。その結果、ユーザーは、表に対する挿入、更新または削除の同時操作すべてを実行できません。同時索引作成および作成操作も許可されません。同時問合せはサポートされますが、問合せではインサート処理以前の情報のみが返されます。

表に関する統計の自動収集

PL/SQLパッケージDBMS_STATSを使用すると、コストベースの最適化に関する統計を生成および管理できます。このパッケージを使用して、統計の収集、変更、表示、エクスポート、インポートおよび削除ができます。また、すでに収集した統計を識別または命名する際も、このパッケージを使用できます。

以前は、DBMS_STATSを使用可能にし、CREATE(またはALTERTABLE文でMONITORINGキーワードを指定して、表の統計を自動的に収集していました。Oracle Database 11gからは、MONITORINGおよびNOMONITORINGキーワードは非推奨になり、統計は自動的に収集されます。これらのキーワードを指定しても無視されます。

監視では、統計が最後に収集された時点以降表に対して実行されたINSERTUPDATEおよびDELETEの概数が追跡されます。影響を受ける行数に関する情報は、SMONが周期的に(およそ3時間ごとに)データをデータ・ディクショナリに取り込むまで、システム・グローバル領域(SGA)に保持されます。このデータ・ディクショナリ情報は、DBA_TAB_MODIFICATIONSALL_TAB_MODIFICATIONSまたはUSER_TAB_MODIFICATIONSを通じて参照できます。データベースはこれらのビューを使用して、失効した統計を持つ表を識別します。

表の監視を使用禁止にするには、STATISTICS_LEVEL初期化パラメータをBASICに設定します。デフォルトはTYPICALで、自動統計収集が使用可能です。自動統計収集とDBMS_STATSパッケージによって、オプティマイザは正確な実行計画を生成できます。

関連項目:

  • STATISTICS_LEVEL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

  • オプティマイザ統計の管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

  • DBMS_STATSパッケージを使用する詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

  • スケジューラを使用して統計を自動的に収集する方法は、「自動化メンテナンス・タスクの概要」を参照してください。

 

表の変更

表を変更するにはALTER TABLE文を使用します。表を変更するには、その表が自分のスキーマに含まれているか、その表のALTERオブジェクト権限またはALTER ANY TABLEシステム権限のいずれかを持っている必要があります。

ALTER TABLE文の使用方法については、次の各項を参照してください。

ALTER TABLE文を使用する理由

ALTER TABLE文は、表に影響を与える次の処理を実行するために使用できます。

これらの多くのタスクについて、次の各項で説明します。

表の物理属性の変更

表のトランザクション・エントリ設定INITRANSを変更する場合、INITRANSの新しい設定は、その後表に割り当てられるデータ・ブロックにのみ適用されます。

記憶域パラメータINITIALMINEXTENTSは変更できません。他の記憶域パラメータ(たとえばNEXTPCTINCREASE)の新しい設定はすべて、その後に表に割り当てられるエクステントにのみ影響します。割り当てられる次のエクステントのサイズは、NEXTPCTINCREASEの現行値によって決まります。前の値に基づいて決まるわけではありません。

関連項目:

物理属性句と記憶域句の詳細は、『Oracle Database SQLリファレンス』を参照してください。 

新規セグメントまたは表領域への表の移動

ALTER TABLE...MOVE文を使用すると、非パーティション表のデータまたはパーティション表のパーティションのデータを新しいセグメントに再配置できます。必要に応じて、割当て制限がある別の表領域に再配置することもできます。また、この文を使用してALTER TABLEでは変更できないデータを含んでいる表またはパーティションの記憶域属性も変更できます。ALTER TABLE...MOVE文にCOMPRESS句を指定すると、表圧縮を使用して新しいセグメントを格納できます。

表を新規データファイルを含む新しい表領域に移動する重要な理由の1つは、列データの古いバージョン(セグメントの縮小、再編成または以前の表移動によってディスクの未使用部分に現在も残されているバージョン)が、オペレーティング・システム・ユーティリティなどを使用してデータベースのアクセス制御を迂回することによって参照される可能性をなくすためです。これは、透過的データ暗号化を追加して変更しようとしている列の場合は特に重要です。


注意:

ALTER TABLE...MOVE文では、文の実行中は表に対するDML操作が許可されません。 表の移動中にも表に対してDMLを使用できるようにする場合は、「表のオンライン再定義」を参照してください。 


次の文は、新しい記憶域パラメータを指定して、hr.admin_emp表を新しいセグメントに移動します。

ALTER TABLE hr.admin_emp MOVE
      STORAGE ( INITIAL 20K
                NEXT 40K
                MINEXTENTS 2
                MAXEXTENTS 20
                PCTINCREASE 0 );

表を移動すると、表の行のROWIDが変わります。これによって、表の索引にUNUSABLEのマークが付き、これらの索引を使用して表にアクセスするDMLに対しては、ORA-01502エラーが返されます。表の索引を削除または再作成する必要があります。同様に、表の統計は無効になるため、表を移動した後に新しい統計を収集する必要があります。

表にLOB列が含まれている場合は、この文を使用して、ユーザーが明示的に指定できるLOBデータと、表に関連したLOB索引セグメントを、表とともに移動できます。特に指定しない場合、デフォルトではLOBデータとLOB索引セグメントは移動されません。

関連項目:

透過的データ暗号化の詳細は、「機密データを格納する列の暗号化」を参照してください。 

表の記憶域の手動割当て

Oracle Databaseは、必要に応じて表のデータ・セグメントに追加のエクステントを動的に割り当てます。ただし、表に追加のエクステントを明示的に割り当てることもできます。たとえば、Oracle Real Application Clusters環境で、表のエクステントを特定のインスタンスに対して明示的に割り当てることが可能です。

新しいエクステントは、ALTER TABLE...ALLOCATE EXTENT句を使用して表に割り当てることができます。

また、ALTER TABLE文のDEALLOCATE UNUSED句を使用して、未使用領域の割当てを明示的に解除することもできます。 この操作については、「使用できない領域の再生」を参照してください。

関連項目:

Oracle Real Application Clusters環境でのALLOCATE EXTENT句の使用方法は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 

既存の列定義の変更

既存の列定義を変更するには、ALTER TABLE...MODIFY文を使用します。列のデータ型、デフォルト値、列制約、列の式(仮想列の場合)または列の暗号化は変更できます。

既存のデータがすべて新しい長さを満たしている場合は、既存の列の長さを拡張または縮小できます。列は、バイト・セマンティクスからCHARセマンティクスに、あるいはその逆に変更できます。空でないCHAR列の長さを縮小するには、初期化パラメータBLANK_TRIMMING=TRUEを設定する必要があります。

データ型CHARの列長を拡張するために表を変更している場合、特に表の行数が多い場合は、この操作は時間がかかり、さらに相当な追加記憶域を必要とする可能性があります。これは、各行のCHAR値に空白を埋めて、新しい列長に合わせる必要があるためです。

関連項目:

表の列の変更とその他の制限事項の詳細は、『Oracle Database SQLリファレンス』を参照してください。 

表の列の追加

既存の表に列を追加するには、ALTER TABLE...ADD文を使用します。

次の文は、hr.admin_emp表を変更して新しい列bonusを追加します。

ALTER TABLE hr.admin_emp
      ADD (bonus NUMBER (7,2));

表に新しい列を追加すると、DEFAULT句を指定しないかぎり、その列は最初はNULLです。デフォルト値を指定すると、各行がデフォルト値で即時に更新されます。この処理に多少時間を要すること、および更新時には表に排他DMLロックがかかることに注意してください。表のタイプ(例: LOB列のない表)によっては、NOT NULL制約とデフォルト値の両方を指定すると、データベースによって列の追加操作が最適化され、表がDML用にロックされる時間が大幅に短縮されます。

NOT NULL制約付きの列を追加できるのは、表に行がまったく含まれていない場合、またはデフォルト値を指定する場合のみです。

関連項目:

表の列の追加に関するその他のルールおよび制限事項は、『Oracle Database SQLリファレンス』を参照してください。 

圧縮表への列の追加

表のすべての操作で圧縮が使用可能な場合は、デフォルト値を指定してもしなくても、その表に列を追加できます。ダイレクト・パス・インサートに対してのみ圧縮が使用可能な場合は、デフォルト値を指定しない場合にのみ、列を追加できます。

関連項目:

「表圧縮の使用」 

仮想列の追加

新しい列が仮想列の場合、その値は列式によって決定されます(仮想列の値は、問合せ実行時にのみ計算されることに注意してください)。

表の列名の変更

Oracle Databaseでは、表の既存の列の名前を変更できます。列名を変更するには、ALTER TABLE文の RENAME COLUMN句を使用します。新しい名前には、表の既存の列名と競合しない名前を指定する必要があります。RENAME COLUMN句とともに他の句は使用できません。

次の文は、hr.admin_emp表のcomm列の名前を変更します。

ALTER TABLE hr.admin_emp
      RENAME COLUMN comm TO commission;

前述のように、表の列を変更すると、依存するオブジェクトが無効になる可能性があります。ただし、列名を変更すると、ファンクション索引とCHECK制約が引き続き有効になるように、関連するデータ・ディクショナリ表が更新されます。

また、Oracle Databaseでは列制約の名前も変更できます。 この操作については、「制約名の変更」を参照してください。


注意:

ALTER TABLERENAME TO句の構文はRENAME COLUMN句に似ていますが、表自体の名前の変更に使用します。 


表の列の削除

索引構成表などの表から、不要になった列を削除できます。これにより、データベースの領域を解放でき、データをエクスポート/インポートしてから索引と制約を再作成する必要がなくなります。

表からすべての列を削除することはできません。また、SYSが所有している表の列も削除できません。削除しようとするとエラーが発生します。

関連項目:

表からの列の削除に関するその他の制限事項およびオプションの詳細は、『Oracle Database SQLリファレンス』を参照してください。 

表から列を削除する方法

ALTER TABLE...DROP COLUMN文を発行すると、列記述子およびターゲット列に関連付けられているデータが表の各行から削除されます。1つの文で複数の列を削除できます。

次の文は、hr.admin_emp表から列を削除する操作の例を示しています。最初の文は、sal列のみを削除します。

ALTER TABLE hr.admin_emp DROP COLUMN sal;

次の文は、bonus列とcomm列を両方とも削除します。

ALTER TABLE hr.admin_emp DROP (bonus, commission);

列に未使用マークを付ける方法

大きい表のすべての行から列データを削除する際に所要時間が重要な場合は、ALTER TABLE...SET UNUSED文を使用できます。この文は1つ以上の列に未使用マークを付けますが、実際にターゲット列を削除したり該当列が占めるディスク領域をリストアすることはありません。ただし、未使用マークが付けられた列は、問合せやデータ・ディクショナリ・ビューに表示されなくなり、その名前が削除されて新しい列に再利用できるようになります。その列に定義されている制約、索引および統計も、すべて削除されます。

hiredate列とmgr列に未使用マークを付けるには、次の文を実行します。

ALTER TABLE hr.admin_emp SET UNUSED (hiredate, mgr);

後でALTER TABLE...DROP UNUSED COLUMNS文を発行し、未使用マークが付いている列を削除できます。表の特定列の明示的な削除文を発行すると、未使用列もターゲット表から削除されます。

データ・ディクショナリ・ビューUSER_UNUSED_COL_TABSALL_UNUSED_COL_TABSまたはDBA_UNUSED_COL_TABSを使用すると、未使用の列を含むすべての表を表示できます。COUNTフィールドには、表の未使用の列数が表示されます。

SELECT * FROM DBA_UNUSED_COL_TABS;

OWNER                       TABLE_NAME                  COUNT
--------------------------- --------------------------- -----
HR                          ADMIN_EMP                       2

外部表の場合は、SET UNUSED文がALTER TABLE DROP COLUMN文に透過的に変換されます。外部表はデータベース内でメタデータのみで構成されているため、DROP COLUMN文はSET UNUSED文の実行と同じことになります。

未使用列の削除

未使用列に対して実行できるのは、ALTER TABLE...DROP UNUSED COLUMNS文のみです。この文では、表から未使用の列が物理的に削除され、ディスク領域が再生されます。

次のALTER TABLE文では、オプションの句CHECKPOINTが指定されています。この句を指定すると、指定した行数(この場合は250行)が処理された後に、チェックポイントが適用されます。チェックポイントによって、列削除操作中に累積されるUNDOログの量が減少し、UNDO領域が使い果たされるおそれがなくなります。

ALTER TABLE hr.admin_emp DROP UNUSED COLUMNS CHECKPOINT 250;

圧縮表の列の削除

表のすべての操作で圧縮が使用可能な場合は、表の列を削除できます。ダイレクト・パス・インサートのみで圧縮が使用可能な場合は、表の列を削除できません。

関連項目:

「表圧縮の使用」 

表を読取り専用モードにする方法

表を読取り専用モードにするには、ALTER TABLE...READ ONLY文を使用し、表を読取り/書込みモードに戻すには、ALTER TABLE...READ WRITE文を使用します。読取り専用モードが有効な表の例に、構成表があります。アプリケーションに含まれている構成表が、インストール後変更されず、ユーザーによる変更を禁止する必要がある場合は、アプリケーションのインストール・スクリプトによって、これらの表を読取り専用モードにできます。

表を読取り専用モードにするには、その表に対するALTER TABLE権限、またはALTER ANY TABLE権限が必要です。また、COMPATIBILE初期化パラメータが11.1.0以上に設定されている必要があります。

次の例は、SALES表を読取り専用モードにします。

ALTER TABLE SALES READ ONLY;

次の例は、表を読取り/書込みモードに戻します。

ALTER TABLE SALES READ WRITE;

表が読取り専用モードの場合、表データの変更操作は許可されません。読取り専用表で許可されない操作は、次のとおりです。

読取り専用表で許可される操作は、次のとおりです。

表のオンライン再定義

データベース・システムでは、次のような理由で表の構造を論理的または物理的に変更する必要が生じます。

Oracle Databaseには、表の可用性に大きな影響を与えずに表の構造を変更できるメカニズムが用意されています。このメカニズムは、表のオンライン再定義と呼ばれます。表のオンライン再定義では、表を再定義する従来の方法に比べて、可用性が大幅に向上します。

オンラインで表を再定義している間も、その再定義プロセスの大部分で、問合せおよびDMLを使用してその表にアクセスできます。表が排他モードでロックされるのは、そのサイズや再定義の複雑さに関係なくわずかな間のみで、ユーザーに対しては完全に透過的です。

表のオンライン再定義には、再定義の対象となる表が使用している領域とほぼ同等の空き領域が必要です。新しい列を追加する場合は、より多くの領域が必要になります。

表のオンライン再定義を実行するには、Enterprise Managerのオブジェクトの再編成ウィザードまたはDBMS_REDEFINITIONパッケージを使用します。


注意:

オブジェクトの再編成ウィザードを起動する手順

  1. Enterprise Managerの「表」ページで「選択」列をクリックし、再定義する表を選択します。

  2. 「アクション」リストで、「再編成」を選択します。

  3. 「実行」をクリックします。

 

ここでは、DBMS_REDEFINITIONパッケージを使用したオンライン再定義について説明します。この章の内容は、次のとおりです。

表のオンライン再定義の機能

表のオンライン再定義では、次のことが可能です。

DBMS_REDEFINITIONを使用したオンライン再定義の実行

表のオンライン再定義を実行するには、DBMS_REDEFINITIONパッケージを使用します。 パッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

オンラインで表を再定義する手順は、次のとおりです。
  1. 再定義方法(キー別またはROWID別)を選択します。

    キー別: 再定義に使用する主キーまたは疑似主キーを選択します。疑似主キーは、NOT NULL制約が指定されているすべての構成要素の列を備えた一意のキーです。この方法の場合、表の再定義前のバージョンと再定義後のバージョンの主キー列は同じになります。これはデフォルトの再定義方法であり、この方法を使用することをお薦めします。

    ROWID別: この方法は、キーを使用できない場合に使用します。この方法では、表の再定義後のバージョンにM_ROW$$という非表示列が追加されます。再定義の完了後は、この列を未使用としてマークするか、削除することをお薦めします。COMPATIBLEが10.2.0以上に設定されている場合は、再定義の最終フェーズでこの列が自動的に未使用に設定されます。 次に、ALTER TABLE ... DROP UNUSED COLUMNS文を使用してその列を削除できます。

    この方法は、索引構成表に対しては使用できません。

  2. CAN_REDEF_TABLEプロシージャを起動して、表をオンラインで再定義できることを確認します。表がオンライン再定義の候補でない場合、このプロシージャは表をオンライン再定義できない理由を示すエラーを出力します。

  3. 必要な論理属性と物理属性のすべてを備えた空の仮表を(再定義する表と同じスキーマ内に)作成します。削除される列の場合は、仮表の定義に含めないでください。列を追加する場合は、その列の定義を仮表に追加します。列を変更する場合は、必要なプロパティを備えた仮表にその列を作成します。

    再定義する表の索引、制約、権限付与およびトリガーすべてを備えた仮表を作成する必要はありません。これらは、依存オブジェクトをコピーするときに手順6で定義します。

  4. (オプション)次の手順のパフォーマンスを改善するために、大きい表の再定義をパラレルで実行する場合は、次の文を発行します。

    alter session force parallel dml parallel degree-of-parallelism;
    alter session force parallel query parallel degree-of-parallelism;
    
    
  5. 次の情報を指定してSTART_REDEF_TABLEをコールし、再定義プロセスを開始します。

    • 再定義する表のスキーマと表名

    • 仮表名

    • 再定義される表の列を仮表の列にマップする列マッピング文字列

      詳細は、「列マッピング文字列の作成」を参照してください。

    • 再定義方法

      再定義方法を指定するために、パッケージ定数が用意されています。DBMS_REDEFINITION.CONS_USE_PKは、主キーまたは擬似主キーを使用して再定義が実行されるように指定するために使用します。DBMS_REDEFINITION.CONS_USE_ROWIDは、ROWIDを使用して再定義が実行されるように指定するために使用します。この引数を指定しない場合は、デフォルトの再定義方法(CONS_USE_PK)が使用されます。

    • 行の順序に使用する列(オプション)

    • パーティション名(パーティション表の単一のパーティションのみを再定義する場合)

    このプロセスにはデータのコピー操作が含まれるため、多少の時間を要する可能性があります。再定義する表は、プロセスの開始から終了まで問合せおよびDMLで使用できます。


    注意:

    なんらかの理由でSTART_REDEF_TABLEに失敗した場合は、ABORT_REDEF_TABLEをコールする必要があります。コールしないと、表を再定義する後続の試行でエラーが発生します。 


  6. 次の2つの方法のいずれかを使用して、再定義する表から仮表に依存オブジェクト(トリガー、索引、マテリアライズド・ビュー・ログ、権限付与、制約など)と統計をコピーします。第1の方法は、ほとんど自動化されているため、この方法を使用することをお薦めします。ただし、場合によっては第2の方法の使用を選択することも考えられます。第1の方法では、表の統計を仮表にコピーすることもできます。

  7. FINISH_REDEF_TABLEプロシージャを実行して、表の再定義を完了します。このプロシージャの実行中、元の表はそのデータ量とは無関係に、わずかな時間ですが排他モードでロックされます。ただし、FINISH_REDEF_TABLE部分は、保留中のDMLすべてがコミットされるのを待機してから、再定義を完了します。

  8. 再定義にROWIDを使用したときに、COMPATIBLE初期化パラメータが10.1.0以下に設定されている場合は、再定義後の表に追加された非表示列(M_ROW$$)を削除するかUNUSEDに設定してください。

    ALTER TABLE table_name SET UNUSED (M_ROW$$);
    
    

    COMPATIBLEが10.2.0以上の場合は、再定義の完了時に非表示列が自動的にUNUSEDに設定されます。 次に、ALTER TABLE ... DROP UNUSED COLUMNS文を使用して列を削除できます。

  9. 仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。

    仮表に対するアクティブな問合せの実行中に仮表を削除すると、ORA-08103エラー(「現在、指定したオブジェクトは存在しません。」)が発生する場合があります。

    関連項目:

    「表のオンライン再定義の例」 

列マッピング文字列の作成

引数としてSTART_REDEF_TABLEに渡す列マッピング文字列には、カンマで区切られた列マッピングのペアのリストが含まれています。各ペアの構文は、次のとおりです。

[expression]  column_name

column_nameは、仮表の列を意味します。オプションのexpressionには、SQL(SELECT)文の式のルールに従って、再定義する表の列、定数、演算子、関数またはメソッド・コールなどを指定できます。ただし、使用できるのは、値がすぐに決定される単純な副次式、つまり、ある評価と次の評価で結果が変化しない副次式と、順序およびSYSDATEのみです。副問合せは使用できません。最も簡単な場合、式は再定義する表の列名のみで構成されます。

式を指定すると、その値は再定義の過程で仮表内の指定の列に配置されます。式を省略した場合は、再定義する表と仮表の両方にcolumn_nameという列が存在し、再定義する表にあるその列の値が仮表の同じ列に配置されていると想定されます。

たとえば、再定義する表のoverride列をoverride_commissionという名前に変更し、すべてのオーバーライド・コミッションを2%増加する場合、正しい列マッピングのペアは次のとおりです。

override*1.02  override_commission

列マッピング文字列に'*'またはNULLを指定すると、すべての列(名前は変更されない)が仮表に配置されることになります。それ以外の場合は、文字列で明示的に指定した列のみが仮表に配置されます。列マッピングのペアの順序は重要ではありません。

列マッピング文字列の例は、「表のオンライン再定義の例」を参照してください。

データの変換

列をマッピングする際は、いくつかの制限はありますが、データ型を変換できます。

'*'またはNULLを列マッピング文字列として指定した場合は、SQLで許可される暗黙的な変換のみがサポートされます。たとえば、CHARからVARCHAR2に、INTEGERからNUMBERに変換できます。

あるオブジェクト型から別のオブジェクト型への変換や、あるコレクション型から別のコレクション型への変換など、その他のデータ型変換を実行する場合は、変換を実行する式とともに列マッピングのペアを指定する必要があります。式には、CAST関数、TO_NUMBERなどの組込み関数、作成した変換関数などを指定できます。

依存オブジェクトの自動作成

仮表に対する依存オブジェクトを自動的に作成するには、COPY_TABLE_DEPENDENTSプロシージャを使用します。

num_errors出力引数をチェックすることで、依存オブジェクトのコピー中にエラーが発生したかどうかを検出できます。ignore_errors引数をTRUEに設定すると、COPY_TABLE_DEPENDENTSプロシージャは、オブジェクト作成時にエラーを検出しても、依存オブジェクトのコピーを続行します。DBA_REDEFINITION_ERRORSビューを問い合せることで、これらのエラーを確認できます。

エラーには、次のような理由があります。

ignore_errorsFALSEに設定すると、COPY_TABLE_DEPENDENTSプロシージャは、エラーを検出すると、オブジェクトのコピーをただちに停止します。

エラーを修正してからCOPY_TABLE_DEPENDENTSプロシージャを再実行することで、依存オブジェクトのコピーを再試行できます。「依存オブジェクトの手動による作成」に説明されているように、オブジェクトを手動で作成し、それらを登録することもできます。COPY_TABLE_DEPENDENTSプロシージャは、必要に応じて何回でも使用できます。オブジェクトがすでに正常にコピーされている場合は、再度コピーされません。

依存オブジェクトの手動による作成

SQL*PlusまたはEnterprise Managerで、仮表に対する依存オブジェクトを手動で作成する場合は、REGISTER_DEPENDENT_OBJECTプロシージャを使用して依存オブジェクトを登録する必要があります。依存オブジェクトを登録すると、再定義の完了プロセスで、依存オブジェクト名を再定義前の名前にリストアできます。

COPY_TABLE_DEPENDENTSプロシージャによる依存オブジェクトのコピーがエラーとなり、手動による介入が必要な場合は、REGISTER_DEPENDENT_OBJECTプロシージャを使用します。

DBA_REDEFINITION_OBJECTSビューを問い合せることによって、登録されている依存オブジェクトを判断できます。このビューには、REGISTER_DEPENDENT_OBJECTプロシージャで明示的に登録、またはCOPY_TABLE_DEPENDENTSプロシージャで暗黙的に登録された依存オブジェクトが表示されます。このビューには、現在の情報のみが表示されます。

UNREGISTER_DEPENDENT_OBJECTプロシージャを使用すると、再定義している表および仮表に対する依存オブジェクトの登録を解除できます。


注意:

手動で作成する依存オブジェクトは、対応する元の依存オブジェクトと同一である必要はありません。たとえば、マテリアライズド・ビュー・ログを仮表に手動で作成する場合は、別の列を記録できます。また、仮表の依存オブジェクトが増減してもかまいません。 


再定義プロセスの結果

再定義プロセスの最終的な結果は、次のようになります。

中間での同期化の実行

START_REDEF_TABLEをコールして再定義プロセスを開始してからFINISH_REDEF_TABLEコールが完了するまでの間に、元の表に対して多数のDML文が実行される可能性があります。これが問題になることがわかっている場合は、定期的に仮表を元の表と同期化することをお薦めします。同期化には、SYNC_INTERIM_TABLEプロシージャをコールします。このプロシージャをコールすると、FINISH_REDEF_TABLEで再定義プロセスを完了するための時間が短縮されます。SYNC_INTERIM_TABLEをコールできる回数に制限はありません。

FINISH_REDEF_TABLEの実行中に元の表がロックされるわずかな時間は、SYNC_INTERIM_TABLEのコールの有無とは関係ありません。

エラー後の表のオンライン再定義の強制終了およびクリーン・アップ

再定義プロセス中にエラーが発生した場合、または再定義プロセスの終了を選択した場合は、ABORT_REDEF_TABLEをコールしてください。このプロシージャは、再定義プロセスに対応付けられた一時ログおよび一時表を削除します。このプロシージャをコールした後は、仮表とその依存オブジェクトを削除できます。

オンライン再定義プロセスの再起動が必要な場合は、最初にABORT_REDEF_TABLEをコールしないと、表を再定義する後続の試みでエラーが発生します。

表のオンライン再定義に関する制限事項

表のオンライン再定義には、次の制限が適用されます。

単一パーティションのオンライン再定義

Oracle Database 10g リリース2からは、表の単一パーティションをオンラインで再定義できます。これは、異なる表領域にパーティションを移動する際に、移動中でもパーティションに対してDMLを使用できるようにする場合などに便利です。

この機能の別の用途は、表全体を再定義する際に、リソース要件を低減するために1度に1つのパーティションずつオンラインで再定義することです。たとえば、異なる表領域に非常に大きな表を移動する場合は、表を1度に1つのパーティションずつ移動することで、移動を完了するために必要な空き領域とUNDO領域を最小化できます。ただし、単一パーティションを再定義するときに、グローバル索引がある場合は、再定義が完了したときにUNUSABLEのマークが設定されることに注意してください。

単一パーティションの再定義は、次の点で表の再定義とは異なります。

単一パーティションのオンライン再定義のルール

単一パーティションを再定義するための基本的な仕組みは、データベースのパーティション交換機能(ALTER TABLE...EXCHANGE PARTITION)です。したがって、単一パーティションのオンライン定義のルールと制限事項は、この仕組みに基づいて決まります。一般的には、次の制限事項があります。

仮表を定義する際のルールは、次のとおりです。

次の補足ルールは、再定義する表がパーティション化された索引構成表である場合に適用されます。

表のオンライン再定義の例

次の例で使用されているすべてのDBMS_REDEFINITIONサブプログラムに関する詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

  説明 

例1 

新しい列を追加しパーティションを追加することで、表を再定義します。 

例2 

オブジェクト・データ型を使用して表を再定義します。 

例3 

手動で登録した依存オブジェクトを使用して表を再定義します。 

例4 

単一の表パーティションを異なる表領域に移動して表を再定義します。 

例1

この例は、以前に作成した表hr.admin_empのオンライン再定義を示しています。この表の列は、この時点ではempnoenamejobdeptnoのみです。表を次のように再定義します。

この再定義の手順は、次のとおりです。

  1. 表がオンライン再定義の候補であることを確認します。この場合は、主キーまたは疑似主キーを使用して再定義が実行されるように指定します。

    BEGIN
    DBMS_REDEFINITION.CAN_REDEF_TABLE('hr','admin_emp',
          DBMS_REDEFINITION.CONS_USE_PK);
    END;
    /
    
    
  2. 仮表hr.int_admin_empを作成します。

    CREATE TABLE hr.int_admin_emp
            (empno      NUMBER(5) PRIMARY KEY,
             ename      VARCHAR2(15) NOT NULL,
             job        VARCHAR2(10),
             mgr        NUMBER(5),
             hiredate   DATE DEFAULT (sysdate),
             sal        NUMBER(7,2),
             deptno     NUMBER(3) NOT NULL,
             bonus      NUMBER (7,2) DEFAULT(1000))
         PARTITION BY RANGE(empno)
           (PARTITION emp1000 VALUES LESS THAN (1000) TABLESPACE admin_tbs,
            PARTITION emp2000 VALUES LESS THAN (2000) TABLESPACE admin_tbs2);
    
    
  3. 再定義プロセスを開始します。

    BEGIN
    DBMS_REDEFINITION.START_REDEF_TABLE('hr', 'admin_emp','int_admin_emp',
           'empno empno, ename ename, job job, deptno+10 deptno, 0 bonus',
            dbms_redefinition.cons_use_pk);
    END;
    /
    
    
  4. 依存オブジェクトをコピーします(hr.int_admin_empに対するトリガー、索引、マテリアライズド・ビュー・ログ、権限付与および制約がある場合、それらは自動的に作成されます)。

    DECLARE
    num_errors PLS_INTEGER;
    BEGIN
    DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS('hr', 'admin_emp','int_admin_emp',
       DBMS_REDEFINITION.CONS_ORIG_PARAMS, TRUE, TRUE, TRUE, TRUE, num_errors);
    END;
    
    

    このコールでは、ignore_errors引数がTRUEに設定されていることに注意してください。これは、仮表が主キー制約付きで作成されており、COPY_TABLE_DEPENDENTSによって、主キー制約と索引が元の表からコピーされる際にエラーが発生するためです。これらのエラーは無視できますが、後続の手順に記載されている問合せを実行して、他のエラーの存在を確認する必要があります。

  5. DBA_REDEFINITION_ERRORSビューを問い合せて、エラーをチェックします。

    SQL> select object_name, base_table_name, ddl_txt from
             DBA_REDEFINITION_ERRORS;
     
    OBJECT_NAME   BASE_TABLE_NAME  DDL_TXT
    ------------- ---------------- ------------------------------
    SYS_C005836   ADMIN_EMP        CREATE UNIQUE INDEX "HR"."TMP$
                                   $_SYS_C0058360" ON "HR"."INT_A
                                   DMIN_EMP" ("EMPNO")
     
    SYS_C005836   ADMIN_EMP        ALTER TABLE "HR"."INT_ADMIN_EM
                                   P" ADD CONSTRAINT "TMP$$_SYS_C
                                   0058360" PRIMARY KEY
    
    

    これらのエラーは、仮表にある既存の主キー制約に起因しているため、無視できます。このアプローチでは、再定義後の表の主キー制約名と索引名が変更されていることに注意してください。別のアプローチを使用すると、エラーの発生と名前の変更を回避できますが、仮表は主キー制約なしで定義されることになります。この例の場合、主キー制約と索引は元の表からコピーされます。


    注意:

    最良のアプローチは、主キー制約付きで仮表を定義し、REGISTER_DEPENDENT_OBJECTを使用して主キー制約と索引を登録してから、COPY_TABLE_DEPENDENTSで残りの依存オブジェクトをコピーすることです。このアプローチでは、エラーが回避され、再定義した表には常に主キーがあり、依存オブジェクト名も変わりません。 


  6. 必要に応じて、仮表hr.int_admin_empを同期化します。

    BEGIN 
    DBMS_REDEFINITION.SYNC_INTERIM_TABLE('hr', 'admin_emp', 'int_admin_emp');
    END;
    /
    
    
  7. 再定義を完了します。

    BEGIN
    DBMS_REDEFINITION.FINISH_REDEF_TABLE('hr', 'admin_emp', 'int_admin_emp');
    END;
    /
    
    

    この手順が終了するまでに、わずかな間のみ、表hr.admin_empが排他モードでロックされます。このコールの後、表hr.admin_emphr.int_admin_emp表のすべての属性を持つように再定義されます。

  8. 仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。

例2

この例では、列をオブジェクト属性に変更するために表を再定義します。再定義した表にオブジェクト型の新しい列を確保します。

元の表(CUSTOMER)の定義は、次のとおりです。

Name         Type          
------------ ------------- 
CID          NUMBER            <- Primary key
NAME         VARCHAR2(30)  
STREET       VARCHAR2(100) 
CITY         VARCHAR2(30)  
STATE        VARCHAR2(2)   
ZIP          NUMBER(5)     

新しいオブジェクトの型定義は、次のとおりです。

CREATE TYPE ADDR_T AS OBJECT (  
   street VARCHAR2(100),        
   city VARCHAR2(30),           
   state VARCHAR2(2),           
   zip NUMBER(5, 0) );          

再定義の手順は、次のとおりです。

  1. 表がオンライン再定義の候補であることを確認します。主キーまたは疑似主キーを使用して再定義が実行されるように指定します。

    BEGIN
    DBMS_REDEFINITION.CAN_REDEF_TABLE('STEVE','CUSTOMER',
            DBMS_REDEFINITION.CONS_USE_PK);
    END;
    /
    
    
  2. 仮表int_customerを作成します。

    CREATE TABLE INT_CUSTOMER(
      CID NUMBER,
      NAME  VARCHAR2(30),          
      ADDR  ADDR_T);             
      
    

    仮表には主キーが定義されていないことに注意してください。手順5で依存オブジェクトがコピーされると、主キー制約と索引がコピーされます。

  3. CUSTOMERは大きい表であるため、後続の手順のためにパラレル操作を指定します。

    alter session force parallel dml parallel 4;
    alter session force parallel query parallel 4;
    
    
  4. 主キーを使用して再定義プロセスを開始します。

    BEGIN
    DBMS_REDEFINITION.START_REDEF_TABLE(
       uname       => 'STEVE',
       orig_table  => 'CUSTOMER',
       int_table   => 'INT_CUSTOMER',
       col_mapping => 'cid cid,  name name,
          addr_t(street, city, state, zip) addr');
    END;
    /
    
    

    addr_t(street, city, state, zip)は、オブジェクト・コンストラクタへのコールです。

  5. 依存オブジェクトをコピーします。

    DECLARE
    num_errors PLS_INTEGER;
    BEGIN
    DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(
       'STEVE','CUSTOMER','INT_CUSTOMER',DBMS_REDEFINITION.CONS_ORIG_PARAMS,
        TRUE, TRUE, TRUE, FALSE, num_errors, TRUE);
    END;
    /
    
    

    このコールの最後の引数は、表の統計が仮表にコピーされることを意味します。

  6. 必要に応じて、仮表を同期化します。

    BEGIN 
    DBMS_REDEFINITION.SYNC_INTERIM_TABLE('STEVE', 'CUSTOMER', 'INT_CUSTOMER');
    END;
    /
    
    
  7. 再定義を完了します。

    BEGIN
    DBMS_REDEFINITION.FINISH_REDEF_TABLE('STEVE', 'CUSTOMER', 'INT_CUSTOMER');
    END;
    /
    
    
  8. 仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。

例3

この例では、依存オブジェクトを手動で作成および登録する必要がある場合を考えてみます。

T1にはC1という列があり、再定義した後、この列をC2にするとします。C1には索引Index1があると想定します。この場合、COPY_TABLE_DEPENDENTSは、Index1に対応して、仮表に対する索引の作成を試行し、仮表には存在しない列C1に対して索引の作成を試行します。これは結果的にエラーとなります。したがって、列C2に対しては、索引を手動で作成して登録する必要があります。手順は、次のとおりです。

  1. 仮表INT_T1を作成し、列C2に対して索引Int_Index1を作成します。

  2. CAN_REDEF_TABLEを使用してT1がオンライン定義の候補であることを確認し、次にSTART_REDEF_TABLEを使用して再定義プロセスを開始します。

  3. 元(Index1)と仮(Int_Index1)の依存オブジェクトを登録します。

    BEGIN
    DBMS_REDEFINITION.REGISTER_DEPENDENT_OBJECT(
       uname         => 'STEVE',
       orig_table    => 'T1',
       int_table     => 'INT_T1',
       dep_type      => DBMS_REDEFINITION.CONS_INDEX,
       dep_owner     => 'STEVE',
       dep_orig_name => 'Index1',
       dep_int_name  => 'Int_Index1');
    END;
    /
    
    
  4. COPY_TABLE_DEPENDENTSを使用して、残りの依存オブジェクトをコピーします。

  5. 必要に応じて、仮表を同期化します。

  6. 再定義を完了し、仮表を削除します。

例4

この例では、単一のパーティションを再定義します。販売表というレンジ・パーティションの最も古いパーティションを、表領域TBS_LOW_FREQに移動します。再定義するパーティションが格納されている表の定義は、次のとおりです。

CREATE TABLE salestable
(s_productid NUMBER,
s_saledate DATE,
s_custid NUMBER,
s_totalprice NUMBER)
TABLESPACE users
PARTITION BY RANGE(s_saledate)
(PARTITION sal03q1 VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MON-YYYY')),
PARTITION sal03q2 VALUES LESS THAN (TO_DATE('01-JUL-2003', 'DD-MON-YYYY')),
PARTITION sal03q3 VALUES LESS THAN (TO_DATE('01-OCT-2003', 'DD-MON-YYYY')),
PARTITION sal03q4 VALUES LESS THAN (TO_DATE('01-JAN-2004', 'DD-MON-YYYY')));

表には、次のように定義されたローカル・パーティション索引があります。

CREATE INDEX sales_index ON salestable 
   (s_saledate, s_productid, s_custid) LOCAL;

手順は、次のとおりです。次のプロシージャ・コールでは、パーティション名(part_name)という特別な引数に注目してください。

  1. salestableが再定義の候補であることを確認します。

    BEGIN
    DBMS_REDEFINITION.CAN_REDEF_TABLE(
       uname        => 'STEVE',
       tname        => 'SALESTABLE',
       options_flag => DBMS_REDEFINITION.CONS_USE_ROWID,
       part_name    => 'sal03q1');
    END;
    /
    
    
  2. TBS_LOW_FREQ表領域に仮表を作成します。これはレンジ・パーティションの再定義であるため、仮表は非パーティション表です。

    CREATE TABLE int_salestable
    (s_productid NUMBER,
    s_saledate DATE,
    s_custid NUMBER,
    s_totalprice NUMBER)
    TABLESPACE tbs_low_freq;
    
    
  3. ROWIDを使用して再定義プロセスを開始します。

    BEGIN
    DBMS_REDEFINITION.START_REDEF_TABLE(
       uname        => 'STEVE',
       orig_table   => 'salestable',
       int_table    => 'int_salestable',
       col_mapping  => NULL,
       options_flag => DBMS_REDEFINITION.CONS_USE_ROWID,
       part_name    => 'sal03q1');
    END;
    /
    
    
  4. 仮表に対してローカル索引を手動で作成します。

    CREATE INDEX int_sales_index ON int_salestable 
    (s_saledate, s_productid, s_custid)
    TABLESPACE tbs_low_freq; 
    
    
  5. 必要に応じて、仮表を同期化します。

    BEGIN 
    DBMS_REDEFINITION.SYNC_INTERIM_TABLE(
       uname      => 'STEVE', 
       orig_table => 'salestable', 
       int_table  => 'int_salestable',
       part_name  => 'sal03q1');
    END;
    /
    
    
  6. 再定義を完了します。

    BEGIN 
    DBMS_REDEFINITION.FINISH_REDEF_TABLE(
       uname      => 'STEVE', 
       orig_table => 'salestable', 
       int_table  => 'int_salestable',
       part_name  => 'sal03q1');
    END;
    /
    
    
  7. 仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。

次の問合せは、最も古いパーティションが新しい表領域に移動したことを示します。

select partition_name, tablespace_name from user_tab_partitions
 where table_name = 'SALESTABLE';
 
PARTITION_NAME                 TABLESPACE_NAME
------------------------------ ------------------------------
SAL03Q1                        TBS_LOW_FREQ
SAL03Q2                        USERS
SAL03Q3                        USERS
SAL03Q4                        USERS
 
4 rows selected.

DBMS_REDEFINITIONパッケージに必要な権限

DBMS_REDEFINITIONパッケージの実行権限は、EXECUTE_CATALOG_ROLEに付与されます。実行ユーザーは、このパッケージの実行権限以外に、次の権限が付与されていることが必要です。

COPY_TABLE_DEPENDENTSを実行するには、次の追加権限が必要です。

エラーが発生した表の変更の調査と取消し

表に対してエラーが発生する変更を調査して取り消せるようにするために、Oracle Databaseには、データベース・オブジェクトの過去の状態を表示したり、Point-in-Timeメディア・リカバリを使用せずにデータベース・オブジェクトを以前の状態に戻すために使用できる一連の機能が用意されています。 これらの機能はOracle Flashback機能と呼ばれており、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』で説明されています。

エラーが発生する変更を調査するために、複数のOracle Flashback問合せを使用して、特定の時点における行データを表示できます。さらに効率的な方法として、Oracle Flashback Version Queryを使用して、ある期間にわたる行への変更すべてを表示できます。この機能では、SELECT文にVERSIONS句を追加できるため、行の値への変更を表示するシステム変更番号(SCN)またはタイムスタンプの範囲を指定できます。この問合せでは、変更の原因となったトランザクションなど、関連するメタデータを返すこともできます。

エラーが発生するトランザクションを特定した後、Oracle Flashback Transaction Queryを使用して、そのトランザクションで実行された他の変更を特定できます。次に、Oracle Flashback Transactionを使用して、エラーが発生するトランザクションを取り消すことができます。(Oracle Flashback Transactionでは、依存するすべてのトランザクション、つまりエラーが発生するトランザクションと同じ行が関係する後続のトランザクションも取り消す必要があることに注意してください。) 「Oracle Flashback Tableを使用した表のリカバリ」に説明されているOracle Flashback Tableも使用できます。


注意:

Oracle Flashback機能を使用するには、自動UNDO管理を使用している必要があります。 「自動UNDO管理の概念」を参照してください。 


関連項目:

Oracle Flashback機能の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 

Oracle Flashback Tableを使用した表のリカバリ

Oracle Flashback Tableでは、以前の時点の状態に表をリストアできます。この文は、ユーザーやアプリケーションによって偶発的に変更または削除された表を迅速にリカバリするためのオンライン・ソリューションです。多くの場合、Oracle Flashback Tableによって、複雑なPoint-in-Timeリカバリ操作を行う必要がなくなります。

Oracle Flashback Table:

表の削除

不要になった表を削除するには、DROP TABLE文を使用します。削除する表は、自分のスキーマに含まれているか、またはDROP ANY TABLEシステム権限を持っている必要があります。


注意:

表を削除する前に、表を削除した結果についてよく理解しておいてください。

  • 表を削除すると、その表定義はデータ・ディクショナリから削除されます。その結果、表のすべての行はアクセスできなくなります。

  • 表に対応付けられている索引とトリガーは、すべて削除されます。

  • 削除した表に依存しているビューとPL/SQLプログラム・ユニットはすべてそのまま残りますが、無効になります(使用できません)。 データベースによる依存性管理の詳細は、「オブジェクト依存性の管理」を参照してください。

  • 削除する表のシノニムはすべてそのまま残りますが、使用するとエラーが返されます。

  • 削除した表に割り当てられていたエクステントは表領域の空き領域にすべて戻され、新しいエクステントまたは新しいオブジェクトを必要とするその他のオブジェクトによって再利用されます。クラスタ化表に対応する行はすべて、そのクラスタのブロックから削除されます。クラスタ化表については、第20章「クラスタの管理」を参照してください。

 

次の文は、hr.int_admin_emp表を削除します。

DROP TABLE hr.int_admin_emp;

削除する表に、他の表の外部キーが参照している主キーまたは一意キーが含まれていて、その子表のFOREIGN KEY制約を削除する場合は、次のようにDROP TABLE文にCASCADE句を指定します。

DROP TABLE hr.admin_emp CASCADE CONSTRAINTS;

表を削除した場合、通常、その表に関連付けられている領域はすぐには解放されません。正確には、表の名前が変更されてリサイクル・ビンに配置されます。これによって、誤って表を削除したことが後で判明した場合は、FLASHBACK TABLE文でリカバリできます。DROP TABLE文の発行時点で、表に関連付けられている領域をただちに解放する場合は、次のようにPURGE句を指定します。

DROP TABLE hr.admin_emp PURGE;

表は、削除するかわりに切り捨てることができます。TRUNCATE文を使用すると、表からすべての行を効率よく高速に削除できます。この操作は、切り捨てる表に対応付けられた構造(列定義、制約、トリガーなど)や認可には影響しません。 TRUNCATE文については、「表とクラスタの切捨て」を参照してください。

フラッシュバック・ドロップの使用とリサイクル・ビンの管理

表を削除した場合、その表に関連付けられている領域はすぐには削除されません。表の名前が変更され、表および関連するオブジェクトがリサイクル・ビンに配置されます。これによって、誤って表が削除された場合に、後でその表をリカバリできます。この機能はフラッシュバック・ドロップと呼ばれます。表のリカバリには、FLASHBACK TABLE文が使用されます。この目的のためにFLASHBACK TABLE文の使用方法を説明する前に、リサイクル・ビンの機能とその内容の管理方法を理解することが重要です。

この項の内容は、次のとおりです。

リサイクル・ビンの概要

リサイクル・ビンとは、実際には、削除されたオブジェクトに関する情報を含んでいるデータ・ディクショナリ表です。削除された表および関連するオブジェクト(索引、制約、ネストした表など)は、削除されずにそのまま領域を使用します。この領域は、リサイクル・ビンから明確にパージされるまで、または、あまり可能性はありませんが、表領域の制約のためにデータベースによるパージが必要となるまでは、ユーザー領域の割当てにとって不利です。

ユーザーにSYSDBA権限がない場合、リサイクル・ビンの中でユーザーが所有するオブジェクトは、アクセス権があるオブジェクトのみであるため、各ユーザーには各自のリサイクル・ビンがあるとみなすことができます。リサイクル・ビンにある各自のオブジェクトは、次の文を使用して表示できます。

SELECT * FROM RECYCLEBIN;

表領域をその内容も含めて削除すると、表領域内のオブジェクトはリサイクル・ビンに配置されず、その表領域に配置されていたオブジェクトに対するリサイクル・ビン内のエントリはすべてパージされます。内容を含まない表領域を削除した場合、つまり空の表領域を削除した場合も、表領域内のオブジェクトに対するリサイクル・ビン内のエントリがすべてパージされます。同様に、それぞれの削除操作は次のように処理されます。

リサイクル・ビン内のオブジェクト名の変更

削除された表をリサイクル・ビンに移動すると、その表とその表に関連するオブジェクトには、システムで生成された名前が割り当てられます。名前の変更は、複数の表が同じ名前の場合に発生する可能性がある、名前の競合を回避するために必要です。名前の変更は、次の状況で発生します。

名前変更の表記規則は、次のとおりです。

BIN$unique_id$version

各項目の意味は次のとおりです。

リサイクル・ビンの有効化と無効化

リサイクル・ビンは、recyclebin初期化パラメータを使用して有効化および無効化できます。リサイクル・ビンが有効化されていると、削除した表とその依存オブジェクトはリサイクル・ビンに配置されます。 リサイクル・ビンが無効化されていると、削除した表とその依存オブジェクトはリサイクル・ビンには配置されず、そのまま削除されるため、それらをリカバリするには他の手段を使用する必要があります(バックアップからのリカバリなど)。

リサイクル・ビンは、デフォルトで有効化されています。

リサイクル・ビンの無効化:

リサイクル・ビンの有効化:

ALTER SYSTEMまたはALTER SESSION文でリサイクル・ビンを有効化および無効化すると、ただちにその設定が有効になります。リサイクル・ビンの無効化はパージではありません。パージの場合は、すでにリサイクル・ビンにあるオブジェクトに影響を与えます。

他の初期化パラメータと同様に、テキスト形式の初期化ファイルinitSID.orarecyclebinパラメータには初期値を設定できます。

recyclebin=on

関連項目:

初期化パラメータの詳細は、「初期化パラメータと初期化パラメータ・ファイルの概要」を参照してください。 

リサイクル・ビン内のオブジェクトの表示と問合せ

Oracle Databaseでは、リサイクル・ビンのオブジェクトに関する情報を取得する2種類の方法を提供しています。

ビュー  説明 

USER_RECYCLEBIN  

ユーザーは、このビューを使用して、リサイクル・ビンにある削除した各自のオブジェクトを表示できます。このビューには、使いやすいシノニムRECYCLEBINがあります。 

DBA_RECYCLEBIN  

管理者はこのビューを使用して、リサイクル・ビンにある削除されたすべてのオブジェクトを表示できます。 

これらのビューの使用目的の1つは、次の例のように、削除したオブジェクトに対してデータベースが割り当てた名前を識別することにあります。

SELECT object_name, original_name FROM dba_recyclebin
   WHERE owner = 'HR';

OBJECT_NAME                    ORIGINAL_NAME
------------------------------ --------------------------------
BIN$yrMKlZaLMhfgNAgAIMenRA==$0 EMPLOYEES

リサイクル・ビンの内容は、SQL*PlusのSHOW RECYCLEBINコマンドを使用して表示することもできます。

SQL> show recyclebin

ORIGINAL NAME    RECYCLEBIN NAME                OBJECT TYPE  DROP TIME
---------------- ------------------------------ ------------ -------------------
EMPLOYEES        BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TABLE        2003-10-27:14:00:19

リサイクル・ビンにあるオブジェクトは、他のオブジェクトと同じ要領で問い合せることができます。ただし、オブジェクトの名前は、リサイクル・ビンの中で識別されているとおりに指定する必要があります。次に例を示します。

SELECT * FROM "BIN$yrMKlZaVMhfgNAgAIMenRA==$0";

リサイクル・ビン内のオブジェクトのパージ

リサイクル・ビンから項目をリストアすることはないと判断した場合は、PURGE文を使用して、項目および関連するオブジェクトをリサイクル・ビンから削除し、記憶域を解放できます。実行するには、項目を削除する場合と同じ権限が必要です。

PURGE文を使用して表をパージする場合は、リサイクル・ビンの中で表に割り当てられている名前または元の表の名前を使用できます。 リサイクル・ビンの名前は、DBA_RECYCLEBINまたはUSER_RECYCLEBINビューから取得できます。詳細は、「リサイクル・ビン内のオブジェクトの表示と問合せ」を参照してください。次の例では、表hr.int_admin_empをパージします。BIN$jsleilx392mk2=293$0は、リサイクル・ビンに配置される際に変更された名前です。

PURGE TABLE BIN$jsleilx392mk2=293$0;

次の文を使用しても同様の結果となります。

PURGE TABLE int_admin_emp;

PURGE文を使用すると、指定の表領域からリサイクル・ビンのすべてのオブジェクトをパージ、または指定のユーザーに属する表領域オブジェクトのみをパージできます。次に例を示します。

PURGE TABLESPACE example;
PURGE TABLESPACE example USER oe;

次の文を使用することで、ユーザーは独自のオブジェクトのリサイクル・ビンをパージして、オブジェクトの領域を解放できます。

PURGE RECYCLEBIN;

SYSDBA権限がある場合は、前述の文のRECYCLEBINのかわりに、DBA_RECYCLEBINを指定することによって、リサイクル・ビン全体をパージできます。

また、PURGE文を使用して、リサイクル・ビンから索引をパージ、またはリサイクル・ビンから指定の表領域にあるすべてのオブジェクトをパージすることもできます。

関連項目:

PURGE文の詳細は、『Oracle Database SQLリファレンス』を参照してください。 

リサイクル・ビンからの表のリストア

FLASHBACK TABLE ...TO BEFORE DROP文を使用して、リサイクル・ビンからオブジェクトをリカバリできます。リサイクル・ビンでの表の名前、または元の表の名前を指定できます。オプションのRENAME TO句を使用すると、リカバリ時に表の名前を変更できます。 リサイクル・ビンの名前は、DBA_RECYCLEBINまたはUSER_RECYCLEBINビューから取得できます。詳細は、「リサイクル・ビン内のオブジェクトの表示と問合せ」を参照してください。FLASHBACK TABLE ...TO BEFORE DROP文を使用するには、表を削除する場合と同じ権限が必要です。

次の例は、int_admin_emp表をリストアし、その表に新しい名前を割り当てます。

FLASHBACK TABLE int_admin_emp TO BEFORE DROP 
   RENAME TO int2_admin_emp;

システム生成のリサイクル・ビン名は、表を複数回削除した場合に大変便利です。たとえば、リサイクル・ビン内のint2_admin_emp表に3つのバージョンがあり、2つ目のバージョンをリカバリするとします。次の例のように、2つのFLASHBACK TABLE文を発行することでリカバリできます。あるいは、リサイクル・ビンを問い合せて、適切なシステム生成の名前にフラッシュバックできます。問合せに作成時間を含めると、正しい表をリストアしていることを確認できます。

SELECT object_name, original_name, createtime FROM recyclebin;    

OBJECT_NAME                    ORIGINAL_NAME   CREATETIME
------------------------------ --------------- -------------------
BIN$yrMKlZaLMhfgNAgAIMenRA==$0 INT2_ADMIN_EMP  2006-02-05:21:05:52
BIN$yrMKlZaVMhfgNAgAIMenRA==$0 INT2_ADMIN_EMP  2006-02-05:21:25:13
BIN$yrMKlZaQMhfgNAgAIMenRA==$0 INT2_ADMIN_EMP  2006-02-05:22:05:53

FLASHBACK TABLE BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TO BEFORE DROP;
依存オブジェクトのリストア

リサイクル・ビンから表をリストアすると、索引などの依存オブジェクトは元の名前が復元されず、システム生成のリサイクル・ビンの名前のままになります。元の名前をリストアする場合は、依存オブジェクトの名前を手動で変更する必要があります。 依存オブジェクトの元の名前を手動でリストアする場合は、表をリストアする前に、各依存オブジェクトのシステム生成のリサイクル・ビン名を記録する必要があります。

次の例では、HRサンプル・スキーマから、削除した表JOB_HISTORYの索引の一部の元の名前をリストアします。この例では、HRユーザーとしてログインしていることを想定しています。

  1. JOB_HISTORYの削除後、リサイクル・ビンからリストアする前に、次の問合せを実行します。

    SELECT OBJECT_NAME, ORIGINAL_NAME, TYPE FROM RECYCLEBIN;
    
    OBJECT_NAME                    ORIGINAL_NAME             TYPE
    ------------------------------ ------------------------- --------
    BIN$DBo9UChtZSbgQFeMiAdCcQ==$0 JHIST_JOB_IX              INDEX
    BIN$DBo9UChuZSbgQFeMiAdCcQ==$0 JHIST_EMPLOYEE_IX         INDEX
    BIN$DBo9UChvZSbgQFeMiAdCcQ==$0 JHIST_DEPARTMENT_IX       INDEX
    BIN$DBo9UChwZSbgQFeMiAdCcQ==$0 JHIST_EMP_ID_ST_DATE_PK   INDEX
    BIN$DBo9UChxZSbgQFeMiAdCcQ==$0 JOB_HISTORY               TABLE
    
    
  2. 次のコマンドを実行して表をリストアします。

    FLASHBACK TABLE JOB_HISTORY TO BEFORE DROP;
    
    
  3. 次の問合せを実行して、すべてのJOB_HISTORY索引がシステム生成のリサイクル・ビン名を保持していることを確認します。

    SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = 'JOB_HISTORY';
     
    INDEX_NAME
    ------------------------------
    BIN$DBo9UChwZSbgQFeMiAdCcQ==$0
    BIN$DBo9UChtZSbgQFeMiAdCcQ==$0
    BIN$DBo9UChuZSbgQFeMiAdCcQ==$0
    BIN$DBo9UChvZSbgQFeMiAdCcQ==$0
    
    
  4. 次のようにして、最初の2つの索引の元の名前をリストアします。

    ALTER INDEX "BIN$DBo9UChtZSbgQFeMiAdCcQ==$0" RENAME TO JHIST_JOB_IX;
    ALTER INDEX "BIN$DBo9UChuZSbgQFeMiAdCcQ==$0" RENAME TO JHIST_EMPLOYEE_IX;
    
    

    システム生成の名前は、二重引用符で囲む必要があります。

索引構成表の管理

ここでは、索引構成表の管理について説明します。この項の内容は、次のとおりです。

索引構成表の概要

索引構成表は、プライマリBツリーの異形である記憶域編成を持っています。順序付けされていないコレクション(ヒープ)としてデータを格納する通常の(ヒープ構成)表とは異なり、索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納されます。索引構造の各リーフ・ブロックには、キー列と非キー列の両方が格納されます。

索引構成表の構造には、次の利点があります。

索引構成表は、すべての表機能を備えています。制約、トリガー、LOB列とオブジェクト列、パーティション化、パラレル操作、オンライン再編成、およびレプリケーションなどの機能をサポートします。さらに、次の機能も提供します。

高速な主キー・アクセスと高可用性を必要とするOLTPアプリケーションには、索引構成表が理想的です。たとえば、電子注文処理に使用される注文表の問合せおよびDMLは大部分が主キー・ベースであるため、大量のボリュームが断片化の原因となり、再編成が頻繁に必要となります。索引構成表は、2次索引を無効化せずにオンラインで再編成できるため、ウィンドウの使用を制限される時間が大幅に短縮または排除されます。

索引構成表は、アプリケーション固有の索引構造をモデル化するのに適しています。たとえば、テキスト、イメージおよびオーディオ・データを含むコンテンツ・ベースの情報検索アプリケーションには、索引構成表を使用して有効にモデル化できる逆索引が必要です。インターネット検索エンジンの基本の構成要素は、索引構成表を使用してモデル化できる逆向きの索引です。

これらは、索引構成表のアプリケーションのほんの数例です。

関連項目:

  • 索引構成表に関する詳細は、『Oracle Database概要』を参照してください。

  • 索引構成表のパーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

 

索引構成表の作成

索引構成表を作成するには、CREATE TABLE文を使用します。ただし、追加情報を指定する必要があります。

必要に応じて、次の情報を指定できます。

例: 索引構成表の作成

次の文によって、索引構成表が作成されます。

CREATE TABLE admin_docindex(
        token char(20), 
        doc_id NUMBER,
        token_frequency NUMBER,
        token_offsets VARCHAR2(2000),
        CONSTRAINT pk_admin_docindex PRIMARY KEY (token, doc_id))
    ORGANIZATION INDEX 
    TABLESPACE admin_tbs
    PCTTHRESHOLD 20
    OVERFLOW TABLESPACE admin_tbs2;

この例では、token列とdoc_id列で構成される主キーを使用して、admin_docindexという索引構成表を作成します。OVERFLOW句とPCTTHRESHOLD句では、行の長さが索引ブロック・サイズの20%を超えた場合に、そのしきい値を超えた列とその後のすべての列がオーバーフロー・セグメントに移動されるように指定しています。オーバーフロー・セグメントは、admin_tbs2表領域に格納されます。

関連項目:

索引構成表を作成する構文の詳細は、『Oracle Database SQLリファレンス』を参照してください。 

索引構成表に対する制限

索引構成表の作成には、次の制限があります。

オブジェクト型を含む索引構成表の作成

索引構成表は、オブジェクト型を格納できます。次の例は、オブジェクト型admin_typを作成し、オブジェクト型admin_typの列を含む索引構成表を作成しています。

CREATE OR REPLACE TYPE admin_typ AS OBJECT
    (col1 NUMBER, col2 VARCHAR2(6));
CREATE TABLE admin_iot (c1 NUMBER primary key, c2 admin_typ)
    ORGANIZATION INDEX;

オブジェクト型の索引構成表を作成することもできます。次に例を示します。

CREATE TABLE admin_iot2 OF admin_typ (col1 PRIMARY KEY)
    ORGANIZATION INDEX;

次に、索引構成表がネストした表を効率的に格納する例を示します。ネストした表の列ごとに、ネストした表のすべての行を保持する記憶表が内部的に作成されます。

CREATE TYPE project_t AS OBJECT(pno NUMBER, pname VARCHAR2(80));
/
CREATE TYPE project_set AS TABLE OF project_t;
/
CREATE TABLE proj_tab (eno NUMBER, projects PROJECT_SET)
    NESTED TABLE projects STORE AS emp_project_tab
                ((PRIMARY KEY(nested_table_id, pno)) 
    ORGANIZATION INDEX)
    RETURN AS LOCATOR;

ネストした表のシングル・インスタンスに属する行は、nested_table_id列で識別されます。ネストした表の列を格納するために通常の表が使用される場合、ネストした表の行は、一般的にクラスタ化が解除されます。ただし、索引構成表を使用する場合、ネストした表はnested_table_id列に基づいてクラスタ化できます。

関連項目:

  • 索引構成表を作成する構文の詳細は、『Oracle Database SQLリファレンス』を参照してください。

  • パーティション化された索引構成表の作成方法は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

  • オブジェクト型の詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。

 

しきい値の選択と監視

キー列とともに最初のいくつかの非キー列が頻繁にアクセスされる場合は、その非キー列を取り込めるしきい値を選択してください。

しきい値を選択した後、指定した値が適切な値であることを確認するために、表を監視できます。ANALYZE TABLE ...LIST CHAINED ROWS文を使用して、しきい値を超える行の数と、どの行がしきい値を超えているかを判断できます。

関連項目:

 

INCLUDING句の使用

PCTTHRESHOLDを指定する以外に、INCLUDING句を使用して、キー列とともに格納する非キー列を制御できます。データベースでは、索引リーフ・ブロック内にINCLUDING句で指定した列を含めてその列までのすべての非キー列を取り込むことができます。ただし、その列が指定したしきい値を超えない場合にかぎります。INCLUDING句で指定した列より後のすべての非キー列は、オーバーフロー・セグメントに格納されます。INCLUDING句とPCTTHRESHOLD句が競合する場合は、PCTTHRESHOLD句が優先されます。


注意:

Oracle Databaseでは、主キー・ベースのアクセス効率を高めるために、索引構成表のすべての主キー列が、表の先頭に(キー順に)移動されます。次に例を示します。

CREATE TABLE admin_iot4(a INT, b INT, c INT, d INT, 
primary key(c,b))
ORGANIZATION INDEX;

格納後の列順は、a b c dではなく、c b a dとなります。格納された列順に基づき、最後の主キー列はbになります。INCLUDING列には、最後の主キー列(この例ではb)と非キー列(つまり、格納後の列順でbの後の任意の列)のどちらでも指定できます。 


次のCREATE TABLE文は、「例: 索引構成表の作成」で示した文と類似していますが、token_offsets列の値が常にオーバーフロー領域に格納される索引構成表を作成するように変更されています。

CREATE TABLE admin_docindex2(
        token CHAR(20), 
        doc_id NUMBER,
        token_frequency NUMBER,
        token_offsets VARCHAR2(2000),
        CONSTRAINT pk_admin_docindex2 PRIMARY KEY (token, doc_id))
    ORGANIZATION INDEX 
    TABLESPACE admin_tbs
    PCTTHRESHOLD 20
    INCLUDING token_frequency
    OVERFLOW TABLESPACE admin_tbs2;

この例では、索引リーフ・ブロック内のキー列値とともに、token_offsetsまでの非キー列のみ(この場合は1つの列のみ)が格納されます。

索引構成表作成のパラレル化

CREATE TABLE...AS SELECT文を使用すると、索引構成表を作成して、既存の表からその索引構成表にデータをロードできます。PARALLEL句を指定することによって、ロードをパラレルで実行できます。

次の文は、従来型の表hr.jobsから行を選択し、索引構成表をパラレルに作成します。

CREATE TABLE admin_iot3(i PRIMARY KEY, j, k, l) 
     ORGANIZATION INDEX 
     PARALLEL
     AS SELECT * FROM hr.jobs;

この文によって、SQL*Loaderを使用するパラレル・バルク・ロードの代替手段が提供されます。

キー圧縮の使用

キー圧縮を使用して索引構成表を作成すると、キー列の接頭辞が同じ値で繰り返し格納されるのを避けることができます。

キー圧縮によって、索引キーは接頭辞および接尾辞エントリに分割されます。圧縮するために、接頭辞エントリは索引ブロック内のすべての接尾辞エントリ間で共有されます。このような共有によって、領域が大幅に節約され、各索引ブロックに格納できるキー数が増え、パフォーマンスが向上します。

キー圧縮を使用可能にするには、次の操作を行う際にCOMPRESS句を使用します。

また、接頭辞の長さをキー列の数で指定できます。これにより、キー列が接頭辞および接尾辞エントリにどのように分割されるかが決まります。

CREATE TABLE admin_iot5(i INT, j INT, k INT, l INT, PRIMARY KEY (i, j, k)) 
    ORGANIZATION INDEX COMPRESS;

この文は、次の文と等価です。

CREATE TABLE admin_iot6(i INT, j INT, k INT, l INT, PRIMARY KEY(i, j, k)) 
    ORGANIZATION INDEX COMPRESS 2;

値リスト(1,2,3)、(1,2,4)、(1,2,7)、(1,3,5)、(1,3,4)、(1,4,4)では、(1,2)、(1,3)の反復的な発生が圧縮されます。

また、次のように、圧縮に使用されるデフォルトの接頭辞の長さを変更することもできます。

CREATE TABLE admin_iot7(i INT, j INT, k INT, l INT, PRIMARY KEY (i, j, k)) 
    ORGANIZATION INDEX COMPRESS 1;

値リスト(1,2,3)、(1,2,4)、(1,2,7)、(1,3,5)、(1,3,4)、(1,4,4)では、1の反復的な発生が圧縮されます。

圧縮は、次のように使用禁止にすることができます。

ALTER TABLE admin_iot5 MOVE NOCOMPRESS;

キー圧縮のアプリケーションは、株価など、単一の項目に属して一連のタイムスタンプを表す行を使用する時系列のアプリケーションで使用されます。索引構成表には、主キーに従って行をクラスタ化する機能があるため、このようなアプリケーションには効果的です。索引構成表を主キー(株式銘柄、タイムスタンプ)で定義することによって、時系列データを効率的に格納および操作できます。キー圧縮を採用した索引構成表を使用することによって、項目識別子(株式銘柄など)の反復的な発生を圧縮して、記憶域を大幅に節約できます。

関連項目:

キー圧縮の詳細は、『Oracle Database概要』を参照してください。 

索引構成表のメンテナンス

索引構成表と通常の表の相違点は、物理的な構成のみです。論理的には、通常の表と同じように操作されます。INSERTSELECTDELETEおよびUPDATEの各文では、通常の表を指定する場合と同じように、索引構成表を指定できます。

索引構成表の変更

通常の表に使用可能な変更オプションはすべて索引構成表にも使用できます。使用可能なオプションには、ADDMODIFYDROP COLUMNSおよびCONSTRAINTSがあります。ただし、索引構成表の主キー制約は、削除、遅延または使用禁止にできません。

ALTER TABLE文を使用すると、主キー索引セグメントとオーバーフロー・データ・セグメントの物理属性と記憶域属性を変更できます。OVERFLOWキーワードより前に指定したすべての属性は、主キー索引セグメントに適用できます。OVERFLOWキーワードより後に指定したすべての属性は、オーバーフロー・データ・セグメントに適用できます。たとえば、次のようにして、主キー索引セグメントのINITRANSを4に、オーバーフロー・データ・セグメントのINITRANSを6に設定できます。

ALTER TABLE admin_docindex INITRANS 4 OVERFLOW INITRANS 6;

また、PCTTHRESHOLDおよびINCLUDING列の値も変更できます。後続の操作では、新しい設定を使用して、先頭部分とオーバーフローの後尾の部分に行が分割されます。たとえば、admin_docindex表のPCTHRESHOLDおよびINCLUDING列の値を次のように変更できます。

ALTER TABLE admin_docindex PCTTHRESHOLD 15 INCLUDING doc_id;

INCLUDING列をdoc_idに設定すると、その後のすべての列、つまりtoken_frequencyおよびtoken_offsetsはオーバーフロー・データ・セグメントに格納されます。

オーバーフロー・データ・セグメントなしで作成された索引構成表の場合は、ADD OVERFLOW句を使用してオーバーフロー・データ・セグメントを追加できます。たとえば、次のように表admin_iot3にオーバーフロー・セグメントを追加できます。

ALTER TABLE admin_iot3 ADD OVERFLOW TABLESPACE admin_tbs2;

索引構成表の移動(再作成)

索引構成表は主としてBツリー索引に格納されるため、増分更新の結果として断片化が生じることがあります。ただし、このような断片化は、ALTER TABLE...MOVE文を使用して索引を再作成することで低減できます。

次の文は、索引構成表admin_docindexを再作成します。

ALTER TABLE admin_docindex MOVE;

ONLINEキーワードを使用して、索引構成表をオンラインで再作成できます。OVERFLOWキーワードを指定すると、オーバーフロー・データ・セグメントが存在する場合はそれが再作成されます。たとえば、admin_docindex表を再作成し、オーバーフロー・データ・セグメントを再作成しない場合は、次のようにオンラインで移動します。

ALTER TABLE admin_docindex MOVE ONLINE;

admin_docindex表とオーバーフロー・データ・セグメントを再作成するには、次の文のように移動操作を実行します。この文は、表とオーバーフロー・データ・セグメントを新しい表領域に移動する方法も示しています。

ALTER TABLE admin_docindex MOVE TABLESPACE admin_tbs2 
    OVERFLOW TABLESPACE admin_tbs3;

次の最後の文で、LOB列(CLOB)を持つ索引構成表が作成されます。その後、この表はLOB索引とともに移動し、データ・セグメントが再作成され新しい表領域に移動します。

CREATE TABLE admin_iot_lob
   (c1 number (6) primary key,
    admin_lob CLOB)
   ORGANIZATION INDEX
   LOB (admin_lob) STORE AS (TABLESPACE admin_tbs2);
.
.
.
ALTER TABLE admin_iot_lob MOVE LOB (admin_lob) STORE AS (TABLESPACE admin_tbs3); 

関連項目:

索引構成表のLOBの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。 

索引構成表に対する2次索引の作成

索引構成表に2次索引を作成することで、複数のアクセス・パスを提供できます。索引構成表の2次索引は、2つの点で通常の表の索引とは異なります。

一意の2次索引、一意でない2次索引、機能ベースの2次索引およびビットマップ索引が、索引構成表の2次索引としてサポートされます。

1つの索引構成表に対する1つの2次索引の作成

次の文は、索引構成表docindexに2次索引を作成します、doc_idtokenはキー列です。

CREATE INDEX Doc_id_index on Docindex(Doc_id, Token);

この2次索引によって、問合せ(次の文にあるdoc_idの述語に関係する問合せ)が効率的に処理されます。

SELECT Token FROM Docindex WHERE Doc_id = 1;

論理ROWIDの物理的不確定要素のメンテナンス

論理ROWIDには、不確定要素が作成される際に行のブロック位置を識別する不確定要素を含めることができます。完全なキー検索を実行するかわりに、不確定要素を使用してブロックが直接検索されます。ただし、新しい行が挿入されると、不確定要素は失効となる可能性があります。索引は論理ROWIDの主キー構成要素を介してそのまま使用できますが、行へのアクセスは遅くなります。

不確定要素の失効を監視するには、DBMS_STATSパッケージを使用して索引統計を収集します。既存の不確定要素が有効かどうかがチェックされ、有効な不確定要素を保持している行の割合がデータ・ディクショナリに記録されます。この統計は、DBA_INDEXESビュー(および関連するビュー)のPCT_DIRECT_ACCESS列に格納されます。

新しい不確定要素を取得するために、2次索引を再作成できます。索引構成表に対する2次索引の再作成には、通常の表に対する索引の再作成とは異なり、実表の読込みが必要です。不確定要素を修正する迅速で手軽な方法は、ALTER INDEX ...UPDATE BLOCK REFERENCES文を使用する方法です。この文はオンラインで実行されますが、DMLは基礎となる索引構成表でそのまま実行できます。

2次索引を再作成した後、あるいは不確定要素のブロック参照を更新した後は、索引統計を再度収集してください。

ビットマップ索引

索引構成表とともにマッピング表が作成される場合は、索引構成表でのビットマップ索引がサポートされます。ビットマップ索引を作成するには、索引構成表の作成に使用するCREATE TABLE文、または後でマッピング表を追加するALTER TABLE文に、MAPPING TABLE句を指定します。

関連項目:

マッピング表の説明は、『Oracle Database概要』を参照してください。 

索引構成表の分析

通常の表と同様に、索引構成表の分析にはDBMS_STATSパッケージ、またはANALYZE文を使用します。

索引構成表のオプティマイザ統計の収集

オプティマイザ統計を収集するには、DBMS_STATSパッケージを使用します。

たとえば、次の文はhrスキーマの索引構成表countriesについて統計を収集します。

EXECUTE DBMS_STATS.GATHER_TABLE_STATS ('HR','COUNTRIES');

DBMS_STATSパッケージでは、主キー索引セグメントとオーバーフロー・データ・セグメントの両方が分析され、表の論理統計と物理統計が算出されます。

索引構成表の構造の検証

索引構成表の構造を検証、または連鎖行をリストする場合は、ANALYZE文を使用します。これらの操作は、このマニュアルの該当する項で説明されています。

索引構成表でのORDER BY句の使用

ORDER BY句が主キー列またはその接頭辞のみを参照する場合、行は主キー列でソートされた状態で返されるため、オプティマイザはソートのオーバーヘッドを回避します。

データはすでに主キーでソートされているので、次の2つの問合せはソートのオーバーヘッドを回避します。

SELECT * FROM admin_docindex2 ORDER BY token, doc_id;
SELECT * FROM admin_docindex2 ORDER BY token;

ただし、主キー列の接尾辞または非主キー列にORDER BY句がある場合は、別のソートが必要になります(他の2次索引が定義されていない場合)。

SELECT * FROM admin_docindex2 ORDER BY doc_id;
SELECT * FROM admin_docindex2 ORDER BY token_frequency;

索引構成表の標準的な表への変換

索引構成表を標準的な表に変換するには、Oracleのインポート/エクスポート・ユーティリティ、あるいはCREATE TABLE...AS SELECT文を使用します。

索引構成表を標準的な表に変換する手順

外部表の管理

Oracle Databaseでは、外部表内のデータへの読取り専用アクセスが可能です。外部表はデータベース内に存在しない表として定義されており、アクセス・ドライバが提供されていればどのようなフォーマットにすることもできます。外部表を記述するメタデータを提供することで、外部表内のデータをあたかも標準的なデータベース表内に存在しているデータのように公開できます。外部データは、SQLを使用して直接およびパラレルに問合せできます。

外部表のデータは、選択、結合、ソートなどが行えます。外部表のビューやシノニムも作成できます。ただし、外部表に対してDML操作(UPDATEINSERTまたはDELETE)は実行できず、索引も作成できません。

外部表は、任意のSELECT文の結果をOracle Data Pumpで使用できるように、オラクル社が開発したプラットフォームに依存しないフォーマットにアンロードするフレームワークも提供しています。


注意:

外部表の統計収集には、DBMS_STATSパッケージを使用できます。ANALYZE文による外部表の統計収集はサポートされていません。

DBMS_STATSパッケージの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 


外部表のメタデータは、CREATE TABLE...ORGANIZATION EXTERNAL文を使用して定義します。外部表の定義は、外部データを最初にデータベースにロードしなくても外部データに対して任意のSQL問合せを実行できるビューとみなすことができます。表内の外部データを読み込むために実際に使用されているメカニズムが、アクセス・ドライバです。外部表を使用してデータをアンロードすると、SELECT文のデータ型(問合せの形式とも呼ばれます)に基づいてメタデータが自動的に作成されます。

Oracle Databaseでは、外部表のための2種類のアクセス・ドライバを提供しています。デフォルトのアクセス・ドライバはORACLE_LOADERで、Oracleのローダー・テクノロジを使用して外部ファイルからデータを読み込むことができます。ORACLE_LOADERアクセス・ドライバは、SQL*Loaderユーティリティの制御ファイル構文のサブセットであるデータ・マッピング機能を提供します。第2のアクセス・ドライバORACLE_DATAPUMPは、データをアンロード(つまり、データベースからデータを読み取り、1つ以上の外部ファイルで表された外部表にそのデータを挿入)してから、データをOracle Databaseに再ロードします。

Oracle Databaseの外部表機能は、データ・ウェアハウスで一般的な、抽出、変換およびロード(ETL)の基本タスクを実行する際に役立つ手段を提供します。

次の項では、外部表のためにサポートされているデータ定義言語(DDL)文について説明します。サポートされているDDL文はここで説明しているもののみですが、これらの文の句がすべてサポートされているわけではありません。

外部表の作成

外部表は、CREATE TABLE文のORGANIZATION EXTERNAL句を使用して作成します。実際には表が作成されるわけではなく、外部表にはエクステントが対応付けられません。そのかわりに、外部データへのアクセスを可能にするメタデータをデータ・ディクショナリに作成します。


注意:

外部表に仮想列は設定できません。 


次の例では、外部表を作成してから、データをデータベース表にアップロードしています。あるいは、CREATE TABLE文のAS subquery句を指定し、外部表フレームワークを介してデータをアンロードできます。外部表のデータ・ポンプ・アンロードは、ORACLE_DATAPUMPアクセス・ドライバのみを使用できます。

例: 外部表の作成とデータのロード

ファイルempxt1.datには、次のサンプル・データが収められています。

360,Jane,Janus,ST_CLERK,121,17-MAY-2001,3000,0,50,jjanus
361,Mark,Jasper,SA_REP,145,17-MAY-2001,8000,.1,80,mjasper
362,Brenda,Starr,AD_ASST,200,17-MAY-2001,5500,0,10,bstarr
363,Alex,Alda,AC_MGR,145,17-MAY-2001,9000,.15,80,aalda

ファイルempxt2.datには、次のサンプル・データが収められています。

401,Jesse,Cromwell,HR_REP,203,17-MAY-2001,7000,0,40,jcromwel
402,Abby,Applegate,IT_PROG,103,17-MAY-2001,9000,.2,60,aapplega
403,Carol,Cousins,AD_VP,100,17-MAY-2001,27000,.3,90,ccousins
404,John,Richardson,AC_ACCOUNT,205,17-MAY-2001,5000,0,110,jrichard

次のSQL文の例は、スキーマhrに外部表admin_ext_employeesを作成し、そのデータをhr.employees表にロードします。

CONNECT  /  AS SYSDBA;
-- Set up directories and grant access to hr 
CREATE OR REPLACE DIRECTORY admin_dat_dir
    AS '/flatfiles/data'; 
CREATE OR REPLACE DIRECTORY admin_log_dir 
    AS '/flatfiles/log'; 
CREATE OR REPLACE DIRECTORY admin_bad_dir 
    AS '/flatfiles/bad'; 
GRANT READ ON DIRECTORY admin_dat_dir TO hr; 
GRANT WRITE ON DIRECTORY admin_log_dir TO hr; 
GRANT WRITE ON DIRECTORY admin_bad_dir TO hr;
-- hr connects. Provide the user password (hr) when prompted.
CONNECT hr
-- create the external table
CREATE TABLE admin_ext_employees
                   (employee_id       NUMBER(4), 
                    first_name        VARCHAR2(20),
                    last_name         VARCHAR2(25), 
                    job_id            VARCHAR2(10),
                    manager_id        NUMBER(4),
                    hire_date         DATE,
                    salary            NUMBER(8,2),
                    commission_pct    NUMBER(2,2),
                    department_id     NUMBER(4),
                    email             VARCHAR2(25) 
                   ) 
     ORGANIZATION EXTERNAL 
     ( 
       TYPE ORACLE_LOADER 
       DEFAULT DIRECTORY admin_dat_dir 
       ACCESS PARAMETERS 
       ( 
         records delimited by newline 
         badfile admin_bad_dir:'empxt%a_%p.bad' 
         logfile admin_log_dir:'empxt%a_%p.log' 
         fields terminated by ',' 
         missing field values are null 
         ( employee_id, first_name, last_name, job_id, manager_id, 
           hire_date char date_format date mask "dd-mon-yyyy", 
           salary, commission_pct, department_id, email 
         ) 
       ) 
       LOCATION ('empxt1.dat', 'empxt2.dat') 
     ) 
     PARALLEL 
     REJECT LIMIT UNLIMITED; 
-- enable parallel for loading (good if lots of data to load)
ALTER SESSION ENABLE PARALLEL DML;
-- load the data in hr employees table
INSERT INTO employees (employee_id, first_name, last_name, job_id, manager_id,
                       hire_date, salary, commission_pct, department_id, email) 
            SELECT * FROM admin_ext_employees;

この例について、次の各段落で説明します。

この例で、最初の数行の文は、データソースを保存するオペレーティング・システム・ディレクトリ用のディレクトリ・オブジェクトと、アクセス・パラメータで指定される不良レコードやログ・ファイル用のディレクトリ・オブジェクトを作成します。また、必要に応じてREADまたはWRITEのディレクトリ・オブジェクト権限を付与する必要があります。


注意:

ディレクトリ・オブジェクトまたはBFILEを作成する場合は、次の条件が満たされているかどうかを確認してください。

  • オペレーティング・システム・ファイルが、シンボリック・リンクまたはハード・リンクでないこと。

  • Oracle Databaseのディレクトリ・オブジェクトに指定されているオペレーティング・システムのディレクトリ・パスが、既存のオペレーティング・システムのディレクトリ・パスであること。

  • ディレクトリ・オブジェクトに指定されているオペレーティング・システムのディレクトリ・パスの構成要素に、シンボリック・リンクが含まれていないこと。

 

TYPE指定は、外部表のアクセス・ドライバを示します。アクセス・ドライバはデータベースの外部データを解析するAPIです。Oracle Databaseでは、ORACLE_LOADERORACLE_DATAPUMPの2種類のアクセス・ドライバを提供しています。TYPE指定を省略した場合は、ORACLE_LOADERがデフォルトのアクセス・ドライバになります。AS subquery句を指定して、あるOracle Databaseからデータをアンロードし、同一または異なるOracle Databaseに再ロードする場合は、ORACLE_DATAPUMPアクセス・ドライバを指定する必要があります。

ACCESS PARAMETERS句で指定するアクセス・パラメータは、データベースには不透明です。これらのアクセス・パラメータはアクセス・ドライバによって定義されるもので、データベースが外部表にアクセスするときにアクセス・ドライバに提供されます。 ORACLE_LOADERアクセス・パラメータの詳細は、『Oracle Databaseユーティリティ』を参照してください。

PARALLEL句は、データソースに対するパラレル問合せを可能にします。パラレル化の最小単位はデフォルトではデータソースですが、データソース内部でのパラレル・アクセスは可能なかぎり実装されます。たとえば、PARALLEL=3と指定すると、データソースに対して複数のパラレル実行サーバーを稼働しておくことができます。しかし、データソース内部でのパラレル・アクセスは、次の条件がすべて成り立つ場合にのみ、アクセス・ドライバによって提供されます。

REJECT LIMIT句は、外部データの問合せ中に発生する可能性のあるエラーの数に上限を設けないことを指定します。パラレル・アクセスの場合、この上限は各パラレル実行サーバーに個別に適用されます。たとえば、REJECT LIMITを指定すると、各パラレル問合せプロセスで10個の拒否が許可されます。したがって、パラレル問合せに関して正確に規定されるREJECT LIMITの値は、0(ゼロ)およびUNLIMITEDのみです。

この例では、INSERT INTO TABLE文によって外部データソースからOracle Database SQLエンジンへのデータフローが生成され、そこでデータが処理されます。外部表ソースからのデータがアクセス・ドライバで解析されて外部表インタフェースに提供されると、外部データがその外部表現からOracle Databaseの内部データ型に変換されます。

関連項目:

外部表を作成するためのCREATE TABLE文の構文の詳細、および句の使用に関する制限については、『Oracle Database SQLリファレンス』を参照してください。 

外部表の変更

外部表の特性を変更するには、表18-3のいずれかのALTER TABLE句を使用します。これ以外の句は使用できません。

表 18-3    外部表のALTER TABLE句 

ALTER TABLE句  説明   

REJECT LIMIT  

拒否の上限を変更します。 

ALTER TABLE admin_ext_employees
REJECT LIMIT 100;
 

PROJECT COLUMN 

アクセス・ドライバが後続の問合せで行の妥当性をチェックする方法を決定します。

  • PROJECT COLUMN REFERENCED: アクセス・ドライバは、問合せの選択リストのみを処理します。この設定では、同一の外部表とは異なる列リストを問い合せたときに、一貫した行のセットが提供されない可能性があります。これはデフォルトです。

  • PROJECT COLUMN ALL: アクセス・ドライバは、外部表に定義されているすべての列を処理します。この設定では、外部表を問い合せたときに、常に一貫した行のセットが提供されます。

 
ALTER TABLE admin_ext_employees
PROJECT COLUMN REFERNCED;

ALTER TABLE admin_ext_employees
PROJECT COLUMN ALL;
 

DEFAULT DIRECTORY  

デフォルトのディレクトリ指定を変更します。 

ALTER TABLE admin_ext_employees 
DEFAULT DIRECTORY admin_dat2_dir;
 

ACCESS PARAMETERS  

外部表のメタデータの削除と再作成を行わずにアクセス・パラメータを変更できます。 

ALTER TABLE admin_ext_employees
ACCESS PARAMETERS
(FIELDS TERMINATED BY ';');
 

LOCATION  

外部表のメタデータの削除と再作成を行わずにデータソースを変更できます。 

ALTER TABLE admin_ext_employees
LOCATION ('empxt3.txt',
'empxt4.txt');
 

PARALLEL  

標準的な表の場合と同じです。並列度を変更できます。 

新しい構文はありません。 

ADD COLUMN  

標準的な表の場合と同じです。外部表に列を追加できます。仮想列は使用できません。 

新しい構文はありません。 

MODIFY COLUMN  

標準的な表の場合と同じです。外部表の列を変更できます。仮想列は使用できません。 

新しい構文はありません。 

SET UNUSED 

ALTER TABLE DROP COLUMNコマンドに透過的に変換されます。外部表はデータベース内でメタデータのみで構成されているため、DROP COLUMNコマンドはSET UNUSEDコマンドの実行と同じことになります。 

新しい構文はありません。 

DROP COLUMN  

標準的な表の場合と同じです。外部表の列を削除できます。 

新しい構文はありません。 

RENAME TO  

標準的な表の場合と同じです。外部表の名前を変更できます。 

新しい構文はありません。 

外部表の削除

外部表では、DROP TABLE文によってデータベース内の表メタデータのみ削除されます。実際のデータはデータベースの外側に存在しているため、影響はありません。

外部表のシステム権限およびオブジェクト権限

外部表のシステム権限およびオブジェクト権限は、標準的な表のサブセットになります。外部表に適用できるシステム権限は、次のものにかぎられます。

外部表に適用できるオブジェクト権限は、次のものにかぎられます

ただし、ディレクトリには次のオブジェクト権限が対応付けられています。

外部表では、データソースのあるディレクトリ・オブジェクトに対してREAD権限が必要であり、同時に、不良ファイル、ログ・ファイルまたは廃棄ファイルのあるディレクトリ・オブジェクトに対してWRITE権限が必要です。

表のデータ・ディクショナリ・ビュー

次のビューを使用して、表に関する情報にアクセスできます。

ビュー  説明 

DBA_TABLES

ALL_TABLES

USER_TABLES  

DBAビューには、データベース内のすべてのリレーショナル表が表示されます。ALLビューには、ユーザーがアクセス可能なすべての表が表示されます。USERビューは、ユーザーが所有する表のみに制限されます。これらのビューの一部の列には、DBMS_STATSパッケージまたはANALYZE文によって生成される統計が含まれます。 

DBA_TAB_COLUMNS

ALL_TAB_COLUMNS

USER_TAB_COLUMNS  

これらのビューには、データベース内の表の列、ビューおよびクラスタが表示されます。これらのビューの一部の列には、DBMS_STATSパッケージまたはANALYZE文によって生成される統計が含まれます。 

DBA_ALL_TABLES

ALL_ALL_TABLES

USER_ALL_TABLES  

これらのビューには、データベース内のすべてのリレーショナル表およびオブジェクト表が表示されます。オブジェクト表については、このマニュアルでは詳しく説明していません。 

DBA_TAB_COMMENTS

ALL_TAB_COMMENTS

USER_TAB_COMMENTS  

これらのビューには、表およびビューのコメントが表示されます。コメントは、COMMENT文を使用して入力します。 

DBA_COL_COMMENTS

ALL_COL_COMMENTS

USER_COL_COMMENTS  

これらのビューには、表およびビューの列のコメントが表示されます。コメントは、COMMENT文を使用して入力します。 

DBA_EXTERNAL_TABLES

ALL_EXTERNAL_TABLES

USER_EXTERNAL_TABLES  

これらのビューには、データベースで定義されている外部表の特定の属性がリストされます。  

DBA_EXTERNAL_LOCATIONS

ALL_EXTERNAL_LOCATIONS

USER_EXTERNAL_LOCATIONS  

これらのビューには、外部表のデータソースがリストされます。 

DBA_TAB_HISTOGRAMS

ALL_TAB_HISTOGRAMS

USER_TAB_HISTOGRAMS  

これらのビューには、表およびビューに関するヒストグラムが表示されます。 

DBA_TAB_STATISTICS

ALL_TAB_STATISTICS

USER_TAB_STATISTICS 

これらのビューには、表のオプティマイザ統計が格納されます。 

DBA_TAB_COL_STATISTICS

ALL_TAB_COL_STATISTICS

USER_TAB_COL_STATISTICS  

これらのビューは、関連するTAB_COLUMNSビューから抽出された列の統計およびヒストグラム情報を提供します。 

DBA_TAB_MODIFICATIONS

ALL_TAB_MODIFICATIONS

USER_TAB_MODIFICATIONS  

これらのビューには、表統計が最後に収集された時点以降変更された表が表示されます。これらのビューは即時には移入されず、ある程度の時間(通常は3時間)が経過した後に移入されます。 

DBA_ENCRYPTED_COLUMNS

USER_ENCRYPTED_COLUMNS

ALL_ENCRYPTED_COLUMNS 

これらのビューには、暗号化された表の列がリストされ、各列に使用している暗号化アルゴリズムがリストされます。 

DBA_UNUSED_COL_TABS

ALL_UNUSED_COL_TABS

USER_UNUSED_COL_TABS  

これらのビューには、ALTER TABLE ...SET UNUSED文によって未使用のマークが付けられた列を持つ表がリストされます。 

DBA_PARTIAL_DROP_TABS

ALL_PARTIAL_DROP_TABS

USER_PARTIAL_DROP_TABS  

これらのビューには、DROP COLUMN操作が一部完了している表がリストされます。これらの操作は、ユーザーによる中断やシステム障害が原因で不完全になることがあります。 

例: 列情報の表示

_COLUMNS接尾辞で終わるビューのいずれかを使用すれば、名前、データ型、長さ、精度、位取り、デフォルト・データ値などの列情報を表示できます。たとえば、次の問合せは、emp表とdept表のデフォルトの列値をすべてリストします。

SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, DATA_LENGTH, LAST_ANALYZED
    FROM DBA_TAB_COLUMNS
    WHERE OWNER = 'HR'
    ORDER BY TABLE_NAME;
    

問合せの出力は次のとおりです。

TABLE_NAME           COLUMN_NAME          DATA_TYPE   DATA_LENGTH LAST_ANALYZED
-------------------- -------------------- ---------- ------------ -------------
COUNTRIES            COUNTRY_ID           CHAR                  2 05-FEB-03
COUNTRIES            COUNTRY_NAME         VARCHAR2             40 05-FEB-03
COUNTRIES            REGION_ID            NUMBER               22 05-FEB-03
DEPARTMENTS          DEPARTMENT_ID        NUMBER               22 05-FEB-03
DEPARTMENTS          DEPARTMENT_NAME      VARCHAR2             30 05-FEB-03
DEPARTMENTS          MANAGER_ID           NUMBER               22 05-FEB-03
DEPARTMENTS          LOCATION_ID          NUMBER               22 05-FEB-03
EMPLOYEES            EMPLOYEE_ID          NUMBER               22 05-FEB-03
EMPLOYEES            FIRST_NAME           VARCHAR2             20 05-FEB-03
EMPLOYEES            LAST_NAME            VARCHAR2             25 05-FEB-03
EMPLOYEES            EMAIL                VARCHAR2             25 05-FEB-03
.
.
.
LOCATIONS            COUNTRY_ID           CHAR                  2 05-FEB-03
REGIONS              REGION_ID            NUMBER               22 05-FEB-03
REGIONS              REGION_NAME          VARCHAR2             25 05-FEB-03

51 rows selected.

関連項目:

  • これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

  • オブジェクト表の詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。

  • ヒストグラムおよび表の統計生成の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

  • 「表、索引およびクラスタの分析」

 


戻る 次へ
Oracle
Copyright © 2001, 2008, Oracle Corporation.
All Rights Reserved.
目次
目次
索引
索引