| Oracle® Database管理者ガイド 11g リリース2 (11.2) B56301-04 |
|
 前 |
 次 |
ここでは、表を管理するときに従うべきガイドラインについて説明します。これらのガイドラインに従うことで、表の作成や表データのロード、更新および問合せを行うときに、表の管理が容易になり、パフォーマンスの向上にもつながります。
この項の内容は、次のとおりです。
通常、アプリケーション開発者は、表などのアプリケーションの要素を設計する必要があります。データベース管理者は、アプリケーション表を保持する、基礎となる表領域に対する属性の設定を担当します。DBAまたはアプリケーション開発者は(あるいは双方が協力して)、サイトの業務に基づいて実際の表の作成を担当します。
表を設計する場合は、アプリケーション開発者と協力し、次のガイドラインを考慮してください。
表、列、索引およびクラスタには、内容を表現する名前を使用します。
表名および列に略語を使用する場合や、単数形と複数形の使用には、一貫性を持たせます。
COMMENTコマンドを使用して、各表とその列の意味を記載します。
各表は正規化します。
各列に適切なデータ型を選択します。
一部の表に仮想列を1つ以上追加した場合、アプリケーションに利点があるかどうかを検討します。
記憶域を節約するために、NULLを許可する列を最後に定義します。
記憶域を節約し、SQL文のパフォーマンスを最適化するために、適切な場合は必ず表をクラスタ化します。
表を作成する前に、整合性制約の使用についても判断します。表の列に整合性制約を定義することによって、データベースのビジネス・ルールを自動的に徹底できます。
作成できる表のタイプは次のとおりです。
| 表のタイプ | 説明 |
|---|---|
| 通常の(ヒープ構成)表 | この章の主な説明の対象でもある基本的で多目的な表です。この表のデータは、順序付けされていないコレクション(ヒープ)として格納されます。 |
| クラスタ化表 | クラスタ化表は、クラスタの一部である表です。クラスタとは、各表が共通の列を共有していて一緒に使用されるケースが多いために、同じデータ・ブロックを共有する表のグループです。
クラスタおよびクラスタ化表の詳細は、第22章「クラスタの管理」を参照してください。 |
| 索引構成表 | 通常の(ヒープ構成)表とは異なり、索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納されます。Bツリーの各索引エントリには、索引構成表の行の主キー列値以外に、非キー列値も格納されます。
索引構成表の詳細は、「索引構成表の管理」を参照してください。 |
| パーティション表 | パーティション表では、データをパーティションと呼ばれるさらに小さく管理が容易な単位に分割でき、さらにサブパーティションに分割することもできます。各パーティションには、圧縮の有効化または無効化、圧縮のタイプ、物理記憶域設定、表領域など別個の物理属性を指定できるため、可用性およびパフォーマンスをより適切にチューニングできる構造になります。さらに、各パーティションを個別に管理できるため、バックアップや管理が簡素化され、これらの処理に必要な時間を削減できます。
パーティション表の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
新しい表を格納する表領域を識別するには、CREATE TABLE文にTABLESPACE句を指定します。パーティション表の場合は、各パーティションを格納する表領域をオプションとして指定できます。使用する表領域に対する適切なシステム権限と割当て権限があることを確認してください。CREATE TABLE文で表領域を指定しない場合は、作成したユーザーのデフォルト表領域内に表が作成されます。
新しい表を含む表領域を指定するときは、その選択が意味することを確実に理解しておいてください。各表の作成時に表領域を適切に指定することによって、データベース・システムのパフォーマンスが向上し、データベース管理に必要な時間を短縮できます。
次のように、表領域を指定しない場合や不適切な表領域を指定した場合は、パフォーマンスに影響を与えます。
ユーザーのオブジェクトをSYSTEM表領域に作成すると、データ・ディクショナリ・オブジェクトとユーザー・オブジェクトの両方が同じデータファイルを求めて競合し、データベースのパフォーマンスが低下するおそれがあります。ユーザーのオブジェクトはSYSTEM表領域に格納しないでください。これを回避するには、データベースに表領域が作成される際に、すべてのユーザーにデフォルトの表領域が割り当てられていることを確認します。
アプリケーションに関係する表をいろいろな表領域に無計画に格納すると、DBAがアプリケーションのデータ管理操作(バックアップやリカバリなど)に要する時間が増大する可能性があります。
CREATE TABLE文で副問合せ(AS SELECT)を使用して表を作成する際は、パラレル実行を使用できます。複数のプロセスが同時に動作して表を作成するため、表を作成するときのパフォーマンスが向上します。
表作成のパラレル化の説明は、「表作成のパラレル化」を参照してください。
表を最も効率よく作成するには、CREATE TABLE...AS SELECT文でNOLOGGING句を使用します。NOLOGGING句を指定すると、表の作成中に最小限のREDO情報しか生成されません。これには、次のような利点があります。
REDOログ・ファイルの領域を節約できます。
表の作成に要する時間が削減できます。
大規模な表のパラレル作成のパフォーマンスが向上します。
また、NOLOGGING句を指定することで、SQL*Loaderを使用した後続のダイレクト・ロードおよびダイレクト・ロードINSERT操作がロギングされなくなります。後続のデータ操作文(DML)文(UPDATE、DELETEおよび従来型パスの挿入)は、表のNOLOGGING属性の影響を受けず、REDOを生成します。
表の作成後にその表の損失(たとえば、表の作成に使用したデータにアクセスできなくなるなど)を避ける必要がある場合は、作成直後に表のバックアップを取得してください。一時的に使用するために作成する表など、そのような予防策が不要な場合もあります。
一般に、NOLOGGINGを指定して表を作成するときは、小規模な表より大規模な表のほうが相対的にパフォーマンスの向上が大きくなります。小規模な表の場合は、NOLOGGINGを指定しても、表作成に要する時間にほとんど影響はありません。一方、大規模な表では、特に表作成をパラレル化したときにもパフォーマンスが著しく向上します。
データベースが大きくなるにつれて、表圧縮の使用を検討してください。圧縮を使用すると、ディスク領域が節約され、データベース・バッファ・キャッシュのメモリー使用が削減されて、読込み中の問合せ実行速度が大幅に向上します。圧縮には、データのロードやDMLのためのCPUオーバーヘッドがかかります。ただし、この負荷はI/O要件の削減によって相殺される可能性があります。
表の圧縮は、アプリケーションに対して完全に透過的です。意思決定支援システム(DSS)、オンライン・トランザクション処理(OLTP)システムおよびアーカイブ・システムで役立ちます。
圧縮は、表領域、表またはパーティションに対して指定できます。表領域レベルで指定した場合、その表領域内に作成されるすべての表がデフォルトで圧縮されます。
圧縮は、表に対するデータの挿入、更新またはバルク・ロード中に実行できます。圧縮が許可される操作は次のとおりです。
単一行または単一配列の挿入および更新
次のダイレクト・パスINSERT方法
ダイレクト・パスSQL*Loader
CREATE TABLE AS SELECT文
パラレルINSERT文
APPENDまたはAPPEND_VALUESヒントを指定したINSERT文
Oracle Databaseでは、表の圧縮でいくつかの方法がサポートされます。これらの方法を表20-1にまとめます。
表20-1 表圧縮方法
| 表圧縮方法 | 圧縮レベル | CPUオーバーヘッド | アプリケーション | 注意 |
|---|---|---|---|---|
|
基本圧縮 |
高 |
最小限 |
DSS |
なし。 |
|
OLTP圧縮 |
高 |
最小限 |
OLTP、DSS |
なし。 |
|
ウェアハウス圧縮(ハイブリッド・コラム圧縮) |
より高い |
より高い |
DSS |
圧縮レベルとCPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します。 |
|
オンライン・アーカイブ圧縮(ハイブリッド・コラム圧縮) |
最高 |
最高 |
アーカイブ |
圧縮レベルとCPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します。 |
基本表圧縮は、ダイレクト・パス・ロードによって挿入されたデータのみを圧縮し、制限されたデータ型およびSQL操作をサポートします。OLTP表圧縮はOLTPアプリケーション向けで、すべてのSQL操作によって操作されたデータを圧縮します。
ウェアハウス圧縮とオンライン・アーカイブ圧縮では、ハイブリッド・コラム圧縮テクノロジが使用されるため、最高の圧縮レベルが実現します。ハイブリッド・コラム圧縮テクノロジでは、行優先ストレージではなく、修正された形式の列指向ストレージが使用されます。これにより、データベースでは、同様のデータをまとめて格納できるため、圧縮アルゴリズムの効率性が向上します。ハイブリッド・コラム圧縮では、DMLでCPUオーバーヘッドが多く必要とされるため、更新頻度の低いデータにのみこの圧縮機能を使用してください。
より高い圧縮レベルのハイブリッド・コラム圧縮は、ダイレクト・パス・インサートが行われるデータでのみ実現されます。従来の挿入および更新もサポートされますが、その場合はより低い圧縮形式となり、圧縮レベルも低下します。
表20-2は、表の各圧縮方法の特徴を示しています。
表20-2 表の圧縮の特徴
| 表圧縮方法 | CREATE/ALTER TABLEの構文 | ダイレクト・パス・インサート | 注意 |
|---|---|---|---|
|
基本圧縮 |
|
行は基本圧縮方式で圧縮されます。 |
ダイレクト・パス・インサートを使用せずに挿入された行と更新された行は圧縮されません。 |
|
OLTP圧縮 |
|
行はOLTP圧縮方式で圧縮されます。 |
ダイレクト・パス・インサートを使用せずに挿入された行と更新された行は、OLTP圧縮を使用して圧縮されます。 |
|
ウェアハウス圧縮(ハイブリッド・コラム圧縮) |
|
行はウェアハウス圧縮方式で圧縮されます。 |
この圧縮方式は高いCPUオーバーヘッドが発生する可能性があります。 ダイレクト・パス・インサートを使用せずに挿入された行および更新された行は、より低い圧縮形式でブロックに配置されるため、圧縮レベルは低下します。 |
|
オンライン・アーカイブ圧縮(ハイブリッド・コラム圧縮) |
|
行はオンライン・アーカイブ圧縮方式で圧縮されます。 |
この圧縮方式は高いCPUオーバーヘッドが発生する可能性があります。 ダイレクト・パス・インサートを使用せずに挿入された行および更新された行は、より低い圧縮形式でブロックに配置されるため、圧縮レベルは低下します。 |
表圧縮の指定には、CREATE TABLE文のCOMPRESS句を使用します。既存の表に対して圧縮を使用可能にするには、これらの句をALTER TABLE文で使用します。この場合、圧縮を使用可能にした後で挿入または更新されたデータのみが圧縮されます。同様に、ALTER TABLE...NOCOMPRESS文を使用すると、既存の圧縮表に対する表圧縮を使用禁止にできます。この場合、圧縮済のデータはすべて圧縮されたままになり、新規データは圧縮されずに挿入されます。
COMPRESS FOR QUERY HIGHオプションは、デフォルトのデータ・ウェアハウス圧縮モードです。Exadataストレージでハイブリッド・コラム圧縮を使用する場合に、高い圧縮レベルと優れたパフォーマンスが実現します。COMPRESS FOR QUERY LOWオプションは、ロード・パフォーマンスが非常に重要な環境で使用する必要があります。このオプションでは、COMPRESS FOR QUERY HIGHオプションで圧縮されたデータより高速にロードが行われます。
COMPRESS FOR ARCHIVE LOWオプションは、デフォルトのオンライン・アーカイブ圧縮モードです。これにより、高い圧縮レベルが実現し、頻繁にアクセスしないデータに最適です。めったにアクセスされないデータに対しては、COMPRESS FOR ARCHIVE HIGHオプションを使用する必要があります。
DBMS_COMPRESSIONパッケージで提供される圧縮アドバイザを使用すると、特定の表に特定の圧縮方法を適用したときに予想される圧縮レベルを確認できます。
|
注意: ハイブリッド・コラム圧縮は、基礎となるストレージ・システムに依存します。詳細は、『Oracle Databaseライセンス情報』を参照してください。 |
次に示す例は、表圧縮に関連があります。
例20-1 OLTP表圧縮を使用した表の作成
次の例では、表ordersに対してOLTP表圧縮を使用可能にします。
CREATE TABLE orders ... COMPRESS FOR OLTP;
orders表のデータは、ダイレクト・パスINSERTおよび従来のDMLの両方で圧縮されます。
例20-2 基本表圧縮を使用した表の作成
次に示す同等の文では、データ・ウェアハウス内のファクト表であるsales_history表に対して基本表圧縮を使用可能にします。
CREATE TABLE sales_history ... COMPRESS BASIC; CREATE TABLE sales_history ... COMPRESS;
この表には問合せが頻繁に実行されますが、DMLの実行は想定されていません。
例20-3 ダイレクト・パス・インサートを使用した表への行の挿入
この例では、ダイレクト・パスINSERTを使用してsales_history表に行を挿入する場合にAPPENDヒントを使用する方法を示しています。
INSERT /*+ APPEND */ INTO sales_history SELECT * FROM sales WHERE cust_id=8890; COMMIT;
表には圧縮パーティションと非圧縮パーティションの両方を含めることができ、異なるパーティションでは異なる圧縮方法を使用できます。表に対する圧縮の設定とそのパーティションに対する設定が一致しない場合、パーティションについてはパーティションの設定が優先されます。
パーティションの圧縮方法を変更するには、次のどちらかを実行します。
新しいデータのみの圧縮方法を変更するには、ALTER TABLE ... MODIFY PARTITION ... COMPRESS ...を使用します。
新しいデータと既存のデータの両方の圧縮方法を変更するには、ALTER TABLE ... MOVE PARTITION ... COMPRESS ...または表のオンライン再定義のどちらかを使用します。
圧縮表の場合は、*_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 OLTP 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 OLTP SALES Q2_2009 ENABLED OLTP
ハイブリッド・コラム圧縮表が更新されると、行はウェアハウス圧縮(QUERY HIGH)からOLTP圧縮または圧縮なしなどの低レベルの圧縮に変更されます。行の圧縮レベルを確認するには、DBMS_COMPRESSIONパッケージのGET_COMPRESSION_TYPEファンクションを使用します。
たとえば、次の問合せは、hr.employees表の行の圧縮タイプを返します。
SELECT DECODE(DBMS_COMPRESSION.GET_COMPRESSION_TYPE(
ownname => 'HR',
tabname => 'EMPLOYEES',
row_id => 'AAAVEIAAGAAAABTAAD'),
1, 'No Compression',
2, 'Basic or OLTP 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',
'Unknown Compression Type') compression_type
FROM DUAL;
表の行をサンプリングすることで、高レベルの圧縮ではなくなった行の割合を確認できます。ALTER TABLEまたはMOVE PARTITIONを使用すると、より高い圧縮レベルを指定できます。たとえば、行のうちの10パーセントが最高の圧縮レベルでなくなった場合、表を変更するか、パーティションを移動してより高い圧縮レベルを指定できます。
|
関連項目: GET_COMPRESSION_TYPEの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
パーティション、表または表領域の圧縮レベルは変更できます。たとえば、ある企業でその売上データにウェアハウス圧縮を使用している一方で、6か月より古い売上データにはめったにアクセスしないとします。売上データがその経過時間に基づいてパーティション化された表に格納されている場合、古いデータの圧縮レベルをオンライン・アーカイブ圧縮に変更して、ディスク領域を解放できます。
表がパーティション化されている場合、DBMS_REDEFINITIONパッケージを使用して表の圧縮レベルを変更できます。このパッケージでは、表の再定義をオンラインで実行するために、再定義中に表のデータを保持する一時コピーを作成します。再定義される表は、再定義中でも引き続き問合せやDML文に対応できます。オンラインでの表の再定義に使用される空き領域の容量は、既存の表と新しい表の相対的な圧縮レベルに応じて変化します。DBMS_REDEFINITIONパッケージを使用する前に、システム上に十分なハード・ディスク領域が存在することを確認してください。
表がパーティション化されていない場合、ALTER TABLE...MOVE...COMPRESS FOR...文を使用して圧縮レベルを変更できます。ALTER TABLE...MOVE文では、コマンドの実行中に表に対するDML文は許可されません。
パーティションの圧縮レベルを変更するには、ALTER TABLE...MODIFY PARTITION文を使用します。表領域の圧縮レベルを変更するには、ALTER TABLESPACE文を使用します。
|
関連項目:
|
圧縮表に列を追加する場合、次の制限が適用されます。
基本圧縮: 追加される列にはデフォルト値を指定できません。
OLTP圧縮: 追加される列にデフォルト値を指定する場合、列はNOT NULLであることが必要です。デフォルト値が設定されたNULL値可能列の追加はサポートされません。
圧縮表の列を削除する場合、次の制限が適用されます。
基本圧縮: 列の削除はサポートされていません。
OLTP圧縮: DROP COLUMNはサポートされていますが、長時間実行される解凍と再圧縮の操作を避けるために、データベースでは列が内部的にUNUSEDに設定されます。
ハイブリッド・コラム圧縮表は、データ・ポンプのインポート・ユーティリティのimpdpコマンドを使用してインポートできます。デフォルトでは、impdpコマンドは表プロパティを保存し、インポートされた表はハイブリッド・コラム圧縮表となります。ハイブリッド・コラム圧縮をサポートしていない表領域では、impdpコマンドは失敗し、エラーが表示されます。表はexpdpコマンドでエクスポートすることもできます。
ハイブリッド・コラム圧縮表は、impdpコマンドのTRANSFORM:SEGMENT_ATTRIBUTES=nオプション句を使用して、非圧縮表としてインポートできます。
非圧縮表またはOLTP圧縮表は、インポート中にハイブリッド・コラム圧縮形式に変換できます。ハイブリッド・コラム圧縮表でない表をハイブリッド・コラム圧縮表に変換するには、次のようにします。
ALTER TABLESPACE ... SET DEFAULT COMPRESSコマンドを使用して、表領域のデフォルト圧縮を指定します。
インポート中にインポートされた表のSEGMENT_ATTRIBUTESオプションを上書きします。
|
関連項目:
|
ハイブリッド・コラム圧縮表をバックアップからリストアする必要がある場合があります。表はハイブリッド・コラム圧縮をサポートしているシステム、またはハイブリッド・コラム圧縮をサポートしていないシステムにリストアできます。ハイブリッド・コラム圧縮が含まれる表をハイブリッド・コラム圧縮をサポートしているシステムにリストアする場合は、通常どおり、Oracle Recovery Manager (RMAN)を使用してファイルをリストアします。
ハイブリッド・コラム圧縮表がハイブリッド・コラム圧縮をサポートしていないシステムにリストアされている場合は、表をハイブリッド・コラム圧縮からOLTP圧縮形式または非圧縮形式に変換する必要があります。表をリストアするには、次のようにします。
環境に非圧縮形式またはOLTP圧縮形式のデータを保存するに十分なストレージがあることを確認します。
RMANを使用して、ハイブリッド・コラム圧縮表領域をリストアします。
次のいずれかのアクションを実行して、表をハイブリッド・コラム圧縮からOLTP圧縮形式または非圧縮形式に変換します。
次の文を使用して、データ圧縮をハイブリッド・コラム圧縮からCOMPRESS FOR OLTPに変更します。
ALTER TABLE table_name MOVE COMPRESS FOR OLTP;
次の文を使用して、データ圧縮をハイブリッド・コラム圧縮からNOCOMPRESSに変更します。
ALTER TABLE table_name MOVE NOCOMPRESS;
各パーティションをNOCOMPRESSに変更するには、次の文を使用します。
ALTER TABLEtable_nameMOVE PARTITIONpartition_nameNOCOMPRESS;
各パーティションは個別に変更します。
次の文を使用して、データをNOCOMPRESSに並列で移動します。
ALTER TABLE table_name MOVE NOCOMPRESS PARALLEL;
|
関連項目:
|
圧縮表に関して、次の注意点や制限があります。
オンラインによるセグメントの縮小は、圧縮表ではサポートされていません。
この項で説明する表圧縮方法は、SecureFilesラージ・オブジェクト(LOB)には適用されません。SecureFiles LOBには独自の圧縮方法があります。詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
圧縮テクノロジではCPUを使用します。追加の負荷を処理するために使用可能なCPUが十分にあることを確認する必要があります。
基本圧縮で作成された表では、特に指定しないかぎり、PCT_FREEパラメータが自動的に0(ゼロ)に設定されます。
基本圧縮またはハイブリッド・コラム圧縮で圧縮した表で従来のDMLを使用すると、挿入および更新されるすべての行は非圧縮、または低レベルの圧縮形式で保存されます。このような行が圧縮されるように圧縮表をパックするには、ALTER TABLE MOVE文を使用できます。この操作には表の排他ロックが必要なため、この操作が完了するまで更新とロードを実行しないでください。このような状況が望ましくない場合は、表のオンライン再定義を使用できます。
|
関連項目:
|
機密データを格納する個々の表の列を暗号化できます。機密データには、社会保障番号、クレジット・カード番号、医療記録などがあります。列の暗号化は、アプリケーションに対して完全に透過的ですが、いくつか制限事項があります。
暗号化は、セキュリティの問題をすべて解決するわけではありませんが、ユーザーがデータベースのセキュリティ機能を迂回して、オペレーティング・システムのファイル・システムから直接データベース・ファイルにアクセスしようとした場合に、そのユーザーからデータを保護します。
列暗号化はOracle Databaseの透過的データ暗号化機能を使用しますが、この機能を使用するには、データベースのマスター暗号化鍵を保存するためにOracleウォレットを作成する必要があります。暗号化列を含む表を作成する場合、および暗号化データを格納または取得する場合は、ウォレットがオープンしている必要があります。ウォレットは、オープンするとすべてのセッションで使用可能になり、明示的にクローズするか、データベースが停止されるまではオープンしたままになります。
透過的データ暗号化では、次に示すAdvanced Encryption Standard(AES)アルゴリズムやTriple Data Encryption Standard(3DES)アルゴリズムなど、業界標準の暗号化アルゴリズムがサポートされています。
AES256
AES192
AES128
3DES168
使用するアルゴリズムは表の作成時に選択します。表のすべての暗号化列で同じアルゴリズムが使用されます。デフォルトはAES192です。暗号化キーの長さはアルゴリズム名で示されています。たとえば、AES128アルゴリズムでは128ビットのキーが使用されます。
1つ以上の表にある多数の列を暗号化する場合は、かわりに表領域全体を暗号化してその表領域にこれらの表を格納することも考慮できます。表領域の暗号化でも同様に透過的データ暗号化機能が使用されますが、物理的なブロック・レベルで暗号化されるため、多数の列を暗号化するよりパフォーマンスが向上します。表領域レベルで暗号化する別の理由は、列暗号化の次の制限事項に対処するためです。
COMPATIBLE初期化パラメータが10.2.0(透過的データ暗号化を使用可能にするための最小設定値)に設定されている場合、ソートまたはハッシュ結合に関与していて一時表領域に書き込まれる暗号化列のデータは、平文で書き込まれるため、攻撃にさらされます。一時表領域に書き込まれる暗号化データを暗号化されたままにするには、COMPATIBLEを11.1.0以上に設定する必要があります。なお、UNDO表領域またはREDOログに書き込まれる場合は、COMPATIBLEが10.2.0以上に設定されていれば、暗号化列のデータは暗号化されたままです。
オブジェクト・データ型などの特定のデータ型は、列暗号化ではサポートされていません。
暗号化列がある表が含まれた表領域に対しては、トランスポータブル表領域機能を使用できません。
その他の制限の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
|
関連項目:
|
Oracle Database 11g リリース2以降、ローカルで管理される表領域内にヒープ構成表を作成すると、最初の行が挿入されるまで表セグメントの作成が遅延されます。
さらに、セグメントの作成は、表のすべてのLOB列、表作成の一環として暗黙的に作成されたすべての索引、および後から明示的にその表に作成されたすべての索引に対して遅延されます。
|
注意: リリース11.2.0.1では、パーティション表に対するセグメント作成の遅延はサポートされていません。この制限は、リリース11.2.0.2以降では除去されています。 |
この領域割当て方法の利点は次のとおりです。
インストール時に何百もの表が作成され、その表の多くに一度もデータが移入されないようなアプリケーションで、ディスク領域が大幅に削減されます。
アプリケーションのインストール時間が短縮されます。
最初の行が挿入される際に新しいセグメントを作成する必要があるため、パフォーマンスが多少低下します。
セグメント作成の遅延を有効にするには、互換性を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言語リファレンス』を参照してください。 |
Oracle Database 11g リリース2(11.2.0.2)からは、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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
表を作成する前に表のサイズを見積ります。見積りは、なるべくデータベース計画の一部として実行します。データベース表のサイズと用途を確認することは、データベース計画の重要な部分です。
表の見積りサイズの合計と、索引、UNDO領域およびREDOログ・ファイルの見積りを使用して、作成するデータベースを格納するために必要なディスク容量を決定できます。この見積りによって、適切なハードウェアを購入できます。
見積ったサイズと個々の表サイズの増加率を使用すると、作成する表に最適な表領域の属性とその基礎となるデータファイルを適格に判断できます。これによって、表のディスク領域の管理が容易になり、表を使用するアプリケーションのI/Oパフォーマンスが向上します。
表の計画と使用に影響を与える可能性のある制限事項がいくつかあります。
オブジェクト型を含む表は、Oracle8より古いバージョンのデータベースにインポートできません。
エクスポートされた表は、異なるスキーマで同じ名前の付いた既存の表にマージできません。
オリジナルのデータがデータベースにまだ存在するときは、型とエクステント表を異なるスキーマには移動できません。
Oracle Databaseには、表が持つ列(またはオブジェクト型の属性)の合計数に制限があります。この制限の詳細は、『Oracle Databaseリファレンス』を参照してください。
ユーザー定義型のデータを含む表を作成すると、ユーザー定義型の列はその型データを格納するリレーショナル列にマップされます。これにより、追加のリレーショナル列が作成されます。これらのリレーショナル列は「非表示」で、DESCRIBE表の文では表示されず、SELECT *文でも返されません。したがって、オブジェクト表、REFの列を持つリレーショナル表、VARRAY、ネストした表またはオブジェクト型を作成するときは、データベースが表に対して実際に作成した列の合計数が、指定した数よりも多くなることがあるので注意してください。
|
関連項目: ユーザー定義のタイプの詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。 |
