20 表の管理
表の管理には、表の作成、表のロード、表の変更および表の削除などのタスクが含まれます。
Live SQL:
この章の例に関連するOracle Live SQLでの例を参照して実行するには、Oracle Live SQL: 表の作成および変更にアクセスしてください。
- 表について
表は、Oracle Databaseのデータ記憶域の基本単位です。データは、行および列に格納されます。 - 表を管理するためのガイドライン
これらのガイドラインに従うことで、表の作成や表データのロード、更新および問合せを行うときに、表の管理が容易になり、パフォーマンスの向上にもつながります。 - 表の作成
表はSQL文CREATE TABLE
を使用して作成します。 - 表のロード
ここでは、データを表にロードするための手法について説明します。 - バルク更新のパフォーマンス最適化
DBMS_REDEFINITION
パッケージのEXECUTE_UPDATE
プロシージャを使用して、表のバルク更新のパフォーマンスを最適化できます。REDOログに更新が記録されないため、パフォーマンスが最適化されます。 - 表に関する統計の自動収集
PL/SQLパッケージDBMS_STATS
を使用すると、コストベースの最適化に関する統計を生成および管理できます。このパッケージを使用して、統計の収集、変更、表示、エクスポート、インポートおよび削除ができます。また、すでに収集した統計を識別または命名する際も、このパッケージを使用できます。 - 表の変更
表を変更するにはALTER TABLE
文を使用します。表を変更するには、その表が自分のスキーマに含まれているか、その表のALTER
オブジェクト権限またはALTER ANY TABLE
システム権限のいずれかを持っている必要があります。 - 表のオンライン再定義
表の論理構造または物理構造を変更できます。 - エラーが発生した表の変更の調査と取消し
表に対してエラーが発生する変更を調査して取り消せるようにするために、Oracle Databaseには、データベース・オブジェクトの過去の状態を表示したり、Point-in-Timeメディア・リカバリを使用せずにデータベース・オブジェクトを以前の状態に戻すために使用できる一連の機能が用意されています。これらの機能はOracle Flashback機能と呼ばれます。 - Oracle Flashback Tableを使用した表のリカバリ
Oracle Flashback Tableを使用すると、表を以前の時点の状態にリストアできます。 - 表の削除
不要になった表を削除するには、DROP TABLE
文を使用します。 - フラッシュバック・ドロップの使用とリサイクル・ビンの管理
表を削除した場合、その表に関連付けられている領域はデータベースによってすぐには削除されません。データベースによってこの表の名前が変更され、すべての関連オブジェクトとともにリサイクル・ビンへ入れられますが、後に表が誤って削除されたことがわかった場合、リサイクル・ビンからリカバリすることができます。この機能はフラッシュバック・ドロップと呼ばれ、表のリストアにはFLASHBACK
TABLE
文が使用されます。 - 索引構成表の管理
索引構成表の記憶域の編成はプライマリBツリー索引の変形です。ヒープ構成表とは異なり、データは主キーの順に格納されます。 - 外部表の管理
外部表はデータベースには存在しません。 - 表のデータ・ディクショナリ・ビュー
データ・ディクショナリ・ビューのセットを問い合せて、表についてのデータを取得できます。
親トピック: スキーマ・オブジェクト
20.1 表について
表は、Oracle Databaseのデータ記憶域の基本単位です。データは、行および列に格納されます。
表は、employees
などの表名と一連の列で定義します。各列には列名(employee_id
、last_name
、job_id
など)、データ型(VARCHAR2
、DATE
、NUMBER
など)および幅を指定します。幅は、DATE
データ型の場合のようにデータ型によって事前に決定されている場合があります。NUMBER
データ型の列の場合は、幅ではなく、精度および位取りを定義します。行は、単一のレコードに対応する列情報の集合です。
表の各列にはルールを指定できます。これらのルールは整合性制約と呼ばれています。一例としてNOT NULL
の整合性制約があります。この制約では、列のすべての行に値が含まれている必要があります。
透過的データ暗号化を起動して、データを暗号化してから格納できます。ユーザーが、オペレーティング・システムのツールを使用してOracleデータファイルの内容を直接参照することによって、データベース・アクセス制御メカニズムを迂回しようとした場合でも、暗号化によって、このようなユーザーが機密データを参照できないようにします。
表には仮想列を含めることもできます。仮想列は表の他の列とほぼ同じですが、値が式を評価して導出される点が異なります。式には、同じ表からの列、制約、SQL関数およびユーザー定義PL/SQL関数を含めることができます。仮想列に明示的に書き込むことはできません。
列の型には、LOB
、VARRAYおよびネストした表のように専用セグメントに格納されるものがあります。LOB
とVARRAYはLOB
セグメントに格納されますが、ネストした表は記憶表に格納されます。これらのセグメントに対してSTORAGE
句を指定し、表レベルで指定した記憶域パラメータを上書きできます。
表を作成した後は、SQL文またはOracleのバルク・ロード・ユーティリティを使用してデータ行を挿入します。表データは、SQLを使用して問合せ、削除または更新できます。
関連項目:
-
表の概要は、『Oracle Database概要』を参照してください。
-
Oracle Databaseのデータ型の説明は、『Oracle Database SQL言語リファレンス』を参照してください。
-
表の領域を管理するためのガイドラインは、「スキーマ・オブジェクトの領域の管理」を参照してください
-
整合性制約の指定や表の分析など、表の管理に関するその他の詳細は、「スキーマ・オブジェクトの管理」を参照してください
-
透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
親トピック: 表の管理
20.2 表を管理するためのガイドライン
ガイドラインに従うことで、表の作成や表データのロード、更新および問合せを行うときに、表の管理が容易になり、パフォーマンスの向上にもつながります。
- 作成前の表の設計
通常、アプリケーション開発者は、表などのアプリケーションの要素を設計する必要があります。データベース管理者は、アプリケーション表を保持する、基礎になる表領域に対する属性の設定を担当します。 - 作成する表のタイプの指定
Oracle Databaseでは様々なタイプの表を作成できます。 - 各表の位置の指定
新しい表を格納する表領域を識別するには、CREATE TABLE
文にTABLESPACE
句を指定します。パーティション表の場合は、各パーティションを格納する表領域をオプションとして指定できます。 - 表作成のパラレル化
CREATE TABLE
文で副問合せ(AS SELECT
)を使用して表を作成する際は、パラレル実行を使用できます。複数のプロセスが同時に動作して表を作成するため、表を作成するときのパフォーマンスが向上します。 - 表作成時のNOLOGGINGの使用
表を最も効率よく作成するには、CREATE TABLE...AS SELECT
文でNOLOGGING
句を使用します。NOLOGGING
句を指定すると、表の作成中に最小限のREDO情報しか生成されません。 - 表圧縮の使用
データベースのサイズが大きくなった場合、表圧縮を使用して領域を節約し、パフォーマンスを改善することを検討してください。 - Enterprise Manager Cloud Controlを使用した表圧縮の管理
Oracle Enterprise Manager Cloud Controlで表圧縮を管理できます。 - セグメント・レベルおよび行レベルの圧縮層の使用
セグメント・レベルの圧縮層を使用すると、表内のセグメント・レベルで圧縮を指定できます。行レベルの圧縮層を使用すると、表内の行レベルで圧縮を指定できます。同じ表でこれらの組合せを使用して、表内のデータが格納および管理される方法を細かく制御できます。 - 属性クラスタ表の使用
属性クラスタ表とは、ユーザー指定のクラスタリング・ディレクティブに基づいてディスク上に近接近でデータを格納するヒープ構成表です。 - ゾーン・マップの使用
ゾーンとは、ディスク上で連続している一群のデータ・ブロックです。ゾーン・マップでは、個々のゾーンすべてについて、指定された列の最小値および最大値を追跡管理します。 - インメモリー列ストアへの表の格納
インメモリー列ストアは、システム・グローバル領域(SGA)のオプション部分で、高速スキャン用に最適化された表、表パーティション、その他のデータベース・オブジェクトのコピーが格納されます。インメモリー列ストアでは、表データがSGAに行ではなく列ごとに格納されます。 - 不可視の列の使用
表を使用するアプリケーションを中断しないで表を変更する場合に、不可視の列を使用できます。 - 機密データを格納する列の暗号化
機密データが格納された表の列を個々に暗号化できます。機密データには、社会保障番号、クレジット・カード番号、医療記録などがあります。列の暗号化は、アプリケーションに対して完全に透過的ですが、いくつか制限事項があります。 - セグメント作成の遅延の理解
ローカルで管理される表領域内にヒープ構成表を作成すると、最初の行が挿入されるまで表セグメントの作成が遅延されます。 - セグメントのマテリアライズ
DBMS_SPACE_ADMIN
パッケージにはMATERIALIZE_DEFERRED_SEGMENTS()
プロシージャが含まれており、このプロシージャを使用すると、セグメント作成の遅延が有効であるときに作成された表、表パーティションおよび依存オブジェクトのセグメントをマテリアライズできます。 - 表サイズの見積りと見積りに応じた計画
表を作成する前に表のサイズを見積ります。見積りは、なるべくデータベース計画の一部として実行します。データベース表のサイズと用途を確認することは、データベース計画の重要な部分です。 - 表作成時の制限事項
表を作成するときには制限事項を考慮する必要があります。
親トピック: 表の管理
20.2.1 作成前の表の設計
通常、アプリケーション開発者は、表などのアプリケーションの要素を設計する必要があります。データベース管理者は、アプリケーション表を保持する、基礎になる表領域に対する属性の設定を担当します。
DBAまたはアプリケーション開発者は(あるいは双方が協力して)、サイトの業務に基づいて実際の表の作成を担当します。表を設計する場合は、アプリケーション開発者と協力し、次のガイドラインを考慮してください。
-
表、列、索引およびクラスタには、内容を表現する名前を使用します。
-
表名および列に略語を使用する場合や、単数形と複数形の使用には、一貫性を持たせます。
-
COMMENT
コマンドを使用して、各表とその列の意味を記載します。 -
各表は正規化します。
-
各列に適切なデータ型を選択します。
-
一部の表に仮想列を1つ以上追加した場合、アプリケーションに利点があるかどうかを検討します。
-
記憶域を節約するために、NULLを許可する列を最後に定義します。
-
記憶域を節約し、SQL文のパフォーマンスを最適化するために、適切な場合は必ず表をクラスタ化します。
表を作成する前に、整合性制約の使用についても判断します。表の列に整合性制約を定義することによって、データベースのビジネス・ルールを自動的に徹底できます。
親トピック: 表を管理するためのガイドライン
20.2.2 作成する表のタイプの指定
Oracle Databaseでは様々なタイプの表を作成できます。
作成できる表のタイプは次のとおりです。
表のタイプ | 説明 |
---|---|
通常の(ヒープ構成)表 |
この章の主な説明の対象でもある基本的で多目的な表です。この表のデータは、順序付けされていないコレクション(ヒープ)として格納されます。 |
クラスタ化表 |
クラスタ化表は、クラスタの一部である表です。クラスタとは、各表が共通の列を共有していて一緒に使用されるケースが多いために、同じデータ・ブロックを共有する表のグループです。 クラスタおよびクラスタ化表の詳細は、「クラスタの管理」を参照してください。 |
索引構成表 |
通常の(ヒープ構成)表とは異なり、索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納されます。Bツリーの各索引エントリには、索引構成表の行の主キーの列値のみでなく、非キーの列値も格納されます。 索引構成表の詳細は、「索引構成表の管理」を参照してください。 |
パーティション表 |
パーティション表では、データをパーティションと呼ばれるさらに小さく管理が容易な単位に分割でき、さらにサブパーティションに分割することもできます。各パーティションには、圧縮の有効化または無効化、圧縮のタイプ、物理記憶域設定、表領域など別個の物理属性を指定できるため、可用性およびパフォーマンスをより適切にチューニングできる構造になります。さらに、各パーティションを個別に管理できるため、バックアップや管理が簡素化され、これらの処理に必要な時間を削減できます。 パーティション表の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
親トピック: 表を管理するためのガイドライン
20.2.3 各表の位置の指定
新しい表を格納する表領域を識別するには、CREATE TABLE文にTABLESPACE
句を指定します。パーティション表の場合は、各パーティションを格納する表領域をオプションとして指定できます。
使用する表領域に対する適切なシステム権限と割当て権限があることを確認してください。CREATE TABLE
文で表領域を指定しない場合は、作成したユーザーのデフォルト表領域内に表が作成されます。
新しい表を含む表領域を指定するときは、その選択が意味することを確実に理解しておいてください。各表の作成時に表領域を適切に指定することによって、データベース・システムのパフォーマンスが向上し、データベース管理に必要な時間を短縮できます。
次のように、表領域を指定しない場合や不適切な表領域を指定した場合は、パフォーマンスに影響を与えます。
-
ユーザーのオブジェクトを
SYSTEM
表領域に作成すると、データ・ディクショナリ・オブジェクトとユーザー・オブジェクトの両方が同じデータファイルを求めて競合し、データベースのパフォーマンスが低下するおそれがあります。ユーザーのオブジェクトはSYSTEM
表領域に格納しないでください。これを回避するには、データベースに表領域が作成される際に、すべてのユーザーにデフォルトの表領域が割り当てられていることを確認します。 -
アプリケーションに関係する表をいろいろな表領域に無計画に格納すると、アプリケーションのデータ管理操作(バックアップやリカバリなど)に要する時間が増大する可能性があります。
親トピック: 表を管理するためのガイドライン
20.2.4 表作成のパラレル化
CREATE TABLE文で副問合せ(AS SELECT
)を使用して表を作成する際は、パラレル実行を使用できます。複数のプロセスが同時に動作して表を作成するため、表を作成するときのパフォーマンスが向上します。
表作成のパラレル化の説明は、「表作成のパラレル化」を参照してください。
親トピック: 表を管理するためのガイドライン
20.2.5 表作成時のNOLOGGINGの使用
表を最も効率よく作成するには、CREATE TABLE...AS SELECT文で
NOLOGGING
句を使用します。NOLOGGING
句を指定すると、表の作成中に最小限のREDO情報しか生成されません。
NOLOGGING
句を使用すると、次のような利点があります。
-
REDOログ・ファイルの領域を節約できます。
-
表の作成に要する時間が削減できます。
-
大規模な表のパラレル作成のパフォーマンスが向上します。
また、NOLOGGING
句を指定することで、SQL*Loaderを使用した後続のダイレクト・ロードおよびダイレクト・ロードINSERT
操作がロギングされなくなります。後続のデータ操作文(DML)文(UPDATE
、DELETE
および従来型パスの挿入)は、表のNOLOGGING
属性の影響を受けず、REDOを生成します。
表の作成後にその表の損失(たとえば、表の作成に使用したデータにアクセスできなくなるなど)を避ける必要がある場合は、作成直後に表のバックアップを取得してください。一時的に使用するために作成する表など、そのような予防策が不要な場合もあります。
一般に、NOLOGGING
を指定して表を作成するときは、小規模な表より大規模な表の方が相対的にパフォーマンスの向上が大きくなります。小規模な表の場合は、NOLOGGING
を指定しても、表作成に要する時間にほとんど影響はありません。一方、大規模な表では、特に表作成をパラレル化したときにもパフォーマンスが著しく向上します。
親トピック: 表を管理するためのガイドライン
20.2.6 表圧縮の使用
データベースのサイズが大きくなった場合、表圧縮を使用して領域を節約し、パフォーマンスを改善することを検討してください。
- 表圧縮について
圧縮を使用すると、ディスク領域が節約され、データベース・バッファ・キャッシュのメモリー使用が削減されて、読込み中の問合せ実行速度が大幅に向上します。 - 表圧縮に関連のある例
例を使用して表圧縮の使用方法を説明します。 - 圧縮とパーティション表
表には圧縮パーティションと非圧縮パーティションの両方を含めることができ、異なるパーティションでは異なる圧縮方法を使用できます。表に対する圧縮の設定とそのパーティションに対する設定が一致しない場合、パーティションについてはパーティションの設定が優先されます。 - 表が圧縮されているかどうかの確認
*_TABLES
データ・ディクショナリ・ビューで、圧縮表にはCOMPRESSION
列にENABLED
と表示されます。 - 圧縮されている行の確認
行の圧縮レベルを確認するには、DBMS_COMPRESSION
パッケージのGET_COMPRESSION_TYPE
ファンクションを使用します。 - 圧縮レベルの変更
パーティション、表または表領域の圧縮レベルは変更できます。 - 圧縮表の列の追加と削除
圧縮表に列を追加したり、圧縮表から列を削除する際には制限が適用されます。 - ハイブリッド列圧縮表のエクスポートおよびインポート
ハイブリッド列圧縮表は、データ・ポンプ・インポート・ユーティリティのimpdp
コマンドを使用してインポートできます。 - ハイブリッド列圧縮表のリストア
ハイブリッド列圧縮表をバックアップからリストアする必要がある場合があります。表はハイブリッド列圧縮をサポートしているシステム、またはハイブリッド列圧縮をサポートしていないシステムにリストアできます。 - 圧縮表に関するノートおよび制限事項
圧縮表に関するノートと制限事項を考慮してください。 - 圧縮表のパック
基本表圧縮またはハイブリッド列圧縮で圧縮した表で従来のDMLを使用すると、挿入および更新されるすべての行は非圧縮、または低レベルの圧縮形式で保存されます。このような行が圧縮されるように圧縮表をパックするには、ALTER
TABLE
MOVE
文を使用できます。
親トピック: 表を管理するためのガイドライン
20.2.6.1 表圧縮について
圧縮を使用すると、ディスク領域が節約され、データベース・バッファ・キャッシュのメモリー使用が削減されて、読込み中の問合せ実行速度が大幅に向上します。
圧縮には、データのロードやDMLのためのCPUオーバーヘッドがかかります。ただし、この負荷はI/O要件の削減によって相殺されます。圧縮された表データはメモリー内で圧縮されたままになるため、より多くの行をデータベース・バッファ・キャッシュ(および有効になっている場合はフラッシュ・キャッシュ)に収めることができ、圧縮によってDML操作のパフォーマンスを向上させることもできます。
表の圧縮は、アプリケーションに対して完全に透過的です。意思決定支援システム(DSS)、オンライン・トランザクション処理(OLTP)システムおよびアーカイブ・システムで役立ちます。
圧縮は、表領域、表またはパーティションに対して指定できます。表領域レベルで指定した場合、その表領域内に作成されるすべての表がデフォルトで圧縮されます。
Oracle Databaseでは、表の圧縮でいくつかの方法がサポートされます。これらの方法を表20-1にまとめます。
表20-1 表圧縮方法
表の圧縮方法 | 圧縮レベル | CPUオーバーヘッド | アプリケーション | ノート |
---|---|---|---|---|
基本表圧縮 |
高 |
最小 |
DSS |
なし。 |
高度な行圧縮 |
高 |
最小 |
OLTP、DSS |
なし。 |
ウェアハウス圧縮(ハイブリッド列圧縮) |
より高い |
より高い |
DSS |
圧縮レベルとCPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します。 |
アーカイブ圧縮(ハイブリッド列圧縮) |
最高 |
最高 |
アーカイブ |
圧縮レベルとCPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します。 |
基本表圧縮、ウェアハウス圧縮またはアーカイブ圧縮を使用する場合、圧縮はデータが表にバルク・ロードまたは配列挿入されるときにのみ実行されます。
基本表圧縮では、サポートされるデータ型およびSQL操作が制限されます。
高度な行圧縮はOLTPアプリケーション向けで、すべてのSQL操作によって操作されたデータを圧縮します。高度な行圧縮を使用する場合、圧縮は、表に対するデータの挿入、更新またはバルク・ロード中に実行されます。高度な行圧縮が許可される操作は次のとおりです。
-
単一行の挿入と更新
挿入および更新は即時に圧縮されません。すでに圧縮されているブロックを更新する場合、更新されない列は通常、圧縮されたままです。更新された列は、圧縮されていないブロックと同様に非圧縮形式で格納されます。更新された値は、ブロックがデータベース制御されたしきい値に達すると、再圧縮されます。挿入されたデータも、ブロック内のデータがデータベース制御されたしきい値に達すると、圧縮されます。
-
配列の挿入
配列挿入には、
APPEND
ヒントを使用しないINSERT INTO SELECT
のSQL文、およびPL/SQLやOracle Call Interface (OCI)などのプログラム・インタフェースからの配列の挿入があります。 -
次のダイレクト・パス
INSERT
方法-
ダイレクト・パスSQL*Loader
-
CREATE
TABLE
AS
SELECT
文 -
パラレル
INSERT
文 -
APPEND
またはAPPEND_VALUES
ヒントを指定したINSERT
文
これらのダイレクト・パス
INSERT
メソッドを使用した挿入は、すぐに圧縮されます。 -
ウェアハウス圧縮とアーカイブ圧縮では、ハイブリッド列圧縮テクノロジが使用されるため、最高の圧縮レベルが実現します。ハイブリッド列圧縮テクノロジでは、行優先ストレージではなく、修正された形式の列指向ストレージが使用されます。これにより、データベースでは、同様のデータをまとめて格納できるため、圧縮アルゴリズムの効率性が向上します。データを更新する場合、ハイブリッド列圧縮ではより多くのCPUが使用され、将来の更新を迅速に行うために、更新された行は行形式に移動されます。このような最適化が行われるため、更新頻度の低いデータにのみこの圧縮機能を使用してください。
より高い圧縮レベルのハイブリッド列圧縮は、ダイレクト・パス・インサートまたは配列挿入を使用したデータの場合のみ可能です。従来の挿入および更新もサポートされますが、その場合、行が列形式から行形式に移動され、圧縮レベルも低下します。自動データ最適化(ADO)ポリシーを使用して、これらの行をハイブリッド列圧縮の目的のレベルに自動的に戻すことができます。
ハイブリッド列圧縮(ウェアハウスとアーカイブ)で配列挿入をすぐに圧縮するには、次の条件を満たしている必要があります。
-
自動セグメント領域管理(ASSM)が有効なローカル管理表領域に、表が格納されている。
-
データベースの互換性レベルが12.2.0以上。
圧縮方法に関係なく、圧縮されたブロックに対するDELETE
操作は、圧縮されていないブロックに対するDELETE
操作と同じです。SQL DELETE
操作によってデータ・ブロックで取得される領域はすべて、後続のSQL INSERT
操作で再利用されます。ハイブリッド列圧縮テクノロジを使用すると、圧縮単位内の行がすべて削除された場合、圧縮単位内の領域は再利用に使用できます。
表20-2は、表の各圧縮方法の特徴を示しています。
表20-2 表の圧縮の特徴
表の圧縮方法 | CREATE/ALTER TABLEの構文 | ダイレクト・パス挿入または配列挿入 | ノート |
---|---|---|---|
基本表圧縮 |
|
行は基本表圧縮方式で圧縮されます。 |
ダイレクト・パス・インサートまたは配列挿入を使用せずに挿入された行および更新された行は圧縮されません。 |
高度な行圧縮 |
|
行は高度な行圧縮方式で圧縮されます。 |
ダイレクト・パス・インサートまたは配列挿入の使用に関係なく、挿入された行と更新された行は高度な行圧縮を使用して圧縮されます。 |
ウェアハウス圧縮(ハイブリッド列圧縮) |
|
行はウェアハウス圧縮方式で圧縮されます。 |
この圧縮方式は高いCPUオーバーヘッドが発生する可能性があります。 更新された行およびダイレクト・パス・インサートまたは配列挿入を使用せずに挿入された行は、列形式ではなく行形式で格納されるため、圧縮レベルが低下します。 |
アーカイブ圧縮(ハイブリッド列圧縮) |
|
行はアーカイブ圧縮方式で圧縮されます。 |
この圧縮方式は高いCPUオーバーヘッドが発生する可能性があります。 更新された行およびダイレクト・パス・インサートまたは配列挿入を使用せずに挿入された行は、列形式ではなく行形式で格納されるため、圧縮レベルが低下します。 |
表圧縮の指定には、CREATE
TABLE
文のCOMPRESS
句を使用します。既存の表で圧縮を有効にするには、ALTER
TABLE
文でこれらの句を使用します。この場合、圧縮を使用可能にした後で挿入または更新されたデータのみが圧縮されます。ALTER
TABLE
MOVE
文を使用した場合にも、挿入および更新されたデータの圧縮が有効になりますが、この文では既存のデータも圧縮されます。同様に、ALTER
TABLE
...NOCOMPRESS
文を使用すると、既存の圧縮表に対する表圧縮を使用禁止にできます。この場合、すでに圧縮されているすべてのデータは圧縮されたままですが、新規データは圧縮されずに挿入されます。
COLUMN STORE COMPRESS FOR QUERY HIGH
オプションは、デフォルトのデータ・ウェアハウス圧縮モードです。Exadataストレージでハイブリッド列圧縮を使用する場合に、高い圧縮レベルと優れたパフォーマンスが実現します。COLUMN STORE COMPRESS FOR QUERY LOW
オプションは、ロード・パフォーマンスが非常に重要な環境で使用する必要があります。このオプションでは、COLUMN STORE COMPRESS FOR QUERY HIGH
オプションで圧縮されたデータより高速にロードが行われます。
COLUMN STORE COMPRESS FOR ARCHIVE LOW
オプションは、デフォルトのアーカイブ圧縮モードです。これにより、高い圧縮レベルが実現し、頻繁にアクセスしないデータに最適です。めったにアクセスされないデータに対しては、COLUMN STORE COMPRESS FOR ARCHIVE HIGH
オプションを使用する必要があります。
DBMS_COMPRESSION
パッケージで提供される圧縮アドバイザを使用すると、特定の表に特定の圧縮方法を適用したときに予想される圧縮レベルを確認できます。
ノート:
ハイブリッド列圧縮は、基礎となるストレージ・システムに依存します。詳細は、『Oracle Databaseライセンス情報』を参照してください。
関連項目:
-
表圧縮の概要は、『Oracle Database概要』を参照してください。
親トピック: 表圧縮の使用
20.2.6.2 表圧縮に関連のある例
表圧縮の使用例を示します。
例20-1 高度な行圧縮を使用した表の作成
次の例では、表orders
に対して高度な行圧縮を使用可能にします。
CREATE TABLE orders ... ROW STORE COMPRESS ADVANCED;
orders
表のデータは、ダイレクト・パスINSERT
、配列挿入および従来のDMLで圧縮されます。
例20-2 基本表圧縮を使用した表の作成
次に示す同等の文では、データ・ウェアハウス内のファクト表であるsales_history
表に対して基本表圧縮を使用可能にします。
CREATE TABLE sales_history ... ROW STORE COMPRESS BASIC; CREATE TABLE sales_history ... ROW STORE COMPRESS;
この表には問合せが頻繁に実行されますが、DMLの実行は想定されていません。
例20-3 ダイレクト・パス・インサートを使用した表への行の挿入
この例では、ダイレクト・パスINSERT
を使用してsales_history
表に行を挿入する場合にAPPEND
ヒントを使用する方法を示しています。
INSERT /*+ APPEND */ INTO sales_history SELECT * FROM sales WHERE cust_id=8890; COMMIT;
例20-4 配列挿入を使用した表への行の挿入
この例では、SQLで配列挿入を使用して、sales_history
表に行を挿入しています。
INSERT INTO sales_history SELECT * FROM sales WHERE cust_id=8890; COMMIT;
この例では、PL/SQLで配列挿入を使用して、hr.jobs_test
表に行を挿入しています。
DECLARE TYPE table_def IS TABLE OF hr.jobs%ROWTYPE; array table_def := table_def(); BEGIN SELECT * BULK COLLECT INTO array FROM hr.jobs; FORALL i in array.first .. array.last INSERT INTO hr.jobs_test VALUES array(i); COMMIT; END; /
ノート:
ハイブリッド列圧縮(ウェアハウスとアーカイブ)を使用する場合は、SQL、PL/SQLまたはOCIで配列挿入を実行して即座に圧縮するには、自動セグメント領域管理(ASSM)が有効なローカル管理表領域に表が格納されており、データベースの互換性レベルが12.2.0以上である必要があります。
例20-5 ウェアハウス圧縮を使用した表の作成
この例では、表sales_history
でハイブリッド列圧縮を使用可能にします。
CREATE TABLE sales_history ... COLUMN STORE COMPRESS FOR QUERY;
表は、デフォルトのCOLUMN STORE COMPRESS FOR QUERY HIGH
オプションを使用して作成されます。このオプションは、基本表圧縮または高度な行圧縮よりも高レベルの圧縮を実現します。問合せが頻繁に表に対して実行され、DMLが予期されない場合に適しています。
例20-6 アーカイブ圧縮を使用した表の作成
次の例では、表sales_history
でハイブリッド列圧縮を使用可能にします。
CREATE TABLE sales_history ... COLUMN STORE COMPRESS FOR ARCHIVE;
表は、デフォルトのCOLUMN STORE COMPRESS FOR ARCHIVE LOW
オプションを使用して作成されます。このオプションは、基本圧縮、高度な行圧縮またはウェアハウス圧縮よりも高レベルの圧縮を実現します。ロード・パフォーマンスが非常に重要であり、データへのアクセスが頻繁でない場合に適しています。デフォルトのCOLUMN STORE COMPRESS FOR ARCHIVE LOW
オプションでは、COLUMN STORE COMPRESS FOR ARCHIVE HIGH
オプションより低レベルの圧縮を実現します。
親トピック: 表圧縮の使用
20.2.6.3 圧縮とパーティション表
表には圧縮パーティションと非圧縮パーティションの両方を含めることができ、異なるパーティションでは異なる圧縮方法を使用できます。表に対する圧縮の設定とそのパーティションに対する設定が一致しない場合、パーティションについてはパーティションの設定が優先されます。
パーティションの圧縮方法を変更するには、次のどちらかを実行します。
-
新しいデータのみの圧縮方法を変更するには、
ALTER
TABLE
...MODIFY
PARTITION
...COMPRESS
...を使用します。 -
新しいデータと既存のデータの両方の圧縮方法を変更するには、
ALTER
TABLE
...MOVE
PARTITION
...COMPRESS
...または表のオンライン再定義のどちらかを使用します。
これらの文を実行する場合は、圧縮方法を指定します。たとえば、次の文を実行して、新規データと既存データの両方の圧縮方式を高度な行圧縮に変更します。
ALTER TABLE ... MOVE PARTITION ... ROW STORE COMPRESS ADVANCED...
親トピック: 表圧縮の使用
20.2.6.4 表が圧縮されているかどうかの確認
*_TABLES
データ・ディクショナリ・ビューで、圧縮表にはCOMPRESSION
列にENABLED
と表示されます。
パーティション表では、この列はNULLですが、*_TAB_PARTITIONS
ビューのCOMPRESSION
列に、圧縮されているパーティションが表示されます。また、COMPRESS_FOR
列には、表またはパーティションで使用中の圧縮方法が表示されます。
SQL> SELECT table_name, compression, compress_for FROM user_tables; TABLE_NAME COMPRESSION COMPRESS_FOR ---------------- ------------ ----------------- T1 DISABLED T2 ENABLED BASIC T3 ENABLED ADVANCED T4 ENABLED QUERY HIGH T5 ENABLED ARCHIVE LOW
SQL> SELECT table_name, partition_name, compression, compress_for FROM user_tab_partitions; TABLE_NAME PARTITION_NAME COMPRESSION COMPRESS_FOR ----------- ---------------- ----------- ------------------------------ SALES Q4_2004 ENABLED ARCHIVE HIGH ... SALES Q3_2008 ENABLED QUERY HIGH SALES Q4_2008 ENABLED QUERY HIGH SALES Q1_2009 ENABLED ADVANCED SALES Q2_2009 ENABLED ADVANCED
親トピック: 表圧縮の使用
20.2.6.5 圧縮されている行の確認
行の圧縮レベルを確認するには、DBMS_COMPRESSION
パッケージのGET_COMPRESSION_TYPE
ファンクションを使用します。
たとえば、次の問合せは、hr.employees
表の行の圧縮タイプを返します。
SELECT DECODE(DBMS_COMPRESSION.GET_COMPRESSION_TYPE( ownname => 'HR', tabname => 'EMPLOYEES', subobjname => '', row_id => 'AAAVEIAAGAAAABTAAD'), 1, 'No Compression', 2, 'Advanced Row Compression', 4, 'Hybrid Columnar Compression for Query High', 8, 'Hybrid Columnar Compression for Query Low', 16, 'Hybrid Columnar Compression for Archive High', 32, 'Hybrid Columnar Compression for Archive Low', 4096, 'Basic Table Compression', 'Unknown Compression Type') compression_type FROM DUAL;
関連項目:
GET_COMPRESSION_TYPE
の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: 表圧縮の使用
20.2.6.6 圧縮レベルの変更
パーティション、表または表領域の圧縮レベルは変更できます。
たとえば、ある企業でその売上データにウェアハウス圧縮を使用している一方で、6か月より古い売上データにはめったにアクセスしないとします。売上データがその経過時間に基づいてパーティション化された表に格納されている場合、古いデータの圧縮レベルをアーカイブ圧縮に変更して、ディスク領域を解放できます。
パーティションまたはサブパーティションの圧縮レベルを変更するには、次の文を使用できます。
-
ALTER
TABLE
...
MOVE
PARTITION
...
ONLINE
-
ALTER
TABLE
...
MOVE
SUBPARTITION
...
ONLINE
この2つの文では、ONLINE
キーワードがサポートされており、移動中のパーティションまたはサブパーティションに対してDML操作を中断なく実行できます。これらの文では、パーティションまたはサブパーティションの移動中に更新されたすべての索引も自動的に保持します。ALTER TABLE...MODIFY PARTITION
文またはオンライン再定義を使用して、パーティションの圧縮レベルを変更することもできます。
表がパーティション化されていない場合、ALTER TABLE...MOVE...COMPRESS FOR...
文を使用して圧縮レベルを変更できます。ALTER TABLE...MOVE
文では、コマンドの実行中に表に対するDML文は許可されません。ただし、オンライン再定義を使用して表を圧縮することもでき、これにより、再定義中でも問合せおよびDML文で表を使用できるようになります。
表領域の圧縮レベルを変更するには、ALTER TABLESPACE
文を使用します。
関連項目:
-
ALTER TABLE
コマンドの詳細は、「新規セグメントまたは表領域への表の移動」を参照してください -
DBMS_REDEFINITION
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: 表圧縮の使用
20.2.6.7 圧縮表の列の追加と削除
圧縮表に列を追加したり、圧縮表から列を削除する際には制限が適用されます。
圧縮表に列を追加する場合、次の制限が適用されます。
-
高度な行圧縮、ウェアハウス圧縮およびアーカイブ圧縮: 追加された列にデフォルト値が指定され、表がすでに移入されている場合、最適化された追加列動作の条件を満たしている必要があります。これらの条件については、『Oracle Database SQL言語リファレンス』を参照してください。
圧縮表の列を削除する場合、次の制限が適用されます。
-
基本表圧縮: 列の削除はサポートされていません。
-
高度な行圧縮、ウェアハウス圧縮およびアーカイブ圧縮:
DROP
COLUMN
はサポートされていますが、長時間実行される解凍と再圧縮の操作を避けるために、データベースでは列が内部的にUNUSED
に設定されます。
親トピック: 表圧縮の使用
20.2.6.8 ハイブリッド列圧縮表のエクスポートおよびインポート
ハイブリッド列圧縮表は、データ・ポンプのインポート・ユーティリティのimpdp
コマンドを使用してインポートできます。
デフォルトでは、impdp
コマンドは表プロパティを保存し、インポートされた表はハイブリッド列圧縮表となります。ハイブリッド列圧縮をサポートしていない表領域では、impdp
コマンドは失敗し、エラーが表示されます。表はexpdp
コマンドでエクスポートすることもできます。
ハイブリッド列圧縮表は、impdp
コマンドのTRANSFORM:SEGMENT_ATTRIBUTES=n
オプション句を使用して、非圧縮表としてインポートできます。
非圧縮表または高度な行圧縮表は、インポート中にハイブリッド列圧縮形式に変換できます。ハイブリッド列圧縮表でない表をハイブリッド列圧縮表に変換するには、次のようにします。
ALTER TABLESPACE ... SET DEFAULT COMPRESS
コマンドを使用して、表領域のデフォルト圧縮を指定します。- インポート中にインポートされた表の
SEGMENT_ATTRIBUTES
オプションを上書きします。
関連項目:
-
データ・ポンプのインポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。
-
ALTER TABLESPACE
コマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 表圧縮の使用
20.2.6.9 ハイブリッド列圧縮表のリストア
ハイブリッド列圧縮表をバックアップからリストアする必要がある場合があります。表はハイブリッド列圧縮をサポートしているシステム、またはハイブリッド列圧縮をサポートしていないシステムにリストアできます。
ハイブリッド列圧縮が含まれる表をハイブリッド列圧縮をサポートしているシステムにリストアする場合は、通常どおり、Oracle Recovery Manager (RMAN)を使用してファイルをリストアします。
ハイブリッド列圧縮表がハイブリッド列圧縮をサポートしていないシステムにリストアされている場合は、表をハイブリッド列圧縮から高度な行圧縮形式または非圧縮形式に変換する必要があります。表をリストアするには、次のようにします。
関連項目:
-
RMANの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
-
ALTER TABLE
コマンドの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 表圧縮の使用
20.2.6.10 圧縮表に関するノートおよび制限事項
圧縮表に関連するノートと制限事項を考慮してください。
圧縮表に関して、次のノートや制限があります。
-
次のタイプの表では、高度な行圧縮、ウェアハウス圧縮およびアーカイブ圧縮はサポートされません。
-
索引構成表
-
外部表
-
LONG
列またはLONG RAW
列を含む表 -
一時表
-
ROWDEPENDENCIES
が有効な表 -
クラスタ表
-
-
次の圧縮メソッドで圧縮された表では、オンラインのセグメント縮小はサポートされません。
-
ROW STORE COMPRESS BASIC
を使用した基本表圧縮 -
COLUMN STORE COMPRESS FOR QUERY
を使用したウェアハウス圧縮 -
COLUMN STORE COMPRESS FOR ARCHIVE
を使用したアーカイブ圧縮
-
-
この項で説明する表圧縮方法は、SecureFilesラージ・オブジェクト(LOB)には適用されません。SecureFiles LOBには独自の圧縮方法があります。詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
-
圧縮テクノロジではCPUを使用します。追加の負荷を処理するために使用可能なCPUが十分にあることを確認する必要があります。
-
基本表圧縮で作成された表では、特に指定しないかぎり、
PCT_FREE
パラメータが自動的に0
(ゼロ)に設定されます。
親トピック: 表圧縮の使用
20.2.6.11 圧縮表のパック
基本表圧縮またはハイブリッド列圧縮で圧縮した表で従来のDMLを使用すると、挿入および更新されるすべての行は非圧縮、または低レベルの圧縮形式で保存されます。このような行が圧縮されるように圧縮表をパックするには、ALTER
TABLE
MOVE
文を使用できます。
この操作には表の排他ロックが必要なため、この操作が完了するまで更新とロードを実行しないでください。このような状況が望ましくない場合は、表のオンライン再定義を使用できます。
パーティションまたはサブパーティションを移動する場合、移動中のパーティションまたはサブパーティションに対してDML操作の実行を中断して、ALTER
TABLE
MOVE
文を使用してパーティションまたはサブパーティションを圧縮できます。
関連項目:
-
制限事項を含む
ALTER
TABLE
...COMPRESS
文およびALTER
TABLE
...MOVE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 -
表のパーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
-
表、パーティションまたはサブパーティションの移動の詳細は、「新規セグメントおよび表領域への表の移動」を参照してください
親トピック: 表圧縮の使用
20.2.7 Enterprise Manager Cloud Controlを使用した表圧縮の管理
Oracle Enterprise Manager Cloud Controlで、表の圧縮を管理できます。
- 表圧縮とEnterprise Manager Cloud Control
Enterprise Managerには、データベースおよび表領域レベルの圧縮の機能を要約する複数の集中圧縮ページが表示され、様々な圧縮ページへのリンクが含まれます。「圧縮」ページには、データベースおよび表領域レベルで圧縮された記憶域のサマリーが表示されます。 - データベース・レベルの圧縮サマリーの表示
データベース・レベルで圧縮サマリー情報を表示できます。 - 表領域レベルの圧縮サマリーの表示
表領域レベルで圧縮サマリー情報を表示できます。 - 圧縮率の見積り
特定のオブジェクトの圧縮率を計算するために、圧縮アドバイザを実行できます。 - オブジェクトの圧縮
表などのオブジェクトを圧縮できます。 - 圧縮アドバイスの表示
セグメント・アドバイザから圧縮アドバイスを表示し、それらに基づいてアクションを実行できます。 - オブジェクトでの自動データ最適化の開始
オブジェクトに対する自動データ最適化を開始できます。
親トピック: 表を管理するためのガイドライン
20.2.7.1 表圧縮とEnterprise Manager Cloud Control
Enterprise Managerには、データベースおよび表領域レベルの圧縮の機能を要約する複数の集中圧縮ページが表示され、様々な圧縮ページへのリンクが含まれます。「圧縮」ページには、データベースおよび表領域レベルで圧縮された記憶域のサマリーが表示されます。
データベースの圧縮サマリー・ページには、データベース・レベルに応じて、データベースの合計サイズ(圧縮と未圧縮の両方のオブジェクトすべての合計サイズ)、データベースの圧縮オブジェクトの合計サイズ、データベースの未圧縮オブジェクトの合計サイズ、および圧縮オブジェクトの合計サイズとデータベースの合計サイズの比率が表示されます。これには、データベース内で圧縮されている記憶域の量に関する概略が提供されます。表示される情報に基づいてアクションを実行できます。
同様に、表領域の圧縮サマリー・ページには、表領域レベルに応じて、表領域の合計サイズ(圧縮と未圧縮の両方のオブジェクトすべての合計サイズ)、表領域の圧縮オブジェクトの合計サイズ、表領域の未圧縮オブジェクトの合計サイズ、および圧縮オブジェクトの合計サイズと表領域の合計サイズの比率が表示されます。
圧縮機能を使用すると、次のタスクを実行できます。
-
データベースレベルの上位100の表領域および表領域レベルの上位100のオブジェクトで、圧縮された記憶域のサマリーを表示します。表領域の合計サイズ、表領域の圧縮サイズ、表領域の未圧縮サイズ、および表領域内で圧縮された記憶域の割合を含む、最も大きいデータベース記憶域を使用する上位100の各表領域内で圧縮された記憶域の量のサマリーを表示できます。表示された情報に基づいて、圧縮タスクを実行できます。
-
表、索引、LOB (ラージ・オブジェクト)およびDBFS (Oracle Database File System)の4つのオブジェクト・タイプの各圧縮タイプ別に、圧縮された記憶域のサイズを表示します。
-
特定のオブジェクトの圧縮率を計算します。
-
オブジェクト(表領域、表、パーティションまたはLOB)を圧縮します。これにより、記憶域を節約できます。圧縮アドバイザを実行して、保存可能な記憶域の量を確認し、オブジェクトで圧縮アクションを実行できます。
-
セグメント・アドバイザから圧縮アドバイスを表示します。セグメント・アドバイザへのリンクにアクセスして、セグメントを圧縮できます。
20.2.7.4 圧縮率の見積り
特定のオブジェクトの圧縮率を計算するために、圧縮アドバイザを実行できます。
ジョブが即時実行またはスケジュールされ、「表領域内の上位100のオブジェクトの圧縮サマリー」ページに戻ります。
20.2.8 セグメント・レベルおよび行レベルの圧縮層の使用
セグメント・レベルの圧縮層を使用すると、表内のセグメント・レベルで圧縮を指定できます。行レベルの圧縮層を使用すると、表内の行レベルで圧縮を指定できます。同じ表でこれらの組合せを使用して、表内のデータが格納および管理される方法を細かく制御できます。
セグメントおよび行に対するユーザー変更は時間の経過に伴って変化するため、それらのユーザー変更の圧縮レベルを変更することは、多くの場合、効果的です。たとえば、一部のセグメントおよび行がデータベースに追加された後、短期間は頻繁に変更されるが、時間の経過に伴って変更の頻度が低下することがあります。
圧縮層を使用すると、ルールに基づいて、どのセグメントおよび行を圧縮するかを指定できます。たとえば、2週間変更されていない行を高度な行圧縮方式で圧縮することを指定できます。また、6か月間変更されていないセグメントをウェアハウス圧縮方式で圧縮することを指定できます。
セグメント・レベルおよび行レベルの圧縮層を使用する前に、次の前提条件を満たしている必要があります。
-
HEAT_MAP
初期化パラメータをON
に設定する必要があります。 -
COMPATIBLE
初期化パラメータは12.0.0
以上に設定されている必要があります。
セグメント・レベルの圧縮層または行レベルの圧縮層を使用するには、次のいずれかのSQL文を実行し、ルールを指定する自動データ最適化(ADO)ポリシーを含めます。
-
CREATE
TABLE
-
ALTER
TABLE
例20-7 行レベルの圧縮層
この例では、oe.orders
表に対して行レベルの圧縮層を指定します。変更なしで14日が経過した後、Oracle Databaseによって、ウェアハウス(QUERY
)圧縮を使用して行が圧縮されます。
ALTER TABLE oe.orders ILM ADD POLICY COLUMN STORE COMPRESS FOR QUERY ROW AFTER 14 DAYS OF NO MODIFICATION;
例20-8 セグメント・レベルの圧縮層
この例では、oe.order_items
表に対してセグメント・レベルの圧縮層を指定します。Oracle Databaseでは、セグメント内の行の変更またはセグメント内の行にアクセスする問合せが行われずに6か月間経過すると、アーカイブ(ARCHIVE
HIGH
)圧縮を使用してセグメントが圧縮されます。
ALTER TABLE oe.order_items ILM ADD POLICY COLUMN STORE COMPRESS FOR ARCHIVE HIGH SEGMENT AFTER 6 MONTHS OF NO ACCESS;
ノート:
これらの例では、基礎となるストレージ・システムに依存するハイブリッド列圧縮が指定されています。詳細は、『Oracle Databaseライセンス情報』を参照してください。
関連項目:
-
様々な圧縮レベルの詳細は、「表圧縮の使用」を参照してください
-
セグメント・レベルの圧縮層と行レベルの圧縮層の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
親トピック: 表を管理するためのガイドライン
20.2.9 属性クラスタ表の使用
属性クラスタ化表は、ユーザー指定のクラスタリング・ディレクティブに基づいて近接度の近いデータをディスク上に格納する、ヒープ構成表です。
ノート:
この機能は、Oracle Database 12cリリース1 (12.1.0.2)以降で使用可能です。
ディレクティブは次のようになります。
-
CLUSTERING
...
BY
LINEAR
ORDER
ディレクティブは、指定の列に従って表のデータを並べます。問合せでクラスタリング句に指定された列の接頭辞を修飾とする場合、
BY
LINEAR
ORDER
クラスタリング(デフォルト)が最適です。たとえば、sh.sales
の問合せで、顧客IDまたは顧客IDと製品IDの両方を指定する場合、線形の列順序cust_id
、prod_id
を使用して、表のデータをクラスタ化できます。指定の列は、複数の表に存在してもかまいません。 -
CLUSTERING
...
BY
INTERLEAVED
ORDER
ディレクティブは、複数列I/Oの削減を可能にするz-order関数のような特殊なアルゴリズムを使用して1つ以上の表のデータを並べます。問合せで様々な列の組合せを指定する場合、
BY
INTERLEAVED
ORDER
クラスタリングが最適です。列は、1つ以上の表に存在してもかまいません。たとえば、sh.sales
の問合せで様々な順序で異なるディメンションを指定する場合、そのディメンションの列に従ってsales
表のデータをクラスタ化できます。
属性クラスタリングは次のタイプの操作で使用できます。
-
ダイレクト・パス
INSERT
「ダイレクト・パス・インサートを使用したINSERTパフォーマンスの向上」を参照してください。
-
オンライン再定義
「表のオンライン再定義」を参照してください。
-
ALTER
TABLE
...
MOVE
操作などのデータ移動操作「新規セグメントまたは表領域への表の移動」を参照してください。
-
ALTER
TABLE
...
MERGE
PARTITION
操作などの、新しいセグメントを作成するパーティション・メンテナンス操作詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
属性クラスタリングは、従来のDMLでは無視されます。
属性クラスタ表には次の利点があります。
-
属性クラスタリングが一般的な索引アクセスと連携している場合、表参照では、より最適化された単一ブロックI/Oが可能です。たとえば、属性クラスタリング用に選択した先頭列での索引範囲スキャンでは、最適化されたI/Oが可能です。
-
データ順序付けにより、Exadata記憶域索引に対するより最適なプルーニングおよびインメモリー最小/最大プルーニングが可能になります。
-
他の表から結合された属性に基づいて、ファクト表をクラスタ化できます。
-
属性クラスタリングによってデータ圧縮が改善でき、この方法で表スキャンのコストが間接的に改善されます。ディスク上で同じ値が互いに接近している場合、データベースでは、これらの値を容易に圧縮できます。
データ・ウェアハウス環境では属性クラスタ表がよく使用されますが、このような利点を享受できるどの環境でも、この表は有用です。CREATE
TABLE
SQL文でCLUSTERING
句を使用して属性クラスタ表を作成します。
関連項目:
-
属性クラスタ表の概念は、『Oracle Database概要』を参照してください。
-
属性クラスタ化表の使用の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください
親トピック: 表を管理するためのガイドライン
20.2.10 ゾーン・マップの使用
ゾーンとは、ディスク上の連続したデータ・ブロックのセットです。ゾーン・マップでは、個々のゾーンすべてについて、指定された列の最小値および最大値を追跡管理します。
ノート:
この機能は、Oracle Database 12cリリース1 (12.1.0.2)以降で使用可能です。
ゾーン・マップに格納されている列に関する述語がSQL文に含まれている場合、データベースでは、述語の値をゾーンに格納されている最小値および最大値と比較して、SQL実行時にどのゾーンを読み取るかを判断します。ゾーン・マップの主要な利点は、表スキャンのI/O削減です。I/Oは、問合せ結果で不要な表ブロックをスキップすると減ります。CREATE
MATERIALIZED
ZONEMAP
SQL文を使用してゾーン・マップを作成します。
表で属性クラスタリングが指定されている場合は常に、クラスタ列に関するゾーン・マップを自動的に作成できます。クラスタリングのために、列の最小値および最大値は属性クラスタ表の連続するデータ・ブロックと相関するため、関連付けられたゾーン・マップを使用してより効果的なI/Oプルーニングが可能になります。
ノート:
ゾーン・マップおよび属性クラスタ表は、一緒に使用することも、別々に使用することもできます。
関連項目:
-
ゾーン・マップの概念は、『Oracle Database概要』を参照してください。
-
ゾーン・マップの使用の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。
-
CREATE
MATERIALIZED
ZONEMAP
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 表を管理するためのガイドライン
20.2.11 インメモリー列ストアへの表の格納
インメモリー列ストアは、システム・グローバル領域(SGA)のオプション部分で、高速スキャン用に最適化された表、表パーティション、その他のデータベース・オブジェクトのコピーが格納されます。インメモリー列ストアでは、表データがSGAに行ではなく列ごとに格納されます。
ノート:
この機能は、Oracle Database 12cリリース1 (12.1.0.2)以降で使用可能です。
20.2.12 不可視の列の使用
表を使用するアプリケーションを中断することなく、表に変更を加える場合、不可視の列を使用できます。
- 不可視の列の理解
表の列を個々に不可視にできます。表の一般的なアクセスでは、表の不可視の列は表示されません。 - 不可視の列と列の順序
不可視の列と列の順序については、特別な考慮事項があります。
親トピック: 表を管理するためのガイドライン
20.2.12.1 不可視の列の理解
表の個々の列を不可視にできます。表の一般的なアクセスでは、表の不可視の列は表示されません。
たとえば、次の操作では、不可視の列は出力に表示されません。
-
SQLの
SELECT
*
FROM
文 -
SQL*Plusの
DESCRIBE
コマンド -
PL/SQLの
%ROWTYPE
属性宣言 -
Oracle Call Interface (OCI)の説明
列リストで不可視の列を明示的に指定した場合にのみ、SELECT
文を使用して不可視の列の出力を表示できます。同様に、INSERT
文の列リストで不可視の列を明示的に指定した場合にのみ、不可視の列に値を挿入できます。INSERT
文の列リストを省略した場合、その文では可視の列にのみ値を挿入できます。
表の作成中または表に列を追加するときに列を不可視にでき、後で、表を変更して、不可視にした列を可視にできます。また、表を変更して、可視の列を不可視にすることもできます。
表を使用するアプリケーションを中断しないで表を変更する場合に、不可視の列を使用することがあります。表に不可視の列を追加した後、不可視の列にアクセスする必要がある問合せおよびその他の操作では、名前で明示的にその列を参照する必要があります。不可視の列が考慮されるアプリケーションを移行するとき、不可視の列を可視にできます。
仮想列は不可視にできます。また、表を作成するときに、不可視の列をパーティション化キーとして使用することもできます。
不可視の列には、次の制限が適用されます。
-
次のタイプの表に不可視の列を含めることはできません。
-
外部表
-
クラスタ表
-
一時表
-
-
ユーザー定義型の属性は不可視にできません。
ノート:
不可視の列は、システム生成の非表示列とは同じではありません。不可視の列を可視にすることはできますが、非表示列を可視にすることはできません。
関連項目:
親トピック: 不可視の列の使用
20.2.12.2 不可視の列と列の順序
不可視の列と列の順序については、特別な考慮事項があります。
データベースでは、通常、CREATE
TABLE
文でリストされた順序で列が格納されます。表に新しい列を追加すると、その新しい列は表の列順の最後の列になります。
表に1つ以上の不可視の列が含まれている場合、不可視の列は表の列順には含まれません。表のすべての列にアクセスする場合は、列の順序が重要となります。たとえば、SELECT
*
FROM
文では、表の列順で列が表示されます。不可視の列は表のこのタイプの汎用アクセスには含まれないため、列順に含まれません。
不可視の列を可視にすると、その列は表の列順に最後の列として含められます。可視の列を不可視にした場合、不可視の列は列順に含められないため、表の可視の列の順序が並べ替えられることがあります。
たとえば、不可視の列のある次の表を考えてみます。
CREATE TABLE mytable (a INT, b INT INVISIBLE, c INT);
列b
は不可視であるため、この表の列順は次のようになります。
列 | 列の順序 |
---|---|
|
1 |
|
2 |
次に、列b
を可視にします。
ALTER TABLE mytable MODIFY (b VISIBLE);
列b
を可視にすると、列bは表の列順の最後の列になります。したがって、表の列順は次のようになります。
列 | 列の順序 |
---|---|
|
1 |
|
2 |
|
3 |
不可視の列を含む表の列順を示す別の例を考えてみます。次の表には、不可視の列は含まれていません。
CREATE TABLE mytable2 (x INT, y INT, z INT);
この表の列順は次のようになります。
列 | 列の順序 |
---|---|
|
1 |
|
2 |
|
3 |
次に、列y
を不可視にします。
ALTER TABLE mytable2 MODIFY (y INVISIBLE);
列y
を不可視にすると、列y
は表の列順に含まれなくなるため、列z
の列順が変更されます。したがって、表の列順は次のようになります。
列 | 列の順序 |
---|---|
|
1 |
|
2 |
列y
を再び可視にします。
ALTER TABLE mytable2 MODIFY (y VISIBLE);
列y
は表の列順の最後になります。
列 | 列の順序 |
---|---|
|
1 |
|
2 |
|
3 |
親トピック: 不可視の列の使用
20.2.13 機密データを格納する列の暗号化
機密データを格納する個々の表の列を暗号化できます。機密データには、社会保障番号、クレジット・カード番号、医療記録などがあります。列の暗号化は、アプリケーションに対して完全に透過的ですが、いくつか制限事項があります。
暗号化は、セキュリティの問題をすべて解決するわけではありませんが、ユーザーがデータベースのセキュリティ機能を迂回して、オペレーティング・システムのファイル・システムから直接データベース・ファイルにアクセスしようとした場合に、そのユーザーからデータを保護します。
列暗号化はOracle Databaseの透過的データ暗号化機能を使用しますが、この機能を使用するには、データベースのマスター暗号化キーを保存するためにキーストアを作成する必要があります。暗号化列を含む表を作成する場合、および暗号化データを格納または取得する場合は、キーストアがオープンしている必要があります。キーストアは、オープンするとすべてのセッションで使用可能になり、明示的にクローズするか、データベースが停止されるまではオープンしたままになります。
透過的データ暗号化では、次のタイプの暗号化アルゴリズム(Advanced Encryption Standard (AES)アルゴリズム、Triple Data Encryption Standard (3DES)アルゴリズムなど)を含む、業界標準の暗号化アルゴリズムがサポートされています。
-
Advanced Encryption Standard(AES)
-
ARIA
-
GHOST
-
SEED
-
Triple Data Encryption Standard
サポートされる暗号化アルゴリズムの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
使用するアルゴリズムは表の作成時に選択します。表のすべての暗号化列で同じアルゴリズムが使用されます。デフォルトはAES192です。暗号化キーの長さはアルゴリズム名で示されています。たとえば、AES128アルゴリズムでは128ビットのキーが使用されます。
1つ以上の表にある多数の列を暗号化する場合は、かわりに表領域全体を暗号化してその表領域にこれらの表を格納することも考慮できます。表領域の暗号化でも同様に透過的データ暗号化機能が使用されますが、物理的なブロック・レベルで暗号化されるため、多数の列を暗号化するよりパフォーマンスが向上します。表領域レベルで暗号化する別の理由は、列暗号化の次の制限事項に対処するためです。
-
オブジェクト・データ型などの特定のデータ型は、列暗号化ではサポートされていません。
-
暗号化列がある表が含まれた表領域に対しては、トランスポータブル表領域機能を使用できません。
-
その他の制限の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
関連項目:
-
透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
-
キーストアの作成およびオープンの手順は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
-
CREATE
TABLE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 -
Oracle Real Application Clusters環境でのキーストアの使用方法は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
親トピック: 表を管理するためのガイドライン
20.2.14 セグメント作成の遅延の理解
ローカルで管理される表領域内にヒープ構成表を作成すると、最初の行が挿入されるまで表セグメントの作成が遅延されます。
さらに、セグメントの作成は、表のすべてのLOB列、表作成の一環として暗黙的に作成されたすべての索引、および後から明示的にその表に作成されたすべての索引に対して遅延されます。
この領域割当て方法の利点は次のとおりです。
-
インストール時に何百もの表が作成され、その表の多くに一度もデータが移入されないようなアプリケーションで、ディスク領域が大幅に削減されます。
-
アプリケーションのインストール時間が短縮されます。
最初の行が挿入される際に新しいセグメントを作成する必要があるため、パフォーマンスが多少低下します。
セグメント作成の遅延を有効にするには、互換性を11.2.0
以上に設定する必要があります。
CREATE
TABLE
文に新たに導入された句は、次のとおりです。
-
SEGMENT
CREATION
DEFERRED
-
SEGMENT
CREATION
IMMEDIATE
これらの句は、セグメントの作成を遅延するDEFERRED_SEGMENT_CREATION
初期化パラメータのデフォルト設定であるTRUE
を上書きします。セグメントの作成の遅延を無効にするには、このパラメータをFALSE
に設定します。
セグメント作成を遅延する設定で表を作成すると、新しい表が*_TABLES
ビューに表示されますが、その表のエントリは最初の行を入力するまで*_SEGMENTS
ビューに表示されません。
セグメント作成の遅延を確認するには、非パーティション表の場合は*_TABLES
、*_INDEXES
、*_LOBS
の各ビュー、パーティション表の場合は*_TAB_PARTITIONS
、*_IND_PARTITIONS
、*_LOB_PARTITIONS
の各ビューでSEGMENT_CREATED
列を参照します。
ノート:
この新しい割当て方法では、適切な容量計画を行い、表へのデータ移入時にセグメントの作成を処理できるだけの十分なディスク領域がデータベースにあるようにすることが重要です。「データベース・オブジェクトの容量計画」を参照してください。
次の例では2つの表を作成し、遅延セグメント作成を実現します。最初の表はSEGMENT
CREATION
DEFERRED
句を使用します。最初はセグメントが作成されません。2番目の表はSEGMENT
CREATION
IMMEDIATE
句を使用するため、セグメントが即時作成されます。
CREATE TABLE part_time_employees ( empno NUMBER(8), name VARCHAR2(30), hourly_rate NUMBER (7,2) ) SEGMENT CREATION DEFERRED; CREATE TABLE hourly_employees ( empno NUMBER(8), name VARCHAR2(30), hourly_rate NUMBER (7,2) ) SEGMENT CREATION IMMEDIATE PARTITION BY RANGE(empno) (PARTITION empno_to_100 VALUES LESS THAN (100), PARTITION empno_to_200 VALUES LESS THAN (200));
USER_SEGMENTS
に対する次の問合せにより、HOURLY_EMPLOYEES
の行はパーティションごとに1つずつ計2つ返されますが、PART_TIME_EMPLOYEES
の行はこの表のセグメント作成が遅延されたため返されません。
SELECT segment_name, partition_name FROM user_segments; SEGMENT_NAME PARTITION_NAME -------------------- ------------------------------ HOURLY_EMPLOYEES EMPNO_TO_100 HOURLY_EMPLOYEES EMPNO_TO_200
USER_TABLES
ビューには、PART_TIME_EMPLOYEES
にセグメントがないことが示されます。
SELECT table_name, segment_created FROM user_tables;
TABLE_NAME SEGMENT_CREATED ------------------------------ ---------------------------------------- PART_TIME_EMPLOYEES NO HOURLY_EMPLOYEES N/A
HOURLY_EMPLOYEES
表がパーティション表である場合、SEGMENT_CREATED
列はN/A
になっています。これは、USER_TABLES
ビューには、パーティション表のこの列に関する情報がないためです。次のように、USER_TAB_PARTITIONS
ビューから参照できます。
SELECT table_name, segment_created, partition_name FROM user_tab_partitions; TABLE_NAME SEGMENT_CREATED PARTITION_NAME -------------------- -------------------- ------------------------------ HOURLY_EMPLOYEES YES EMPNO_TO_100 HOURLY_EMPLOYEES YES EMPNO_TO_200
次の文は、従業員をこれらの表に追加しています。
INSERT INTO hourly_employees VALUES (99, 'FRose', 20.00); INSERT INTO hourly_employees VALUES (150, 'LRose', 25.00); INSERT INTO part_time_employees VALUES (50, 'KReilly', 10.00);
前述のように同じSELECT
文を繰り返すと、行データが挿入されるため、PART_TIME_EMPLOYEES
にセグメントが作成されました。HOURLY_EMPLOYEES
は前述のままです。
SELECT segment_name, partition_name FROM user_segments; SEGMENT_NAME PARTITION_NAME -------------------- ------------------------------ PART_TIME_EMPLOYEES HOURLY_EMPLOYEES EMPNO_TO_100 HOURLY_EMPLOYEES EMPNO_TO_200
SELECT table_name, segment_created FROM user_tables; TABLE_NAME SEGMENT_CREATED -------------------- -------------------- PART_TIME_EMPLOYEES YES HOURLY_EMPLOYEES N/A
USER_TAB_PARTITIONS
ビューに変更はありません。
関連項目:
セグメント作成の遅延に関する注意および制限は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 表を管理するためのガイドライン
20.2.15 セグメントのマテリアライズ
DBMS_SPACE_ADMIN
パッケージにはMATERIALIZE_DEFERRED_SEGMENTS()
プロシージャが含まれており、このプロシージャを使用すると、セグメント作成の遅延が有効であるときに作成された表、表パーティションおよび依存オブジェクトのセグメントをマテリアライズできます。
最初から必要以上のセグメントを設定して不必要にデータベース・リソースを使用するのではなく、必要に応じてセグメントを追加できます。
次の例では、HR
スキーマのEMPLOYEES
表のセグメントをマテリアライズしています。
BEGIN DBMS_SPACE_ADMIN.MATERIALIZE_DEFERRED_SEGMENTS( schema_name => 'HR', table_name => 'EMPLOYEES'); END;
関連項目:
このプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
親トピック: 表を管理するためのガイドライン
20.2.16 表サイズの見積りと見積りに応じた計画
表を作成する前に表のサイズを見積ります。見積りは、なるべくデータベース計画の一部として実行します。データベース表のサイズと用途を確認することは、データベース計画の重要な部分です。
表の見積りサイズの合計と、索引、UNDO領域およびREDOログ・ファイルの見積りを使用して、作成するデータベースを格納するために必要なディスク容量を決定できます。この見積りによって、適切なハードウェアを購入できます。
見積ったサイズと個々の表サイズの増加率を使用すると、作成する表に最適な表領域の属性とその基礎になるデータファイルを的確に判断できます。これによって、表のディスク領域の管理が容易になり、表を使用するアプリケーションのI/Oパフォーマンスが向上します。
関連項目:
親トピック: 表を管理するためのガイドライン
20.2.17 表作成時の制限事項
表を作成するときには制限事項を考慮する必要があります。
表の計画と使用に影響を与える可能性のある制限事項がいくつかあります。
-
オブジェクト型を含む表は、Oracle8より古いバージョンのデータベースにインポートできません。
-
エクスポートされた表は、異なるスキーマで同じ名前の付いた既存の表にマージできません。
-
オリジナルのデータがデータベースにまだ存在するときは、型とエクステント表を異なるスキーマには移動できません。
-
Oracle Databaseには、表が持つ列(またはオブジェクト型の属性)の合計数に制限があります。この制限の詳細は、『Oracle Databaseリファレンス』を参照してください。
ユーザー定義型のデータを含む表を作成すると、ユーザー定義型の列はその型データを格納するリレーショナル列にマップされます。これにより、追加のリレーショナル列が作成されます。これらのリレーショナル列は「非表示」で、
DESCRIBE
表の文では表示されず、SELECT *
文でも返されません。したがって、オブジェクト表、REF
の列を持つリレーショナル表、VARRAY、ネストした表またはオブジェクト型を作成するときは、データベースが表に対して実際に作成した列の合計数が、指定した数よりも多くなることがあるので注意してください。関連項目:
ユーザー定義型の詳細は、Oracle Databaseオブジェクト・リレーショナル開発者ガイドを参照
親トピック: 表を管理するためのガイドライン
20.3 表の作成
表はSQL文CREATE TABLE
を使用して作成します。
自分のスキーマに新しい表を作成するには、CREATE TABLE
システム権限が必要です。別のユーザーのスキーマに表を作成するには、CREATE ANY TABLE
システム権限が必要です。また、表の所有者には、その表を含む表領域に対する割当て制限またはUNLIMITED TABLESPACE
システム権限が必要です。
- 例: 表の作成
例を使用して表の作成を説明します。 - 一時表の作成
一時表は、複数のDML操作の実行によって作成されるため、結果セットがバッファリング(一時的に保存)されるアプリケーションに有用です。グローバル一時表またはプライベート一時表のどちらかを作成できます。 - 表作成のパラレル化
表の作成にAS SELECT
句を指定して、別の表からデータを移入すると、パラレル実行を使用できます。
関連項目:
この章で説明しているCREATE TABLE
などのSQL文の正確な構文は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 表の管理
20.3.1 例: 表の作成
例を使用して表の作成を説明します。
次の文を発行すると、表admin_emp
がhr
スキーマに作成され、admin_tbs
表領域に格納されます。
Live SQL:
Oracle Live SQLの関連する例をOracle Live SQL: 表の作成および変更で参照して実行してください。
CREATE TABLE hr.admin_emp ( empno NUMBER(5) PRIMARY KEY, ename VARCHAR2(15) NOT NULL, ssn NUMBER(9) ENCRYPT USING 'AES256', 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), comments VARCHAR2(32767), status VARCHAR2(10) INVISIBLE) TABLESPACE admin_tbs STORAGE ( INITIAL 50K); COMMENT ON TABLE hr.admin_emp IS 'Enhanced employee table';
この例では、次に注意してください。
-
表の複数の列で整合性制約が定義されています。
-
STORAGE
句では、第1エクステントのサイズが指定されています。この句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 -
1つの列(
ssn
)で、Oracle Databaseの透過的データ暗号化機能を使用した暗号化が定義されています。したがって、このCREATE
TABLE
文を正常に実行するためには、キーストアがオープンしている必要があります。 -
photo
列はデータ型がBLOB
で、これはラージ・オブジェクト(LOB)と呼ばれるデータ型のセットのメンバーです。LOBは、準構造化データ(XMLツリーなど)および非構造化データ(カラー・イメージのビット・ストリームなど)の保存に使用されます。 -
1つの列(
hrly_rate
)が仮想列として定義されています。この列は、年収を2,080で除算して従業員の時給を計算しています。仮想列に関するルールの説明は、『Oracle Database SQL言語リファレンス』を参照してください。 -
comments
列は、4000バイトより大きいVARCHAR2
列です。Oracle Database 12cからは、VARCHAR2
、NVARCHAR2
およびRAW
データ型の最大サイズが32767バイトに増加されました。拡張データ型を使用するには、
MAX_STRING_SIZE
初期化パラメータをEXTENDED
に設定します。このパラメータの設定の詳細は、『Oracle Databaseリファレンス』を参照してください。 -
status
列は不可視です。 -
COMMENT
文を使用して、表に関するコメントが格納されています。*_TAB_COMMENTS
データ・ディクショナリ・ビューを問い合せると、このようなコメントを取得できます。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
関連項目:
-
表の列に指定できるデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
-
透過的データ暗号化の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
-
LOBの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
親トピック: 表の作成
20.3.2 一時表の作成
一時表は、複数のDML操作の実行によって作成されるため、結果セットがバッファリング(一時的に保存)されるアプリケーションに有用です。グローバル一時表またはプライベート一時表のどちらかを作成できます。
- 一時表の概要
一時表には、トランザクションまたはセッションの期間中にのみ存在するデータを保持します。 - 一時表作成時の考慮事項
一時表の作成時には、いくつかの考慮事項がある点に注意してください。 - グローバル一時表の作成
グローバル一時表は、ディスクに格納される永続的なデータベース・オブジェクトであり、データベースに接続しているすべてのセッションで参照できます。 - プライベート一時表の作成
プライベート一時表は、トランザクションまたはセッションの終了時に削除される一時データベース・オブジェクトです。プライベート一時表はメモリーに格納され、その表を作成したセッションでのみ参照できます。
親トピック: 表の作成
20.3.2.1 一時表の概要
一時表には、トランザクションまたはセッションの期間中にのみ存在するデータが保持されます。
一時表内のデータはセッション専用です。各セッションで参照および変更できるのは、そのセッション自体のデータのみです。
グローバル一時表またはプライベート一時表のどちらかを作成できます。次の表に、これらの本質的な相違点を示します。
表20-3 一時表の特徴
特徴 | グローバル | プライベート |
---|---|---|
命名規則 | 永続表の場合と同じです | 先頭にORA$PTT_ を付ける必要があります |
表定義の可視性 | すべてのセッション | 表を作成したセッションのみ |
表定義の記憶域 | ディスク | メモリーのみ |
タイプ | トランザクション固有(ON COMMIT DELETE ROWS )、またはセッション固有(ON COMMIT PRESERVE ROWS )
|
トランザクション固有(ON COMMIT DROP DEFINITION )、またはセッション固有(ON COMMIT PRESERVE DEFINITION )
|
3番目のタイプの一時表は、cursor-duration一時表と呼ばれるもので、特定のタイプの問合せに対してデータベースによって自動的に作成されます。
関連項目:
cursor-duration一時表の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
親トピック: 一時表の作成
20.3.2.2 一時表作成時の考慮事項
一時表の作成時には、いくつかの考慮事項がある点に注意してください。
永続表とは異なり、一時表の作成時にはセグメントは自動的に割り当てられません。かわりに、最初にINSERT
(またはCREATE
TABLE
AS
SELECT
)が実行されると、セグメントが割り当てられます。したがって、最初のINSERT
の前に、SELECT
、UPDATE
またはDELETE
が実行されると、表が空に見えます。
既存の一時表でDDL操作(TRUNCATE
を除く)が許可されるのは、その一時表にバインドされているセッションがない場合のみです。
トランザクションをロールバックすると、入力したデータは消失しますが、表定義はそのまま残ります。
トランザクション固有の一時表では、1回に1トランザクションのみが許可されます。単一のトランザクションに複数の自律型トランザクションがある場合、各自律型トランザクションは、直前のトランザクションのコミット直後にのみ表を使用できます。
一時表のデータは、その定義どおり一時的なため、一時表データのバックアップとリカバリはシステム障害のイベントでは使用できません。このような障害に備えて、一時表データを保存する代替方法を用意してください。
親トピック: 一時表の作成
20.3.2.3 グローバル一時表の作成
グローバル一時表は、ディスクに格納される永続的なデータベース・オブジェクトであり、データベースに接続しているすべてのセッションで参照できます。
- グローバル一時表の作成について
グローバル一時表のメタデータは、複数のユーザーとそのユーザーのセッションで参照できますが、その内容はセッションに対してローカルになります。 - 例: グローバル一時表の作成
グローバル一時表の作成方法を例で示します。
親トピック: 一時表の作成
20.3.2.3.1 グローバル一時表の作成について
グローバル一時表のメタデータは、複数のユーザーとそのユーザーのセッションで参照できますが、その内容はセッションに対してローカルになります。
たとえば、Webベースの航空予約アプリケーションでは、顧客がオプションの旅程を複数作成できます。各旅程はグローバル一時表の行で表されます。アプリケーションは、旅程への変更を反映するように行を更新します。使用する旅程を顧客が決定すると、アプリケーションは、該当する旅程の行を永続表に移動します。
セッションの開始時から終了時まで旅程データはプライベートです。セッションの終了時に、オプションの旅程は削除されます。
グローバル一時表の定義はすべてのセッションで参照できますが、グローバル一時表内のデータを参照できるのは、そのデータを表に挿入するセッションのみです。
グローバル一時表は、CREATE GLOBAL TEMPORARY TABLE
文を使用して作成します。ON COMMIT
句は、表内のデータがトランザクション固有(デフォルト)またはセッション固有のいずれであるかを示し、それぞれの意味は次のとおりです。
ON COMMIT設定 | 意味 |
---|---|
|
トランザクション固有のグローバル一時表を作成します。セッションは、最初に表に挿入するトランザクションでグローバル一時表にバインドされます。バインドは、トランザクション終了時に消失します。表は、各コミット後に切捨て(すべての行を削除)が行われます。 |
|
セッション固有のグローバル一時表を作成します。セッションは、そのセッションで最初の表への挿入でグローバル一時表にバインドされます。このバインドは、セッションの最後で、またはセッション内で表に対する |
親トピック: グローバル一時表の作成
20.3.2.3.2 例: グローバル一時表の作成
グローバル一時表の作成方法を例で示します。
次の文では、トランザクション固有のグローバル一時表を作成します。
CREATE GLOBAL TEMPORARY TABLE admin_work_area_trans (startdate DATE, enddate DATE, class CHAR(20)) ON COMMIT DELETE ROWS;
次の文では、セッション固有のグローバル一時表を作成します。
CREATE GLOBAL TEMPORARY TABLE admin_work_area_session (startdate DATE, enddate DATE, class CHAR(20)) ON COMMIT PRESERVE ROWS;
グローバル一時表には索引を作成できます。この索引も一時索引であり、索引内のデータのセッションまたはトランザクションの有効範囲は、基礎になる表のデータと同じです。
デフォルトでは、グローバル一時表の行は、それを作成したユーザーのデフォルト一時表領域に保存されます。ただし、グローバル一時表の作成時にCREATE GLOBAL TEMPORARY TABLE
のTABLESPACE
句を使用することで、別の表領域にグローバル一時表を割り当てることができます。この機能を使用すると、グローバル一時表に使用する領域を節約できます。たとえば、多数の小さなグローバル一時表操作を実行する必要があり、デフォルトの一時表領域がソート操作用に構成されていて、かつ大きなエクステント・サイズを使用する場合、これらの小さな操作は大量の不必要なディスク領域を消費します。このような場合、小さいエクステント・サイズを持つ別の一時表領域を割り当てることをお薦めします。
次の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;
関連項目:
-
グローバル一時表を作成するための
CREATE TABLE
文の使用方法と適用される制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
親トピック: グローバル一時表の作成
20.3.2.4 プライベート一時表の作成
プライベート一時表は、トランザクションまたはセッションの終了時に削除される一時データベース・オブジェクトです。プライベート一時表はメモリーに格納され、その表を作成したセッションでのみ参照できます。
- プライベート一時表の作成について
プライベート一時表のメタデータと内容は、それを作成したセッション内でのみ参照できます。 - 例: プライベート一時表の作成
プライベート一時表の作成例を示します。
親トピック: 一時表の作成
20.3.2.4.1 プライベート一時表の作成について
プライベート一時表のメタデータと内容は、それを作成したセッション内でのみ参照できます。
プライベート一時表は、次のような状況で役立ちます。
-
アプリケーションで、データを1回移入して、数回の読込み後、トランザクションまたはセッションの終了時に破棄する一時的な表に一時データを保存する場合
-
セッションが無期限に維持され、別のトランザクション用に別の一時表を作成する必要がある場合
-
一時表の作成時に、新しいトランザクションの開始や既存のトランザクションのコミットができない場合
-
同じユーザーの異なるセッションで一時表に同じ名前を使用する必要がある場合
-
読取り専用データベースに一時表が必要な場合
たとえば、1つのスキーマのみを使用するレポート・アプリケーションがあるとします。このアプリケーションは異なるレポートを実行するために、そのスキーマで複数の接続を使用するとします。セッションはそれぞれのトランザクションで計算用にプライベート一時表を使用し、各セッションは同じ名前のプライベート一時表を作成します。各トランザクションがコミットされると、その一時データは不要になります。プライベート一時表の定義とプライベート一時表内のデータは、どちらも表を作成したセッションでのみ参照できます。
プライベート一時表は、CREATE PRIVATE TEMPORARY TABLE
文を使用して作成します。ON COMMIT
句は、表内のデータがトランザクション固有(デフォルト)またはセッション固有のいずれであるかを示し、それぞれの意味は次のとおりです。
ON COMMIT設定 | 意味 |
---|---|
|
トランザクション固有のプライベート一時表を作成します。表内のすべてのデータが失われ、トランザクションの終了時に表が削除されます。 |
|
セッション固有のプライベート一時表を作成します。表内のすべてのデータが失われ、表を作成したセッションの終了時に表が削除されます。 |
ノート:
プライベート一時表の名前は、初期化パラメータprivate_temp_table_prefix
に従って接頭辞を付ける必要があります。
親トピック: プライベート一時表の作成
20.3.2.4.2 例: プライベート一時表の作成
プライベート一時表の作成例を示します。
次の文では、トランザクション固有のプライベート一時表を作成します。
CREATE PRIVATE TEMPORARY TABLE ORA$PTT_sales_ptt_transaction (time_id DATE, amount_sold NUMBER(10,2)) ON COMMIT DROP DEFINITION;
次の文では、セッション固有のプライベート一時表を作成します。
CREATE PRIVATE TEMPORARY TABLE ORA$PTT_sales_ptt_session (time_id DATE, amount_sold NUMBER(10,2)) ON COMMIT PRESERVE DEFINITION;
デフォルトでは、プライベート一時表の行は、それを作成したユーザーのデフォルト一時表領域に保存されます。ただし、一時表の作成時にCREATE PRIVATE TEMPORARY TABLE
のTABLESPACE
句を使用することで、別の表領域に一時表を割り当てることができます。
関連項目:
-
プライベート一時表を作成するための
CREATE TABLE
文の使用方法と適用される制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
親トピック: プライベート一時表の作成
20.3.3 表作成のパラレル化
表の作成にAS SELECT
句を指定して、別の表からデータを移入すると、パラレル実行を使用できます。
CREATE TABLE...AS SELECT
文には、CREATE
部分(DDL)とSELECT
部分(問合せ)の2つの部分があります。Oracle Databaseでは、この文の両方の部分をパラレル化できます。CREATE
の部分がパラレル化されるのは、次の中の1つに該当する場合です。
-
PARALLEL
句がCREATE TABLE...AS SELECT
文に含まれている。 -
ALTER SESSION FORCE PARALLEL DDL
文が指定されている。
問合せ部分がパラレル化されるのは、次のすべてに該当する場合です。
-
問合せにパラレル・ヒントの指定(
PARALLEL
またはPARALLEL_INDEX
)が含まれるか、またはCREATE
の部分にPARALLEL
句が含まれているか、または問合せで参照されているスキーマ・オブジェクトにPARALLEL
宣言が関連付けられている。 -
問合せに指定された少なくとも1つの表で、全表スキャンまたは複数のパーティションに及ぶ索引レンジ・スキャンが必要である。
表の作成をパラレル化した場合、その表には対応付けられたパラレル宣言(PARALLEL
句)が付きます。表に対するその後のすべてのDMLまたは問合せでは、パラレル化が可能な場合、パラレル実行の使用が試みられます。
表の作成をパラレル化し、表圧縮を使用して圧縮形式で結果を格納する簡単な文を次に示します。
CREATE TABLE hr.admin_emp_dept PARALLEL COMPRESS AS SELECT * FROM hr.employees WHERE department_id = 10;
この場合のPARALLEL
句は、表の作成時に最適な数のパラレル実行サーバーを選択することをデータベースに指示しています。
関連項目:
-
パラレル実行の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
親トピック: 表の作成
20.4 表のロード
データを表にロードするための手法について説明します。
ノート:
パーティション表のすべての新規セグメントについて、第1エクステントのデフォルトのサイズは64KBではなく8MBです。このことは、パーティション表に対する挿入と問合せのパフォーマンス向上に役立ちます。パーティション表の初期サイズが大きくても、十分なデータが挿入されると、領域消費は以前のリリースと同じになります。このデフォルトは、表の記憶域句にINITIAL
サイズを設定して上書きできます。この新しいデフォルトは、表パーティションおよびLOBパーティションにのみ適用されます。
- 表のロード方法
表にデータを挿入または初期ロードするには、いくつかの方法があります。 - ダイレクト・パスINSERTを使用したINSERTパフォーマンスの向上
大量のデータをロードするときは、ダイレクト・パスINSERT
を使用してロードのパフォーマンスを高めることができます。 - 従来型のインサートを使用した表のロード
従来型のINSERT処理では、表内の空き領域が再利用され、新規に挿入するデータと既存のデータが相互に配置されます。このような操作では、参照整合性制約も維持されます。ダイレクト・パスINSERT
操作と異なり、従来型のINSERT
操作は表に対する排他的ロックを必要としません。 - DMLエラー・ロギングを使用したバルクINSERT失敗の回避
DMLエラー・ロギング機能を使用して、バルクINSERT
の失敗を回避できます。
親トピック: 表の管理
20.4.1 表のロード方法
表にデータを挿入または初期ロードするには、いくつかの方法があります。
最も一般的に使用される方法は、次のとおりです。
方法 | 説明 |
---|---|
SQL*Loader |
これは、外部ファイルからOracle Databaseの表にデータをロードするOracleのユーティリティ・プログラムです。 Oracle Database 12cからは、SQL*Loaderでエクスプレス・モードがサポートされます。SQL*Loaderのエクスプレス・モードを使用すると、ファイルを制御する必要がなくなります。エクスプレス・モードにより、外部ファイルからのデータのロードが簡素化されます。エクスプレス・モードでは、SQL*Loaderは外部表ロード・メソッドの使用を試行します。外部表ロード・メソッドが使用できない場合、SQL*Loaderはダイレクト・パスの使用を試行します。ダイレクト・パスが使用できない場合、SQL*Loaderは従来型パスを使用します。 SQL*Loaderのエクスプレス・モードでは、表の列の型に基づいて入力データ型が自動的に識別され、並列度が制御されます。SQL*Loaderではデフォルトを使用して使用方法が簡素化されますが、多くのデフォルトはコマンド・ライン・パラメータで上書きできます。必要に応じて、エクスプレス・モードを使用するかわりに、ダイレクト・パスまたは従来型パスのロード・メソッドを指定できます。 SQL*Loaderの詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
CREATE TABLE |
このSQL文を使用すると、表を作成し、外部表を含む別の既存の表から選択したデータを移入できます。 |
大量のデータを挿入するときにエラーが発生した場合の文の終了およびロールバックを回避するには、DMLエラー・ロギングを指定して挿入できます。「DMLエラー・ロギングを使用したバルクINSERT失敗の回避」を参照してください。 |
|
|
ノート:
このマニュアルに記載されている、表にデータを挿入する詳細と例は少数です。データ・ウェアハウスおよびアプリケーション開発に関するオラクル社のマニュアルには、表へのデータの挿入および操作に関する広範囲にわたる情報が記載されています。参照:
20.4.2 ダイレクト・パスINSERTを使用したINSERTパフォーマンスの向上
大量のデータをロードするときは、ダイレクト・パスINSERT
を使用してロードのパフォーマンスを高めることができます。
- ダイレクト・パスINSERTについて
ダイレクト・パス・インサート操作は、一般に従来の挿入操作より高速です。 - ダイレクト・パスINSERTの動作
ダイレクト・パスINSERT
は、パーティション表と非パーティション表の両方で使用できます。 - ダイレクト・パスINSERTを使用したデータのロード
ダイレクト・パスINSERT
SQL文を使用してパラレル・モードでデータを挿入するか、またはOracleのSQL*Loaderユーティリティをダイレクト・パス・モードで使用することによって、ダイレクト・パスINSERT
を使用してデータをロードできます。ダイレクト・パスINSERT
トは、シリアル・モードまたはパラレル・モードで実行できます。 - ダイレクト・パスINSERTのロギング・モード
ダイレクト・パスINSERT
では、インサート処理中のREDOおよびUNDO情報を記録するかどうかを選択できます。 - ダイレクト・パスINSERTのその他の考慮事項
親トピック: 表のロード
20.4.2.1 ダイレクト・パスINSERTについて
ダイレクト・パス・インサート操作は、一般に従来の挿入操作より高速です。
Oracle Databaseでは、次の2つのいずれかの方法でデータが挿入されます。
-
従来型のINSERT処理では、表内の空き領域が再利用され、新規に挿入するデータと既存のデータが相互に配置されます。このような操作では、参照整合性制約も維持されます。
-
ダイレクト・パスINSERT処理では、表内の既存データの後ろに挿入データが追加されます。データは、バッファ・キャッシュを回避してデータファイルに直接書き込まれます。表の空き領域は再利用されず、参照整合性制約は無視されます。ダイレクト・パス
INSERT
は従来型のインサートよりもパフォーマンスが大幅に優れています。
データベースは、1つのプロセスが文を実行するシリアル・モードか、同時に多数のプロセスが連携して1つのSQL文を実行するパラレル・モードでデータを挿入できます。後者はパラレル実行と呼ばれます。
ダイレクト・パスINSERT
の利点は、次のとおりです。
-
ダイレクト・パス
INSERT
では、REDOおよびUNDOエントリのロギングを使用禁止にしてロード時間を削減できます。これに対して、従来型のインサート処理では空き領域を再利用し、参照整合性を維持するため、これらのエントリを常にロギングする必要があります。 -
ダイレクト・パス
INSERT
処理は、パラレル・モードで実行する場合でも、トランザクションの原子性が保証されます。原子性は、パラレル・ダイレクト・パス・ロード(SQL*Loaderを使用)では保証されません。
パラレル・ダイレクト・パス・ロード実行時のSQL*LoaderとINSERT
文の間の大きな違いの1つは、SQL*Loaderによるパラレル・ダイレクト・パス・ロード中にエラーが発生した場合、ロードは完了しますが、一部の索引にはロードの終了時にUNUSABLE
のマークが付くことです。対照的に、パラレル・ダイレクト・パスINSERT
の場合は、索引更新時にエラーが発生すると、文がロールバックされます。
ノート:
従来のINSERT
操作では、挿入中のNOT
NULL
制約の違反をチェックします。そのため、従来のINSERT
操作のNOT
NULL
制約に違反すると、挿入時にエラーが返されます。ダイレクト・パスINSERT
操作では、挿入前にNOT
NULL
制約の違反をチェックします。そのため、ダイレクト・パスINSERT
操作のNOT
NULL
制約に違反した場合は、挿入前にエラーが返されます。
20.4.2.2 ダイレクト・パスINSERTの動作
ダイレクト・パスINSERT
は、パーティション表と非パーティション表の両方で使用できます。
- パーティション表または非パーティション表へのシリアル・ダイレクト・パスINSERT
単一のプロセスは、表セグメントまたは各パーティション・セグメントの現在の最高水位標を超えてもデータを挿入します。(最高水位標とは、ブロックがデータを受け取るためにフォーマットされたことのないレベルを指します。)COMMIT
が実行されると、最高水位標が新しい値に更新され、データがユーザーに表示可能になります。 - パーティション表へのパラレル・ダイレクト・パスINSERT
この状況はシリアル・ダイレクト・パスINSERT
に似ています。各パラレル実行サーバーが1つ以上のパーティションに割り当てられ、1つのパーティションでは1つのプロセスしか実行されません。 - 非パーティション表へのパラレル・ダイレクト・パスINSERT
各パラレル実行サーバーは、新しい一時セグメントを割り当て、その一時セグメントにデータを挿入します。COMMIT
を実行すると、パラレル実行コーディネータが新しい一時セグメントをプライマリ表セグメントにマージし、ユーザーにデータが表示されます。
20.4.2.2.1 パーティション表または非パーティション表へのシリアル・ダイレクト・パスINSERT
単一のプロセスは、表セグメントまたは各パーティション・セグメントの現在の最高水位標を超えてもデータを挿入します。(最高水位標とは、ブロックがデータを受け取るためにフォーマットされたことのないレベルを指します。)COMMIT
が実行されると、最高水位標が新しい値に更新され、データがユーザーに表示可能になります。
親トピック: ダイレクト・パスINSERTの動作
20.4.2.2.2 パーティション表へのパラレル・ダイレクト・パスINSERT
この状況は、シリアル・ダイレクト・パスINSERT
と類似しています。各パラレル実行サーバーが1つ以上のパーティションに割り当てられ、1つのパーティションでは1つのプロセスしか実行されません。
各パラレル実行サーバー割り当てられたパーティション・セグメントの現在の最高水位標を超えてもデータを挿入します。COMMIT
が実行されると、各パーティション・セグメントの最高水位標が新しい値に更新され、データがユーザーに表示可能になります。
親トピック: ダイレクト・パスINSERTの動作
20.4.2.2.3 非パーティション表へのパラレル・ダイレクト・パスINSERT
各パラレル実行サーバーは、新しい一時セグメントを割り当て、その一時セグメントにデータを挿入します。COMMIT
を実行すると、パラレル実行コーディネータが新しい一時セグメントをプライマリ表セグメントにマージし、ユーザーにデータが表示されます。
親トピック: ダイレクト・パスINSERTの動作
20.4.2.3 ダイレクト・パスINSERTを使用したデータのロード
ダイレクト・パスINSERT
SQL文を使用してパラレル・モードでデータを挿入するか、またはOracleのSQL*Loaderユーティリティをダイレクト・パス・モードで使用することによって、ダイレクト・パスINSERT
を使用してデータをロードできます。ダイレクト・パスINSERT
は、シリアル・モードまたはパラレル・モードで実行できます。
- SQL文を使用したシリアル・モード・インサート
SQL文を使用したシリアル・モードのダイレクト・パスINSERT
は様々な方法でアクティブにできます。 - SQL文を使用したパラレル・モード・インサート
パラレル・モードで挿入する場合は、ダイレクト・パスINSERT
がデフォルトです。ただし、NOAPPEND
PARALLEL
ヒントを使用して、従来型のINSERT
を使用したパラレル・モードでの挿入も実行できます。
20.4.2.3.1 SQL文を使用したシリアル・モード・インサート
SQL文を使用したシリアル・モードのダイレクト・パスINSERT
は様々な方法でアクティブにできます。
SQLを使用したシリアル・モードでのダイレクト・パスINSERT
は、次の方法でアクティブ化します。
-
副問合せを使用して
INSERT
を実行している場合は、INSERT
キーワードの直後またはINSERT
文の副問合せのSELECT
キーワードの直後にある各INSERT
文にAPPEND
ヒントを指定します。 -
VALUES
句を使用してINSERT
を実行している場合は、INSERT
キーワードの直後にある各INSERT
文にAPPEND_VALUES
ヒントを指定します。VALUES
句を使用するダイレクト・パスINSERT
は、ロードする行が数百、数千またはさらに膨大な数になる場合の使用が最適です。一般的な使用例として、OCIを使用した配列の挿入があります。また、PL/SQLのFORALL
文での挿入に使用する例もあります。
VALUES
句を使用するINSERT
文にAPPEND
ヒント(APPEND_VALUES
ヒントではなく)を指定すると、このAPPEND
ヒントは無視され、従来の挿入が実行されます。
ダイレクト・パスINSERT
を実行するためにAPPEND
ヒントを使用する例を次に示します。
INSERT /*+ APPEND */ INTO sales_hist SELECT * FROM sales WHERE cust_id=8890;
次のPL/SQLコードの一部は、APPEND_VALUES
ヒントの使用例です。
FORALL i IN 1..numrecords INSERT /*+ APPEND_VALUES */ INTO orderdata VALUES(ordernum(i), custid(i), orderdate(i),shipmode(i), paymentid(i)); COMMIT;
親トピック: ダイレクト・パスINSERTを使用したデータのロード
20.4.2.3.2 SQL文を使用したパラレル・モード・インサート
パラレル・モードで挿入する場合は、ダイレクト・パスINSERT
がデフォルトです。ただし、NOAPPEND
PARALLEL
ヒントを使用して、従来型のINSERT
を使用したパラレル・モードでの挿入も実行できます。
パラレルDMLモードで実行するには、次の要件を満たす必要があります。
-
Oracle Enterprise Editionがインストールされていること。
-
セッションでパラレルDMLが使用可能であること。そのためには、次の文を発行します。
ALTER SESSION { ENABLE | FORCE } PARALLEL DML;
-
次の要件を最低1つ満たす必要があります。
-
ターゲット標のパラレル属性を、作成時またはその後に指定すること。
-
各挿入操作に対して
PARALLEL
ヒントを指定すること。 -
データベースの初期化パラメータ
PARALLEL_DEGREE_POLICY
をAUTO
に指定すること。
-
ダイレクト・パスINSERT
を使用禁止にするには、各INSERT
文にNOAPPEND
ヒントを指定します。この指定によって、パラレルDMLモードが無視されます。
ノート:
ダイレクト・パスINSERT
によって挿入したデータを、挿入した直後に問合せまたは変更することはできません。問合せまたは変更を試みると、ORA-12838エラーが発生します。新しく挿入したデータの読取りまたは変更を試みる前に、COMMIT
文を発行する必要があります。
関連項目:
-
ヒントの使用方法の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
-
INSERT
文の副問合せ構文の詳細およびダイレクト・パスINSERT
の使用に関する追加の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: ダイレクト・パスINSERTを使用したデータのロード
20.4.2.4 ダイレクト・パスINSERTのロギング・モード
ダイレクト・パスINSERT
では、インサート処理中のREDOおよびUNDO情報を記録するかどうかを選択できます。
ダイレクト・パスINSERT
のロギング・モードは次のように指定します。
-
作成時(
CREATE
文で)または作成後(ALTER
文で)に、表、パーティション、索引またはLOB
記憶域について、ロギング・モードを指定できます。 -
作成時または作成後に
LOGGING
またはNOLOGGING
を指定しないと、次のようにデフォルト設定されます。-
パーティションのロギング属性は、その表のロギング属性にデフォルト設定されます。
-
表または索引のロギング属性は、常駐している表領域のロギング属性にデフォルト設定されます。
-
LOB
記憶域のロギング属性は、LOB
記憶域にCACHE
を指定した場合はLOGGING
にデフォルト設定されます。CACHE
を指定しなかった場合、ロギング属性はLOB
値が常駐している表領域の属性にデフォルト設定されます。
-
-
CREATE
TABLESPACE
またはALTER
TABLESPACE
文で、表領域のロギング属性を設定します。ノート:
データベースまたは表領域が
FORCE
LOGGING
モードの場合、ダイレクト・パスINSERT
は、ロギング設定に関係なく常にログに記録されます。
- ロギング付きダイレクト・パスINSERT
このモードでは、Oracle Databaseによってインスタンスおよびメディア・リカバリの完全なREDOロギングが実行されます。 - ロギングなしダイレクト・パスINSERT
このモードでは、REDOロギングまたはUNDOロギングを実行せずにOracle Databaseによってデータが挿入されます。かわりにデータベースは少数のブロック範囲無効化REDOレコードをロギングし、定期的に最新の直接書込みに関する情報で制御ファイルを更新します。
20.4.2.4.1 ロギング付きダイレクト・パスINSERT
このモードでは、Oracle Databaseによってインスタンスの完全なREDOロギングおよびメディア・リカバリが実行されます。
データベースがARCHIVELOG
モードの場合は、REDOログをテープにアーカイブできます。データベースがNOARCHIVELOG
モードの場合、インスタンスのクラッシュはリカバリできますが、ディスク障害はリカバリできません。
親トピック: ダイレクト・パスINSERTのロギング・モード
20.4.2.4.2 ロギングなしダイレクト・パスINSERT
このモードでは、Oracle DatabaseはデータをREDOまたはUNDOロギングなしでデータを挿入します。かわりにデータベースは少数のブロック範囲無効化REDOレコードをロギングし、定期的に最新の直接書込みに関する情報で制御ファイルを更新します。
ロギングなしダイレクト・パスINSERT
を使用すると、パフォーマンスが向上します。ただし、後でメディア・リカバリを実行する必要がある場合は、REDOデータがロギングされていないため、無効化REDOレコードによって一連のブロックに論理的破損のマークが付きます。したがって、このようなインサート処理の後にはデータをバックアップすることが重要です。
制御ファイルの定期更新を無効にして、リカバリ不能なダイレクト・パス・インサートのパフォーマンスを大幅に向上させることができます。このことを行うには、DB_UNRECOVERABLE_SCN_TRACKING
初期化パラメータをFALSE
に設定します。ただし、これらの制御ファイルの更新を無効化してリカバリ不能なダイレクト・パス・インサートを実行すると、データファイルが現在リカバリ不能かどうかをデータベースに問い合せて正確に判断できなくなります。
関連項目:
-
リカバリ不能なデータファイルの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
-
『Oracle Data Guard概要および管理』のリカバリ不能操作後にバックアップが必要かどうかの判断に関する項を参照してください。
親トピック: ダイレクト・パスINSERTのロギング・モード
20.4.2.5 ダイレクト・パスINSERTのその他の考慮事項
ダイレクト・パスINSERT
を使用する際は、圧縮表、索引メンテナンス、ディスク領域およびロック関連の問題を考慮してください。
- 圧縮表とダイレクト・パスINSERT
表が基本表圧縮で作成されている場合は、ダイレクト・パスINSERT
を使用して、表のデータをロード時に圧縮する必要があります。表が拡張行、ウェアハウスまたはアーカイブ圧縮で作成されている場合は、ダイレクト・パスINSERT
によって最適な圧縮率が得られます。 - ダイレクト・パスINSERTでの索引メンテナンス
索引がある(パーティションまたは非パーティション)表では、ダイレクト・パスINSERT
処理の終了時に、Oracle Databaseが索引メンテナンスを実行します。 - ダイレクト・パスINSERTでの領域に関する考慮事項
ダイレクト・パスINSERT
は、従来型パスINSERT
よりも多くの領域を必要とします。 - ダイレクト・パスINSERTでのロックに関する考慮事項
ダイレクト・パスINSERT
中は、データベースは表(またはパーティション表のすべてのパーティション)に対して排他的ロックを取得します。
20.4.2.5.1 圧縮表とダイレクト・パスINSERT
表が基本表圧縮で作成されている場合は、ダイレクト・パスINSERT
を使用して、表のデータをロード時に圧縮する必要があります。表が拡張行、ウェアハウスまたはアーカイブ圧縮で作成されている場合は、ダイレクト・パスINSERT
によって最適な圧縮率が得られます。
詳細は、「表圧縮の使用」を参照してください。
親トピック: ダイレクト・パスINSERTのその他の考慮事項
20.4.2.5.2 ダイレクト・パスINSERTでの索引メンテナンス
索引がある(パーティションまたは非パーティション)表では、ダイレクト・パスINSERT
処理の終了時に、Oracle Databaseが索引メンテナンスを実行します。
この索引メンテナンスは、パラレル・ダイレクト・パスINSERT
に対してはパラレル実行サーバーで、シリアル・ダイレクト・パスINSERT
に対してはシングル・プロセスで実行されます。INSERT
処理の前に索引を使用禁止にし、後で再作成することによって、索引メンテナンスでのパフォーマンスへの影響を回避できます。
関連項目:
親トピック: ダイレクト・パスINSERTのその他の考慮事項
20.4.2.5.3 ダイレクト・パスINSERTでの領域に関する考慮事項
ダイレクト・パスINSERT
は、従来型パスINSERT
よりも多くの領域を必要とします。
すべてのシリアル・ダイレクト・パスINSERT
処理では、パーティション表へのパラレル・ダイレクト・パスINSERT
と同様に、影響を受けるセグメントの最高水位標の上にデータが挿入されます。このため、追加の領域が必要となります。
非パーティション表へのパラレル・ダイレクト・パスINSERT
は、各並列度ごとに一時セグメントを作成するため、より多くの領域を必要とします。非パーティション表が自動セグメント領域管理モードのローカル管理表領域にない場合は、NEXT
およびPCTINCREASE
記憶域パラメータ、およびMINIMUM
EXTENT
表領域パラメータの値を変更して、一時セグメントに十分な(かつ過剰ではない)記憶域を用意してください。次の事項を考慮に入れ、これらのパラメータに値を選択します。
-
各エクステントのサイズは、さほど小さくありません(1MB以上)。この設定は、オブジェクト内のエクステント総数に影響を与えます。
-
各エクステントのサイズが小さいと、パラレル
INSERT
では、必要以上に大きいセグメントで領域を無駄にすることになります。
これらのパラメータは、ダイレクト・パスINSERT
処理の完了後に、シリアル処理に適した設定に再設定できます。
親トピック: ダイレクト・パスINSERTのその他の考慮事項
20.4.2.5.4 ダイレクト・パスINSERTでのロックに関する考慮事項
ダイレクト・パスINSERT
中は、データベースは表(またはパーティション表のすべてのパーティション)に対して排他的ロックを取得します。
その結果、ユーザーは同時挿入、更新、または削除操作を表に対して実行できず、同時索引作成および構築操作は許可されません。ただし、同時問合せはサポートされますが、問合せで返されるのは挿入操作前の情報のみです。
親トピック: ダイレクト・パスINSERTのその他の考慮事項
20.4.3 従来型のインサートを使用した表のロード
従来型のINSERT処理では、表内の空き領域が再利用され、新規に挿入するデータと既存のデータが相互に配置されます。このような操作では、参照整合性制約も維持されます。ダイレクト・パスINSERT
操作と異なり、従来型のINSERT
操作は表に対する排他的ロックを必要としません。
ダイレクト・パスINSERT
操作に適用される他のいくつかの制約も、従来型のINSERT
操作には該当しません。これらの制限事項については、『Oracle Database SQL言語リファレンス』を参照してください。
従来型のINSERT
操作は、NOAPPEND
ヒントを使用して、シリアル・モードまたはパラレル・モードで実行できます。
従来型のINSERT
をシリアル・モードで実行するためにNOAPPEND
ヒントを使用する例を次に示します。
INSERT /*+ NOAPPEND */ INTO sales_hist SELECT * FROM sales WHERE cust_id=8890;
従来型のINSERT
をパラレル・モードで実行するためにNOAPPEND
ヒントを使用する例を次に示します。
INSERT /*+ NOAPPEND PARALLEL */ INTO sales_hist SELECT * FROM sales;
パラレルDMLモードで実行するには、次の要件を満たす必要があります。
-
Oracle Enterprise Editionがインストールされていること。
-
セッションでパラレルDMLが使用可能であること。そのためには、次の文を発行します。
ALTER SESSION { ENABLE | FORCE } PARALLEL DML;
-
次の要件を最低1つ満たす必要があります。
-
ターゲット標のパラレル属性を、作成時またはその後に指定すること。
-
各挿入操作に対して
PARALLEL
ヒントを指定すること。 -
データベースの初期化パラメータ
PARALLEL_DEGREE_POLICY
をAUTO
に指定すること。
-
親トピック: 表のロード
20.4.4 DMLエラー・ロギングを使用したバルクINSERT失敗の回避
DMLエラー・ロギング機能を使用して、バルクINSERT
の失敗を回避できます。
- DMLエラー・ロギングを使用したデータ挿入
副問合せでINSERT
文を使用して表をロードすると、エラーが発生した場合は文が終了して文全体がロールバックされます。これは、時間とシステム・リソースを無駄に消費することになります。このようなINSERT
文の場合は、DMLエラー・ロギング機能を使用することで、この状況を回避できます。 - エラー・ロギング表の書式
エラー・ロギング表には固有の書式があります。 - エラー・ロギング表の作成
エラー・ロギング表は手動で作成できます。または、PL/SQLパッケージを使用して自動的に作成できます。 - エラー・ロギングの制限事項と注意
一部のエラーはエラー・ロギング表に記録されません。
親トピック: 表のロード
20.4.4.1 DMLエラー・ロギングを使用したデータ挿入
副問合せでINSERT
文を使用して表をロードすると、エラーが発生した場合は文が終了して文全体がロールバックされます。これは、時間とシステム・リソースを無駄に消費することになります。このようなINSERT
文の場合は、DMLエラー・ロギング機能を使用することで、この状況を回避できます。
DMLエラー・ロギングを使用するには、データベースがDML操作中に検出したエラーを記録するエラー・ロギング表の名前を指定する文の句を追加します。このエラー・ロギング句をINSERT
文に追加すると、特定のタイプのエラーで文が終了およびロールバックしなくなります。そのかわり、それぞれのエラーがロギングされ、文が続行します。その後、エラーの発生した行に対して修正アクションを取ることができます。
DMLエラー・ロギングは、INSERT
、UPDATE
、MERGE
およびDELETE
文で機能します。ここでは、特にINSERT
文について説明します。
DMLエラー・ロギングを使用してデータを挿入するには:
例20-9 DMLエラー・ロギングを使用したデータ挿入
次の文は、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データ・ウェアハウス・ガイド』を参照してください。
20.4.4.2 エラー・ロギング表の書式
エラー・ロギング表には固有の書式があります。
エラー・ロギング表は、次の2つの部分で構成されます。
-
エラーを説明する一連の必須列。Oracleエラー番号の列は、この一例です。
表20-4に、これらのエラーを説明する列を示します。
-
エラーの原因となった行のデータが格納される一連のオプション列。列名は、挿入対象の表(DML表)の列名に対応しています。
エラー・ロギング表のこの部分の列数は、0(ゼロ)、1または複数(最大でDML表の列数)の場合があります。DML表の列と同じ名前の列がエラー・ロギング表に存在する場合は、対応するデータが、障害のある挿入予定の行から、このエラー・ロギング表の列に書き込まれます。DML表の列に対応する列がエラー・ロギング表にない場合、その列は記録されません。エラー・ロギング表に、DML表の列と一致しない名前の列がある場合、その列は無視されます。
型変換エラーが発生する場合があるため、エラー・ロギング表のオプション列のデータ型は、データの消失または変換エラーなしで値を取得できる型である必要があります。(オプションのログの列がDML表の列と同じ型だった場合、問題の発生したデータをログに取得すると、エラーの原因となった同じデータ変換の問題が発生する可能性があります。)データベースは、変換エラーの原因となったデータについて、可能なかぎり意味のある値をロギングしようとします。値を導出できなかった場合、
NULL
が列にロギングされます。エラー・ロギング表への挿入時にエラーが発生すると、文が終了します。表20-5に、DML表の各データ型について、使用を推奨するエラー・ロギング表の列のデータ型を示します。
DBMS_ERRLOG
パッケージを使用してエラー・ロギングを自動的に作成すると、これらの推奨データ型が使用されます。
表20-4 エラーを説明する必須列
列名 | データ型 | 説明 |
---|---|---|
|
|
Oracleエラー番号 |
|
|
Oracleエラー・メッセージのテキスト |
|
|
エラーとなった行のROWID(更新および削除の場合) |
|
|
操作の種類: 挿入( ノート: |
|
|
ユーザーがエラー・ロギング句に指定したタグの値 |
表20-5 エラー・ロギング表の列のデータ型
DML表の列の型 | エラー・ロギング表の列の型 | ノート |
---|---|---|
|
|
変換エラーを記録できます。 |
|
|
情報の消失なしで値を記録します。 |
|
|
情報の消失なしで値を記録します。 |
|
|
情報の消失なしで値を記録します。デフォルトの日時書式マスクを使用して文字書式に変換します。 |
|
|
情報の消失なしで値を記録します。 |
|
|
ROWID型を記録します。 |
|
サポートされていません |
|
ユーザー定義型 |
サポートされていません |
20.4.4.3 エラー・ロギング表の作成
エラー・ロギング表は手動で作成できます。または、PL/SQLパッケージを使用して自動的に作成できます。
- エラー・ロギング表の自動作成
エラー・ロギング表を自動作成するには、DBMS_ERRLOG
パッケージを使用します。 - 手動によるエラー・ロギング表の作成
エラー・ロギング表を手動で作成するには標準DDLを使用します。
20.4.4.3.1 エラー・ロギング表の自動作成
エラー・ロギング表を自動作成するには、DBMS_ERRLOG
パッケージを使用します。
CREATE_ERROR_LOG
プロシージャは、エラーを説明するための必須列および指定されたDML表の列をすべて備えたエラー・ロギング表を作成し、表20-5に示したデータ型マッピングを実行します。
次の文は、前述の例で使用したエラー・ロギング表を作成します。
EXECUTE DBMS_ERRLOG.CREATE_ERROR_LOG('DW_EMPL', 'ERR_EMPL');
DBMS_ERRLOG
の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: エラー・ロギング表の作成
20.4.4.3.2 手動によるエラー・ロギング表の作成
エラー・ロギング表を手動で作成するには、標準DDLを使用します。
表の構造の要件は、「エラー・ロギング表の書式」を参照してください。エラーを説明するための必須列はすべて挿入する必要があります。列は順不同にできますが、必須列は表の最初の方の列に指定する必要があります。
親トピック: エラー・ロギング表の作成
20.4.4.4 エラー・ロギングの制限事項と注意
一部のエラーはエラー・ロギング表に記録されません。
Oracle Databaseは、DML操作中に次のエラーを記録します。
-
列の値が大きすぎる場合
-
制約(
NOT
NULL
制約、一意制約、参照制約、CHECK制約)違反の場合 -
トリガー実行時にエラーが発生した場合
-
副問合せの列と表内の対応する列との間の型変換でエラーが発生した場合
-
パーティション・マッピング・エラー
-
特定の
MERGE
操作エラー(ORA-30926
:MERGE
操作の安定したセット行を取得できません)
一部のエラーは記録されずに、DML操作の終了およびロールバックが実施されます。これらのエラーの一覧とDMLロギングの他の制約は、『Oracle Database SQL言語リファレンス』のINSERT
に関する項でerror_logging_clause
の説明を参照してください。
20.4.4.4.1 領域に関する考慮事項
DMLエラー・ロギングを使用するには、その前に領域の要件について考慮する必要があります。挿入する表の領域のみでなく、エラー・ロギング表の領域も必要です。
親トピック: エラー・ロギングの制限事項と注意
20.4.4.4.2 セキュリティ
DMLエラー・ロギングを指定したINSERT
文を発行するユーザーには、エラー・ロギング表に対するINSERT
権限が必要です。
関連項目:
DMLエラー・ロギングの例は、『Oracle Database SQL言語リファレンス』および『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。
親トピック: エラー・ロギングの制限事項と注意
20.5 バルク更新のパフォーマンス最適化
DBMS_REDEFINITION
パッケージのEXECUTE_UPDATE
プロシージャを使用して、表のバルク更新のパフォーマンスを最適化できます。REDOログに更新が記録されないため、パフォーマンスが最適化されます。
EXECUTE_UPDATE
プロシージャは、仮表、マテリアライズド・ビュー、マテリアライズド・ビュー・ログなどのオンライン表再定義のコンポーネントを自動的に使用して、表のバルク更新を最適化します。また、EXECUTE_UPDATE
プロシージャは影響を受ける行のフラグメンテーションも除去して、アトミックな更新を保証します。バルク更新でエラーが発生した場合は、ABORT_UPDATE
プロシージャを使用して、EXECUTE_UPDATE
プロシージャで行った変更を元に戻すことができます。
EXECUTE_UPDATE
プロシージャには、次の制限が適用されます。
-
オンライン表再定義に適用されるすべての制限が、
EXECUTE_UPDATE
プロシージャとABORT_UPDATE
プロシージャにも適用されます。 -
1つの表に複数の
EXECUTE_UPDATE
プロシージャを同時には実行できません。 -
EXECUTE_UPDATE
プロシージャが表に対して実行されているときに、別のセッションからその表に対してDMLによる変更を行わないでください。それらのDMLによる変更は、EXECUTE_UPDATE
プロシージャが完了したときに失われます。 -
UPDATE
文の実行時に起動するトリガーを表に設定することはできません。 -
EXECUTE_UPDATE
プロシージャに渡されるUPDATE
文には、拡張パーティション名を持つ表を指定できません。 -
ユーザー定義型(VARRAY、REFおよびネストした表)を表に使用できません。
-
Oracle提供のタイプ(
ANYTYPE
、ANYDATASET
、URIタイプ、SDO_TOPO_GEOMETRY
、SDO_GEORASTER
およびExpression
)を表に使用できません。 -
次のタイプの列を表に使用できません: 非表示列、仮想列、未使用列、疑似列またはアイデンティティ列。
-
オブジェクト表は表として指定できません。
-
表に仮想プライベート・データベース(VPD)ポリシーを指定することはできません。
-
表にチェック制約を指定できません。
-
表で行アーカイブを有効にできません。
バルク更新のパフォーマンスを最適化するには:
例20-10 製品データに対する最適化されたバルク更新の実行
この例では、oe.order_items
表のバルク更新を実行しています。具体的には、product_id
が3106
である各注文項目のunit_price
に45
を設定しています。バルク更新が失敗した場合は、ABORT_UPDATE
プロシージャを使用して、EXECUTE_UPDATE
プロシージャで実行したすべての変更をキャンセルし、データをプロシージャ実行前の状態に戻すことができます。
DECLARE
update_stmt VARCHAR2(300) := 'UPDATE oe.order_items SET unit_price = 45
WHERE product_id = 3106';
BEGIN
DBMS_REDEFINITION.EXECUTE_UPDATE(update_stmt);
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE ('No Data found for SELECT');
DBMS_REDEFINITION.ABORT_UPDATE(update_stmt);
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE ('Reason for failure is'|| SQLERRM);
IF (SQLCODE = 100)
THEN
DBMS_REDEFINITION.ABORT_UPDATE(update_stmt);
END IF;
END;
/
親トピック: 表の管理
20.6 表に関する統計の自動収集
PL/SQLパッケージDBMS_STATS
を使用すると、コストベースの最適化に関する統計を生成および管理できます。このパッケージを使用して、統計の収集、変更、表示、エクスポート、インポートおよび削除ができます。また、すでに収集した統計を識別または命名する際も、このパッケージを使用できます。
以前は、DBMS_STATS
を使用可能にし、CREATE
(またはALTER
) TABLE
文でMONITORING
キーワードを指定して、表の統計を自動的に収集していました。MONITORING
およびNOMONITORING
キーワードは非推奨になり、統計は自動的に収集されます。これらのキーワードを指定しても無視されます。
監視では、統計が最後に収集された時点以降表に対して実行されたINSERT
、UPDATE
およびDELETE
の概数が追跡されます。影響を受ける行数に関する情報は、SMONが周期的に(およそ3時間ごとに)データをデータ・ディクショナリに取り込むまで、システム・グローバル領域(SGA)に保持されます。このデータ・ディクショナリの情報は、DBA_TAB_MODIFICATIONS,ALL_TAB_MODIFICATIONS
またはUSER_TAB_MODIFICATIONS
ビューで表示可能です。データベースはこれらのビューを使用して、失効した統計を持つ表を識別します。
STATISTICS_LEVEL
初期化パラメータのデフォルトはTYPICAL
で、これは自動統計収集機能を有効にします。自動統計収集とDBMS_STATS
パッケージによって、オプティマイザは正確な実行計画を生成できます。STATISTICS_LEVEL
初期化パラメータをBASIC
に設定すると、Oracle Database機能で必要とされる多くの重要な統計が収集されません。すべての表の監視を使用禁止にするには、STATISTICS_LEVEL
初期化パラメータをBASIC
に設定します。自動統計収集とDBMS_STATS
パッケージによって、オプティマイザは正確な実行計画を生成できます。
関連項目:
-
STATISTICS_LEVEL
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。 -
オプティマイザ統計の管理の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
-
DBMS_STATS
パッケージの使用方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
スケジューラを使用して統計を自動的に収集する方法は、「自動化メンテナンス・タスクについて」を参照してください
親トピック: 表の管理
20.7 表の変更
表を変更するにはALTER TABLE
文を使用します。表を変更するには、その表が自分のスキーマに含まれているか、その表のALTER
オブジェクト権限またはALTER ANY TABLE
システム権限のいずれかを持っている必要があります。
ノート:
表を変更する前に、表を変更した結果についてよく理解しておいてください。これらの結果については、『Oracle Database SQL言語リファレンス』のALTER TABLE
句の説明を参照してください。
パッケージのビュー、マテリアライズド・ビュー、トリガー、ドメイン索引、ファンクション索引、CHECK制約、ファンクション、プロシージャが実表に依存する場合は、その実表または列を変更すると依存するオブジェクトに影響する可能性があります。データベースによる依存性管理の詳細は、「オブジェクト依存性の管理」を参照してください。
- ALTER TABLE文を使用する理由
ALTER TABLE
文を使用する理由がいくつかあります。 - 表の物理属性の変更
表の物理属性を変更する際には、いくつかの考慮事項があります。 - 新規セグメントまたは表領域への表の移動
新規セグメントまたは表領域に表を移動して、圧縮を有効にしたり、データ・メンテナンスを実行できます。 - 表の記憶域の手動割当て
Oracle Databaseは、必要に応じて表のデータ・セグメントに追加のエクステントを動的に割り当てます。ただし、表に追加のエクステントを明示的に割り当てることもできます。たとえば、Oracle Real Application Clusters環境で、表のエクステントを特定のインスタンスに対して明示的に割り当てることが可能です。 - 既存の列定義の変更
既存の列定義を変更するには、ALTER TABLE...MODIFY
文を使用します。列のデータ型、デフォルト値、列制約、列の式(仮想列の場合)、列の暗号化および可視/不可視プロパティは変更できます。 - 表の列の追加
既存の表に列を追加するには、ALTER TABLE...ADD
文を使用します。 - 表の列名の変更
Oracle Databaseでは、表の既存の列の名前を変更できます。列名を変更するには、ALTER TABLE
文のRENAME COLUMN
句を使用します。 - 表の列の削除
索引構成表などの表から、不要になった列を削除できます。これにより、データベースの領域を解放でき、データをエクスポート/インポートしてから索引と制約を再作成する必要がなくなります。 - 表を読取り専用モードにする方法
表を読取り専用モードにするには、ALTER
TABLE
...READ
ONLY
文を使用し、表を読取り/書込みモードに戻すには、ALTER
TABLE
...READ
WRITE
文を使用します。
親トピック: 表の管理
20.7.1 ALTER TABLE文を使用する理由
ALTER TABLE
文を使用する理由がいくつかあります。
ALTER
TABLE
文は、表に影響を与える次の処理を実行するために使用できます。
-
物理的な特性(
INITRANS
または記憶域パラメータ)を変更する場合 -
表を新しいセグメントまたは表領域に移動する場合
-
明示的にエクステントを割り当てるか、未使用領域の割当てを解除する場合
-
列を追加、削除または名前変更する場合、あるいは既存の列定義(データ型、長さ、デフォルト値、
NOT NULL
整合性制約、列の式(仮想列の場合)および暗号化プロパティ)を変更する場合 -
表のロギング属性を変更する場合
-
CACHE
/NOCACHE
属性を変更する場合 -
表に関連付けられている整合性制約を追加、変更または削除する場合
-
表に関連付けられている整合性制約またはトリガーを使用可能にするか、使用禁止にする場合
-
表の並列度を変更する場合
-
表の名前を変更する場合
-
表を読取り専用モードにする場合および読取り/書込みモードに戻す場合
-
索引構成表の特性を追加または変更する場合
-
外部表の特性を変更する場合
-
LOB
列を追加または変更する場合 -
オブジェクト型、ネストした表またはVARRAYの列を追加または変更する場合
-
表パーティションを変更する場合
Oracle Database 12cからは、パーティションの分割操作やパーティションのマージ操作などの操作を、一度に3つ以上のパーティションまたはサブパーティションに対して実行できます。詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
これらの多くのタスクについて、次の各項で説明します。
親トピック: 表の変更
20.7.2 表の物理属性の変更
表の物理属性を変更する際には、いくつかの考慮事項があります。
表のトランザクション・エントリ設定INITRANS
を変更する場合、INITRANS
の新しい設定は、その後表に割り当てられるデータ・ブロックにのみ適用されます。
記憶域パラメータINITIAL
とMINEXTENTS
は変更できません。他の記憶域パラメータ(NEXT
、PCTINCREASE
など)の新しい設定はすべて、その後に表に割り当てられるエクステントにのみ影響します。次に割り当てられるエクステントのサイズはNEXT
およびPCTINCREASE
の現在の値によって決定され、これらのパラメータの以前の値には基づきません。
関連項目:
物理属性句と記憶域句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 表の変更
20.7.3 新規セグメントまたは表領域への表の移動
新規セグメントまたは表領域に表を移動して、圧縮を有効にしたり、データ・メンテナンスを実行できます。
- 新規セグメントまたは表領域への表の移動について
ターゲット表領域に適切な割当てを持っている場合は、ALTER TABLE...MOVE [PARTITION|SUBPARTITION]
文を使用して、表、パーティションまたはサブパーティションを移動して、圧縮や表領域などの物理的な記憶域属性を変更できます。 - 表の移動
表を新しいセグメントまたは表領域に移動するには、ALTER TABLE...MOVE
文を使用します。 - 表パーティションまたはサブパーティションのオンラインでの移動
表パーティションまたはサブパーティションを移動するには、それぞれALTER TABLE...MOVE PARTITION
文またはALTER TABLE...MOVE SUBPARTITION
文を使用します。
親トピック: 表の変更
20.7.3.1 新規セグメントまたは表領域への表の移動について
ターゲット表領域に適切な割当てを持っている場合は、ALTER TABLE...MOVE [PARTITION|SUBPARTITION]
文を使用して、表、パーティションまたはサブパーティションを移動して、圧縮や表領域などの物理的な記憶域属性を変更できます。
ALTER TABLE...MOVE
文では、ONLINE
キーワードがサポートされており、移動中の表、パーティションまたはサブパーティションに対してデータ操作言語(DML)による操作を中断なく実行できます。以下の文を使用して、表、パーティションまたはサブパーティションをオンラインで移動できます。
-
ALTER
TABLE
...
MOVE
...
ONLINE
-
ALTER
TABLE
...
MOVE
PARTITION
...
ONLINE
-
ALTER
TABLE
...
MOVE
SUBPARTITION
...
ONLINE
表を移動すると、表の行のROWIDが変わります。ONLINE
キーワードおよびUPDATE INDEXES
句を指定して表を移動する場合、移動操作中も索引が使用可能になります。UPDATE INDEXES
句を指定し、ONLINE
キーワードを指定しない場合は、移動操作完了後すぐに索引が使用可能になります。UPDATE INDEXES
句で変更できるのは、表のグローバル索引の記憶域プロパティ、または表のグローバル・パーティション索引の索引パーティションの記憶域プロパティのみです。UPDATE INDEXES
句を指定しない場合、rowidを変更すると、表の索引にUNUSABLE
のマークが付き、これらの索引を使用して表にアクセスするDMLに対しては、ORA-01502エラーが返されます。この場合、表の索引を削除または再作成する必要があります。
移動操作により表の統計は無効になるため、表を移動した後に新しい統計を収集する必要があります。
表にLOB
列が含まれている場合は、この文を使用して、明示的に指定したLOB
データおよび(表に関連付けられた)LOB
索引セグメントを表とともに移動できます。特に指定しない場合、デフォルトではLOB
データとLOB
索引セグメントは移動されません。
親トピック: 新規セグメントまたは表領域への表の移動
20.7.3.2 表の移動
表を新しいセグメントまたは表領域に移動するには、ALTER TABLE...MOVE
文を使用します。
この文にONLINE
キーワードを指定すると、移動中の表に対してデータ操作言語(DML)による操作を中断なく実行できます。ONLINE
キーワードを指定しない場合は、移動中は表のデータに対して同時DML操作を実行できません。
表を移動するには:
-
SQL*Plusで、表の変更に必要な権限を持つユーザーとして接続します。
表の変更に必要な権限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
-
ALTER
TABLE
...
MOVE
文を実行します。
例20-11 オンライン・モードによる新規表領域への表の移動
次の文は、新しい記憶域パラメータを指定して、hr.jobs
表をオンラインで新しいセグメントおよび表領域に移動します。ONLINE
キーワードは、移動中も表に対してDML操作を中断なく実行できることを意味します。hr_tbs
表領域が存在している必要があります。
ALTER TABLE hr.jobs MOVE ONLINE STORAGE ( INITIAL 20K NEXT 40K MINEXTENTS 2 MAXEXTENTS 20 PCTINCREASE 0 ) TABLESPACE hr_tbs;
Example 20-12 表の移動および表の索引の更新
次の文で、表とその索引を作成したとします。
CREATE TABLE dept_exp (
DEPTNO NUMBER (2) NOT NULL,
DNAME VARCHAR2 (14),
LOC VARCHAR2 (13))
TABLESPACE tbs_1;
CREATE INDEX i1_deptno ON dept_exp(deptno) TABLESPACE tbs_1;
CREATE INDEX i2_dname ON dept_exp(dname) TABLESPACE tbs_1;
次の文で、表を新しい表領域(tbs_2
)に移動し、表を圧縮します。これは索引i2_dbname
も表領域tbs_2
に移動し、移動操作後にi1_deptno
索引とi2_dname
索引の両方が使用可能になるように指定します。
ALTER TABLE dept_exp MOVE
COMPRESS TABLESPACE tbs_2
UPDATE INDEXES
(i1_deptno TABLESPACE tbs_1,
i2_dname TABLESPACE tbs_2);
この文にはONLINE
キーワードは指定されていません。ただし、移動操作中も表に対してDML操作を中断なく実行できる必要がある場合、または移動操作中も索引を使用できる必要がある場合、ONLINE
キーワードはサポートされます。
これらの文を実行する前に、tbs_1
およびtbs_2
表領域が存在している必要があります。
親トピック: 新規セグメントまたは表領域への表の移動
20.7.3.3 表パーティションまたはサブパーティションのオンラインでの移動
表パーティションまたはサブパーティションを移動するには、それぞれALTER TABLE...MOVE PARTITION
文またはALTER TABLE...MOVE SUBPARTITION
文を使用します。
これらの文のいずれかとともにONLINE
キーワードを使用すると、移動中のパーティションまたはサブパーティションに対してDML操作を中断なく実行し続けることができます。ONLINE
キーワードを含めない場合、移動操作が完了するまで、パーティションまたはサブパーティション内のデータに対するDML操作は許可されません。
UPDATE
INDEXES
句を含めると、これらの文によって、移動中にローカル索引とグローバル索引の両方がメンテナンスされます。このため、これらの文とともにONLINE
キーワードを使用すると、移動後にパーティションのパフォーマンスを回復するために、グローバル索引をメンテナンスして手動で索引を再構築する時間を省くことができます。
表パーティションおよびサブパーティションの移動には、いくつかの制限事項が適用されます。これらの制限事項については、『Oracle Database SQL言語リファレンス』を参照してください。
表パーティションまたはサブパーティションをオンラインで移動するには:
-
SQL*Plusで、表の変更、およびパーティションまたはサブパーティションの移動に必要な権限のあるユーザーとして接続します。
必要な権限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
ALTER
TABLE
...
MOVE
PARTITION
またはALTER
TABLE
...
MOVE
SUBPARTITION
文を実行します。
例20-13 新規セグメントへの表パーティションの移動
次の文では、sh.sales
表のsales_q4_2003
パーティションを高度な行圧縮および索引メンテナンスが組み込まれた新しいセグメントに移動します。
ALTER TABLE sales MOVE PARTITION sales_q4_2003 ROW STORE COMPRESS ADVANCED UPDATE INDEXES ONLINE;
20.7.4 表の記憶域の手動割当て
Oracle Databaseは、必要に応じて表のデータ・セグメントに追加のエクステントを動的に割り当てます。ただし、表に追加のエクステントを明示的に割り当てることもできます。たとえば、Oracle Real Application Clusters環境で、表のエクステントを特定のインスタンスに対して明示的に割り当てることが可能です。
表に新しいエクステントを割り当てるには、ALTER TABLE...ALLOCATE EXTENT
文を使用します。
また、ALTER TABLE
文のDEALLOCATE UNUSED
句を使用して、未使用領域の割当てを明示的に解除することもできます。詳細は、「未使用領域の再利用」を参照してください。
親トピック: 表の変更
20.7.5 既存の列定義の変更
既存の列定義を変更するには、ALTER TABLE...MODIFY
文を使用します。列のデータ型、デフォルト値、列制約、列の式(仮想列の場合)、列の暗号化および可視/不可視プロパティは変更できます。
既存のデータがすべて新しい長さを満たしている場合は、既存の列の長さを拡張または縮小できます。Oracle Database 12cからは、VARCHAR2
、NVARCHAR2
およびRAW
データ型の最大サイズの32767バイトを指定できます。このリリースより前は、VARCHAR2
およびNVARCHAR2
データ型の最大サイズは4000バイト、RAW
データ型の最大サイズは2000バイトでした。拡張データ型を使用するには、MAX_STRING_SIZE
初期化パラメータをEXTENDED
に設定します。
列は、バイト・セマンティクスからCHAR
セマンティクスに、あるいはその逆に変更できます。空でないCHAR
列の長さを縮小するには、初期化パラメータBLANK_TRIMMING=TRUE
を設定する必要があります。
データ型CHAR
の列長を拡張するために表を変更している場合、特に表の行数が多い場合は、この操作は時間がかかり、さらに相当な追加記憶域を必要とする可能性があります。これは、各行のCHAR
値に空白を埋めて、新しい列長に合わせる必要があるためです。
列の可視/不可視プロパティを変更する場合、同じSQL文に他の列変更オプションを含めることはできません。
例20-14 4000バイトより大きいサイズへの列の長さの変更
この例では、oe.product_information
表のproduct_description
列の長さを32767バイトに変更します。
ALTER TABLE oe.product_information MODIFY(product_description VARCHAR2(32767));
関連項目:
-
表の列の変更の詳細およびその他の制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。
-
MAX_STRING_SIZE
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
親トピック: 表の変更
20.7.6 表の列の追加
既存の表に列を追加するには、ALTER TABLE...ADD
文を使用します。
次の文は、hr.admin_emp
表を変更して新しい列bonus
を追加します。
ALTER TABLE hr.admin_emp ADD (bonus NUMBER (7,2));
Live SQL:
Oracle Live SQLの関連する例をOracle Live SQL: 表の作成および変更で参照して実行してください。
表に新しい列を追加すると、DEFAULT
句を指定しないかぎり、その列は最初はNULL
です。一部の表タイプのNULL値可能列にDEFAULT
句を指定すると、デフォルト値はメタデータとして格納されますが、列自体にはデータは移入されません。ただし、デフォルト値が結果セットに戻されるように、新しい列を指定する後続の問合せは再書込みされます。この動作によって、操作のリソース使用率と記憶域要件が最適化されます。
NOT
NULL
制約付きの列を追加できるのは、表に行がまったく含まれていない場合、またはデフォルト値を指定する場合のみです。
ノート:
-
表での基本表圧縮を有効化する場合は、デフォルト値を指定しない場合にのみ、列を追加できます。
-
表での高度な行圧縮を有効化する場合は、デフォルト値を指定してもしなくても、その表に列を追加できます。
-
新しい列が仮想列の場合、値は列の式によって決定されます。(仮想列の値は問い合せられたときにのみ計算される点に注意してください。)
関連項目:
-
表の列の追加に関するルールおよび制限事項は、『Oracle Database SQL言語リファレンス』を参照してください。
-
仮想列の例については、「例: 表の作成」を参照してください
親トピック: 表の変更
20.7.7 表の列名の変更
Oracle Databaseでは、表の既存の列の名前を変更できます。列名を変更するには、ALTER TABLE
文のRENAME COLUMN
句を使用します。
新しい名前には、表の既存の列名と競合しない名前を指定する必要があります。RENAME COLUMN
句とともに他の句は使用できません。
次の文は、hr.admin_emp
表のcomm
列の名前を変更します。
ALTER TABLE hr.admin_emp RENAME COLUMN comm TO commission;
Live SQL:
Oracle Live SQLの関連する例をOracle Live SQL: 表の作成および変更で参照して実行してください。
前述のように、表の列を変更すると、依存するオブジェクトが無効になる可能性があります。ただし、列名を変更すると、ファンクション索引とCHECK制約が引き続き有効になるように、関連するデータ・ディクショナリ表が更新されます。
また、Oracle Databaseでは列制約の名前も変更できます。この操作の説明は、「制約名の変更」を参照してください。
ノート:
ALTER TABLE
のRENAME TO
句の構文はRENAME COLUMN
句に似ていますが、表自体の名前変更に使用します。
親トピック: 表の変更
20.7.8 表の列の削除
索引構成表などの表から、不要になった列を削除できます。これにより、データベースの領域を解放でき、データをエクスポート/インポートしてから索引と制約を再作成する必要がなくなります。
ノート:
表からすべての列を削除したり、SYS
が所有する表の列を削除することはできません。その場合はエラーが発生します。
- 表から列を削除する方法
ALTER TABLE...DROP COLUMN
文を発行すると、列記述子およびターゲット列に関連付けられているデータが表の各行から削除されます。1つの文で複数の列を削除できます。 - 列に未使用のマークを付ける方法
大きい表のすべての行から列データを削除する際に所要時間が重要な場合は、ALTER TABLE...SET UNUSED
文を使用できます。 - 未使用列の削除
未使用の列に対して実行できるアクションはALTER TABLE...DROP UNUSED COLUMNS
文のみです。表から未使用の列を物理的に削除し、ディスク領域を再生します。 - 圧縮表の列の削除
表での高度な行圧縮を有効化する場合は、表の列を削除できます。基本表圧縮のみを有効化する場合は、表の列を削除できません。
関連項目:
表からの列の削除に関するその他の制限事項およびオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 表の変更
20.7.8.1 表から列を削除する方法
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);
Live SQL:
Oracle Live SQLの関連する例をOracle Live SQL: 表の作成および変更で参照して実行してください。
親トピック: 表の列の削除
20.7.8.2 列に未使用マークを付ける方法
大きい表のすべての行から列データを削除する際に所要時間が重要な場合は、ALTER TABLE...SET UNUSED
文を使用できます。
この文は1つ以上の列に未使用マークを付けますが、実際にターゲット列を削除したり該当列が占めるディスク領域をリストアすることはありません。ただし、未使用マークが付けられた列は、問合せやデータ・ディクショナリ・ビューに表示されなくなり、その名前が削除されて新しい列に再利用できるようになります。ほとんどの場合、その列に定義されている制約、索引および統計も削除されます。例外として、未使用とマークされたLOB列の内部索引は削除されません。
hiredate
列とmgr
列に未使用マークを付けるには、次の文を実行します。
ALTER TABLE hr.admin_emp SET UNUSED (hiredate, mgr);
Live SQL:
Oracle Live SQLの関連する例をOracle Live SQL: 表の作成および変更で参照して実行してください。
後でALTER TABLE...DROP UNUSED COLUMNS
文を発行し、未使用マークが付いている列を削除できます。表の特定列の明示的な削除文を発行すると、未使用列もターゲット表から削除されます。
データ・ディクショナリ・ビューUSER_UNUSED_COL_TABS
、ALL_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
文の実行と同じことになります。
親トピック: 表の列の削除
20.7.8.3 未使用列の削除
未使用の列に対して実行できるアクションはALTER TABLE...DROP UNUSED COLUMNS
文のみです。表から未使用の列を物理的に削除し、ディスク領域を再生します。
次のALTER TABLE
文では、オプションの句CHECKPOINT
が指定されています。この句を指定すると、指定した行数(この場合は250行)が処理された後に、チェックポイントが適用されます。チェックポイントによって、列削除操作中に累積されるUNDOログの量が減少し、UNDO領域が使い果たされるおそれがなくなります。
ALTER TABLE hr.admin_emp DROP UNUSED COLUMNS CHECKPOINT 250;
Live SQL:
Oracle Live SQLの関連する例をOracle Live SQL: 表の作成および変更で参照して実行してください。
親トピック: 表の列の削除
20.7.9 表を読取り専用モードにする方法
表を読取り専用モードにするには、ALTER
TABLE
...READ
ONLY
文を使用し、表を読取り/書込みモードに戻すには、ALTER
TABLE
...READ
WRITE
文を使用します。
読取り専用モードが有効な表の例に、構成表があります。アプリケーションに含まれている構成表が、インストール後変更されず、ユーザーによる変更を禁止する必要がある場合は、アプリケーションのインストール・スクリプトによって、これらの表を読取り専用モードにできます。
表を読取り専用モードにするには、その表に対するALTER
TABLE
権限、またはALTER
ANY
TABLE
権限が必要です。また、COMPATIBLE
初期化パラメータが11.2.0
以上に設定されている必要があります。
次の例は、SALES
表を読取り専用モードにします。
ALTER TABLE SALES READ ONLY;
次の例は、表を読取り/書込みモードに戻します。
ALTER TABLE SALES READ WRITE;
表が読取り専用モードの場合、表データの変更操作は許可されません。表またはパーティションが読取り専用モードにされたら、その後の表に対するSELECT column_list ON table_name
文では、常に同じデータ・セットが返される必要があります。
読取り専用表で許可されない操作は、次のとおりです。
-
読取り専用表または読取り専用パーティションに対するすべてのDML操作
-
TRUNCATE
TABLE
-
SELECT
FOR
UPDATE
-
ALTER
TABLE
RENAME
/DROP
COLUMN
-
読取り専用パーティションまたは読取り専用表のパーティションの
DROP
-
ALTER
TABLE
SET
COLUMN
UNUSED
-
ALTER
TABLE
DROP
/TRUNCATE
/EXCHANGE
(
SUB
)
PARTITION
-
読取り専用表が関係している型に対する
ALTER
TABLE
UPGRADE
INCLUDING
DATA
またはALTER
TYPE
CASCADE
INCLUDING
TABLE
DATA
-
オンライン再定義
-
FLASHBACK
TABLE
読取り専用表で許可される操作は、次のとおりです。
-
SELECT
-
CREATE
/ALTER
/DROP
INDEX
-
ALTER
TABLE
ADD
/MODIFY
COLUMN
-
ALTER
TABLE
ADD
/MODIFY
/DROP
/ENABLE
/DISABLE
CONSTRAINT
-
物理的なプロパティ変更のための
ALTER
TABLE
-
ALTER
TABLE
DROP
UNUSED
COLUMNS
-
ALTER
TABLE
ADD
/COALESCE
/MERGE
/MODIFY
/MOVE
/RENAME
/SPLIT
(SUB)PARTITION
-
ALTER
TABLE
MOVE
-
ALTER
TABLE
ENABLE
ROW
MOVEMENT
およびALTER
TABLE
SHRINK
-
RENAME
TABLE
およびALTER
TABLE
RENAME
TO
-
DROP
TABLE
-
ALTER
TABLE
DEALLOCATE
UNUSED
-
ALTER
TABLE
ADD
/DROP
SUPPLEMENTAL
LOG
関連項目:
-
ALTER
TABLE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 -
読取り専用パーティションの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
親トピック: 表の変更
20.8 表のオンライン再定義
表の論理構造または物理構造を変更できます。
- 表のオンライン再定義について
データベース・システムでは、問合せまたはDMLのパフォーマンスを改善したり、アプリケーションの変更に対応したり、記憶域を管理するために、表の構造を論理的または物理的に変更する必要が生じることがあります。DBMS_REDEFINITION
パッケージを使用して、オンラインで表を再定義できます。 - 表のオンライン再定義の機能
表のオンライン再定義により、表をオンラインにしたまま、いくつかの方法で表を変更できます。 - DBMS_REDEFINITIONパッケージに必要な権限
パッケージのサブプログラムを実行するには、DBMS_REDEFINITION
パッケージの実行権限が必要です。DBMS_REDEFINITION
パッケージの実行権限は、EXECUTE_CATALOG_ROLE
に付与されます。 - 表のオンライン再定義に関する制限事項
表のオンライン再定義にはいくつかの制限事項が適用されます。 - REDEF_TABLEプロシージャを使用したオンライン再定義の実行
DBMS_REDEFINITION
パッケージのREDEF_TABLE
プロシージャを使用して、表の記憶域プロパティのオンライン再定義を実行できます。 - DBMS_REDEFINITIONの複数のプロシージャを使用した表のオンライン再定義
DBMS_REDEFINITION
パッケージの複数のプロシージャを使用して、表のオンライン再定義を実行できます。 - 再定義プロセスの結果
再定義プロセスにはいくつかの結果があります。 - 中間での同期化の実行
元の表に対して多数のDML文を実行する場合は、再定義プロセス中に仮表を元の表と同期できます。 - 表のオンライン再定義中に依存マテリアライズド・ビューをリフレッシュする方法
表のオンライン再定義中に、高速リフレッシュ可能な依存マテリアライズド・ビューをリフレッシュするには、REDEF_TABLE
プロシージャまたはSTART_REDEF_TABLE
プロシージャで、refresh_dep_mviews
パラメータをY
に設定します。 - 表のオンライン再定義の進行状況の監視
V$ONLINE_REDEF
ビューを問い合せて、表のオンライン再定義操作の進行状況を監視できます。 - 失敗後の表のオンライン再定義の再開
表のオンライン再定義が失敗した場合は、DBA_REDEFINITION_STATUS
ビューでエラー情報および再開可能性に関する情報を確認できます。 - 表のオンライン再定義のロールバック
表のオンライン再定義後のロールバックを有効にして、表を元の定義に戻し、表に対して行ったDML変更を保持できます。 - エラー後の表のオンライン再定義の強制終了およびクリーン・アップ
オンライン再定義プロセスを強制終了できます。これにより、再定義プロセスに対応付けられた一時ログおよび一時表が削除されます。このプロシージャをコールした後は、仮表とその依存オブジェクトを削除できます。 - 1つ以上のパーティションのオンライン再定義
表の1つ以上のパーティションのオンライン再定義を実行できます。これは、異なる表領域にパーティションを移動する際に、移動中でもパーティションに対してDMLを使用できるようにする場合などに便利です。 - 表のオンライン再定義の例
例を使用して表のオンライン再定義を説明します。
親トピック: 表の管理
20.8.1 表のオンライン再定義について
データベース・システムでは、問合せまたはDMLのパフォーマンスを改善したり、アプリケーションの変更に対応したり、記憶域を管理するために、表の構造を論理的または物理的に変更する必要が生じることがあります。DBMS_REDEFINITION
パッケージを使用して、オンラインで表を再定義できます。
Oracle Databaseには、表の可用性に大きな影響を与えずに表の構造を変更できるメカニズムが用意されています。このメカニズムは、表のオンライン再定義と呼ばれます。表のオンライン再定義では、表を再定義する従来の方法に比べて、可用性が大幅に向上します。
オンラインで表を再定義している間も、その再定義プロセスの大部分で、問合せおよびDMLを使用してその表にアクセスできます。通常、表が排他モードでロックされるのは、そのサイズや再定義の複雑さに関係なくわずかな間のみで、ユーザーに対しては完全に透過的です。ただし、再定義中に数多くの同時DML操作がある場合、表をロックできるようになる前に、より長く待機することが必要になることがあります。
表のオンライン再定義には、再定義の対象になる表が使用している領域とほぼ同等の空き領域が必要です。新しい列を追加する場合は、より多くの領域が必要になります。
表のオンライン再定義を実行するには、Oracle Enterprise Manager Cloud Control (Cloud Control)のオブジェクトの再編成ウィザードまたはDBMS_REDEFINITION
パッケージを使用します。
ノート:
オブジェクトの再編成ウィザードを起動するには:
-
Cloud Controlの「表」ページで「選択」列をクリックし、再定義する表を選択します。
-
「アクション」リストで、「再編成」を選択します。
-
「実行」をクリックします。
関連項目:
DBMS_REDEFINITIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: 表のオンライン再定義
20.8.2 表のオンライン再定義の機能
表のオンライン再定義により、表をオンラインにしたまま、いくつかの方法で表を変更できます。
表のオンライン再定義では、次のことが可能です。
-
表またはクラスタの記憶域パラメータの変更
-
異なる表領域への表またはクラスタの移動
ノート:
表を別の表領域に移動する際に、DMLでその表を使用する必要性がない場合は、より簡単な
ALTER
TABLE
MOVE
コマンドを使用できます。「新規セグメントまたは表領域への表の移動」を参照してください。 -
表またはクラスタの1つ以上の列の追加、変更、または削除
-
パーティション化サポートの追加または削除(非クラスタ化表のみ)
-
パーティション構造の変更
-
同じスキーマ内の別の表領域へのパーティションの移動を含む、単一の表パーティションまたはサブパーティションの物理的なプロパティの変更
Oracle Database 12cからは、表のオンライン再定義を使用しないで、パーティションまたはサブパーティションをオンラインで移動できます。移動中のパーティションまたはサブパーティションに対してDML操作を中断なく実行し続けることができます。「新規セグメントまたは表領域への表の移動」を参照してください。
-
マテリアライズド・ビュー・ログまたはOracle Databaseアドバンスト・キューイングのキュー表の物理的なプロパティの変更
ノート:
DBMS_REDEFINITION
パッケージのREDEF_TABLE
プロシージャは、Oracle Database Advanced Queuingキュー表の物理プロパティの変更はサポートしません。 -
パラレル問合せのサポートの追加
-
表またはクラスタの再作成による断片化の低減
ノート:
多くの場合、オンラインによるセグメントの縮小が断片化を削減する簡単な方法です。詳細は、「未使用領域の再利用について」を参照してください。
-
通常の表(ヒープ構成表)から索引構成表へ、または索引構成表から通常の表への編成の変更。
-
リレーショナル表からオブジェクト列を持つ表へ、またはオブジェクト列を持つ表からリレーショナル表への変換。
-
オブジェクト表からリレーショナル表またはオブジェクト列を持つ表へ、あるいはリレーショナル表またはオブジェクト列を持つ表からオブジェクト表への変換。
-
表、パーティション、索引キーまたはLOB列の圧縮、あるいはその圧縮タイプの変更
-
BasicFiles LOB記憶域からSecureFiles LOB記憶域へ、またはSecureFiles LOB記憶域からBasicFiles LOB記憶域へのLOB列の変換
-
表のオンライン再定義後のロールバックを有効にして、表を元の定義に戻し、表に対して行ったDML変更を保持できます。
-
表のオンライン再定義中に、高速リフレッシュ可能な依存マテリアライズド・ビューをリフレッシュするには、
REDEF_TABLE
プロシージャまたはSTART_REDEF_TABLE
プロシージャで、refresh_dep_mviews
パラメータをY
に設定します。 -
V$ONLINE_REDEF
ビューを問い合せて、表のオンライン再定義操作の進行状況を監視できます。 -
表のオンライン再定義が失敗したときは、多くの場合、失敗の原因となった問題を修正し、最後に停止したところからオンライン再定義プロセスを再開できます。
これらの使用例の2つ以上を1つの操作に組み合せることができます。例は、「表のオンライン再定義の例」の例8を参照してください。
親トピック: 表のオンライン再定義
20.8.3 DBMS_REDEFINITIONパッケージに必要な権限
DBMS_REDEFINITION
パッケージの実行権限は、パッケージ内のサブプログラムの実行に必要です。DBMS_REDEFINITION
パッケージの実行権限は、EXECUTE_CATALOG_ROLE
に付与されます。
さらに、パッケージを使用してユーザーのスキーマの表を再定義するには、ユーザーは次の権限を付与されている必要があります。
-
CREATE
TABLE
-
CREATE
MATERIALIZED
VIEW
COPY_TABLE_DEPENDENTS
プロシージャを実行するには、CREATE TRIGGER
権限も必要です。
パッケージを使用して他のスキーマの表を再定義するには、ユーザーは次の権限を付与されている必要があります。
-
CREATE
ANY
TABLE
-
ALTER
ANY
TABLE
-
DROP
ANY
TABLE
-
LOCK
ANY TABLE
-
SELECT
ANY
TABLE
他のスキーマの表でCOPY_TABLE_DEPENDENTS
を実行するには、次の追加権限が必要です。
-
CREATE
ANY
TRIGGER
-
CREATE
ANY
INDEX
親トピック: 表のオンライン再定義
20.8.4 表のオンライン再定義に関する制限事項
表のオンライン再定義には、いくつかの制限が適用されます。
表のオンライン再定義には、次の制限が適用されます。
-
表を主キーまたは擬似主キー(すべてのコンポーネント列がNULLでない制約を持つ一意キーまたは制約)を使用して再定義する場合、再定義後の表でも同じ主キーまたは擬似主キー列を使用する必要があります。ROWIDを使用して再定義する表に、索引構成表を含めないでください。
-
マテリアライズド・ビュー・ログが含まれている表を再定義した後に依存マテリアライズド・ビューをリフレッシュする場合は、完全リフレッシュを実行する必要があります。
この制限には例外があります。表のオンライン再定義に
REDEF_TABLE
またはSTART_REDEF_TABLE
プロシージャを使用し、プロシージャでrefresh_dep_mviews
パラメータをY
に設定した場合、増分リフレッシュのために構成された依存マテリアライズド・ビューが、表のオンライン再定義操作中にリフレッシュされます。 -
n-wayマスター構成でレプリケートされた表の再定義は可能ですが、水平サブセット化(表内の行のサブセット)、垂直サブセット化(表内の列のサブセット)または列変換は使用できません。
-
索引構成表のオーバーフロー表は、個別にオンライン再定義できません。
-
Flashbackデータ・アーカイブが有効になっている表は、オンラインで再定義できません。Flashbackデータ・アーカイブを仮表に対して有効にはできません。
-
複数の
LONG
列を保持している表は、オンラインで再定義できますが、これらの列は、CLOB
に変換する必要があります。また、LONG RAW
列は、BLOB
に変換する必要があります。LOB
列を持つ表は、オンライン再定義可能です。 -
パラレル実行のためのリソースが十分なシステムで、仮表がパーティション化されていない環境では、次の場合にのみ、
LONG
列からLOB
列への再定義をパラレルで実行できます。-
仮表への
LOB
列の格納に使用するセグメントが、自動セグメント領域管理(ASSM)を使用できるローカル管理表領域に属している場合。 -
単一の
LONG
列から単一のLOB
列への簡単なマッピングで、仮表に存在するLOB
列が1つのみの場合。
仮表がパーティション化されている場合は、パラレル実行でパーティション化する通常の方法が適用されます。
-
-
SYS
およびSYSTEM
スキーマ内の表は、オンライン再定義できません。 -
一時表は再定義できません。
-
表内の行のサブセットは再定義できません。
-
仮表の列を元の表の列にマッピングするときに使用できるのは、値がすぐに決定される単純な式、順序および
SYSDATE
のみです。たとえば、副問合せは使用できません。 -
新しい列を再定義の一部として追加しようとして、それらの列に列マッピングがない場合は、その再定義が完了するまで
NOT
NULL
を宣言しないでください。 -
再定義しようとする表と仮表の間では参照制約を作成できません。
-
表の再定義は、
NOLOGGING
モードでは実行できません。 -
マテリアライズド・ビュー・ログおよびキュー表の場合、オンライン再定義は物理的なプロパティの変更に制限されます。水平サブセット化または垂直サブセット化が使用できず、列の変換もできません。列マッピング文字列に唯一有効な値は
NULL
です。 -
1つ以上のネストした表が含まれているパーティションに対するオンライン再定義は実行できません。
-
VARRAY
は、列マッピングにCAST
演算子を使用してネストした表に変換できます。ただし、ネストした表をVARRAY
に変換することはできません。 -
DBMS_REDEFINITION.START_REDEF_TABLE
プロシージャのcol_mapping
パラメータ内の列に順序が含まれている場合、orderby_cols
パラメータはNULL
でなくてはなりません。 -
仮想プライベート・データベース(VPD)セキュリティ・ポリシーが適用された表では、
copy_vpd_opt
パラメータをDBMS_REDEFINITION.CONS_VPD_AUTO
として指定した場合、次の制限が適用されます。-
元の表と仮表の間の列マッピング文字列は、
NULL
または'*'
にする必要があります。 -
VPDポリシーを仮表に指定することはできません。
「オンライン再定義時の仮想プライベート・データベース(VPD)ポリシーの処理」を参照してください。また、VPDポリシーの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
-
-
参照パーティション化によって複数の表が関連付けられている場合、異なる
DBMS_REDEFINITION
セッションにおいてそれらの表でオンライン再定義を同時に実行することはできません。参照パーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
-
オブジェクト表または
XMLType
表のオンライン再定義は、他の表に再定義済の表を参照するREF
列がある場合に、他の表のREF
の参照先がない状態を引き起こす可能性があります。REF
の参照先がないことの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 -
Oracle Label Security (OLS)を使用する表は、オンライン再定義できません。
Oracle Label Security管理者ガイドを参照してください。
-
ファイングレイン・アクセス制御が設定された表は、オンライン再定義できません。
-
Oracle Real Application Securityを使用する表は、オンライン再定義できません。
Oracle Databaseセキュリティ・ガイドを参照してください。
親トピック: 表のオンライン再定義
20.8.5 REDEF_TABLEプロシージャを使用したオンライン再定義の実行
DBMS_REDEFINITION
パッケージのREDEF_TABLE
プロシージャを使用して、表の記憶域プロパティのオンライン再定義を実行できます。
REDEF_TABLE
プロシージャを使用すると、次のプロパティを変更するときに、表の記憶域プロパティのオンライン再定義を1つのステップで実行できます。
-
表、パーティション、索引、LOB列などの表領域の変更
-
表、パーティション、索引キー、LOB列などの圧縮タイプの変更
-
LOB列の場合、
SECUREFILE
またはBASICFILE
記憶域の変更
オンライン再定義操作がこれらの変更に限定されない場合は、複数のステップで表のオンライン再定義を実行する必要があります。これらのステップでは、DBMS_REDEFINITION
パッケージ内の複数のプロシージャ(CAN_REDEF_TABLE
、START_REDEF_TABLE
、COPY_TABLE_DEPENDENTS
およびFINISH_REDEF_TABLE
)を呼び出します。
ノート:
REDEF_TABLE
プロシージャを使用して表を再定義した場合は、表のオンライン再定義のロールバックはサポートされません。
関連項目:
-
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
-
詳細は、「DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行」を参照してください
親トピック: 表のオンライン再定義
20.8.6 DBMS_REDEFINITIONの複数のプロシージャを使用した表のオンライン再定義
DBMS_REDEFINITION
パッケージの複数のプロシージャを使用して、表のオンライン再定義を実行できます。
- DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行
DBMS_REDEFINITION
パッケージの複数のプロシージャを使用して、表のオンライン再定義を実行できます。 - 列マッピング文字列の作成
引数としてSTART_REDEF_TABLE
に渡す列マッピング文字列には、カンマで区切られた列マッピングのペアのリストが含まれています。 - オンライン再定義中の仮想プライベート・データベース(VPD)ポリシーの処理
再定義する元の表にVPDポリシーが指定されている場合、START_REDEF_TABLE
プロシージャでcopy_vpd_opt
パラメータを使用して、オンライン再定義中にこれらのポリシーを処理できます。 - 依存オブジェクトの自動作成
仮表に対する依存オブジェクトを自動的に作成するには、COPY_TABLE_DEPENDENTS
プロシージャを使用します。 - 依存オブジェクトの手動による作成
SQL*PlusまたはCloud Controlで、仮表に対する依存オブジェクトを手動で作成する場合は、REGISTER_DEPENDENT_OBJECT
プロシージャを使用して依存オブジェクトを登録する必要があります。依存オブジェクトを登録すると、再定義の完了プロセスで、依存オブジェクト名を再定義前の名前にリストアできます。
親トピック: 表のオンライン再定義
20.8.6.1 DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行
DBMS_REDEFINITION
パッケージの複数のプロシージャを使用して、表のオンライン再定義を実行できます。
複数のステップで表のオンライン再定義を実行するには:
関連項目:
-
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
20.8.6.2 列マッピング文字列の作成
引数として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
などの組込み関数、作成した変換関数などを指定できます。
20.8.6.3 オンライン再定義中の仮想プライベート・データベース(VPD)ポリシーの処理
再定義する元の表にVPDポリシーが指定されている場合、START_REDEF_TABLE
プロシージャでcopy_vpd_opt
パラメータを使用して、オンライン再定義中にこれらのポリシーを処理できます。
このパラメータには、次の値を指定できます。
パラメータ値 | 説明 |
---|---|
|
元の表にVPDポリシーがない場合は、この値を指定します。この値がデフォルトです。 この表を指定したときに、元の表にVPDポリシーが存在する場合は、エラーが発生します。 |
|
オンライン再定義中に元の表から新しい表にVPDポリシーを自動的にコピーするには、この値を指定します。 |
|
オンライン再定義中に元の表から新しい表にVPDポリシーを手動でコピーするには、この値を指定します。 |
元の表にVPDポリシーが指定されていない場合は、copy_vpd_opt
パラメータにデフォルト値のDBMS_REDEFINITION.CONS_VPD_NONE
を指定します。
元の表と仮表で列名と列の型が同じ場合は、copy_vpd_opt
パラメータにDBMS_REDEFINITION.CONS_VPD_AUTO
を指定します。この値を使用するには、元の表と仮表の間の列マッピング文字列をNULL
または'*'
にする必要があります。copy_vpd_opt
パラメータにDBMS_REDEFINITION.CONS_VPD_AUTO
を使用した場合、表の所有者およびオンライン再定義を開始したユーザーのみがオンライン再定義中に仮表にアクセスできます。
次のいずれかの条件が満たされる場合は、copy_vpd_opt
パラメータにDBMS_REDEFINITION.CONS_VPD_MANUAL
を指定します。
-
元の表にVPDポリシーが指定されており、元の表と仮表の間に列マッピングがあります。
-
表のオンライン再定義中にVPDポリシーを追加または変更します。
VPDポリシーを手動でコピーするには、START_REDEF_TABLE
プロシージャを実行する前に、仮表にVPDポリシーを指定します。表のオンライン再定義が完了すると、再定義された表には変更されたポリシーが指定されています。
関連項目:
-
VPDポリシーが指定された表に関する制限事項の詳細は、「表のオンライン再定義に関する制限事項」を参照してください
-
VPDポリシーが指定された表を再定義する例は、「表のオンライン再定義の例」を参照してください
20.8.6.4 依存オブジェクトの自動作成
仮表に対する依存オブジェクトを自動的に作成するには、COPY_TABLE_DEPENDENTS
プロシージャを使用します。
num_errors
出力引数をチェックすることで、依存オブジェクトのコピー中にエラーが発生したかどうかを検出できます。ignore_errors
引数をTRUE
に設定すると、COPY_TABLE_DEPENDENTS
プロシージャは、オブジェクト作成時にエラーを検出しても、依存オブジェクトのコピーを続行します。DBA_REDEFINITION_ERRORS
ビューを問い合せることで、これらのエラーを確認できます。
エラーには、次のような理由があります。
-
システム・リソースの不足
-
依存オブジェクトの再コーディングが必要になるような表の論理構造の変更。
この種のエラーの説明は、「表のオンライン再定義の例」の例3を参照してください。
ignore_errors
をFALSE
に設定すると、COPY_TABLE_DEPENDENTS
プロシージャは、エラーを検出すると、オブジェクトのコピーをただちに停止します。
エラーを修正してからCOPY_TABLE_DEPENDENTS
プロシージャを再実行することで、依存オブジェクトのコピーを再試行できます。「依存オブジェクトの手動による作成」に説明されているように、オブジェクトを手動で作成し、それらを登録することもできます。COPY_TABLE_DEPENDENTS
プロシージャは、必要に応じて何回でも使用できます。オブジェクトがすでに正常にコピーされている場合は、再度コピーされません。
20.8.6.5 依存オブジェクトの手動による作成
SQL*PlusまたはCloud Controlで、仮表に対する依存オブジェクトを手動で作成する場合は、REGISTER_DEPENDENT_OBJECT
プロシージャを使用して依存オブジェクトを登録する必要があります。依存オブジェクトを登録すると、再定義の完了プロセスで、依存オブジェクト名を再定義前の名前にリストアできます。
次に、依存オブジェクトを手動で作成するために必要な変更の例を示します。
-
別の表領域への索引の移動
-
索引の列の変更
-
制約の変更
-
トリガーの変更
-
マテリアライズド・ビュー・ログの変更
REGISTER_DEPENDENT_OBJECT
プロシージャを実行するときに、dep_type
パラメータで依存オブジェクトのタイプを指定する必要があります。このパラメータで次の定数を指定できます。
-
依存オブジェクトが索引の場合は
DEMS_REDEFINITION.CONS_INDEX
-
依存オブジェクト・タイプが制約の場合は
DEMS_REDEFINITION.CONS_CONSTRAINT
-
依存オブジェクトがトリガーの場合は
DEMS_REDEFINITION.CONS_TRIGGER
-
依存オブジェクトがマテリアライズド・ビュー・ログの場合は
DEMS_REDEFINITION.CONS_MVLOG
COPY_TABLE_DEPENDENTS
プロシージャによる依存オブジェクトのコピーがエラーとなり、手動による介入が必要な場合は、REGISTER_DEPENDENT_OBJECT
プロシージャを使用します。
DBA_REDEFINITION_OBJECTS
ビューを問い合せることによって、登録されている依存オブジェクトを判断できます。このビューには、REGISTER_DEPENDENT_OBJECT
プロシージャで明示的に登録、またはCOPY_TABLE_DEPENDENTS
プロシージャで暗黙的に登録された依存オブジェクトが表示されます。このビューには、現在の情報のみが表示されます。
UNREGISTER_DEPENDENT_OBJECT
プロシージャを使用すると、再定義している表および仮表に対する依存オブジェクトの登録を解除できます。
ノート:
-
手動で作成する依存オブジェクトは、対応する元の依存オブジェクトと同一である必要はありません。たとえば、マテリアライズド・ビュー・ログを仮表に手動で作成する場合は、別の列を記録できます。また、仮表の依存オブジェクトが増減してもかまいません。
-
指定されたLOBセグメントが再定義する表に含まれている場合、LOBセグメント名は、オンライン再定義中にシステム生成の名前に置き換えられます。これを回避するには、新しいLOBセグメント名で仮表を作成できます。
関連項目:
依存オブジェクトを登録する例は、「表のオンライン再定義の例」の例4を参照してください
20.8.7 再定義プロセスの結果
再定義プロセスにはいくつかの結果があります。
再定義プロセスの最終的な結果は、次のようになります。
-
REDEF_TABLE
またはCOPY_TABLE_DEPENDENTS
が使用された場合、元の表は、仮表の列、索引、制約、権限付与、トリガーおよび統計を使用して再定義されます。 -
REGISTER_DEPENDENT_OBJECT
を明示的に使用するか、またはCOPY_TABLE_DEPENDENTS
を暗黙的に使用して登録された依存オブジェクトは、自動的に名前が変更されるため、再定義した表の依存オブジェクト名は再定義の前と同じになります。ノート:
登録または自動コピーが行われていない依存オブジェクトの名前は、手動で変更する必要があります。
-
仮表に関与する参照制約は、再定義した表に関与して使用可能になります。
-
(再定義前に)元の表に定義されていた索引、トリガー、マテリアライズド・ビュー・ログ、権限付与および制約がすべて仮表に移動し、ユーザーが仮表を削除したときに同時に削除されます。再定義する前に元の表に関与していた参照制約がすべて仮表に関与し、使用禁止になります。
-
一部のPL/SQLオブジェクト、ビュー、シノニムおよびその他の表依存オブジェクトが、無効になる場合があります。変更された表の要素に依存するオブジェクトのみが無効になります。たとえば、再定義で変更されなかった再定義表の列のみを問い合せるPL/SQLプロシージャは有効のままです。スキーマ・オブジェクトの依存性の詳細は、「オブジェクト依存性の管理」を参照してください。
親トピック: 表のオンライン再定義
20.8.8 中間での同期化の実行
元の表に対して多数のDML文を実行する場合は、再定義プロセス中に仮表を元の表と同期できます。
START_REDEF_TABLE
をコールして再定義プロセスを開始してからFINISH_REDEF_TABLE
コールが完了するまでの間に、元の表に対して多数のDML文が実行される可能性があります。これが問題になることがわかっている場合は、定期的に仮表を元の表と同期化することをお薦めします。
START_REDEF_TABLE
プロシージャを使用して表のオンライン再定義操作を開始した場合は、同期を容易にするために内部マテリアライズド・ビューが作成されます。この内部マテリアライズド・ビューがリフレッシュされて、仮表が元の表と同期されます。
仮表と元の表を同期するには、次にようにします。
-
DBMS_REDEFINITION
パッケージのSYNC_INTERIM_TABLE
プロシージャを実行します。
このプロシージャをコールすると、FINISH_REDEF_TABLE
で再定義プロセスを完了するための時間が短縮されます。SYNC_INTERIM_TABLE
をコールできる回数に制限はありません。
FINISH_REDEF_TABLE
の実行中に元の表がロックされるわずかな時間は、SYNC_INTERIM_TABLE
のコールの有無とは関係ありません。
親トピック: 表のオンライン再定義
20.8.9 表のオンライン再定義中に依存マテリアライズド・ビューをリフレッシュする方法
表のオンライン再定義中に、高速リフレッシュ可能な依存マテリアライズド・ビューをリフレッシュするには、REDEF_TABLE
プロシージャまたはSTART_REDEF_TABLE
プロシージャで、refresh_dep_mviews
パラメータをY
に設定します。
依存マテリアライズド・ビューは、再定義される表で定義されているマテリアライズド・ビューです。表のオンライン再定義後に依存マテリアライズド・ビューの完全リフレッシュを実行すると、時間がかかることがあります。表のオンライン再定義中に、高速リフレッシュ可能なマテリアライズド・ビューを増分リフレッシュすると、処理を効率化できます。
依存マテリアライズド・ビューのリフレッシュには、次の制限が適用されます。
-
マテリアライズド・ビューが高速リフレッシュ可能な必要があります。
-
ROWID
マテリアライズド・ビューはサポートされません。 -
マテリアライズド結合ビューはサポートされません。
表のオンライン再定義後に、依存ROWID
マテリアライズド・ビューおよびマテリアライズド結合ビューの完全リフレッシュが必要です。
例20-15 REDEF_TABLEプロシージャ実行中の依存マテリアライズド・ビューのリフレッシュ
この例では、hr.employees
表を再定義して、高度な行圧縮で表を圧縮し、依存マテリアライズド・ビューをリフレッシュしています。BEGIN
DBMS_REDEFINITION.REDEF_TABLE(
uname => 'HR',
tname => 'EMPLOYEES',
table_compression_type => 'ROW STORE COMPRESS ADVANCED',
refresh_dep_mviews => 'Y');
END;
/
例20-16 START_REDEF_TABLEプロシージャによる開始時の依存マテリアライズド・ビューのリフレッシュ
oe.orders
表を再定義する必要があるとします。次に表の定義を示します。
CREATE TABLE oe.orders(
order_id NUMBER(12),
order_date TIMESTAMP WITH LOCAL TIME ZONE,
order_mode VARCHAR2(8),
customer_id NUMBER(6),
order_status NUMBER(2),
order_total NUMBER(8,2),
sales_rep_id NUMBER(6),
promotion_id NUMBER(6));
この例では、表を再定義してorder_mode
列のサイズを16
に増やしています。次に仮表の定義を示します。
CREATE TABLE oe.int_orders(
order_id NUMBER(12),
order_date TIMESTAMP WITH LOCAL TIME ZONE,
order_mode VARCHAR2(16),
customer_id NUMBER(6),
order_status NUMBER(2),
order_total NUMBER(8,2),
sales_rep_id NUMBER(6),
promotion_id NUMBER(6));
また、この表には依存するマテリアライズド・ビューがあるとします。表には、次の文で作成されるマテリアライズド・ビュー・ログが含まれます。
CREATE MATERIALIZED VIEW LOG ON oe.orders WITH PRIMARY KEY, ROWID;
oe.orders
表には、次の依存マテリアライズド・ビューが含まれます。
CREATE MATERIALIZED VIEW oe.orders_pk REFRESH FAST AS
SELECT * FROM oe.orders;
CREATE MATERIALIZED VIEW oe.orders_rowid REFRESH FAST WITH ROWID AS
SELECT * FROM oe.orders;
oe.orders_pk
マテリアライズド・ビューは高速リフレッシュ可能な主キー・マテリアライズド・ビューです。したがって、表のオンライン再定義中にリフレッシュできます。
oe.orders_rowid
マテリアライズド・ビューは高速リフレッシュ可能ですが、これはROWID
マテリアライズド・ビューです。したがって、表のオンライン再定義中にリフレッシュできません。
次のステップで、oe.orders
表のオンライン再定義を実行し、同時にoe.orders_pk
マテリアライズド・ビューをリフレッシュします。
-
再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( uname => 'oe', orig_table => 'orders', int_table => 'int_orders', options_flag => DBMS_REDEFINITION.CONS_USE_PK, refresh_dep_mviews => 'Y'); END; /
-
依存オブジェクトをコピーします。(
oe.int_orders
に対するトリガー、索引、マテリアライズド・ビュー・ログ、権限付与および制約がある場合、それらは自動的に作成されます。)DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'oe', orig_table => 'orders', int_table => 'int_orders', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => TRUE, num_errors => num_errors); END; /
-
再定義ステータスを確認します。
SELECT REDEFINITION_ID, REFRESH_DEP_MVIEWS FROM DBA_REDEFINITION_STATUS WHERE BASE_TABLE_OWNER = 'OE' AND BASE_TABLE_NAME = 'ORDERS';
-
元の表に対してDMLを実行します。例:
INSERT INTO oe.orders VALUES(3000,sysdate,'direct',102,1,42283.2,154,NULL); COMMIT;
-
仮表
oe.int_orders
を同期します。このステップで、依存マテリアライズド・ビューoe.orders_pk
がリフレッシュされます。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'OE', orig_table => 'ORDERS', int_table => 'INT_ORDERS'); END; /
-
oe.orders
表の依存マテリアライズド・ビューのリフレッシュ・ステータスを確認します。SELECT m.OWNER, m.MVIEW_NAME, m.STALENESS, m.LAST_REFRESH_DATE FROM ALL_MVIEWS m, ALL_MVIEW_DETAIL_RELATIONS d WHERE m.OWNER=d.OWNER AND m. MVIEW_NAME=d.MVIEW_NAME AND d.DETAILOBJ_OWNER = 'OE' AND d.DETAILOBJ_NAME = 'ORDERS';
oe.orders_pk
マテリアライズド・ビューは前のステップでリフレッシュされたため、STALENESS
ステータスはFRESH
です。oe.orders_rowid
マテリアライズド・ビューは前のステップでリフレッシュされなかったため、STALENESS
ステータスはNEEDS_COMPLILE
です。 -
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'OE', orig_table => 'ORDERS', int_table => 'INT_ORDERS'); END; /
oe.orders_pk
マテリアライズド・ビューを問い合せると、表のオンライン再定義中にリフレッシュされたため、oe.orders
表に挿入された新しい行がマテリアライズド・ビューに存在することを確認できます。
関連トピック
親トピック: 表のオンライン再定義
20.8.10 表のオンライン再定義の進行状況の監視
V$ONLINE_REDEF
ビューを問い合せて、表のオンライン再定義操作の進行状況を監視できます。
表のオンライン再定義プロセス中は、一部の操作の実行に時間がかかる場合があります。これらの操作の実行中にV$ONLINE_REDEF
ビューを問い合せて、操作の進行状況について詳細な情報を確認できます。たとえば、DBMS_REDEFINITION.START_REDEF_TABLE
プロシージャでデータを仮表にロードするために時間がかかることがあります。
V$ONLINE_REDEF
ビューのPROGRESS
列に、操作の完了がパーセンテージで示されます。このビューには、OPERATION
列の操作を完了するために必要なステップの総数のうち、現在のステップが示されます。たとえば、操作に10のステップがある場合は、この列にStep 6 out of 10
のように示されます。ビューにはSUBOPERATION
列およびDETAILED_MESSAGE
列も含まれており、現在の操作についてより詳細な情報を確認できます。
表のオンライン再定義プロセス中に内部マテリアライズド・ビューが作成され、このマテリアライズド・ビューが一部の操作の実行中にリフレッシュされて、元の表と仮表の同期が維持されます。表のオンライン再定義中に自動的に実行されるリフレッシュの進行状況を確認するには、V$ONLINE_REDEF
ビューのREFRESH_STATEMENT_SQL_ID
列およびREFRESH_STATEMENT
列を問い合せます。REFRESH_STATEMENT_SQL_ID
列で返されるSQL_ID
値を使用して、V$SQL
ビューやV$SQL_MONITOR
ビューなどでリフレッシュの進行状況を監視できます。
- 表のオンライン再定義を実行中のセッションとは別個のセッションのデータベースに接続します。
V$ONLINE_REDEF
ビューを問い合せます。
例20-17 表のオンライン再定義の進行状況の監視
この例では、cust_alt_phone_number
列を追加して、Oracleが提供するsh.customers
表を再定義します。
CREATE TABLE customers (
cust_id NUMBER NOT NULL,
cust_first_name VARCHAR2(20) NOT NULL,
cust_last_name VARCHAR2(40) NOT NULL,
cust_gender CHAR(1) NOT NULL,
cust_year_of_birth NUMBER(4) NOT NULL,
cust_marital_status VARCHAR2(20),
cust_street_address VARCHAR2(40) NOT NULL,
cust_postal_code VARCHAR2(10) NOT NULL,
cust_city VARCHAR2(30) NOT NULL,
cust_city_id NUMBER NOT NULL,
cust_state_province VARCHAR2(40) NOT NULL,
cust_state_province_id NUMBER NOT NULL,
country_id NUMBER NOT NULL,
cust_main_phone_number VARCHAR2(25) NOT NULL,
cust_income_level VARCHAR2(30),
cust_credit_limit NUMBER,
cust_email VARCHAR2(50),
cust_total VARCHAR2(14) NOT NULL,
cust_total_id NUMBER NOT NULL,
cust_src_id NUMBER,
cust_eff_from DATE,
cust_eff_to DATE,
cust_valid VARCHAR2(1));
この表には大量のデータが含まれるため、表のオンライン再定義プロセスの一部の操作には時間がかかります。この例では、V$ONLINE_REDEF
ビューを問い合せて様々な操作を監視します。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
仮表
sh.int_customers
を作成します。CREATE TABLE sh.int_customers ( cust_id NUMBER NOT NULL, cust_first_name VARCHAR2(20) NOT NULL, cust_last_name VARCHAR2(40) NOT NULL, cust_gender CHAR(1) NOT NULL, cust_year_of_birth NUMBER(4) NOT NULL, cust_marital_status VARCHAR2(20), cust_street_address VARCHAR2(40) NOT NULL, cust_postal_code VARCHAR2(10) NOT NULL, cust_city VARCHAR2(30) NOT NULL, cust_city_id NUMBER NOT NULL, cust_state_province VARCHAR2(40) NOT NULL, cust_state_province_id NUMBER NOT NULL, country_id NUMBER NOT NULL, cust_main_phone_number VARCHAR2(25) NOT NULL, cust_income_level VARCHAR2(30), cust_credit_limit NUMBER, cust_email VARCHAR2(50), cust_total VARCHAR2(14) NOT NULL, cust_total_id NUMBER NOT NULL, cust_src_id NUMBER, cust_eff_from DATE, cust_eff_to DATE, cust_valid VARCHAR2(1), cust_alt_phone_number VARCHAR2(25));
-
再定義プロセスを開始し、操作の進行状況を監視します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( uname => 'sh', orig_table => 'customers', int_table => 'int_customers', options_flag => DBMS_REDEFINITION.CONS_USE_PK); END; /
この操作の実行中に、表のオンライン再定義を実行しているセッションとは別のセッションで
V$ONLINE_REDEF
ビューを問い合せて進行状況を監視します。SELECT * FROM V$ONLINE_REDEF;
この問合せの出力例を次に示します。
-
OPERATION
にSTART_REDEF_TABLE
-
SUBOPERATION
にcomplete refresh the materialized view
-
PROGRESS
にstep 6 out of 7
-
-
依存オブジェクトをコピーします。(
sh.int_customers
に対するトリガー、索引、マテリアライズド・ビュー・ログ、権限付与および制約がある場合、それらは自動的に作成されます。)DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'sh', orig_table => 'customers', int_table => 'int_customers', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => TRUE, num_errors => num_errors); END; /
この操作の実行中に、表のオンライン再定義を実行しているセッションとは別のセッションで
V$ONLINE_REDEF
ビューを問い合せて進行状況を監視します。SELECT * FROM V$ONLINE_REDEF;
この問合せの出力例を次に示します。
-
OPERATION
にCOPY_TABLE_DEPENDENTS
-
SUBOPERATION
にcopy the indexes
-
PROGRESS
にstep 3 out of 7
このコールでは、
ignore_errors
引数がTRUE
に設定されていることに注意してください。これは、仮表が主キー制約付きで作成されており、COPY_TABLE_DEPENDENTS
によって、主キー制約と索引が元の表からコピーされる際にエラーが発生するためです。これらのエラーは無視できます。 -
-
仮表
hr.int_emp_redef
を同期します。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'sh', orig_table => 'customers', int_table => 'int_customers'); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'sh', orig_table => 'customers', int_table => 'int_customers'); END; /
親トピック: 表のオンライン再定義
20.8.11 失敗後の表のオンライン再定義の再開
表のオンライン再定義が失敗した場合は、DBA_REDEFINITION_STATUS
ビューでエラー情報および再開可能性に関する情報を確認できます。
RESTARTABLE
がY
の場合は、エラーを修正して、最後に停止したところからオンライン再定義プロセスを再開できます。RESTARTABLE
がN
の場合は、再定義操作を中断する必要があります。
場合によっては、失敗後に表のオンライン再定義を再開できます。操作の再開とは、失敗のために停止したところからオンライン再定義プロセスが開始し、処理内容が失われないことを意味します。たとえば、「表領域で表を拡張できません」エラーによってSYNC_INTERIM_TABLE
プロシージャ・コールが失敗した場合、不足した表領域のサイズを増やすことで問題を修正して、SYNC_INTERIM_TABLE
プロシージャ・コールを再実行できます。
表のオンライン再定義が失敗した場合は、次のステップを実行してそれを再開できます。
例20-18 SYNC_INTERIM_TABLEプロシージャ・コールの失敗
SYNC_INTERIM_TABLE
プロシージャ・コール時に失敗したオンライン再定義操作の再開を示しています。BEGIN
DBMS_REDEFINITION.SYNC_INTERIM_TABLE('U1', 'ORIG', 'INT');
END;
/
ORA-42009: error occurred while synchronizing the redefinition
ORA-01653: unable to extend table U1.INT by 8 in tablespace my_tbs
ORA-06512: at "SYS.DBMS_REDEFINITION", line 148
ORA-06512: at "SYS.DBMS_REDEFINITION", line 2807
ORA-06512: at line 2
-
DBA_REDEFINITION_STATUS
ビューを問い合せます。SELECT BASE_TABLE_NAME, INT_TABLE_NAME, OPERATION, STATUS, RESTARTABLE, ACTION FROM DBA_REDEFINITION_STATUS; BASE_TABLE_NAME INT_OBJ_NAME OPERATION STATUS RESTARTABLE ACTION --------------- ------------ ------------------ ------- ----------- --------- ORIG INT SYNC_INTERIM_TABLE FAILED Y Fix error
問合せ結果では
RESTARTABLE
がY
になっているため、オンライン再定義操作を再開できます。操作を再開するには、操作の失敗時に返されたエラーを修正してから再開します。この例ではエラーは、ORA-01653: 「表U1.INT
を8(表領域my_tbs
)で拡張できません」です。 -
my_tbs
表領域にデータファイルを追加してサイズを大きくします。ALTER TABLESPACE my_tbs ADD DATAFILE '/u02/oracle/data/my_tbs2.dbf' SIZE 100M;
-
SYNC_INTERIM_TABLE
プロシージャ・コールを再実行します。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE('U1', 'ORIG', 'INT'); END; /
例20-19 マテリアライズド・ビュー・ログの問題
元の表に対する再定義が開始した後で、マテリアライズド・ビュー・ログに問題が発生する場合があります。たとえば、マテリアライズド・ビュー・ログがなんらかの原因で誤って削除されたり、破損する可能性があります。この場合、次のようなエラーが返されます。
ERROR at line 1:
ORA-42010: error occurred while synchronizing the redefinition
ORA-12034: materialized view log on "HR"."T1" younger than last refresh
次のSQL文で作成された表を再定義するとします。
CREATE TABLE hr.t1(
c1 NUMBER PRIMARY KEY,
c2 NUMBER)
TABLESPACE example_tbs;
次のSQL文で仮表を作成し、表の表領域を変更するとします。
CREATE TABLE hr.int_t1(
c1 NUMBER PRIMARY KEY,
c2 NUMBER)
TABLESPACE hr_tbs;
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( uname => 'hr', orig_table => 't1', int_table => 'int_t1'); END; /
-
元の表のマテリアライズド・ビュー・ログを削除します。
DROP MATERIALIZED VIEW LOG ON hr.t1;
-
元の表に新しいマテリアライズド・ビュー・ログを作成します。
CREATE MATERIALIZED VIEW LOG ON hr.t1 WITH COMMIT SCN PURGE IMMEDIATE ASYNCHRONOUS;
-
仮表
hr.int_t1
を同期します。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'hr', orig_table => 't1', int_table => 'int_t1'); END; / BEGIN * ERROR at line 1: ORA-42010: error occurred while synchronizing the redefinition ORA-12034: materialized view log on "HR"."T1" younger than last refresh
-
エラーが返されたため、
DBA_REDEFINITION_STATUS
ビューを確認します。COLUMN BASE_OBJECT_NAME FORMAT A11 COLUMN OPERATION FORMAT A10 COLUMN STATUS FORMAT A10 COLUMN RESTARTABLE FORMAT A11 COLUMN ERR_TXT FORMAT A15 COLUMN ACTION FORMAT A18 SELECT BASE_OBJECT_NAME, OPERATION, STATUS, RESTARTABLE, ERR_TXT, ACTION FROM DBA_REDEFINITION_STATUS ORDER BY BASE_TABLE_NAME, BASE_OBJECT_NAME; BASE_OBJECT OPERATION STATUS RESTARTABLE ERR_TXT ACTION ----------- ---------- ---------- ----------- --------------- ------------------ T1 SYNC_REDEF Failure N ORA-12034: mate Abort redefinition _TABLE rialized view l og on "HR"."T1" younger than l ast refresh
問合せ結果で、
RESTARTABLE
がN
になっており、ACTION
列に表のオンライン再定義操作を中断する必要があると示されているため、オンライン再定義操作を再開できません。 -
表のオンライン再定義操作を中断します。
BEGIN DBMS_REDEFINITION.ABORT_REDEF_TABLE( uname => 'hr', orig_table => 't1', int_table => 'int_t1'); END; /
親トピック: 表のオンライン再定義
20.8.12 表のオンライン再定義のロールバック
表のオンライン再定義後のロールバックを有効にして、表を元の定義に戻し、表に対して行ったDML変更を保持できます。
- 表のオンライン再定義のロールバックについて
表のオンライン再定義後に、表をオンライン再定義前の定義にロールバックし、同時に、表に対して行われたデータ操作言語(DML)変更をすべて保持できます。 - 表のオンライン再定義のロールバックの実行
DBMS_REDEFINITION
パッケージのROLLBACK
プロシージャは、DML変更を保持しながら、オンラインで再定義された表を元の定義に戻します。
親トピック: 表のオンライン再定義
20.8.12.1 表のオンライン再定義のロールバックについて
表のオンライン再定義後に、表をオンライン再定義前の定義にロールバックし、同時に、表に対して行われたデータ操作言語(DML)変更をすべて保持できます。
場合によっては、表のオンライン再定義を元に戻す必要が生じることがあります。たとえば、再定義後に表の操作のパフォーマンスが再定義前より低下する場合があります。このような場合、再定義後に表に対して行われたDML変更をすべて保持しながら、表を元の定義にロールバックできます。表のオンライン再定義のロールバックは、主に、再定義によって表の記憶域の特性が変化した場合、および変更により予期しないパフォーマンス低下が発生した場合に使用します。
表のオンライン再定義のロールバックを有効にするには、DBMS_REDEFINITION.START_TABLE_REDEF
プロシージャでENABLE_ROLLBACK
パラメータをTRUE
に設定する必要があります。このパラメータをTRUEに設定すると、再定義中に作成された仮表が再定義完了後もOracle Databaseに保持されます。SYNC_INTERIM_TABLE
プロシージャを実行して仮表を定期的に同期し、再定義された表に対して行われたDML変更を仮表に適用できます。内部マテリアライズド・ビューおよびマテリアライズド・ビュー・ログを使用して、仮表をメンテナンスできます。表のオンライン再定義をロールバックする場合は、仮表が同期され、表が元の定義になるようにOracle Databaseは仮表にスイッチ・バックします。
表のオンライン再定義のロールバックには、次の制限が適用されます。
-
元の表の列と暫定表の列に1対1のマッピングがない場合は、再定義中に列マッピングに演算子またはファンクションを使用できません。
元の表の列と暫定表の列に1対1のマッピングがある場合は、列マッピングに演算子またはファンクションを使用できます。
-
再定義のロールバックが有効な場合は、表のオンライン再定義がロールバックされるか中断されるまで、表を再び再定義はできません。
親トピック: 表のオンライン再定義のロールバック
20.8.12.2 表のオンライン再定義のロールバックの実行
DBMS_REDEFINITION
パッケージのROLLBACK
プロシージャは、DML変更を保持しながら、オンラインで再定義された表を元の定義に戻します。
ROLLBACK
プロシージャを使用するには、表のオンライン再定義時に、表のオンライン再定義のロールバックを有効にする必要があります。表のオンライン再定義で行われた変更を保持する場合は、ABORT_ROLLBACK
プロシージャを実行します。
例20-20 表のオンライン再定義のロールバック
この例では、表の記憶域特性の変更による表のオンライン再定義について説明します。特に、この例ではオンライン再定義中に表の表領域を圧縮します。オンライン再定義の完了後に、表のパフォーマンスを評価する必要があるとします。表のパフォーマンスが予想より低い場合は、オンライン再定義による変更をロールバックできます。
次の文で元の表領域と表を作成したとします。
CREATE TABLESPACE tst_rollback_tbs
DATAFILE 'tst_rollback_tbs.dbf' SIZE 10M
ONLINE;
CREATE TABLE hr.tst_rollback
(rllbck_id NUMBER(6) PRIMARY KEY,
rllbck_name VARCHAR2(20))
TABLESPACE tst_rollback_tbs
STORAGE (INITIAL 2M);
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
仮表用に圧縮された表領域を作成します。
CREATE TABLESPACE tst_cmp_rollback_tbs DEFAULT ROW STORE COMPRESS ADVANCED DATAFILE 'tst_cmp_rollback_tbs.dbf' SIZE 10M ONLINE;
-
仮表
hr.int_tst_rollback
を作成します。CREATE TABLE hr.int_tst_rollback (rllbck_id NUMBER(6) PRIMARY KEY, rllbck_name VARCHAR2(20)) TABLESPACE tst_cmp_rollback_tbs STORAGE (INITIAL 2M);
仮表が、前のステップで作成した圧縮された表領域を使用していることを確認します。
-
再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( uname => 'hr', orig_table => 'tst_rollback', int_table => 'int_tst_rollback', options_flag => DBMS_REDEFINITION.CONS_USE_PK, enable_rollback => TRUE); END; /
enable_rollback
がTRUE
に設定されており、オンライン再定義による変更がロールバックできることを確認します。 -
依存オブジェクトをコピーします。
DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'hr', orig_table => 'tst_rollback', int_table => 'int_tst_rollback', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => TRUE, num_errors => num_errors); END; /
-
DBA_REDEFINITION_ERRORS
ビューを問い合せて、エラーをチェックします。SET LONG 8000 SET PAGES 8000 COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A20 COLUMN BASE_TABLE_NAME HEADING 'Base Table Name' FORMAT A10 COLUMN DDL_TXT HEADING 'DDL That Caused Error' FORMAT A40 SELECT OBJECT_NAME, BASE_TABLE_NAME, DDL_TXT FROM DBA_REDEFINITION_ERRORS;
主キーと索引に関連するエラーは無視できます。
-
仮表
hr.int_tst_rollback
を同期します。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'hr', orig_table => 'tst_rollback', int_table => 'int_tst_rollback'); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'hr', orig_table => 'tst_rollback', int_table => 'int_tst_rollback'); END; /
このステップが終了するまでに、わずかな間のみ、表
hr.tst_rollbck
が排他モードでロックされます。このコールの後、表hr.tst_rollback
はhr.int_tst_rollback
表のすべての属性を持つように再定義されます。この例では、hr.tst_rollbck
表の表領域が圧縮されました。 -
評価期間中に、仮表
hr.int_tst_rollback
を定期的に同期できます。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'hr', orig_table => 'tst_rollback', int_table => 'int_tst_rollback'); END; /
表を同期すると、再定義された表に対して行われたDML変更によって元の表が更新されます。定期的に表を同期すると、元の表に対するDML変更を削減できるため、ロールバック操作が効率的になります。
DBA_REDEFINITION_STATUS
ビューのSTATUS
列を問い合せると、ロールバック操作のステータスを判別できます。 -
次のいずれかのアクションを実行します。
-
表のパフォーマンスが予想より低かったため、オンライン再定義による変更をロールバックするとします。
BEGIN DBMS_REDEFINITION.ROLLBACK( uname => 'hr', orig_table => 'tst_rollback', int_table => 'int_tst_rollback'); END; /
-
再定義された表のパフォーマンスが予想どおりだったため、ロールバックを中断して表のオンライン再定義による変更内容を保持し、ロールバックを有効にするデータベース・オブジェクトをクリーンアップするとします。
BEGIN DBMS_REDEFINITION.ABORT_ROLLBACK( uname => 'hr', orig_table => 'tst_rollback', int_table => 'int_tst_rollback'); END; /
-
親トピック: 表のオンライン再定義のロールバック
20.8.13 エラー後の表のオンライン再定義の強制終了およびクリーン・アップ
オンライン再定義プロセスを中断できます。これにより、再定義プロセスに対応付けられた一時ログおよび一時表が削除されます。このプロシージャをコールした後は、仮表とその依存オブジェクトを削除できます。
再定義プロセス中にエラーが発生したときにオンライン再定義プロセスを中断する場合、または手動で再定義プロセスを終了するには:
-
ABORT_REDEF_TABLE
プロシージャを実行します。
オンライン再定義プロセスの再起動が必要な場合は、最初にABORT_REDEF_TABLE
をコールしないと、表を再定義する後続の試みでエラーが発生します。
ノート:
FINISH_REDEF_TABLE
プロシージャがタイムアウトしたために再定義プロセスが停止した場合は、ABORT_REDEF_TABLE
プロシージャをコールする必要はありません。タイムアウト間隔は、FINISH_REDEF_TABLE
プロシージャのdml_lock_timeout
パラメータで制御します。詳細は、「DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行」のステップp 8を参照してください
親トピック: 表のオンライン再定義
20.8.14 1つ以上のパーティションのオンライン再定義
表の1つ以上のパーティションをオンラインで再定義できます。これは、異なる表領域にパーティションを移動する際に、移動中でもパーティションに対してDMLを使用できるようにする場合などに便利です。
一度に表の複数のパーティションを再定義できます。その場合は、表の再定義プロセス中に複数の仮表が必要になります。表の再定義を完了するには、十分な空き領域とUNDO領域があることを確認してください。
複数のパーティションを再定義する場合、特定のパーティションでエラーが発生した場合にも再定義が続行されるように指定できます。そのためには、DBMS_REDEFINITION
パッケージの再定義プロシージャでcontinue_after_errors
パラメータをTRUE
に設定します。DBA_REDEFINITION_STATUS
ビューをチェックして、再定義プロセス中にエラーが発生したかどうかを確認できます。このビューのSTATUS
列には、各パーティションの再定義プロセスが成功したか失敗したかが表示されます。
リソース要件を低減するために、表全体を一度に1つのパーティションずつ再定義することもできます。たとえば、異なる表領域に非常に大きな表を移動するには、表を1度に1つのパーティションずつ移動することで、移動を完了するために必要な空き領域とUNDO領域を最小化できます。
パーティションの再定義は、次の点で表の再定義とは異なります。
-
依存オブジェクトをコピーする必要はありません。1つのパーティションを再定義する場合、
COPY_TABLE_DEPENDENTS
プロシージャの使用は有効ではありません。 -
仮表に対してローカル索引を手動で作成し、登録する必要があります。
「依存オブジェクトの手動による作成」を参照してください。
-
START_REDEF_TABLE
には、NULL
の列マッピング文字列が必要です。
ノート:
Oracle Database 12cからは、より簡単なALTER
TABLE
...
MOVE
PARTITION
...
ONLINE
文を使用して、表のオンライン再定義を使用せずにパーティションまたはサブパーティションをオンラインで移動できます。移動中のパーティションまたはサブパーティションに対してDML操作を中断なく実行し続けることができます。「新規セグメントまたは表領域への表の移動」を参照してください。
- 単一パーティションのオンライン再定義のルール
単一パーティションを再定義するための基本的な仕組みは、データベースのパーティション交換機能(ALTER
TABLE
...EXCHANGE
PARTITION
)です。
親トピック: 表のオンライン再定義
20.8.14.1 単一パーティションのオンライン再定義のルール
単一パーティションを再定義するための基本的な仕組みは、データベースのパーティション交換機能(ALTER
TABLE
...EXCHANGE
PARTITION
)です。
したがって、単一パーティションのオンライン定義のルールと制限事項は、この仕組みに基づいて決まります。一般的には、次の制限事項があります。
-
論理的な変更(列の追加や削除など)は許可されません。
-
パーティション化する方法の変更(レンジ・パーティション化からハッシュ・パーティション化への変更など)は許可されません。
仮表を定義する際のルールは、次のとおりです。
-
再定義するパーティションが、レンジ、ハッシュまたはリスト・パーティションである場合は、非パーティションの仮表が必要です。
-
再定義するパーティションがレンジ-ハッシュ・コンポジット・パーティション表のレンジ・パーティションである場合は、ハッシュ・パーティション表の仮表が必要です。また、仮表のパーティション化キーは、レンジ-ハッシュ・パーティション表のサブパーティション化キーと同一であり、仮表のパーティション数は、再定義するレンジ・パーティションのサブパーティション数と同一であることが必要です。
-
再定義するパーティションがレンジ-リスト・コンポジット・パーティション表のレンジ・パーティションである場合は、リスト・パーティション表の仮表が必要です。また、仮表のパーティション化キーは、レンジ-リスト・パーティション表のサブパーティション化キーと同一であり、仮表のリスト・パーティションの値リストは、再定義するレンジ・パーティションのリスト・サブパーティションの値リストと正確に一致している必要があります。
-
仮表を圧縮するよう定義する場合、ROWIDによる再定義ではなく、キーによる再定義を使用する必要があります。
次の補足ルールは、再定義する表がパーティション化された索引構成表である場合に適用されます。
-
仮表も索引構成されている必要があります。
-
元の表と仮表では、同じ列に対する主キーが同じ順序で保持されている必要があります。
-
接頭辞圧縮が使用可能な場合は、元の表と仮表の両方で、同じ接頭辞の長さで接頭辞圧縮が使用可能になっている必要があります。
-
オーバーフロー・セグメントがある場合は、元の表と仮表の両方にあるか、または両方にないことが必要です。マッピング表についても同様です。
関連項目:
-
『Oracle Database VLDBおよびパーティショニング・ガイド』のパーティションの交換に関する項
-
パーティションを使用して表を再定義する例は、「表のオンライン再定義の例」を参照してください
親トピック: 1つ以上のパーティションのオンライン再定義
20.8.15 表のオンライン再定義の例
例を使用して表のオンライン再定義を説明します。
次の各例について、すべてのDBMS_REDEFINITION
サブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
例 | 説明 |
---|---|
|
|
新しい列を追加しパーティションを追加することで、表を再定義します。 |
|
オブジェクト・データ型を使用して表を再定義します。 |
|
手動で登録した依存オブジェクトを使用して表を再定義します。 |
|
複数のパーティションを異なる表領域に移動して再定義します。 |
|
表のいずれの列のプロパティも変更せずに、仮想プライベート・データベース(VPD)ポリシーを含む表を再定義します。 |
|
VPDポリシーが指定された表を再定義し、表のいずれかの列のプロパティを変更します。 |
|
オンライン再定義で複数の変更を実行して、表を再定義します。 |
例1
この例では、REDEF_TABLE
プロシージャを使用した表の記憶域プロパティのオンライン再定義を示しています。
元の表(print_ads
)は、次のようにpm
スキーマで定義されています。
Name Null? Type ----------------------------------------- -------- ---------------------------- AD_ID NUMBER(6) AD_TEXT CLOB
この表では、LOB列ad_text
でBasicFiles LOB記憶域が使用されます。
表の索引は、次のSQL文を使用して作成されました。
CREATE INDEX pm.print_ads_ix ON print_ads (ad_id) TABLESPACE example;
表は次のようにして再定義します。
-
表は、高度な行圧縮を使用して圧縮します。
-
表の表領域を
EXAMPLE
からNEWTBS
に変更します。この例では、NEWTBS
表領域が存在しているものとします。 -
索引は、
COMPRESS 1
圧縮を使用して圧縮します。 -
索引の表領域を
EXAMPLE
からNEWIDXTBS
に変更します。この例では、NEWIDXTBS
表領域が存在しているものとします。 -
表のLOB列は、
COMPRESS
HIGH
圧縮を使用して圧縮します。 -
LOB列の表領域を
EXAMPLE
からNEWLOBTBS
に変更します。この例では、NEWLOBTBS
表領域が存在しているものとします。 -
LOB列をSecureFiles LOB記憶域に変更します。
この再定義のステップは、次のとおりです。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
REDEF_TABLE
プロシージャを実行します。BEGIN DBMS_REDEFINITION.REDEF_TABLE( uname => 'PM', tname => 'PRINT_ADS', table_compression_type => 'ROW STORE COMPRESS ADVANCED', table_part_tablespace => 'NEWTBS', index_key_compression_type => 'COMPRESS 1', index_tablespace => 'NEWIDXTBS', lob_compression_type => 'COMPRESS HIGH', lob_tablespace => 'NEWLOBTBS', lob_store_as => 'SECUREFILE'); END; /
ノート:
エラーが発生した場合は、仮表が削除され、REDEF_TABLE
プロシージャを再実行する必要があります。
例2
この例は、新しい列を追加しパーティションを追加することによる表のオンライン再定義を示しています。
元の表(emp_redef
)のhr
スキーマでの定義は、次のとおりです。
Name Type --------- ---------------------------- EMPNO NUMBER(5) <- Primary key ENAME VARCHAR2(15) JOB VARCHAR2(10) DEPTNO NUMBER(3)
表は次のようにして再定義します。
-
新しい列
mgr
、hiredate
、sal
およびbonus
を追加します。 -
新しい列
bonus
を0 (ゼロ)に初期化します。 -
列
deptno
の値を10増やしています。 -
再定義された表を
empno
の範囲でパーティション化します。
この再定義のステップは、次のとおりです。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
表がオンライン再定義の候補であることを確認します。この場合は、主キーまたは疑似主キーを使用して再定義が実行されるように指定します。
BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE( uname => 'hr', tname =>'emp_redef', options_flag => DBMS_REDEFINITION.CONS_USE_PK); END; /
-
仮表
hr.int_emp_redef
を作成します。CREATE TABLE hr.int_emp_redef (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(0)) PARTITION BY RANGE(empno) (PARTITION emp1000 VALUES LESS THAN (1000) TABLESPACE admin_tbs, PARTITION emp2000 VALUES LESS THAN (2000) TABLESPACE admin_tbs2);
指定した表領域が存在することを確認します。
-
再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( uname => 'hr', orig_table => 'emp_redef', int_table => 'int_emp_redef', col_mapping => 'empno empno, ename ename, job job, deptno+10 deptno, 0 bonus', options_flag => DBMS_REDEFINITION.CONS_USE_PK); END; /
-
依存オブジェクトをコピーします。(
hr.int_emp_redef
に対するトリガー、索引、マテリアライズド・ビュー・ログ、権限付与および制約がある場合、それらは自動的に作成されます。)DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'hr', orig_table => 'emp_redef', int_table => 'int_emp_redef', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => TRUE, num_errors => num_errors); END; /
このコールでは、
ignore_errors
引数がTRUE
に設定されていることに注意してください。これは、仮表が主キー制約付きで作成されており、COPY_TABLE_DEPENDENTS
によって、主キー制約と索引が元の表からコピーされる際にエラーが発生するためです。これらのエラーは無視できますが、後続のステップに記載されている問合せを実行して、他のエラーの存在を確認する必要があります。 -
DBA_REDEFINITION_ERRORS
ビューを問い合せて、エラーをチェックします。SET LONG 8000 SET PAGES 8000 COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A20 COLUMN BASE_TABLE_NAME HEADING 'Base Table Name' FORMAT A10 COLUMN DDL_TXT HEADING 'DDL That Caused Error' FORMAT A40 SELECT OBJECT_NAME, BASE_TABLE_NAME, DDL_TXT FROM DBA_REDEFINITION_ERRORS; Object Name Base Table DDL That Caused Error -------------------- ---------- ---------------------------------------- SYS_C006796 EMP_REDEF CREATE UNIQUE INDEX "HR"."TMP$$_SYS_C006 7960" ON "HR"."INT_EMP_REDEF" ("EMPNO") PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 65536 NEXT 1048576 MIN EXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GRO UPS 1 BUFFER_POOL DEFAULT) TABLESPACE "ADMIN_TBS" SYS_C006794 EMP_REDEF ALTER TABLE "HR"."INT_EMP_REDEF" MODIFY ("ENAME" CONSTRAINT "TMP$$_SYS_C0067940" NOT NULL ENABLE NOVALIDATE) SYS_C006795 EMP_REDEF ALTER TABLE "HR"."INT_EMP_REDEF" MODIFY ("DEPTNO" CONSTRAINT "TMP$$_SYS_C0067950 " NOT NULL ENABLE NOVALIDATE) SYS_C006796 EMP_REDEF ALTER TABLE "HR"."INT_EMP_REDEF" ADD CON STRAINT "TMP$$_SYS_C0067960" PRIMARY KEY ("EMPNO") USING INDEX PCTFREE 10 INITRANS 2 MAXT RANS 255 STORAGE(INITIAL 65536 NEXT 1048576 MIN EXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GRO UPS 1 BUFFER_POOL DEFAULT) TABLESPACE "ADMIN_TBS" ENABLE NOVALID ATE
これらのエラーは、仮表にある既存の主キー制約に起因しているため、無視できます。このアプローチでは、再定義後の表の主キー制約名と索引名が変更されていることに注意してください。別のアプローチを使用すると、エラーの発生と名前の変更を回避できますが、仮表は主キー制約なしで定義されることになります。この例の場合、主キー制約と索引は元の表からコピーされます。
ノート:
最良のアプローチは、主キー制約付きで仮表を定義し、
REGISTER_DEPENDENT_OBJECT
を使用して主キー制約と索引を登録してから、COPY_TABLE_DEPENDENTS
で残りの依存オブジェクトをコピーすることです。このアプローチでは、エラーが回避され、再定義した表には常に主キーがあり、依存オブジェクト名も変わりません。 -
(オプション)仮表
hr.int_emp_redef
を同期化します。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'hr', orig_table => 'emp_redef', int_table => 'int_emp_redef'); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'hr', orig_table => 'emp_redef', int_table => 'int_emp_redef'); END; /
このステップが終了するまでに、わずかな間のみ、表
hr.emp_redef
が排他モードでロックされます。このコールの後、表hr.emp_redef
はhr.int_emp_redef
表のすべての属性を持つように再定義されます。このプロシージャの
dml_lock_timeout
パラメータにNULL
以外の値を指定することを検討してください。詳細は、「DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行」のステップp 8を参照してください。 -
仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。
例3
この例では、列をオブジェクト属性に変更するために表を再定義します。再定義した表にオブジェクト型の新しい列を確保します。
元の表(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) ); /
再定義のステップは、次のとおりです。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
表がオンライン再定義の候補であることを確認します。主キーまたは疑似主キーを使用して再定義が実行されるように指定します。
BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE( uname => 'steve', tname =>'customer', options_flag => DBMS_REDEFINITION.CONS_USE_PK); END; /
-
仮表
int_customer
を作成します。CREATE TABLE int_customer( CID NUMBER, NAME VARCHAR2(30), ADDR addr_t);
仮表には主キーが定義されていないことに注意してください。ステップ6で依存オブジェクトがコピーされると、主キー制約と索引がコピーされます。
-
customer
は大きい表であるため、後続のステップのためにパラレル操作を指定します。ALTER SESSION FORCE PARALLEL DML PARALLEL 4; ALTER SESSION FORCE PARALLEL QUERY PARALLEL 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)
は、オブジェクト・コンストラクタへのコールです。 -
依存オブジェクトをコピーします。
DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'steve', orig_table => 'customer', int_table => 'int_customer', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => FALSE, num_errors => num_errors, copy_statistics => TRUE); END; /
このコールの最後の引数は、表の統計が仮表にコピーされることを意味します。
-
必要に応じて、仮表を同期化します。
BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'steve', orig_table => 'customer', int_table => 'int_customer'); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'steve', orig_table => 'customer', int_table => 'int_customer'); END; /
このプロシージャの
dml_lock_timeout
パラメータにNULL
以外の値を指定することを検討してください。詳細は、「DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行」のステップp 8を参照してください。 -
仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。
例4
この例では、依存オブジェクトを手動で作成および登録する必要がある場合を考えてみます。
再定義する表の定義は、次のとおりです。
CREATE TABLE steve.t1 (c1 NUMBER);
表には列c1の索引があります。
CREATE INDEX steve.index1 ON steve.t1(c1);
再定義後に、列c1
が列c2
になる例について考えてみます。この場合、COPY_TABLE_DEPENDENTS
は、index1
に対応して、仮表に対する索引の作成を試行し、仮表には存在しない列c1
に対して索引の作成を試行します。これは結果的にエラーとなります。したがって、列c2
に対しては、索引を手動で作成して登録する必要があります。
再定義のステップは、次のとおりです。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
CAN_REDEF_TABLE
を使用してt1
がオンライン定義の候補であることを確認し、次にSTART_REDEF_TABLE
を使用して再定義プロセスを開始します。BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE( uname => 'steve', tname => 't1', options_flag => DBMS_REDEFINITION.CONS_USE_ROWID); END; /
-
仮表
int_t1
を作成し、列c2
に対して索引int_index1
を作成します。CREATE TABLE steve.int_t1 (c2 NUMBER); CREATE INDEX steve.int_index1 ON steve.int_t1(c2);
-
再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( uname => 'steve', orig_table => 't1', int_table => 'int_t1', col_mapping => 'c1 c2', options_flag => DBMS_REDEFINITION.CONS_USE_ROWID); END; /
-
元(
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; /
-
依存オブジェクトをコピーします。
DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'steve', orig_table => 't1', int_table => 'int_t1', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => TRUE, num_errors => num_errors); END; /
-
必要に応じて、仮表を同期化します。
BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'steve', orig_table => 't1', int_table => 'int_t1'); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'steve', orig_table => 't1', int_table => 'int_t1'); END; /
-
仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。
例5
この例では、複数のパーティションの再定義を示します。レンジ・パーティション化されたsales tableの2つのパーティションを新しい表領域に移動します。再定義するパーティションが含まれている表は、次のようにして定義します。
CREATE TABLE steve.salestable (s_productid NUMBER, s_saledate DATE, s_custid NUMBER, s_totalprice NUMBER) TABLESPACE users PARTITION BY RANGE(s_saledate) (PARTITION sal10q1 VALUES LESS THAN (TO_DATE('01-APR-2010', 'DD-MON-YYYY')), PARTITION sal10q2 VALUES LESS THAN (TO_DATE('01-JUL-2010', 'DD-MON-YYYY')), PARTITION sal10q3 VALUES LESS THAN (TO_DATE('01-OCT-2010', 'DD-MON-YYYY')), PARTITION sal10q4 VALUES LESS THAN (TO_DATE('01-JAN-2011', 'DD-MON-YYYY')));
この例では、sal10q1
パーティションをsales1
表領域に移動し、sal10q2
パーティションをsales2
表領域に移動します。sal10q3
およびsal10q4
パーティションは移動しません。
パーティションを移動するには、表領域sales1
およびsales2
が存在している必要があります。次の例では、これらの表領域を作成します。
CREATE TABLESPACE sales1 DATAFILE '/u02/oracle/data/sales01.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL AUTOALLOCATE; CREATE TABLESPACE sales2 DATAFILE '/u02/oracle/data/sales02.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
ノート:
この操作は、2つのALTER
TABLE
...
MOVE
PARTITION
...
ONLINE
文を実行することによって行うこともできます。「新規セグメントまたは表領域への表の移動」を参照してください。
表には、次のように定義されたローカル・パーティション索引があります。
CREATE INDEX steve.sales_index ON steve.salestable (s_saledate, s_productid, s_custid) LOCAL;
ステップは、次のとおりです。次のプロシージャ・コールでは、パーティション名(part_name
)という特別な引数に注目してください。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
salestable
が再定義の候補であることを確認します。BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE( uname => 'steve', tname => 'salestable', options_flag => DBMS_REDEFINITION.CONS_USE_ROWID, part_name => 'sal10q1, sal10q2'); END; /
-
新しい表領域に仮表を作成します。これはレンジ・パーティションの再定義であるため、仮表は非パーティション表です。
CREATE TABLE steve.int_salestb1 (s_productid NUMBER, s_saledate DATE, s_custid NUMBER, s_totalprice NUMBER) TABLESPACE sales1; CREATE TABLE steve.int_salestb2 (s_productid NUMBER, s_saledate DATE, s_custid NUMBER, s_totalprice NUMBER) TABLESPACE sales2;
-
ROWIDを使用して再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( uname => 'steve', orig_table => 'salestable', int_table => 'int_salestb1, int_salestb2', col_mapping => NULL, options_flag => DBMS_REDEFINITION.CONS_USE_ROWID, part_name => 'sal10q1, sal10q2', continue_after_errors => TRUE); END; /
part_name
パラメータでは両方のパーティションを指定し、int_table
パラメータでは各パーティションの仮表を指定していることに注意してください。また、特定のパーティションでエラーが発生した場合にも再定義プロセスが続行されるように、continue_after_errors
パラメータがTRUE
に設定されています。 -
仮表に対してローカル索引を手動で作成します。
CREATE INDEX steve.int_sales1_index ON steve.int_salestb1 (s_saledate, s_productid, s_custid) TABLESPACE sales1; CREATE INDEX steve.int_sales2_index ON steve.int_salestb2 (s_saledate, s_productid, s_custid) TABLESPACE sales2;
-
必要に応じて、仮表を同期化します。
BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'steve', orig_table => 'salestable', int_table => 'int_salestb1, int_salestb2', part_name => 'sal10q1, sal10q2', continue_after_errors => TRUE); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'steve', orig_table => 'salestable', int_table => 'int_salestb1, int_salestb2', part_name => 'sal10q1, sal10q2', continue_after_errors => TRUE); END; /
このプロシージャの
dml_lock_timeout
パラメータにNULL
以外の値を指定することを検討してください。詳細は、「DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行」のステップp 8を参照してください。 -
仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。
-
(オプション)
DBA_REDEFINITION_STATUS
ビューを問い合せて、各パーティションの再定義が成功したことを確認します。SELECT BASE_TABLE_OWNER, BASE_TABLE_NAME, OPERATION, STATUS FROM DBA_REDEFINITION_STATUS;
いずれかのパーティションの再定義が失敗した場合は、
DBA_REDEFINITION_ERRORS
ビューを問い合せて失敗の原因を確認します。失敗の原因となった状況を修正し、オンライン再定義を再度実行します。
次の問合せは、表内の2つのパーティションが新しい表領域に移動されたことを示しています。
SELECT PARTITION_NAME, TABLESPACE_NAME FROM DBA_TAB_PARTITIONS WHERE TABLE_NAME = 'SALESTABLE'; PARTITION_NAME TABLESPACE_NAME ------------------------------ ------------------------------ SAL10Q1 SALES1 SAL10Q2 SALES2 SAL10Q3 USERS SAL10Q4 USERS 4 rows selected.
例6
この例は、仮想プライベート・データベース(VPD)ポリシーが指定された表のオンライン再定義を示しています。この例では、表の列名および列の型を変更しないで、表のすべてのトリガーを無効にします。
再定義する表の定義は、次のとおりです。
CREATE TABLE hr.employees( employee_id NUMBER(6) PRIMARY KEY, first_name VARCHAR2(20), last_name VARCHAR2(25) CONSTRAINT emp_last_name_nn NOT NULL, email VARCHAR2(25) CONSTRAINT emp_email_nn NOT NULL, phone_number VARCHAR2(20), hire_date DATE CONSTRAINT emp_hire_date_nn NOT NULL, job_id VARCHAR2(10) CONSTRAINT emp_job_nn NOT NULL, salary NUMBER(8,2), commission_pct NUMBER(2,2), manager_id NUMBER(6), department_id NUMBER(4), CONSTRAINT emp_salary_min CHECK (salary > 0), CONSTRAINT emp_email_uk UNIQUE (email));
HR
サンプル・スキーマをインストールした場合は、データベースにこの表が存在します。
次のauth_emp_dep_100
ファンクションがVPDポリシーに対して作成されるとします。
CREATE OR REPLACE FUNCTION hr.auth_emp_dep_100( schema_var IN VARCHAR2, table_var IN VARCHAR2 ) RETURN VARCHAR2 AS return_val VARCHAR2 (400); unm VARCHAR2(30); BEGIN SELECT USER INTO unm FROM DUAL; IF (unm = 'HR') THEN return_val := NULL; ELSE return_val := 'DEPARTMENT_ID = 100'; END IF; RETURN return_val; END auth_emp_dep_100; /
次のADD_POLICY
プロシージャでは、auth_emp_dep_100
ファンクションを使用して、元の表hr.employees
のVPDポリシーを指定しています。
BEGIN DBMS_RLS.ADD_POLICY ( object_schema => 'hr', object_name => 'employees', policy_name => 'employees_policy', function_schema => 'hr', policy_function => 'auth_emp_dep_100', statement_types => 'select, insert, update, delete' ); END; /
この例では、hr.employees
表を再定義して、そのすべてのトリガーを無効にします。再定義中に列名や列の型は変更されません。したがって、START_REFEF_TABLE
プロシージャのcopy_vpd_opt
にDBMS_REDEFINITION.CONS_VPD_AUTO
を指定します。
この再定義のステップは、次のとおりです。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限およびVPDポリシーの管理に必要な権限のあるユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限、および
DBMS_RLS
パッケージに対するEXECUTE
権限を持っている必要があります。「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
表がオンライン再定義の候補であることを確認します。この場合は、主キーまたは疑似主キーを使用して再定義が実行されるように指定します。
BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE('hr','employees', DBMS_REDEFINITION.CONS_USE_PK); END; /
-
仮表
hr.int_employees
を作成します。CREATE TABLE hr.int_employees( employee_id NUMBER(6), first_name VARCHAR2(20), last_name VARCHAR2(25), email VARCHAR2(25), phone_number VARCHAR2(20), hire_date DATE, job_id VARCHAR2(10), salary NUMBER(8,2), commission_pct NUMBER(2,2), manager_id NUMBER(6), department_id NUMBER(4));
-
再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE ( uname => 'hr', orig_table => 'employees', int_table => 'int_employees', col_mapping => NULL, options_flag => DBMS_REDEFINITION.CONS_USE_PK, orderby_cols => NULL, part_name => NULL, copy_vpd_opt => DBMS_REDEFINITION.CONS_VPD_AUTO); END; /
copy_vpd_opt
パラメータがDBMS_REDEFINITION.CONS_VPD_AUTO
に設定されている場合、表の所有者およびオンライン再定義を開始したユーザーのみがオンライン再定義中に仮表にアクセスできます。また、
col_mapping
パラメータがNULL
に設定されていることにも注意してください。copy_vpd_opt
パラメータがDBMS_REDEFINITION.CONS_VPD_AUTO
に設定されている場合、col_mapping
パラメータはNULL
または'*'
であることが必要です。「オンライン再定義時の仮想プライベート・データベース(VPD)ポリシーの処理」を参照してください。 -
依存オブジェクトをコピーします。(
hr.int_employees
に対するトリガー、索引、マテリアライズド・ビュー・ログ、権限付与および制約がある場合、それらは自動的に作成されます。)DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'hr', orig_table => 'employees', int_table => 'int_employees', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => FALSE, num_errors => num_errors); END; /
-
仮表に対するすべてのトリガーを無効にします。
ALTER TABLE hr.int_employees DISABLE ALL TRIGGERS;
-
(オプション)仮表
hr.int_employees
を同期化します。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'hr', orig_table => 'employees', int_table => 'int_employees'); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'hr', orig_table => 'employees', int_table => 'int_employees'); END; /
このステップが終了するまでに、わずかな間のみ、表
hr.employees
が排他モードでロックされます。このコールの後、表hr.employees
はhr.int_employees
表のすべての属性を持つように再定義されます。このプロシージャの
dml_lock_timeout
パラメータにNULL
以外の値を指定することを検討してください。詳細は、「DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行」のステップp 8を参照してください。 -
仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。
例7
この例は、仮想プライベート・データベース(VPD)ポリシーが指定された表のオンライン再定義を示しています。この例では、表の列名を変更します。
再定義する表の定義は、次のとおりです。
CREATE TABLE oe.orders( order_id NUMBER(12) PRIMARY KEY, order_date TIMESTAMP WITH LOCAL TIME ZONE CONSTRAINT order_date_nn NOT NULL, order_mode VARCHAR2(8), customer_id NUMBER(6) CONSTRAINT order_customer_id_nn NOT NULL, order_status NUMBER(2), order_total NUMBER(8,2), sales_rep_id NUMBER(6), promotion_id NUMBER(6), CONSTRAINT order_mode_lov CHECK (order_mode in ('direct','online')), CONSTRAINT order_total_min check (order_total >= 0));
OE
サンプル・スキーマをインストールした場合は、データベースにこの表が存在します。
次のauth_orders
ファンクションがVPDポリシーに対して作成されるとします。
CREATE OR REPLACE FUNCTION oe.auth_orders( schema_var IN VARCHAR2, table_var IN VARCHAR2 ) RETURN VARCHAR2 AS return_val VARCHAR2 (400); unm VARCHAR2(30); BEGIN SELECT USER INTO unm FROM DUAL; IF (unm = 'OE') THEN return_val := NULL; ELSE return_val := 'SALES_REP_ID = 159'; END IF; RETURN return_val; END auth_orders; /
次のADD_POLICY
プロシージャでは、auth_orders
ファンクションを使用して、元の表oe.orders
のVPDポリシーを指定しています。
BEGIN DBMS_RLS.ADD_POLICY ( object_schema => 'oe', object_name => 'orders', policy_name => 'orders_policy', function_schema => 'oe', policy_function => 'auth_orders', statement_types => 'select, insert, update, delete'); END; /
この例では、表を再定義してsales_rep_id
列をsale_pid
に変更します。再定義中に1つ以上の列名または列の型を変更する場合、START_REFEF_TABLE
プロシージャのcopy_vpd_opt
にDBMS_REDEFINITION.CONS_VPD_MANUAL
を指定する必要があります。
この再定義のステップは、次のとおりです。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限およびVPDポリシーの管理に必要な権限のあるユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限、および
DBMS_RLS
パッケージに対するEXECUTE
権限を持っている必要があります。「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
表がオンライン再定義の候補であることを確認します。この場合は、主キーまたは疑似主キーを使用して再定義が実行されるように指定します。
BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE( uname => 'oe', tname => 'orders', options_flag => DBMS_REDEFINITION.CONS_USE_PK); END; /
-
仮表
oe.int_orders
を作成します。CREATE TABLE oe.int_orders( order_id NUMBER(12), order_date TIMESTAMP WITH LOCAL TIME ZONE, order_mode VARCHAR2(8), customer_id NUMBER(6), order_status NUMBER(2), order_total NUMBER(8,2), sales_pid NUMBER(6), promotion_id NUMBER(6));
仮表では
sales_rep_id
列がsales_pid
列に変更されていることに注意してください。 -
再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE ( uname => 'oe', orig_table => 'orders', int_table => 'int_orders', col_mapping => 'order_id order_id, order_date order_date, order_mode order_mode, customer_id customer_id, order_status order_status, order_total order_total, sales_rep_id sales_pid, promotion_id promotion_id', options_flag => DBMS_REDEFINITION.CONS_USE_PK, orderby_cols => NULL, part_name => NULL, copy_vpd_opt => DBMS_REDEFINITION.CONS_VPD_MANUAL); END; /
元の表と仮表で列名が異なるため、
copy_vpd_opt
パラメータにDBMS_REDEFINITION.CONS_VPD_MANUAL
を指定する必要があります。「オンライン再定義時の仮想プライベート・データベース(VPD)ポリシーの処理」を参照してください。 -
仮表に対するVPDポリシーを作成します。
この例では、次のステップを実行します。
-
sales_rep_id
列のかわりにsales_pid
列を指定するVPDポリシーのために、auth_orders_sales_pid
という新しいファンクションを作成します。CREATE OR REPLACE FUNCTION oe.auth_orders_sales_pid( schema_var IN VARCHAR2, table_var IN VARCHAR2 ) RETURN VARCHAR2 AS return_val VARCHAR2 (400); unm VARCHAR2(30); BEGIN SELECT USER INTO unm FROM DUAL; IF (unm = 'OE') THEN return_val := NULL; ELSE return_val := 'SALES_PID = 159'; END IF; RETURN return_val; END auth_orders_sales_pid; /
-
ADD_POLICY
プロシージャを実行し、新しいファンクションauth_orders_sales_pid
および仮表int_orders
を指定します。BEGIN DBMS_RLS.ADD_POLICY ( object_schema => 'oe', object_name => 'int_orders', policy_name => 'orders_policy', function_schema => 'oe', policy_function => 'auth_orders_sales_pid', statement_types => 'select, insert, update, delete'); END; /
-
-
依存オブジェクトをコピーします。(
oe.int_orders
に対するトリガー、索引、マテリアライズド・ビュー・ログ、権限付与および制約がある場合、それらは自動的に作成されます。)DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'oe', orig_table => 'orders', int_table => 'int_orders', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => TRUE, num_errors => num_errors); END; /
このコールでは、
ignore_errors
引数がTRUE
に設定されていることに注意してください。これは、元の表にはsales_rep_id
列に関連する索引および制約があり、仮表ではこの列がsales_pid
に変更されるためです。次のステップではエラーを示し、仮表に対して索引と制約を作成する方法を説明します。 -
DBA_REDEFINITION_ERRORS
ビューを問い合せて、エラーをチェックします。SET LONG 8000 SET PAGES 8000 COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A20 COLUMN BASE_TABLE_NAME HEADING 'Base Table Name' FORMAT A10 COLUMN DDL_TXT HEADING 'DDL That Caused Error' FORMAT A40 SELECT OBJECT_NAME, BASE_TABLE_NAME, DDL_TXT FROM DBA_REDEFINITION_ERRORS; Object Name Base Table DDL That Caused Error -------------------- ---------- ---------------------------------------- ORDERS_SALES_REP_FK ORDERS ALTER TABLE "OE"."INT_ORDERS" ADD CONSTR AINT "TMP$$_ORDERS_SALES_REP_FK1" FOREIG N KEY ("SALES_REP_ID") REFERENCES "HR"."EMPLOYEES" ("EMPLOYE E_ID") ON DELETE SET NULL DISABLE ORD_SALES_REP_IX ORDERS CREATE INDEX "OE"."TMP$$_ORD_SALES_REP_I X0" ON "OE"."INT_ORDERS" ("SALES_REP_ID" ) PCTFREE 10 INITRANS 2 MAXTRANS 255 COM PUTE STATISTICS STORAGE(INITIAL 65536 NEXT 1048576 MIN EXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GRO UPS 1 BUFFER_POOL DEFAULT) TABLESPACE "EXAMPLE" TMP$$_ORDERS_SALES_R ORDERS ALTER TABLE "OE"."INT_ORDERS" ADD CONSTR EP_FK0 AINT "TMP$$_TMP$$_ORDERS_SALES_RE0" FORE IGN KEY ("SALES_REP_ID") REFERENCES "HR"."INT_EMPLOYEES" ("EMP LOYEE_ID") ON DELETE SET NULL DISABLE
必要に応じて、出力でレポートされたエラーを修正します。
この例では、元の表に
sales_rep_id
列に対する索引および外部キー制約があります。列名がsales_rep_id
からsales_pid
に変更されたため、索引と制約を仮表にコピーできませんでした。問題を修正するには、次のステップを実行して、仮表に対する索引と制約を追加します。
-
索引を追加します。
ALTER TABLE oe.int_orders ADD (CONSTRAINT orders_sales_pid_fk FOREIGN KEY (sales_pid) REFERENCES hr.employees(employee_id) ON DELETE SET NULL);
-
外部キー制約を追加します。
CREATE INDEX ord_sales_pid_ix ON oe.int_orders (sales_pid);
-
-
(オプション)仮表
oe.int_orders
を同期化します。BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'oe', orig_table => 'orders', int_table => 'int_orders'); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'oe', orig_table => 'orders', int_table => 'int_orders'); END; /
このステップが終了するまでに、わずかな間のみ、表
oe.orders
が排他モードでロックされます。このコールの後、表oe.orders
はoe.int_orders
表のすべての属性を持つように再定義されます。このプロシージャの
dml_lock_timeout
パラメータにNULL
以外の値を指定することを検討してください。詳細は、「DBMS_REDEFINITIONの複数のプロシージャを使用したオンライン再定義の実行」のステップp 8を参照してください。 -
仮表に対する長時間実行の問合せがある場合は、完了するのを待ってから、仮表を削除します。
例8
この例では、オンライン再定義を使用した表の複数の変更について説明します。
再定義する表の定義は、次のとおりです。
CREATE TABLE testredef.original( col1 NUMBER PRIMARY KEY, col2 VARCHAR2(10), col3 CLOB, col4 DATE) ORGANIZATION INDEX;
表は次のようにして再定義します。
-
表は、高度な行圧縮を使用して圧縮します。
-
LOB列をSecureFiles LOB記憶域に変更します。
-
表の表領域を
example
からtestredeftbs
に変更し、表のブロック・サイズを8KBから16KBに変更します。この例では、データベースのブロック・サイズを8KBとしています。また、この例では、
DB_16K_CACHE_SIZE
初期化パラメータが設定され、testredef
表領域が16KBのブロック・サイズで作成されていると仮定しています。例:CREATE TABLESPACE testredeftbs DATAFILE '/u01/app/oracle/oradata/testredef01.dbf' SIZE 500M EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO BLOCKSIZE 16384;
-
表は
col1
列でパーティション化します。 -
col5
列を追加します。 -
col2
列を削除します。 -
列
col3
およびcol4
の名前を変更し、表におけるその位置を変更します。 -
col3
列のタイプをDATE
からTIMESTAMP
に変更します。 -
表を索引構成表(IOT)からヒープ構成表に変更します。
-
表の断片化を解消します。
断片化の解消を示すには、表にデータが移入されている必要があります。この例の目的のために、次のPL/SQLブロックを使用して表にデータを移入できます。
DECLARE V_CLOB CLOB; BEGIN FOR I IN 0..999 LOOP V_CLOB := NULL; FOR J IN 1..1000 LOOP V_CLOB := V_CLOB||TO_CHAR(I,'0000'); END LOOP; INSERT INTO testredef.original VALUES(I,TO_CHAR(I),V_CLOB,SYSDATE+I); COMMIT; END LOOP; COMMIT; END; /
次のSQL文を実行し、3番目の行を削除して表を断片化します。
DELETE FROM testredef.original WHERE (COL1/3) <> TRUNC(COL1/3);
DBMS_SPACE.SPACE_USAGE
プロシージャを使用して断片化を確認できます。関連項目:
DBMS_SPACE.SPACE_USAGE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
この再定義のステップは、次のとおりです。
-
SQL*Plusで、表のオンライン再定義の実行に必要な権限を持つユーザーとして接続します。
特に、ユーザーは「DBMS_REDEFINITIONパッケージに必要な権限」に記載されている権限を持っている必要があります。
「SQL*Plusを使用したデータベースへの接続」を参照してください。
-
表がオンライン再定義の候補であることを確認します。この場合は、主キーまたは疑似主キーを使用して再定義が実行されるように指定します。
BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE( uname => 'testredef', tname => 'original', options_flag => DBMS_REDEFINITION.CONS_USE_PK); END; /
-
仮表
testredef.interim
を作成します。CREATE TABLE testredef.interim( col1 NUMBER, col3 TIMESTAMP, col4 CLOB, col5 VARCHAR2(3)) LOB(col4) STORE AS SECUREFILE (NOCACHE FILESYSTEM_LIKE_LOGGING) PARTITION BY RANGE (COL1) ( PARTITION par1 VALUES LESS THAN (333), PARTITION par2 VALUES LESS THAN (666), PARTITION par3 VALUES LESS THAN (MAXVALUE)) TABLESPACE testredeftbs ROW STORE COMPRESS ADVANCED;
-
再定義プロセスを開始します。
BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( uname => 'testredef', orig_table => 'original', int_table => 'interim', col_mapping => 'col1 col1, TO_TIMESTAMP(col4) col3, col3 col4', options_flag => DBMS_REDEFINITION.CONS_USE_PK); END; /
-
依存オブジェクトをコピーします。
DECLARE num_errors PLS_INTEGER; BEGIN DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS( uname => 'testredef', orig_table => 'original', int_table => 'interim', copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS, copy_triggers => TRUE, copy_constraints => TRUE, copy_privileges => TRUE, ignore_errors => TRUE, num_errors => num_errors); END; /
-
必要に応じて、仮表を同期化します。
BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( uname => 'testredef', orig_table => 'original', int_table => 'interim'); END; /
-
再定義を完了します。
BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( uname => 'testredef', orig_table => 'original', int_table => 'interim'); END; /
親トピック: 表のオンライン再定義
20.9 エラーが発生した表の変更の調査と取消し
表に対してエラーが発生する変更を調査して取り消せるようにするために、Oracle Databaseには、データベース・オブジェクトの過去の状態を表示したり、Point-in-Timeメディア・リカバリを使用せずにデータベース・オブジェクトを以前の状態に戻すために使用できる一連の機能が用意されています。これらの機能はOracle Flashback機能と呼ばれます。
エラーが発生する変更を調査するために、複数の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管理の概要」を参照してください。
関連項目:
親トピック: 表の管理
20.10 Oracle Flashback Tableを使用した表のリカバリ
Oracle Flashback Tableを使用すると、表を以前の時点の状態にリストアできます。
この機能では、ユーザーまたはアプリケーションにより、誤って変更または削除された表のリカバリを行うための、迅速なオンラインによる解決方法が提供されています。多くの場合、Oracle Flashback Tableを使用することで、管理者がより複雑なポイント・イン・タイム・リカバリ操作を実行する必要はなくなります。
Oracle Flashback Table:
-
指定された表のすべてのデータが、タイムスタンプまたはSCNで表された以前の時点にリストアされます。
-
リストア操作はオンラインで実行されます。
-
アプリケーションがフラッシュバックされた表を使用して機能するために必要な索引、トリガー、制約など、表の属性すべてが自動的に維持されます。
-
分散環境におけるすべてのリモート状態が維持されます。たとえば、レプリケート表がフラッシュバックされる場合は、レプリケーションに必要な表の変更すべてが維持されます。
-
制約によって指定されているデータの整合性が維持されます。表は、表の制約すべてに違反していないことを条件にしてフラッシュバックされます。この制約には、
FLASHBACK TABLE
文の対象になっている表とFLASHBACK TABLE
文の対象になっていない表との間に指定されている参照整合性制約も含まれます。 -
フラッシュバック操作後も、元の表のデータは消失しません。後で、元の状態に戻すことができます。
ノート:
Oracle Flashback Tableを使用するには、自動UNDO管理を使用している必要があります。「自動UNDO管理の概要」を参照してください。
関連項目:
FLASHBACK TABLE
文の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
親トピック: 表の管理
20.11 表の削除
不要になった表を削除するには、DROP TABLE
文を使用します。
削除する表は、自分のスキーマに含まれているか、またはDROP ANY TABLE
システム権限を持っている必要があります。
ノート:
表を削除する前に、表を削除した結果についてよく理解しておいてください。
-
表を削除すると、その表定義はデータ・ディクショナリから削除されます。その結果、表のすべての行はアクセスできなくなります。
-
表に対応付けられている索引とトリガーは、すべて削除されます。
-
削除した表に依存しているビューとPL/SQLプログラム・ユニットはすべてそのまま残りますが、無効になります(使用できません)。データベースによる依存性管理の詳細は、「オブジェクト依存性の管理」を参照してください。
-
削除する表のシノニムはすべてそのまま残りますが、使用するとエラーが返されます。
-
削除した表に割り当てられていたエクステントは表領域の空き領域にすべて戻され、新しいエクステントまたは新しいオブジェクトを必要とするその他のオブジェクトによって再利用されます。クラスタ化表に対応する行はすべて、そのクラスタのブロックから削除されます。クラスタ化表の説明は、「クラスタの管理」を参照してください。
次の文は、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
文の説明は、「表とクラスタの切捨て」を参照してください。
Live SQL:
Oracle Live SQLの関連する例をOracle Live SQL: 表の作成および変更で参照して実行してください。
親トピック: 表の管理
20.12 フラッシュバック・ドロップの使用とリサイクル・ビンの管理
表を削除した場合、その表に関連付けられている領域はデータベースによってすぐには削除されません。データベースによってこの表の名前が変更され、すべての関連オブジェクトとともにリサイクル・ビンへ入れられますが、後に表が誤って削除されたことがわかった場合、リサイクル・ビンからリカバリすることができます。この機能はフラッシュバック・ドロップと呼ばれ、表のリストアにはFLASHBACK
TABLE
文が使用されます。
この目的のためのFLASHBACK
TABLE
文の使用方法を説明する前に、リサイクル・ビンの機能と、その内容の管理方法を理解することが重要です。
- リサイクル・ビンの概要
リサイクル・ビンとは、実際には、削除されたオブジェクトに関する情報を含んでいるデータ・ディクショナリ表です。削除された表および関連するオブジェクト(索引、制約、ネストした表など)は、実際には削除されず、領域を占有しています。 - リサイクル・ビンの有効化と無効化
リサイクル・ビンが有効化されていると、削除した表とその依存オブジェクトはリサイクル・ビンに配置されます。リサイクル・ビンが無効になっている場合、削除された表およびその依存オブジェクトはリサイクル・ビンに配置されず削除されるため、リカバリするには他の手段(バックアップからのリカバリなど)を使用する必要があります。 - リサイクル・ビン内のオブジェクトの表示と問合せ
リサイクル・ビンのオブジェクトに関する情報を取得するために、Oracle Databaseには2つのビューが用意されています。 - リサイクル・ビン内のオブジェクトのパージ
リサイクル・ビンから項目をリストアすることはないと判断した場合は、PURGE
文を使用して、項目および関連するオブジェクトをリサイクル・ビンから削除し、記憶域を解放できます。実行するには、項目を削除する場合と同じ権限が必要です。 - リサイクル・ビンからの表のリストア
FLASHBACK
TABLE
...TO
BEFORE
DROP
文を使用すると、リサイクル・ビンからオブジェクトをリカバリできます。
親トピック: 表の管理
20.12.1 リサイクル・ビンの概要
リサイクル・ビンとは、実際には、削除されたオブジェクトに関する情報を含んでいるデータ・ディクショナリ表です。削除された表および関連するオブジェクト(索引、制約、ネストした表など)は、実際には削除されず、領域を占有しています。
この領域は、リサイクル・ビンから明確にパージされるまで、または、あまり可能性はありませんが、表領域の制約のためにデータベースによるパージが必要になるまでは、ユーザー領域の割当てにとって不利です。
ユーザーにSYSDBA
権限がない場合、リサイクル・ビンの中でユーザーが所有するオブジェクトは、アクセス権があるオブジェクトのみであるため、各ユーザーには各自のリサイクル・ビンがあるとみなすことができます。リサイクル・ビンにある各自のオブジェクトは、次の文を使用して表示できます。
SELECT * FROM RECYCLEBIN;
DROP
TABLE
SQL文のみがオブジェクトをリサイクル・ビンに配置します。これにより、表とその表に関連するオブジェクトが追加されるため、それらをグループとしてリカバリできるようになります。表自体の他に、リサイクル・ビンに追加された関連するオブジェクトにも、次のタイプのオブジェクトを含めることができます。
-
ネストした表
-
LOBセグメント
-
索引
-
制約(外部キー制約以外)
-
トリガー
-
クラスタ
表領域をその内容も含めて削除すると、表領域内のオブジェクトはリサイクル・ビンに配置されず、その表領域に配置されていたオブジェクトに対するリサイクル・ビン内のエントリはすべてパージされます。内容を含まない表領域を削除した場合、つまり空の表領域を削除した場合も、表領域内のオブジェクトに対するリサイクル・ビン内のエントリがすべてパージされます。同様に、それぞれの削除操作は次のように処理されます。
-
ユーザーを削除すると、そのユーザーが所有しているオブジェクトはリサイクル・ビンには配置されず、リサイクル・ビン内のオブジェクトがすべてパージされます。
-
クラスタを削除すると、そのメンバー表はリサイクル・ビンには配置されず、リサイクル・ビン内の古いメンバー表がすべてパージされます。
-
タイプを削除すると、サブタイプなどの依存オブジェクトはリサイクル・ビンには配置されず、リサイクル・ビン内の古い依存オブジェクトがすべてパージされます。
リサイクル・ビン内のオブジェクト名の変更
削除された表をリサイクル・ビンに移動すると、その表とその表に関連するオブジェクトには、システムで生成された名前が割り当てられます。名前の変更は、複数の表が同じ名前の場合に発生する可能性がある、名前の競合を回避するために必要です。名前の変更は、次の状況で発生します。
-
ユーザーが表を削除し、同じ名前で表を作成し、その後、作成した表を再度削除した場合。
-
2人のユーザーが同じ名前の表を持ち、両方のユーザーが各自の表を削除した場合。
名前変更の表記規則は、次のとおりです。
BIN$unique_id
$version
ここで:
-
unique_id
は、このオブジェクトに対する、26文字からなるグローバルに一意の識別子です。これによって、リサイクル・ビンの名前がすべてのデータベース全体で一意に識別されます。 -
version
は、データベースによって割り当てられるバージョン番号です。
親トピック: フラッシュバック・ドロップの使用とリサイクル・ビンの管理
20.12.2 リサイクル・ビンの有効化と無効化
リサイクル・ビンが有効化されていると、削除した表とその依存オブジェクトはリサイクル・ビンに配置されます。リサイクル・ビンが無効になっている場合、削除された表およびその依存オブジェクトはリサイクル・ビンに配置されず削除されるため、リカバリするには他の手段(バックアップからのリカバリなど)を使用する必要があります。
リサイクルビンを無効にしても、リサイクルビンにすでにあるオブジェクトはパージされず、影響も受けません。デフォルトで、リサイクル・ビンは有効になっています。
リサイクル・ビンは、recyclebin
初期化パラメータを変更して有効化および無効化できます。このパラメータは動的ではないため、ALTER
SYSTEM
文で変更したときにはデータベースの再起動が必要です。
リサイクル・ビンを有効化するには:
-
次のいずれかの文を発行します。
ALTER SESSION SET recyclebin = ON; ALTER SYSTEM SET recyclebin = ON SCOPE = SPFILE;
-
ALTER
SYSTEM
を使用した場合は、データベースを再起動します。
リサイクル・ビンを無効化するには:
-
次のいずれかの文を発行します。
ALTER SESSION SET recyclebin = OFF; ALTER SYSTEM SET recyclebin = OFF SCOPE = SPFILE;
-
ALTER
SYSTEM
を使用した場合は、データベースを再起動します。
関連項目:
-
初期化パラメータの詳細は、「初期化パラメータと初期化パラメータ・ファイルについて」を参照してください
-
動的な初期化パラメータおよび静的な初期化パラメータについては、「初期化パラメータ値の変更」を参照してください
親トピック: フラッシュバック・ドロップの使用とリサイクル・ビンの管理
20.12.3 リサイクル・ビン内のオブジェクトの表示と問合せ
リサイクル・ビンのオブジェクトに関する情報を取得するために、Oracle Databaseには2つのビューが用意されています。
ビュー | 説明 |
---|---|
|
ユーザーはこのビューを使用して、リサイクル・ビンにある削除された自分のオブジェクトを表示できます。使用しやすいように、シノニム |
|
管理者はこのビューを使用して、リサイクル・ビンにある削除されたすべてのオブジェクトを表示できます。 |
これらのビューの使用目的の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";
親トピック: フラッシュバック・ドロップの使用とリサイクル・ビンの管理
20.12.4 リサイクル・ビン内のオブジェクトのパージ
リサイクル・ビンから項目をリストアすることはないと判断した場合は、PURGE
文を使用して、項目および関連するオブジェクトをリサイクル・ビンから削除し、記憶域を解放できます。実行するには、項目を削除する場合と同じ権限が必要です。
PURGE
文を使用して表をパージする場合、リサイクル・ビンでの表の名前、または表の元の名前を使用できます。「リサイクル・ビン内のオブジェクトの表示と問合せ」で説明されているように、リサイクル・ビンでの名前はDBA_
またはUSER_RECYCLEBIN
ビューから取得できます。次の仮定的な例では、リサイクル・ビンに配置されたときにBIN$jsleilx392mk2=293$0
に名前が変更された表hr.int_admin_emp
をパージします。
PURGE TABLE "BIN$jsleilx392mk2=293$0";
次の文を使用しても同様の結果となります。
PURGE TABLE int_admin_emp;
PURGE
文を使用すると、指定の表領域からリサイクル・ビンのすべてのオブジェクトをパージ、または指定のユーザーに属する表領域オブジェクトのみをパージできます。次に例を示します。
PURGE TABLESPACE example; PURGE TABLESPACE example USER oe;
次の文を使用することで、ユーザーは独自のオブジェクトのリサイクル・ビンをパージして、オブジェクトの領域を解放できます。
PURGE RECYCLEBIN;
SYSDBA
権限またはPURGE
DBA_RECYCLEBIN
システム権限がある場合は、前述の文のRECYCLEBIN
のかわりに、DBA_RECYCLEBIN
を指定することによって、リサイクル・ビン全体をパージできます。
また、PURGE
文を使用して、リサイクル・ビンから索引をパージ、またはリサイクル・ビンから指定の表領域にあるすべてのオブジェクトをパージすることもできます。
関連項目:
PURGE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: フラッシュバック・ドロップの使用とリサイクル・ビンの管理
20.12.5 リサイクル・ビンからの表のリストア
FLASHBACK
TABLE
... TO
BEFORE
DROP
文を使用すると、リサイクル・ビンからオブジェクトをリカバリできます。
ごみ箱内の表の名前または元の表の名前のいずれかを指定できます。オプションのRENAME TO
句を使用すると、表をリカバリするときに名前を変更できます。「リサイクル・ビン内のオブジェクトの表示と問合せ」で説明されているように、リサイクル・ビンでの名前はDBA_
または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
ユーザーとしてログインしていることを想定しています。
親トピック: フラッシュバック・ドロップの使用とリサイクル・ビンの管理
20.13 索引構成表の管理
索引構成表の記憶域の編成は、プライマリBツリー索引の変形です。ヒープ構成表とは異なり、データは主キーの順に格納されます。
- 索引構成表の概要
索引構成表は、プライマリBツリーの異形である記憶域編成を持っています。順序付けされていないコレクション(ヒープ)としてデータを格納する通常の(ヒープ構成)表とは異なり、索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納されます。索引構造の各リーフ・ブロックには、キー列と非キー列の両方が格納されます。 - 索引構成表の作成
索引構成表により、高速な主キー・アクセスと高可用性が実現します。 - 索引構成表のメンテナンス
索引構成表と通常の表の相違点は、物理的な構成のみです。論理的には、通常の表と同じように操作されます。INSERT
、SELECT
、DELETE
およびUPDATE
の各文では、通常の表を指定する場合と同じように、索引構成表を指定できます。 - 索引構成表に対する2次索引の作成
2次索引は索引構成表の索引です。2次索引は独立したスキーマ・オブジェクトであり、索引構成表とは別に格納されます。 - 索引構成表の分析
通常の表と同様に、索引構成表の分析にはDBMS_STATS
パッケージ、またはANALYZE
文を使用します。 - 索引構成表でのORDER BY句の使用
ORDER BY
句が主キー列またはその接頭辞のみを参照する場合、行は主キー列でソートされた状態で返されるため、オプティマイザはソートのオーバーヘッドを回避します。 - 索引構成表の標準的な表への変換
索引構成表を標準的な(ヒープ構成)表に変換するには、Oracleのインポート/エクスポート・ユーティリティ、あるいはCREATE TABLE...AS SELECT
文を使用できます。
親トピック: 表の管理
20.13.1 索引構成表の概要
索引構成表は、プライマリBツリーの異形である記憶域編成を持っています。順序付けされていないコレクション(ヒープ)としてデータを格納する通常の(ヒープ構成)表とは異なり、索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納されます。索引構造の各リーフ・ブロックには、キー列と非キー列の両方が格納されます。
索引構成表の構造には、次の利点があります。
-
索引のみのスキャンで十分なため、主キーに対して高速にランダム・アクセスできます。また、索引構造以外に表記憶域がないため、新しい行の追加、行の更新、行の削除などにより表データを変更すると、索引構造の更新のみが実行されます。
-
行が主キー順にクラスタ化されているため、主キーに対して高速にレンジ・アクセスできます。
-
主キーの複製が回避されるため、記憶域の所要量を低く抑えられます。ヒープ構成表の場合、主キーは索引と基礎になる表の両方には格納されません。
索引構成表は、すべての表機能を備えています。制約、トリガー、LOB列とオブジェクト列、パーティション化、パラレル操作、オンライン再編成、およびレプリケーションなどの機能をサポートします。さらに、次の機能も提供します。
-
接頭辞圧縮
-
オーバーフロー記憶域と固有の列配置
-
ビットマップ索引を含めた2次索引。
高速な主キー・アクセスと高可用性を必要とするOLTPアプリケーションには、索引構成表が理想的です。たとえば、電子注文処理に使用される注文表の問合せおよびDMLは大部分が主キー・アクセスに基づいており、同時DMLの大量ボリュームが行の変更や索引での非効率な領域の使用の原因となり、再編成が頻繁に必要となります。索引構成表は、2次索引を無効化せずにオンラインで再編成できるため、ウィンドウの使用を制限される時間が大幅に短縮または排除されます。
索引構成表は、アプリケーション固有の索引構造をモデル化するのに適しています。たとえば、テキスト、イメージおよびオーディオ・データを含むコンテンツ・ベースの情報検索アプリケーションには、索引構成表を使用して有効にモデル化できる逆索引が必要です。インターネット検索エンジンの基本の構成要素は、索引構成表を使用してモデル化できる逆向きの索引です。
これらは、索引構成表のアプリケーションのほんの数例です。
関連項目:
-
索引構成表の詳細は、『Oracle Database概要』を参照してください
-
索引構成表のパーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
親トピック: 索引構成表の管理
20.13.2 索引構成表の作成
索引構成表により、高速な主キー・アクセスと高可用性が実現します。
- 索引構成表の作成について
CREATE TABLE
文を使用して索引構成表を作成します。 - 例: 索引構成表の作成
例を使用して索引構成表の作成を説明します。 - 索引構成表に対する制限
索引構成表を作成する際には、いくつかの制限が適用されます。 - オブジェクト型を含む索引構成表の作成
索引構成表にオブジェクト型を格納できます。 - しきい値の選択と監視
キー列、および最初のいくつかの非キー列(頻繁にアクセスされる場合)を取り込めるしきい値を選択します。 - INCLUDING句の使用
PCTTHRESHOLD
の指定に加え、INCLUDING
句を使用して、索引構成表にキー列とともに保存する非キー列を制御できます。 - 索引構成表作成のパラレル化
CREATE TABLE...AS SELECT
文を使用すると、索引構成表を作成して、既存の表からその索引構成表にデータをロードできます。PARALLEL
句を指定することによって、ロードをパラレルで実行できます。 - 接頭辞圧縮の使用
接頭辞圧縮(キー圧縮とも呼ばれます)を使用して索引構成表を作成すると、キー列の接頭辞が同じ値で繰り返し格納されるのを回避できます。
親トピック: 索引構成表の管理
20.13.2.1 索引構成表の作成について
CREATE TABLE
文を使用して索引構成表を作成します。
索引構成表を作成する際には、次のような追加情報を指定する必要があります。
-
ORGANIZATION INDEX
修飾子。これによって、索引構成表であることを示します。 -
主キー。主キーは、単一列主キーの場合は列制約句、複数列主キーの場合は表制約句によって指定します。
必要に応じて、次の情報を指定できます。
-
OVERFLOW
句。この句は、非キー列の一部を別のオーバーフロー・データ・セグメントに格納できるようにすることにより、Bツリー索引の稠密なクラスタを保ちます。 -
PCTTHRESHOLD
値。これは、オーバーフロー・セグメントが使用されている際、索引ブロックに保存される行の部分の最大サイズを、ブロック・サイズのパーセンテージとして定義します。この行サイズが最大値を超える行の列は、オーバーフロー・セグメントに格納されます。行は、列境界で先頭部分と後尾部分の2つの部分に分割されます。先頭部分は指定されたしきい値に収まり、索引リーフ・ブロックのキーとともに格納されます。後尾部分は1つ以上の行の部分としてオーバーフロー領域に格納されます。このようにして、索引エントリにはキー値、指定したしきい値に収まる非キー列値、および行の残りの部分へのポインタが含まれます。 -
INCLUDING
句。この句は、主キーとともに索引ブロックに格納される非キー列を指定するために使用できます。
親トピック: 索引構成表の作成
20.13.2.2 例: 索引構成表の作成
例を使用して索引構成表の作成を説明します。
次の文によって、索引構成表が作成されます。
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言語リファレンス』を参照してください。
親トピック: 索引構成表の作成
20.13.2.3 索引構成表に対する制限
索引構成表を作成する際には、いくつかの制限が適用されます。
索引構成表の作成には、次の制限があります。
-
列の最大数は1000です。
-
キー列と非キー列を含めて、行の索引部分の最大列数は255です。255個を超える列が必要な場合は、オーバーフロー・セグメントを使用する必要があります。
-
主キーに含めることができる最大列数は32です。
-
PCTTHRESHOLD
は1から50の範囲内である必要があります。デフォルトは50です。 -
すべてのキー列は、指定したしきい値内に収まる必要があります。
-
行の最大サイズが索引ブロック・サイズの50%を超える場合に、オーバーフロー・セグメントを指定しないと、
CREATE
TABLE
文が失敗します。 -
索引構成表に仮想列は設定できません。
-
表に外部キーが含まれ、外部キーの親が索引構成表の場合は、別のセッションが親表のキー以外の列を更新中のとき、外部キーを含む行を更新するセッションがハングすることがあります。
たとえば、
departments
表が索引構成表で、department_id
がその主キーであるとします。employees
表は、departments
表の外部キーであるdepartment_id
列を持ちます。あるセッションが、departments
表のdepartment_id
が20
である行のdepartment_name
を更新中のとき、別のセッションが、employees
表のdepartment_id
が20
である行を更新中であるとします。この場合、departments
表を更新中のセッションがコミットされるかロールバックされるまで、employees
表を更新中のセッションがハングすることがあります。 - 1つ以上のLOB列を含む索引構成表は、パラレルに移動できません。
親トピック: 索引構成表の作成
20.13.2.4 オブジェクト型を含む索引構成表の作成
索引構成表は、オブジェクト型を格納できます。
次の例は、オブジェクト型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オブジェクト・リレーショナル開発者ガイド』を参照してください。
親トピック: 索引構成表の作成
20.13.2.5 しきい値の選択と監視
キー列とともに最初のいくつかの非キー列が頻繁にアクセスされる場合は、その非キー列を取り込めるしきい値を選択してください。
しきい値を選択した後、指定した値が適切な値であることを確認するために、表を監視できます。ANALYZE
TABLE
... LIST
CHAINED
ROWS
文を使用して、しきい値を超える行の数と、どの行がしきい値を超えているかを判断できます。
関連項目:
-
連鎖行の詳細は、「表とクラスタの連鎖行のリスト」を参照してください
-
ANALYZE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 索引構成表の作成
20.13.2.6 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つの列のみ)が格納されます。
親トピック: 索引構成表の作成
20.13.2.7 索引構成表作成のパラレル化
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を使用するパラレル・バルク・ロードの代替手段が提供されます。
親トピック: 索引構成表の作成
20.13.2.8 接頭辞圧縮の使用
接頭辞圧縮(キー圧縮とも呼ばれます)を使用して索引構成表を作成すると、キー列の接頭辞が同じ値で繰り返し格納されるのを回避できます。
接頭辞圧縮によって、索引キーは接頭辞および接尾辞エントリに分割されます。圧縮するために、接頭辞エントリは索引ブロック内のすべての接尾辞エントリ間で共有されます。このような共有によって、領域が大幅に節約され、各索引ブロックに格納できるキー数が増え、パフォーマンスが向上します。
接頭辞圧縮を使用可能にするには、次の操作を行う際に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概要』を参照してください
親トピック: 索引構成表の作成
20.13.3 索引構成表のメンテナンス
索引構成表と通常の表の相違点は、物理的な構成のみです。論理的には、通常の表と同じように操作されます。INSERT
、SELECT
、DELETE
およびUPDATE
の各文では、通常の表を指定する場合と同じように、索引構成表を指定できます。
- 索引構成表の変更
通常の表に使用可能な変更オプションはすべて索引構成表にも使用できます。使用可能なオプションには、ADD
、MODIFY
、DROP
COLUMNS
およびCONSTRAINTS
があります。ただし、索引構成表の主キー制約は、削除、遅延または使用禁止にできません。 - 索引構成表の移動(再作成)
索引構成表は主としてBツリー索引に格納されるため、増分更新の結果として断片化が生じることがあります。ただし、このような断片化は、ALTER TABLE...MOVE
文を使用して索引を再作成することで低減できます。
親トピック: 索引構成表の管理
20.13.3.1 索引構成表の変更
通常の表に使用可能な変更オプションはすべて索引構成表にも使用できます。使用可能なオプションには、ADD
、MODIFY
、DROP
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;
親トピック: 索引構成表のメンテナンス
20.13.3.2 索引構成表の移動(再作成)
索引構成表は主として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およびラージ・オブジェクト開発者ガイド』を参照してください。
親トピック: 索引構成表のメンテナンス
20.13.4 索引構成表に対する2次索引の作成
2次索引は、索引構成表の索引です。2次索引は独立したスキーマ・オブジェクトであり、索引構成表とは別に格納されます。
- 索引構成表に対する2次索引について
索引構成表に2次索引を作成することで、複数のアクセス・パスを提供できます。 - 索引構成表に対する2次索引の作成
索引構成表に2次索引を作成できます。 - 論理ROWIDの物理的不確定要素のメンテナンス
論理ROWIDには、不確定要素が作成される際に行のブロック位置を識別する不確定要素を含めることができます。完全なキー検索を実行するかわりに、不確定要素を使用してブロックが直接検索されます。 - 索引構成表に対するビットマップ索引の指定
索引構成表とともにマッピング表が作成される場合は、索引構成表でのビットマップ索引がサポートされます。
親トピック: 索引構成表の管理
20.13.4.1 索引構成表に対する2次索引について
索引構成表に2次索引を作成することで、複数のアクセス・パスを提供できます。
索引構成表の2次索引は、2つの点で通常の表の索引とは異なります。
-
索引構成表の2次索引には、物理的なROWIDではなく、論理的なROWIDが格納されます。これが必要な理由は、Bツリー索引の行にある本来の可動性のために、その行に永続的な物理アドレスがないためです。列の物理的な位置が変化しても、その論理的なROWIDは有効です。この効果の1つは、
ALTER TABLE
...MOVE
などの表のメンテナンス操作によって2次索引が使用禁止状態にならないことです。 -
論理ROWIDにも、列が見つかる可能性があるデータベースのブロック・アドレスを識別する物理的な不確定要素が含まれています。物理的な不確定要素が正しい場合、2次キーが見つかると、2次索引スキャンによって単一の追加I/Oが生じます。パフォーマンスは、通常の表での2次索引スキャンの場合と同様です。
一意の2次索引、一意でない2次索引、機能ベースの2次索引およびビットマップ索引が、索引構成表の2次索引としてサポートされます。
親トピック: 索引構成表に対する2次索引の作成
20.13.4.2 索引構成表に対する2次索引の作成
索引構成表に対して2次索引を作成できます。
次の文は、索引構成表docindex
に2次索引を作成します、doc_id
とtoken
はキー列です。
CREATE INDEX Doc_id_index on Docindex(Doc_id, Token);
この2次索引によって、問合せ(次の文にあるdoc_id
の述語に関係する問合せ)が効率的に処理されます。
SELECT Token FROM Docindex WHERE Doc_id = 1;
親トピック: 索引構成表に対する2次索引の作成
20.13.4.3 論理ROWIDの物理的不確定要素のメンテナンス
論理ROWIDには、不確定要素が作成される際に行のブロック位置を識別する不確定要素を含めることができます。完全なキー検索を実行するかわりに、不確定要素を使用してブロックが直接検索されます。
ただし、新しい行が挿入されると、不確定要素は失効する可能性があります。索引は論理ROWIDの主キー構成要素を介してそのまま使用できますが、行へのアクセスは遅くなります。
-
不確定要素の失効を監視するには、
DBMS_STATS
パッケージを使用して索引統計を収集します。既存の不確定要素が有効かどうかがチェックされ、有効な不確定要素を保持している行の割合がデータ・ディクショナリに記録されます。
-
DBA_INDEXES
ビュー(および関連するビュー)のPCT_DIRECT_ACCESS
列を問い合せて、既存の不確定要素に関する統計を表示します。 -
新しい不確定要素を取得するために、2次索引を再作成できます。
索引構成表に対する2次索引の再作成には、通常の表に対する索引の再作成とは異なり、実表の読込みが必要です。
不確定要素を修正する迅速で手軽な方法は、ALTER
INDEX
... UPDATE
BLOCK
REFERENCES
文を使用する方法です。この文はオンラインで実行されますが、DMLは基礎になる索引構成表でそのまま実行できます。
2次索引を再作成した後、あるいは不確定要素のブロック参照を更新した後は、索引統計を再度収集してください。
親トピック: 索引構成表に対する2次索引の作成
20.13.4.4 索引構成表に対するビットマップ索引の指定
索引構成表とともにマッピング表が作成される場合は、索引構成表でのビットマップ索引がサポートされます。
ビットマップ索引を作成するには、索引構成表の作成に使用するCREATE
TABLE
文、または後でマッピング表を追加するALTER
TABLE
文に、MAPPING
TABLE
句を指定します。
関連項目:
マッピング表の説明は、『Oracle Database概要』を参照してください
親トピック: 索引構成表に対する2次索引の作成
20.13.5 索引構成表の分析
通常の表と同様に、索引構成表の分析にはDBMS_STATS
パッケージ、またはANALYZE
文を使用します。
- 索引構成表のオプティマイザ統計の収集
オプティマイザ統計を収集するには、DBMS_STATS
パッケージを使用します。 - 索引構成表の構造の検証
索引構成表の構造を検証、または連鎖行をリストするには、ANALYZE
文を使用します。
親トピック: 索引構成表の管理
20.13.5.1 索引構成表のオプティマイザ統計の収集
オプティマイザ統計を収集するには、DBMS_STATS
パッケージを使用します。
たとえば、次の文はhr
スキーマの索引構成表countries
について統計を収集します。
EXECUTE DBMS_STATS.GATHER_TABLE_STATS ('HR','COUNTRIES');
DBMS_STATS
パッケージでは、主キー索引セグメントとオーバーフロー・データ・セグメントの両方が分析され、表の論理統計と物理統計が算出されます。
-
論理統計は、
USER_TABLES
、ALL_TABLES
またはDBA_TABLES
を使用して問合せできます。 -
主キー索引セグメントの物理統計を問い合せるには、
USER_INDEXES
、ALL_INDEXES
またはDBA_INDEXES
(および主キー索引名)を使用します。たとえば、表admin_docindex
の主キー索引セグメントの物理統計は、次のようにして取得できます。SELECT LAST_ANALYZED, BLEVEL,LEAF_BLOCKS, DISTINCT_KEYS FROM DBA_INDEXES WHERE INDEX_NAME= 'PK_ADMIN_DOCINDEX';
-
オーバーフロー・データ・セグメントの物理統計を問い合せるには、
USER_TABLES
、ALL_TABLES
またはDBA_TABLES
を使用します。IOT_TYPE = 'IOT_OVERFLOW'
で検索すると、オーバーフロー・エントリを識別できます。たとえば、admin_docindex
表に対応付けられたオーバーフロー・データ・セグメントの物理属性は、次のようにして取得できます。SELECT LAST_ANALYZED, NUM_ROWS, BLOCKS, EMPTY_BLOCKS FROM DBA_TABLES WHERE IOT_TYPE='IOT_OVERFLOW' and IOT_NAME= 'ADMIN_DOCINDEX';
関連項目:
-
オプティマイザ統計の収集の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
-
DBMS_STATS
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
親トピック: 索引構成表の分析
20.13.5.2 索引構成表の構造の検証
索引構成表の構造を検証、または連鎖行をリストするには、ANALYZE
文を使用します。
これらの操作は、このマニュアルの該当する項で説明されています。
-
ノート:
索引構成表の連鎖行をリストする場合は、特別な注意が必要です。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 索引構成表の分析
20.13.6 索引構成表での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;
親トピック: 索引構成表の管理
20.13.7 索引構成表の標準的な表への変換
索引構成表を標準的な(ヒープ構成)表に変換するには、Oracleのインポート/エクスポート・ユーティリティ、あるいはCREATE TABLE...AS SELECT
文を使用できます。
索引構成表を標準的な表に変換するには:
-
従来型パスを使用して、索引構成表のデータをエクスポートします。
-
同じ定義で、標準的な表の定義を作成します。
-
IGNORE=y
(オブジェクト存在エラーを無視する)を指定して、索引構成表のデータをインポートします。ノート:
索引構成表を標準的な表に変換する前に、Oracle8より古いバージョンのエクスポート・ユーティリティでは索引構成表をエクスポートできないことに注意してください。
関連項目:
従来の
IMP
およびEXP
ユーティリティとデータ・ポンプ・インポート/エクスポート・ユーティリティの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。
親トピック: 索引構成表の管理
20.14 外部表の管理
外部表はデータベース内には存在しません。
- 外部表について
Oracle Databaseでは、外部表内のデータへの読取り専用アクセスが可能です。外部表はデータベース内に存在しない表として定義されており、アクセス・ドライバが提供されていればどのようなフォーマットにすることもできます。 - 外部表の作成
外部表は、CREATE
TABLE
文でORGANIZATION
EXTERNAL
句を使用して作成します。この文は、データ・ディクショナリにメタデータのみを作成します。 - 外部表の変更
ALTER TABLE
文を使用して外部表を変更できます。 - 外部表の前処理
ユーザー指定のプリプロセッサ・プログラムで外部表を前処理できます。前処理プログラムを使用すると、アクセス・ドライバでサポートされていない形式のファイルにあるデータを利用できます。 - 問合せによる外部表のパラメータ上書き
SELECT
文のEXTERNAL MODIFY
句を使用して、外部表のパラメータを変更できます。 - インライン外部表の作成
インライン外部表により、SQL文の一部として外部表の実行時定義が可能になり、データ・ディクショナリに永続オブジェクトとして外部表を作成する必要がなくなります。 - 外部表のパーティション化
大量のデータがある場合は、外部表をパーティション化して、問合せのパフォーマンスを高速化し、データのメンテナンスを強化できます。 - 外部表の削除
外部表の場合、DROP
TABLE
文によって、データベース内の表メタデータのみが削除されます。データベースの外に常駐する実際のデータには影響を与えません。 - 外部表のシステム権限およびオブジェクト権限
外部表のシステム権限およびオブジェクト権限は、標準的な表のサブセットになります。
親トピック: 表の管理
20.14.1 外部表について
Oracle Databaseでは、外部表内のデータへの読取り専用アクセスが可能です。外部表はデータベース内に存在しない表として定義されており、アクセス・ドライバが提供されていればどのようなフォーマットにすることもできます。
外部表を記述するメタデータを提供することで、外部表内のデータをあたかも標準的なデータベース表内に存在しているデータのように公開できます。外部データは、SQLを使用して直接およびパラレルに問合せできます。
外部表のデータは、選択、結合、ソートなどが行えます。外部表のビューやシノニムも作成できます。ただし、外部表に対してDML操作(UPDATE
、INSERT
またはDELETE
)は実行できず、索引も作成できません。
外部表は、プラットフォームに依存しないフォーマット(オラクル社で開発され、Oracle Data Pumpで使用可能)に、任意のSELECT
文の結果をアンロードするためのフレームワークを提供します。外部表は、データ・ウェアハウスで一般的な、抽出、変換およびロード(ETL)の基本タスクを実行する際に役立つ手段を提供します。
外部表のメタデータは、CREATE TABLE...ORGANIZATION EXTERNAL
文を使用して定義します。外部表の定義は、外部データを最初にデータベースにロードしなくても外部データに対して任意のSQL問合せを実行できるビューとみなすことができます。表内の外部データを読み込むために使用されているメカニズムが、アクセス・ドライバです。外部表を使用してデータをアンロードすると、SELECT
文のデータ型に基づいてメタデータが自動的に作成されます。
Oracle Databaseでは、外部表のためのアクセス・ドライバを提供しています。デフォルトのアクセス・ドライバはORACLE_LOADER
で、Oracleのローダー・テクノロジを使用して外部ファイルからデータを読み込むことができます。ORACLE_LOADER
アクセス・ドライバは、SQL*Loaderユーティリティの制御ファイル構文のサブセットであるデータ・マッピング機能を提供します。もう1つのアクセス・ドライバORACLE_DATAPUMP
は、データをアンロード(つまり、データベースからデータを読み取り、1つ以上の外部ファイルで表された外部表にそのデータを挿入)してから、データをOracle Databaseに再ロードします。
Oracle Database 12cリリース2 (12.2)以降では、新しいアクセス・ドライバのORACLE_HIVE
とORACLE_HDFS
を使用できます。ORACLE_HIVE
アクセス・ドライバはApache Hiveに格納されたデータを抽出できます。ORACLE_HDFS
アクセス・ドライバは、Hadoop Distributed File System (HDFS)に格納されたデータを抽出できます。
Oracle Databaseリリース18c以降では、インライン外部表がサポートされています。インライン外部表により、SQL文の一部として外部表の実行時定義が可能になり、データ・ディクショナリに永続オブジェクトとして外部表を作成する必要がなくなります。
ノート:
ANALYZE
文による外部表の統計収集はサポートされていません。かわりにDBMS_STATS
パッケージを使用してください。
関連項目:
-
外部表に対する制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
-
アクセス・ドライバの詳細は、『Oracle Databaseユーティリティ』を参照してください。
-
データ・ウェアハウス環境でETLに外部表を使用する方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。
-
DBMS_STATS
パッケージの使用方法の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。 -
ORACLE_HIVE
ドライバとORACLE_HDFS
ドライバの詳細、および外部表の詳細は、『Oracle Databaseユーティリティ』を参照してください
親トピック: 外部表の管理
20.14.2 外部表の作成
外部表は、CREATE
TABLE
文でORGANIZATION
EXTERNAL
句を使用して作成します。この文は、データ・ディクショナリにメタデータのみを作成します。
ノート:
-
Oracle Database 12cリリース2 (12.2)以降では、大量データの高速問合せパフォーマンスおよび機能拡張されたデータ保守のために、外部表をパーティション化できます。
-
外部表に仮想列を設定できます。ただし、外部表の仮想列は
evaluation_edition_clause
またはunusable_edition_clause
を使用して定義はできません。
次の例では、外部表を作成してから、データをデータベース表にアップロードしています。あるいは、CREATE TABLE
文のAS
subquery
句を指定し、外部表フレームワークを介してデータをアンロードできます。外部表のデータ・ポンプ・アンロードは、ORACLE_DATAPUMP
アクセス・ドライバのみを使用できます。
例: 外部表の作成とデータのロード
この例では、外部表のデータはempxt1.dat
およびempxt2.dat
という2つのテキスト・ファイルに存在します。
ファイル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です。TYPE
指定を省略した場合は、ORACLE_LOADER
がデフォルトのアクセス・ドライバになります。AS
subquery
句を指定して、1つのOracle Databaseからデータをアンロードし、同一または異なるOracle Databaseに再ロードする場合は、ORACLE_DATAPUMP
アクセス・ドライバを指定する必要があります。
ACCESS PARAMETERS
句で指定するアクセス・パラメータは、データベースには不透明です。これらのアクセス・パラメータはアクセス・ドライバによって定義されるもので、データベースが外部表にアクセスするときにアクセス・ドライバに提供されます。ORACLE_LOADER
アクセス・パラメータの詳細は、『Oracle Databaseユーティリティ』を参照してください。
PARALLEL
句は、データソースに対するパラレル問合せを可能にします。パラレル化の最小単位はデフォルトではデータソースですが、データソース内部でのパラレル・アクセスは可能なかぎり実装されます。たとえば、PARALLEL=3
と指定すると、データソースに対して複数のパラレル実行サーバーを稼働しておくことができます。しかし、データソース内部でのパラレル・アクセスは、次の条件がすべて成り立つ場合にのみ、アクセス・ドライバによって提供されます。
-
メディアが、データソース内部でのランダムな位置指定をサポートしている。
-
レコード境界をランダムな位置から検索できる。
-
データファイルが、複数のチャンクに分割することが適切なほど十分大きい。
ノート:
PARALLEL
句の指定は、大量のデータを扱う場合にのみ有効です。データが大量でない場合には、PARALLEL
句を指定すると悪影響を及ぼす可能性が高いので、お薦めできません。
REJECT
LIMIT
句は、外部データの問合せ中に発生する可能性のあるエラーの数に上限を設けないことを指定します。パラレル・アクセスの場合、REJECT
LIMIT
が各パラレル実行サーバーに個別に適用されます。たとえば、REJECT
LIMIT
に10を指定すると、各パラレル問合せプロセスで10個まで拒否が許可されます。このため、並行度が2、REJECT
LIMIT
が10の場合、拒否が10個から20個の間で文が失敗する場合があります。1つのパラレル・サーバーで10個の拒否をすべて処理する場合、制限に達するため文が終了します。ただし、1つのパラレル実行サーバーが9個の拒否を処理し、もう1つのパラレル実行サーバーが9個の拒否を処理する場合、18個の拒否で文が成功します。したがって、パラレル問合せに関して正確に規定されるREJECT
LIMIT
の値は、0
(ゼロ)およびUNLIMITED
のみです。
この例では、INSERT
INTO
TABLE
文によって外部データソースからOracle Database SQLエンジンへのデータフローが生成され、そこでデータが処理されます。外部表ソースからのデータがアクセス・ドライバで解析されて外部表インタフェースに提供されると、外部データがその外部表現からOracle Databaseの内部データ型に変換されます。
関連項目:
外部表を作成するためのCREATE TABLE
文の構文の詳細、および句の使用の制限は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 外部表の管理
20.14.3 外部表の変更
ALTER TABLE
文を使用して外部表を変更できます。
外部表の特性を変更するには、表20-6
のいずれかのALTER TABLE句を使用します。これ以外の句は使用できません。
表20-6 外部表のALTER TABLE句
ALTER TABLE句 | 説明 | 例 |
---|---|---|
|
拒否の上限を変更します。デフォルト値は |
|
|
アクセス・ドライバが後続の問合せで行の妥当性をチェックする方法を決定します。
|
|
|
デフォルトのディレクトリ指定を変更します。 |
|
|
外部表のメタデータの削除と再作成を行わずにアクセス・パラメータを変更できます。 |
|
|
外部表のメタデータの削除と再作成を行わずにデータソースを変更できます。 |
|
|
標準的な表の場合と同じです。並列度を変更できます。 |
新しい構文はありません |
|
標準的な表の場合と同じです。外部表に列を追加できます。仮想列は使用できません。 |
新しい構文はありません。 |
|
標準的な表の場合と同じです。外部表の列を変更できます。仮想列は使用できません。 |
新しい構文はありません。 |
|
|
新しい構文はありません。 |
|
標準的な表の場合と同じです。外部表の列を削除できます。 |
新しい構文はありません。 |
|
標準的な表の場合と同じです。外部表の名前を変更できます。 |
新しい構文はありません。 |
親トピック: 外部表の管理
20.14.4 外部表の前処理
ユーザー指定のプリプロセッサ・プログラムで外部表を前処理できます。前処理プログラムを使用すると、アクセス・ドライバでサポートされていない形式のファイルにあるデータを利用できます。
注意:
PREPROCESSOR
句を使用するときに考慮する必要があるセキュリティ上の注意事項があります。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
たとえば、圧縮形式で格納されているデータにアクセスできます。ORACLE_LOADER
アクセス・ドライバに対して解凍プログラムを指定すると、アクセス・ドライバでデータが処理される際にデータを解凍できます。
前処理機能を使用するには、ORACLE_LOADER
アクセス・ドライバのアクセス・パラメータでPREPROCESSOR
句を指定する必要があります。プリプロセッサはディレクトリ・オブジェクトである必要があり、外部表にアクセスするユーザーには、そのディレクトリ・オブジェクトに対するEXECUTE
権限が必要です。次の例にはPREPROCESSOR
句が含まれており、ディレクトリとプリプロセッサ・プログラムを指定しています。
CREATE TABLE sales_transactions_ext
(PROD_ID NUMBER,
CUST_ID NUMBER,
TIME_ID DATE,
CHANNEL_ID CHAR,
PROMO_ID NUMBER,
QUANTITY_SOLD NUMBER,
AMOUNT_SOLD NUMBER(10,2),
UNIT_COST NUMBER(10,2),
UNIT_PRICE NUMBER(10,2))
ORGANIZATION external
(TYPE oracle_loader
DEFAULT DIRECTORY data_file_dir
ACCESS PARAMETERS
(RECORDS DELIMITED BY NEWLINE
CHARACTERSET AL32UTF8
PREPROCESSOR exec_file_dir:'zcat'
BADFILE log_file_dir:'sh_sales.bad_xt'
LOGFILE log_file_dir:'sh_sales.log_xt'
FIELDS TERMINATED BY "|" LDRTRIM
( PROD_ID,
CUST_ID,
TIME_ID,
CHANNEL_ID,
PROMO_ID,
QUANTITY_SOLD,
AMOUNT_SOLD,
UNIT_COST,
UNIT_PRICE))
location ('sh_sales.dat.gz')
)REJECT LIMIT UNLIMITED;
PREPROCESSOR
句は、Oracle Database Vaultを使用しているデータベースには使用できません。
ノート:
Windowsプラットフォームでは、プリプロセッサ・プログラムの拡張子は.bat
または.cmd
である必要があります。
関連項目:
-
PREPROCESSOR
句の詳細は、『Oracle Databaseユーティリティ』を参照してください。 -
PREPROCESSOR
句のセキュリティ上の注意事項の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
親トピック: 外部表の管理
20.14.5 問合せによる外部表のパラメータ上書き
SELECT
文のEXTERNAL MODIFY
句を使用して、外部表のパラメータを変更できます。
EXTERNAL MODIFY
句を使用して、次に示す外部表の句を上書きできます。
-
DEFAULT DIRECTORY
-
LOCATION
-
ACCESS PARAMETERS
-
REJECT LIMIT
単一の問合せの複数の句を変更できます。LOCATION
およびREJECT LIMIT
にはバインド変数を指定できますが、DEFAULT DIRECTORY
またはACCESS PARAMETERS
には指定できません。
変更は問合せのみに適用されます。表に永続的には影響しません。
パーティション化された外部表の場合は、表レベルの句のみを上書きできます。
- 外部表の問合せに必要な権限を持つユーザーとして、データベースに接続します。
- 外部表に対して、
EXTERNAL MODIFY
句を指定してSELECT
文を発行します。
例 20-21 問合せによる外部表のパラメータ上書き
sales_external
という名前の外部表で、REJECT LIMIT
が25
に設定されているとします。次の問合せで、この設定をREJECT LIMIT UNLIMITED
に変更します。
SELECT * FROM sales_external EXTERNAL MODIFY (LOCATION ('sales_9.csv')
REJECT LIMIT UNLIMITED);
親トピック: 外部表の管理
20.14.6 インライン外部表の使用
インライン外部表により、SQL文の一部として外部表の実行時定義が可能になり、データ・ディクショナリに永続オブジェクトとして外部表を作成する必要がなくなります。
インライン外部表では、外部表の作成にCREATE TABLE
文で使用したものと同じ構文を、実行時にSELECT
文で使用できます。インライン外部表は、問合せブロックのFROM
句で指定します。インライン外部表を含む問合せには、結合や集計などのために標準の表を含めることもできます。
次のSQL文では、外部データに対する実行時の問合せを実行します。
SELECT * FROM EXTERNAL (
(time_id DATE NOT NULL,
prod_id INTEGER NOT NULL,
quantity_sold NUMBER(10,2),
amount_sold NUMBER(10,2))
TYPE ORACLE_LOADER
DEFAULT DIRECTORY data_dir1
ACCESS PARAMETERS (
RECORDS DELIMITED BY NEWLINE
FIELDS TERMINATED BY '|')
LOCATION ('sales_9.csv') REJECT LIMIT UNLIMITED) sales_external;
これまでにsales_external
という名前の表が作成されていませんが、この問合せは外部データを読み取って、その結果を返します。
ノート:
インライン外部表では、パーティション化がサポートされません。問合せでは、スキャンするディレクトリとファイルを制御できるため、問合せに不要なファイルを省略することでプルーニングを実施できます。
親トピック: 外部表の管理
20.14.7 外部表のパーティション化
大量のデータがある場合は、外部表をパーティション化して、問合せのパフォーマンスを高速化し、データのメンテナンスを強化できます。
- 外部表のパーティション化について
外部表のデータのパーティション化は、データベースに格納されている表のパーティション化とほぼ同様ですが、いくつか違いがあります。パーティション化された外部表のファイルは、ファイル・システム、Apache Hive記憶域またはHadoop Distributed File System (HDFS)に格納できます。 - パーティション化された外部表の制限
パーティション化された外部表にはいくつかの制限が適用されます。 - パーティション化された外部表の作成
パーティション化された非コンポジット外部表を作成するには、ORGANIZATION EXTERNAL
句およびPARTITION BY
句を指定して、CREATE TABLE
文を発行します。パーティション化されたコンポジット外部表を作成するには、SUBPARTITION BY
句も指定する必要があります。 - パーティション化された外部表の変更
ALTER TABLE
文を使用して、パーティション化された外部表の表レベルの外部パラメータを変更できますが、パーティション・レベルおよびサブパーティション・レベルのパラメータは変更できません。
親トピック: 外部表の管理
20.14.7.1 外部表のパーティション化について
外部表のデータのパーティション化は、データベースに格納されている表のパーティション化とほぼ同様ですが、いくつか違いがあります。パーティション化された外部表のファイルは、ファイル・システム、Apache Hive記憶域またはHadoop Distributed File System (HDFS)に格納できます。
外部表のパーティション化を開始する前に、パーティション化に関する概念について、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。
外部表をパーティション化する主な理由は、データベースに格納される表のパーティション化と同様のパフォーマンス改善の利点を活用するためです。特に、パーティション・プルーニングおよびパーティション単位の結合によって、問合せのパフォーマンスを改善できます。パーティション・プルーニングでは、問合せが1つのパーティションのみに適用されるため、すべてのデータではなく、外部表のデータのサブセットを対象に問合せを実行できます。パーティション・ワイズ結合は、2つの表を結合する際に両方の表が結合キーでパーティション化される場合や、参照パーティション表を親表と結合する場合に適用できます。パーティション・ワイズ結合では、大きな結合が小さな結合に分割され、その分割が各パーティションで行われるため結合全体がこれまでよりも短い時間で完了します。
データベースの表でサポートされるほとんどのパーティション方法は、外部表の場合もサポートされます。外部表は範囲またはリストに基づいてパーティション化可能で、コンポジット・パーティション化もサポートされます。ただし、外部表の場合はハッシュ・パーティション化はサポートされません。
データベースに格納されるパーティション化表の場合、表領域を使用して各パーティションの記憶域を指定できます。パーティション化された外部表の場合は、各パーティションのディレクトリとファイルを指定して、各パーティションの記憶域を指定します。
パーティション化された外部表を作成するための句
次に、パーティション化されていない外部表を作成する句を示します。
-
TYPE
- 外部表のタイプに応じてアクセス・ドライバを指定します(ORACLE_LOADER
、ORACLE_DATAPUMP
、ORACLE_HIVE
、ORACLE_HDFS
)。 -
DEFAULT DIRECTORY
- 明示的にディレクトリ・オブジェクトに名前を付けないすべての入出力ファイルについて、使用するデフォルトのディレクトリをディレクトリ・オブジェクトで指定します。 -
ACCESS PARAMETERS
- 外部データ・ソースを記述します。 -
LOCATION
- 外部表のファイルを指定します。 -
REJECT LIMIT
- 外部表の問合せ中に発生する可能性のあるエラーの数の制限を指定します。
パーティション化された外部表を作成する際には、各パーティションを定義するPARTITION
句を指定する必要があります。次の表は、外部表の作成時に各レベルで指定できる句の説明です。
表20-7 外部表の句とパーティション化
句 | 表レベル | パーティション・レベル | サブパーティション・レベル |
---|---|---|---|
|
使用可能 |
使用不可 |
使用不可 |
|
使用可能 |
使用可能 |
使用可能 |
|
使用可能 |
使用不可 |
使用不可 |
|
使用不可 |
使用可能 |
使用可能 |
|
使用可能 |
使用不可 |
使用不可 |
非コンポジット・パーティション化表の場合は、パーティションに対するLOCATION
句で、パーティションのファイルを指定する必要があります。コンポジット・パーティション化表の場合は、サブパーティションに対するLOCATION
句で、サブパーティションのファイルを指定する必要があります。パーティションにサブパーティションがある場合は、サブパーティションに対してLOCATION
句を指定できますが、パーティションに対しては指定できません。パーティションまたはサブパーティションに対するLOCATION
句を省略した場合は、空のパーティションまたは空のサブパーティションが作成されます。
LOCATION
句では、ファイルがdirectory:file
の形式で指定され、1つの句で複数のファイルを指定できます。directory
の部分はオプションです。次のルールは、パーティションまたはサブパーティションによって使用されるディレクトリに適用されます。
-
パーティションまたはサブパーティションに対する
LOCATION
句でディレクトリを指定する場合、指定はその場所にのみに適用されます。 -
特定のパーティションに対する
LOCATION
句では、ディレクトリが指定されていない各ファイルについて、パーティション・レベルまたは表レベルのDEFAULT DIRECTORY
句によって指定されたディレクトリが(パーティション・レベル優先で)使用されます。たとえば、
CREATE TABLE
文のORGANIZATION EXTERNAL
句にDEFAULT DIRECTORY
句が含まれており、この文のPARTITION
句ではLOCATION
句のファイルのディレクトリが指定されていない場合、ファイルは、表に対するDEFAULT DIRECTORY
句で指定されたディレクトリを使用します。 -
特定のサブパーティションに対する
LOCATION
句では、ディレクトリが指定されていない各ファイルについて、サブパーティション、パーティションまたは表レベルのDEFAULT DIRECTORY
句によって指定されたディレクトリが(サブパーティション・レベル優先で)使用されます。たとえば、
PARTITION
句にDEFAULT DIRECTORY
句が含まれており、パーティションのSUBPARITION
句ではLOCATION
句のファイルのディレクトリが指定されていない場合、ファイルは、パーティションに対するDEFAULT DIRECTORY
句で指定されたディレクトリを使用します。 -
パーティションまたはサブパーティションのデフォルト・ディレクトリは、
LOCATION
句では指定できません。DEFAULT DIRECTORY
句でのみ指定できます。
関連項目:
例20-23のディレクトリ・ルールの説明ORACLE_HIVEアクセス・ドライバの使用方法
Apache Hiveでは独自のパーティション化を使用します。パーティション化された外部表を作成するには、DBMS_HADOOP
パッケージのCREATE_EXTDDL_FOR_HIVE
プロシージャを使用します。このプロシージャによってデータ定義言語(DDL)文が生成され、これを使用して、Apache Hive記憶域のパーティション化に対応するようにパーティション化された外部表を作成できます。
DBMS_HADOOP
パッケージにはSYNC_PARTITIONS_FOR_HIVE
プロシージャも含まれています。このプロシージャは、Apache Hive記憶域のパーティション化された外部表のパーティションを、Oracle Databaseに格納される同じ表のパーティション・メタデータと自動的に同期します。
20.14.7.2 パーティション化された外部表の制限
パーティション化された外部表にはいくつかの制限が適用されます。
次に、パーティション化された外部表の制限を示します。
-
パーティション化されていない外部表に適用されるすべての制限は、パーティション化されている外部表にも適用されます。
-
パーティションの最大数など、データベースに格納される表に適用されるパーティションの制限が、パーティション化された外部表にも適用されます。
-
Oracle Databaseは、パーティションの外部ファイルにパーティション定義を満たすデータが含まれることを保証できません。
-
DEFAULT DIRECTORY
およびLOCATION
句のみを、PARTITION
またはSUBPARTITION
句で指定できます。 -
パーティション化された外部表を
ALTER TABLE
文で変更する場合、MODIFY PARTITION
、EXCHANGE PARTITION
、MOVE PARTITION
、MERGE PARTITIONS
、SPLIT PARTITION
、COALESCE PARTITION
およびTRUNCATE PARTITION
句はサポートされません。 -
参照パーティション化、自動リスト・パーティション化および間隔パーティション化はサポートされません。
-
サブパーティション・テンプレートはサポートされません。
-
ORACLE_DATAPUMP
アクセス・ドライバでは、CREATE TABLE AS SELECT
文を使用して、パーティションの外部ファイルを移入できません。 -
パーティション化された外部表の場合、増分統計は収集されません。
-
他のドライバの場合に使用できるパーティション化方法に対する制限に加えて、
ORACLE_HIVE
アクセス・ドライバの場合、レンジ・パーティション化とコンポジット・パーティション化もサポートされません。 -
SELECT
文でEXTERNAL MODIFY
句を指定して、パーティション・レベルまたはサブパーティション・レベルの句を上書きはできません。EXTERNAL MODIFY
句で上書きできるのは、表レベルでサポートされる外部の句のみです。パーティション化された外部表の場合、LOCATION
句は表レベルでは使用できないため、EXTERNAL MODIFY
句では上書きできません。
関連項目:
-
外部表を作成するための
CREATE TABLE
文の構文の詳細、および句の使用の制限は、『Oracle Database SQL言語リファレンス』を参照してください。
親トピック: 外部表のパーティション化
20.14.7.3 パーティション化された外部表の作成
パーティション化された非コンポジット外部表を作成するには、ORGANIZATION EXTERNAL
句およびPARTITION BY
句を指定して、CREATE TABLE
文を発行します。パーティション化されたコンポジット外部表を作成するには、SUBPARTITION BY
句も指定する必要があります。
PARTITION BY
句とSUBPARTITION BY
句で、各パーティションとサブパーティションの外部ファイルの場所を指定します。
例20-22 すべてのパーティションに共通のアクセス・パラメータを使用するパーティション化された外部表の作成
この例では、order_date
列の日付データでパーティション化されるorders_external_range
という名前の外部表を作成します。ACCESS PARAMETERS
句は、ORACLE_LOADER
アクセス・ドライバについて表レベルで指定します。data_dir1
ディレクトリ・オブジェクトは、パーティションmonth1
、month2
およびmonth3
に使用されるデフォルトのディレクトリ・オブジェクトです。pmax
パーティションの場合は、DEFAULT DIRECTORY
句でdata_dir2
ディレクトリ・オブジェクトが指定されるため、data_dir2
ディレクトリ・オブジェクトがpmax
パーティションに使用されます。
-- Set up directories and grant access to oe
CREATE OR REPLACE DIRECTORY data_dir1
AS '/flatfiles/data1';
CREATE OR REPLACE DIRECTORY data_dir2
AS '/flatfiles/data2';
CREATE OR REPLACE DIRECTORY bad_dir
AS '/flatfiles/bad';
CREATE OR REPLACE DIRECTORY log_dir
AS '/flatfiles/log';
GRANT READ ON DIRECTORY data_dir1 TO oe;
GRANT READ ON DIRECTORY data_dir2 TO oe;
GRANT WRITE ON DIRECTORY bad_dir TO oe;
GRANT WRITE ON DIRECTORY log_dir TO oe;
-- oe connects. Provide the user password (oe) when prompted.
CONNECT oe
-- create the partitioned external table
CREATE TABLE orders_external_range(
order_id NUMBER(12),
order_date DATE NOT NULL,
customer_id NUMBER(6) NOT NULL,
order_status NUMBER(2),
order_total NUMBER(8,2),
sales_rep_id NUMBER(6))
ORGANIZATION EXTERNAL(
TYPE ORACLE_LOADER
DEFAULT DIRECTORY data_dir1
ACCESS PARAMETERS(
RECORDS DELIMITED BY NEWLINE
BADFILE bad_dir: 'sh%a_%p.bad'
LOGFILE log_dir: 'sh%a_%p.log'
FIELDS TERMINATED BY '|'
MISSING FIELD VALUES ARE NULL))
PARALLEL
REJECT LIMIT UNLIMITED
PARTITION BY RANGE (order_date)
(PARTITION month1 VALUES LESS THAN (TO_DATE('31-12-2014', 'DD-MM-YYYY'))
LOCATION ('sales_1.csv'),
PARTITION month2 VALUES LESS THAN (TO_DATE('31-01-2015', 'DD-MM-YYYY'))
LOCATION ('sales_2.csv'),
PARTITION month3 VALUES LESS THAN (TO_DATE('28-02-2015', 'DD-MM-YYYY'))
LOCATION ('sales_3.csv'),
PARTITION pmax VALUES LESS THAN (MAXVALUE)
DEFAULT DIRECTORY data_dir2 LOCATION('sales_4.csv'));
前述の例では、デフォルト・ディレクトリdata_dir2
がpmax
パーティションに指定されています。次のようにLOCATION
句を使用して、このパーティションの特定の場所に対してディレクトリを指定することもできます。
PARTITION pmax VALUES LESS THAN (MAXVALUE)
LOCATION ('data_dir2:sales_4.csv')
この場合、data_dir2
ディレクトリがsales_4.csv
の場所に対して指定されていますが、data_dir2
ディレクトリはこのパーティションのデフォルト・ディレクトリではありません。したがって、pmax
パーティションのデフォルト・ディレクトリは、表のデフォルト・ディレクトリと同じdata_dir1
です。
例20-23 パーティション化されたコンポジット・リスト・レンジ外部表の作成
この例では、region
列のデータでパーティション化されるaccounts
という名前の外部表を作成します。このパーティションは、balance
列のデータの範囲を使用してサブパーティション化されます。ACCESS PARAMETERS
句は、ORACLE_LOADER
アクセス・ドライバについて表レベルで指定します。各サブパーティションにLOCATION
句を指定します。
表レベルのDEFAULT DIRECTORY
句がdata_dir1
ディレクトリ・オブジェクトに設定されており、次のような場合を除き、このディレクトリ・オブジェクトがすべてのサブパーティションに使用されます。
-
パーティション
p_southcentral
の場合は、パーティション・レベルのDEFAULT DIRECTORY
句がdata_dir2
ディレクトリ・オブジェクトに設定されています。このパーティションの場合、サブディレクトリp_sc_low
、p_sc_high
およびp_sc_extraordinary
がこのデフォルト・ディレクトリを使用します。 -
パーティション
p_southcentral
では、サブパーティションp_sc_average
のサブパーティション・レベルのDEFAULT DIRECTORY
句がdata_dir3
ディレクトリ・オブジェクトに設定されており、このサブパーティションはdata_dir3
ディレクトリ・オブジェクトを使用します。 -
前述のように、
p_sc_high
サブパーティションのデフォルト・ディレクトリはdata_dir2
です。p_sc_high
サブパーティションにはDEFAULT DIRECTORY
句がないため、p_southcentral
パーティションに対してPARTITION BY
句で指定されたDEFAULT DIRECTORY
からデフォルト・ディレクトリdata_dir2
が継承されます。p_sc_high
サブパーティションのファイルは次のディレクトリを使用します。-
psch1.csv
ファイルはdata_dir2
(サブパーティションのデフォルト・ディレクトリ)を使用します。 -
psch2.csv
ファイルは、場所としてdata_dir4
ディレクトリが指定されているため、data_dir4
ディレクトリを使用します。
-
-- Set up the directories and grant access to oe
CREATE OR REPLACE DIRECTORY data_dir1
AS '/stage/data1_dir';
CREATE OR REPLACE DIRECTORY data_dir2
AS '/stage/data2_dir';
CREATE OR REPLACE DIRECTORY data_dir3
AS '/stage/data3_dir';
CREATE OR REPLACE DIRECTORY data_dir4
AS '/stage/data4_dir';
CREATE OR REPLACE DIRECTORY bad_dir
AS '/stage/bad_dir';
CREATE OR REPLACE DIRECTORY log_dir
AS '/stage/log_dir';
GRANT READ ON DIRECTORY data_dir1 TO oe;
GRANT READ ON DIRECTORY data_dir2 TO oe;
GRANT READ ON DIRECTORY data_dir3 TO oe;
GRANT READ ON DIRECTORY data_dir4 TO oe;
GRANT WRITE ON DIRECTORY bad_dir TO oe;
GRANT WRITE ON DIRECTORY log_dir TO oe;
-- oe connects. Provide the user password (oe) when prompted.
CONNECT oe
-- create the partitioned external table
CREATE TABLE accounts
( id NUMBER,
account_number NUMBER,
customer_id NUMBER,
balance NUMBER,
branch_id NUMBER,
region VARCHAR(2),
status VARCHAR2(1)
)
ORGANIZATION EXTERNAL(
TYPE ORACLE_LOADER
DEFAULT DIRECTORY data_dir1
ACCESS PARAMETERS(
RECORDS DELIMITED BY NEWLINE
BADFILE bad_dir: 'sh%a_%p.bad'
LOGFILE log_dir: 'sh%a_%p.log'
FIELDS TERMINATED BY '|'
MISSING FIELD VALUES ARE NULL))
PARALLEL
REJECT LIMIT UNLIMITED
PARTITION BY LIST (region)
SUBPARTITION BY RANGE (balance)
( PARTITION p_northwest VALUES ('OR', 'WA')
( SUBPARTITION p_nw_low VALUES LESS THAN (1000) LOCATION ('pnwl.csv'),
SUBPARTITION p_nw_average VALUES LESS THAN (10000) LOCATION ('pnwa.csv'),
SUBPARTITION p_nw_high VALUES LESS THAN (100000) LOCATION ('pnwh.csv'),
SUBPARTITION p_nw_extraordinary VALUES LESS THAN (MAXVALUE) LOCATION ('pnwe.csv')
),
PARTITION p_southwest VALUES ('AZ', 'UT', 'NM')
( SUBPARTITION p_sw_low VALUES LESS THAN (1000) LOCATION ('pswl.csv'),
SUBPARTITION p_sw_average VALUES LESS THAN (10000) LOCATION ('pswa.csv'),
SUBPARTITION p_sw_high VALUES LESS THAN (100000) LOCATION ('pswh.csv'),
SUBPARTITION p_sw_extraordinary VALUES LESS THAN (MAXVALUE) LOCATION ('pswe.csv')
),
PARTITION p_northeast VALUES ('NY', 'VM', 'NJ')
( SUBPARTITION p_ne_low VALUES LESS THAN (1000) LOCATION ('pnel.csv'),
SUBPARTITION p_ne_average VALUES LESS THAN (10000) LOCATION ('pnea.csv'),
SUBPARTITION p_ne_high VALUES LESS THAN (100000) LOCATION ('pneh.csv'),
SUBPARTITION p_ne_extraordinary VALUES LESS THAN (MAXVALUE) LOCATION ('pnee.csv')
),
PARTITION p_southeast VALUES ('FL', 'GA')
( SUBPARTITION p_se_low VALUES LESS THAN (1000) LOCATION ('psel.csv'),
SUBPARTITION p_se_average VALUES LESS THAN (10000) LOCATION ('psea.csv'),
SUBPARTITION p_se_high VALUES LESS THAN (100000) LOCATION ('pseh.csv'),
SUBPARTITION p_se_extraordinary VALUES LESS THAN (MAXVALUE) LOCATION ('psee.csv')
),
PARTITION p_northcentral VALUES ('SD', 'WI')
( SUBPARTITION p_nc_low VALUES LESS THAN (1000) LOCATION ('pncl.csv'),
SUBPARTITION p_nc_average VALUES LESS THAN (10000) LOCATION ('pnca.csv'),
SUBPARTITION p_nc_high VALUES LESS THAN (100000) LOCATION ('pnch.csv'),
SUBPARTITION p_nc_extraordinary VALUES LESS THAN (MAXVALUE) LOCATION ('pnce.csv')
),
PARTITION p_southcentral VALUES ('OK', 'TX') DEFAULT DIRECTORY data_dir2
( SUBPARTITION p_sc_low VALUES LESS THAN (1000) LOCATION ('pscl.csv'),
SUBPARTITION p_sc_average VALUES LESS THAN (10000)
DEFAULT DIRECTORY data_dir3 LOCATION ('psca.csv'),
SUBPARTITION p_sc_high VALUES LESS THAN (100000)
LOCATION ('psch1.csv','data_dir4:psch2.csv'),
SUBPARTITION p_sc_extraordinary VALUES LESS THAN (MAXVALUE)
LOCATION ('psce.csv')
)
);
親トピック: 外部表のパーティション化
20.14.7.4 パーティション化された外部表の変更
ALTER TABLE
文を使用して、パーティション化された外部表の表レベルの外部パラメータを変更できますが、パーティション・レベルおよびサブパーティション・レベルのパラメータは変更できません。
外部ファイルの場所はPARTITION BY
およびSUBPARTITION BY
句で指定します。パーティションの外部ファイルは、パーティションのPARTITION BY
句で指定します。サブパーティションの外部ファイルは、サブパーティションのSUBPARTITION BY
句で指定します。
唯一の例外として、パーティション化された外部表の作成の際には、表レベルのLOCATION
句は指定できません。したがって、パーティション化された外部表を変更するALTER TABLE
文に、表レベルのLOCATION
句は追加できません。
パーティション・レベルでは、ADD
、DROP
およびRENAME
操作のみサポートされます。ALTER TABLE
文で、既存のパーティションおよびサブパーティションの属性は変更できません。ただし、新しいパーティションやサブパーティションを追加するときに、PARTITION
句またはSUBPARTITION
句にDEFAULT DIRECTORY
およびLOCATION
句を含めることができます。
- 外部表の変更に必要な権限を持つユーザーとして、データベースに接続します。
ALTER TABLE
文を発行します。
例20-24 パーティション化された外部表のパーティションの名前変更
この例は、orders_external_range
というパーティション化されている外部表のパーティションを名前変更しています。
ALTER TABLE orders_external_range RENAME PARTITION pmax TO other_months;
親トピック: 外部表のパーティション化
20.14.8 外部表の削除
外部表の場合、DROP
TABLE
文によって、データベース内の表メタデータのみが削除されます。データベースの外に常駐する実際のデータには影響を与えません。
親トピック: 外部表の管理
20.14.9 外部表のシステム権限およびオブジェクト権限
外部表のシステム権限およびオブジェクト権限は、標準的な表のサブセットになります。
外部表に適用できるシステム権限は、次のものにかぎられます。
-
ALTER
ANY
TABLE
-
CREATE
ANY
TABLE
-
DROP
ANY
TABLE
-
READ
ANY
TABLE
-
SELECT
ANY
TABLE
外部表に適用できるオブジェクト権限は、次のものにかぎられます。
-
ALTER
-
READ
-
SELECT
ただし、ディレクトリには次のオブジェクト権限が対応付けられています。
-
READ
-
WRITE
外部表では、データソースのあるディレクトリ・オブジェクトに対してREAD
権限が必要であり、同時に、不良ファイル、ログ・ファイルまたは廃棄ファイルのあるディレクトリ・オブジェクトに対してWRITE
権限が必要です。
親トピック: 外部表の管理
20.15 表のデータ・ディクショナリ・ビュー
データ・ディクショナリ・ビューのセットを問い合せて、表についてのデータを取得できます。
次のビューを使用して、表に関する情報にアクセスできます。
ビュー | 説明 |
---|---|
|
|
これらのビューには、データベース内の表の列、ビューおよびクラスタが表示されます。これらのビューの一部の列には、 |
|
これらのビューには、データベース内のすべてのリレーショナル表およびオブジェクト表が表示されます。オブジェクト表については、このマニュアルでは詳しく説明していません。 |
|
これらのビューには、表およびビューのコメントが表示されます。コメントは、 |
|
これらのビューには、表およびビューの列のコメントが表示されます。コメントは、 |
|
これらのビューには、データベースで定義されている外部表の特定の属性がリストされます。 |
|
これらのビューには、外部表のデータソースがリストされます。 |
|
これらのビューには、データベースで定義されているパーティション化された外部表の特定の属性がリストされます。 |
|
これらのビューには、データベースで定義されているパーティション化された外部表のパーティション・レベルの情報がリストされます。 |
|
これらのビューには、データベースで定義されているパーティション化された外部表のサブパーティション・レベルの情報がリストされます。 |
|
これらのビューには、外部表のパーティションのデータソースがリストされます。 |
|
これらのビューには、外部表のサブパーティションのデータソースがリストされます。 |
|
これらのビューには、表およびビューに関するヒストグラムが表示されます。 |
|
これらのビューには、表のオプティマイザ統計が格納されます。 |
|
これらのビューは、関連する |
|
これらのビューには、表統計が最後に収集された時点以降変更された表が表示されます。これらのビューは即時には移入されず、ある程度の時間(通常は3時間)が経過した後に移入されます。 |
|
これらのビューには、暗号化された表の列がリストされ、各列に使用している暗号化アルゴリズムがリストされます。 |
|
これらのビューには、 |
|
これらのビューには、 |
例: 列情報の表示
_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 SQLチューニング・ガイド』を参照してください。
親トピック: 表の管理