機械翻訳について

クラウド表を使用したロギングおよび診断情報の格納

表データがOracle管理のクラウド・ストレージに存在し、表データがデータベース・ストレージを消費しないクラウド表を作成できます。

クラウド表について

クラウド表は、データベース内の表の補完的な代替として作成できます。

クラウド表のすべてのデータは、Oracle管理オブジェクト・ストレージに格納されます。 Oracle管理対象オブジェクト・ストレージは、Autonomous Databaseが作成および管理する、データベース外部の外部ストレージです。

クラウド表を使用すると、あまり使用されないアプリケーション・ロギング・データ、診断情報を格納したり、他のデータを格納できます。 Autonomous Databaseで実行されていない既存のアプリケーションでは、この種の情報をローカル・ファイル・システム上のファイルに格納できます(たとえば、UTL_FILE APIを使用)。 このようなロギング・メカニズムと関連ファイルは、アプリケーション・エラーを診断して解決する必要がある場合に非常に役立ちます。 ただし、データベース表に情報を格納すると、あまり使用されないデータに対して大量のデータベース・ストレージを使用できます。 クラウド表を使用すると、データベース・ストレージを使用せずに、永続データがOracle管理オブジェクト・ストレージに保存されます。

ノート:

CLOUD_TABLE_COMMIT_THRESHOLDパラメータはすべてのクラウド表に適用され、ALTER SESSION権限を持つ任意のユーザーが設定できます。 したがって、クラウド表は、コミットされた変更を永続化する必要があり、同時リーダーがすぐに参照できる必要があるセキュリティ・クリティカルなデータには適していません。 このため、クラウド表は監査ログ表などのユースケースには適していない場合があります。

クラウド表のSELECTおよびDMLの制限

クラウド表は、いくつかの制限がある通常のデータベース表と同様に機能します。 次の例外を除いて、SELECT文とDML文、データ操作文を使用できます:

  • MERGE 文はサポートされません。
  • LOB 列は、10MBのデータに制限されています。
  • DML同時実行性制御は異なるため、次のようになります:
    • LOCK TABLEは、データベース表の場合と同様に、同時DMLを防止できません。
    • INSERT は表のロックを取得しないため、INSERTは同時DML操作によってブロックされません。
    • UPDATE 操作とDELETE操作はどちらも、クラウド表に対する排他ロックを取得します。 したがって、UPDATEまたはDELETEトランザクションは、クラウド表に対する同時UPDATEまたはDELETE操作をブロックします。
  • NOT NULL制約のみが適用されます。
  • DMLは、他の表と同様に読取り/書込みAutonomous Databaseでも使用できます。クラウド表では、リフレッシュ可能クローンでのDML操作も可能です。

クラウド表では、次のものはサポートされません:

  • 索引
  • 非表示列
  • 仮想列
  • DMLトリガー
  • 996列以上
  • ブール・データ型の列

ライフサイクル管理操作とクラウド表

クラウド表データは、Oracle管理オブジェクト・ストレージに格納されます。 これは、次のように、Autonomous Databaseに対する特定の操作がデータベース内表とは異なる方法でクラウド表を処理することを意味します:

  • クラウド表データは、Autonomous Databaseインスタンスのバックアップおよびリカバリから除外されます(データはバックアップされず、クラウド表データをリストアできません)。

  • クラウド表データは、Oracle管理オブジェクト・ストレージを介して保護されます。

  • Autonomous Databaseインスタンスの状態に影響するライフサイクル管理操作は、クラウド表に格納されているデータには影響しません。

オブジェクト・ストレージのクラウド表ネーミングは、OCIDに基づいて、Autonomous Databaseインスタンスごとに一意に定義されます。 つまり、既存のデータベースの新しいOCIDを変更または導入する操作は、クラウド表に影響します。 次に、クラウド表データに対するライフサイクル操作の影響を示します。

ライフサイクル操作 クラウド表のデータ可用性
同じリージョン・データベース・クローン クラウド表データなしでクラウド表がクローニングされます
クロス・リージョン・データベース・クローン クラウド表データなしでクラウド表がクローニングされます
同じリージョン(ローカル) Autonomous Data Guardスタンバイ クラウド表およびクラウド表データにアクセスできます
クロス・リージョンAutonomous Data Guardスタンバイ クラウド表は、クラウド表データなしでスタンバイで使用可能
同じリージョン(ローカル)の「バックアップ・ベースの障害リカバリ」ピア クラウド表およびクラウド表データにアクセスできます
リージョン間の「バックアップ・ベースの障害リカバリ」ピア クラウド表は、クラウド表データなしでスタンバイで使用できます
次のような、Autonomous DatabaseインスタンスのSCN/タイムスタンプに影響するライフサイクル管理操作:
  • 長期バックアップ
  • データベースのリストア(時点のリストア)
  • バックアップからのクローニング

クラウド表は引き続き更新され、クラウド表データの古い状態は保持またはリストアされません。 これは、現在のクラウド表データのみが使用可能であることを意味します。

次のようなライフサイクル管理操作:
  • リソース割当ての管理
  • 移動
  • 縮小
  • 名前変更
  • モード: Read-only/read-write
  • ワークロード・タイプの変更: たとえば、データ・ウェアハウスからトランザクション処理へ
 クラウド表またはクラウド表データへの影響なし

クラウド表によるバッファリング

デフォルトでは、DMLのコミット時に、クラウド表に対するDML変更がオブジェクト・ストレージにエクスポートされます。 ただし、DMLが小さい、頻繁にコミットされるトランザクションとして構造化されている場合、これは適切に機能しない可能性があります。 このシナリオのパフォーマンスを向上させるには、CLOUD_TABLE_COMMIT_THRESHOLDパラメータを設定して、セッション内のクラウド表DML変更のバッファリングを有効にします。

CLOUD_TABLE_COMMIT_THRESHOLDパラメータがゼロ以外の値に設定されている場合、値は変更カウントしきい値として処理され、変更数が指定されたしきい値に達するまでクラウド表の変更がバッファリングされます。 しきい値に達すると、バッファされた変更がオブジェクト・ストレージにエクスポートされます。 バッファ済の変更は、CLOUD_TABLE_COMMIT_THRESHOLDに達していない場合でも、セッションが正常に終了するとエクスポートされます。 バッファリングされた変更がエクスポートされる前に、同時セッションに変更は表示されません。 予期しないプロセスの有効期限が切れることがまれに、バッファリングされた変更がエクスポートされず、変更が永続的でない(つまり、バッファリングされた変更がオブジェクト・ストアにエクスポートされない)ことがあります。

詳細は、CLOUD_TABLE_COMMIT_THRESHOLDを参照してください。

クラウド表の作成

Autonomous Databaseにクラウド表を作成するステップを示します。

クラウド表を作成するには:

  1. CREATE_CLOUD_TABLEプロシージャを実行します。

    たとえば:

    BEGIN
  DBMS_CLOUD.CREATE_CLOUD_TABLE(
   table_name  => 'CLOUD_TABLE_TEST',
   column_list => 'I INTEGER, STR1 VARCHAR2(32)' );
END;
/

    詳細については、「CREATE_CLOUD_TABLEプロシージャ」を参照してください。

  2. クラウド表にデータを挿入します。
    INSERT INTO cloud_table_test VALUES (1, 'xyz');

    CLOUD_TABLE_COMMIT_THRESHOLD初期化パラメータを使用して、クラウド表のバッファリングを有効にできます。 詳細は、CLOUD_TABLE_COMMIT_THRESHOLDを参照してください。

  3. クラウド表からデータを選択します。
    SELECT * FROM cloud_table_test;
    I          STR1
---------- --------------------------------
1          xyz

クラウド表を削除する場合は、DROP TABLEを使用します。

たとえば:

DROP TABLE CLOUD_TABLE_TEST;

クラウド表はごみ箱をサポートしていません。

詳細は、「クラウド表のノート」を参照してください。

クラウド表のノート

クラウド表を使用するためのノートを提供します。

クラウド表の使用に関するノートを次に示します。

  • クラウド表に対して、SELECT、INSERTおよびUPDATE権限を付与できます。 他の権限はクラウド表に付与できません。

    詳細については、「権限およびロール認可の構成」を参照してください。

  • クラウド表の制約は、RELY DISABLE NOVALIDATEモードの制約に制限されます。これは、制約が適用されないことを意味します。 この例外は、NOT NULL制約のみです。

    クラウド表では、デフォルト・モード(ENABLE VALIDATE)を含むすべてのNOT NULL制約モードがサポートされます。 PRIMARY KEY, UNIQUE, FOREIGN KEYおよびNOT NULL制約がサポートされています。CHECK制約はサポートされていません。

    制約は、COLUMN_LISTの一部としてインラインで宣言できます。

    たとえば:

    BEGIN
  DBMS_CLOUD.CREATE_CLOUD_TABLE(
        table_name  => 'CLOUD_TAB_WITH_CONSTRAINTS',
        column_list => 'PK INTEGER,
            DATE_ID INT REFERENCES DATE_DIM(DATE_ID) RELY DISABLE NOVALIDATE,
            VAL NUMBER NOT NULL,
            CONSTRAINT CLOUD_TAB_PK PRIMARY KEY(PK) RELY DISABLE NOVALIDATE');
END;
/

    クラウド表のその他の制限については、「クラウド表のノート」を参照してください。

  • DBMS_CLOUDパッケージは、実行者権限パッケージです。 DBMS_CLOUD.CREATE_CLOUD_TABLEプロシージャでは、実行者のスキーマに表のみを作成できます。

    詳細については、「実行者権限および定義者権限条項」を参照してください。

  • DBMS_CLOUD.CREATE_CLOUD_TABLEプロシージャ・コールのcolumn_listパラメータには、CREATE TABLEのDEFAULT句のように機能するDEFAULT句を含めることができます。 詳細については、CREATE TABLEを参照してください。

    たとえば:

    BEGIN
  DBMS_CLOUD.CREATE_CLOUD_TABLE(
   table_name  => 'CLOUD_TABLE_TEST_DEFAULT',
   column_list => 'I INTEGER, STR2 VARCHAR2(32) DEFAULT ''ABC''');
END;
/

    その後、デフォルト値を使用して挿入できます。 たとえば: 

    INSERT INTO cloud_table_test_default (i) VALUES (1); 
1 row created. 
INSERT INTO cloud_table_test_default VALUES (2, default);
1 row created.
INSERT INTO cloud_table_test_default VALUES (3, null);
1 row created.
INSERT INTO cloud_table_test_default VALUES (4, 'xyz');
1 row created.
COMMIT;
Commit complete.
SELECT * FROM cloud_table_test_default ORDER BY i;

I STR2 
- ---- 
1 ABC  
2 ABC  
3 null 
4 xyz

  • CLOUD_TABLE_COMMIT_THRESHOLD初期化パラメータを使用して、クラウド表のバッファリングを有効にできます。 詳細は、CLOUD_TABLE_COMMIT_THRESHOLDを参照してください。