スキーマ・オブジェクトの作成
次のトピックでは、Oracle Globally Distributed Databaseにスキーマ・オブジェクトを作成する方法を示します。
これらのオブジェクトの概念については、スキーマ・オブジェクトを参照してください。
全シャード・ユーザーの作成
シャード・カタログ・データベースにのみ存在するローカル・ユーザーには、Oracle Globally Distributed Databaseにスキーマ・オブジェクトを作成するための権限がありません。分散データベース・スキーマを作成する最初のステップは、全シャード・ユーザーを作成することです。
権限のあるユーザーとしてシャード・カタログ・データベースに接続して、SHARD DDLを有効にし、CREATE USERコマンドを実行して全シャード・ユーザーを作成します。全シャード・ユーザーがシャード・カタログ・データベースに接続すると、SHARD DDLモードがデフォルトで有効になります。
alter session enable shard ddl;
create user <all-shards_user> identified by <password>;
grant ...データベース管理者は、これらのアカウントに必要な権限を決定し、アカウントに個別に付与します。
ノート:
ローカル・ユーザーは、SHARD DDLモードを有効にしている場合、非スキーマ分散データベース・オブジェクト(表領域、ディレクトリ、コンテキストなど)を作成できます。ただし、スキーマ・オブジェクト(表、ビュー、索引、ファンクション、プロシージャなど)は作成できません。
シャード・オブジェクトは、ローカル・オブジェクトに対する依存性を持つことができません。たとえば、ローカル表に全シャード表示は作成できません。
シャードDDLを使用して、シャード・ユーザーにSYS権限を付与することはできません。各シャードにログインし、そのシャードでアカウントに権限を手動で付与する必要があります。
シャード表ファミリの作成
SQL CREATE TABLE文を使用してシャード表ファミリを作成します。参照パーティション化または同一レベル・パーティション化を使用して、表間の親子関係を指定できます。
参照パーティション化を使用した表間の親子関係の指定
シャード表ファミリは、参照パーティション化を使用し、表間の親子関係を指定して作成することをお薦めします。
参照パーティション化の場合、ルート表のみにパーティション化スキームを指定するため構文が簡単です。また、ルート表に対して実行されるパーティション管理操作が自動的に子孫に伝播されます。たとえば、ルート表にパーティションを追加すると、すべての子孫に新しいパーティションが作成されます。
システム管理のデータ分散方法を使用したCustomers–Orders–LineItemsスキーマの適切なCREATE TABLE文を次に示します。最初の文でCustomersという表ファミリのルート表を作成します。
CREATE SHARDED TABLE Customers
( CustNo NUMBER NOT NULL
, Name VARCHAR2(50)
, Address VARCHAR2(250)
, CONSTRAINT RootPK PRIMARY KEY(CustNo)
)
PARTITION BY CONSISTENT HASH (CustNo)
PARTITIONS AUTO
TABLESPACE SET ts1
;次の2つの文で、Customers表の子と孫であるOrders表とLineItems表を作成します。
CREATE SHARDED TABLE Orders
( OrderNo NUMBER NOT NULL
, CustNo NUMBER NOT NULL
, OrderDate DATE
, CONSTRAINT OrderPK PRIMARY KEY (CustNo, OrderNo)
, CONSTRAINT CustFK FOREIGN KEY (CustNo) REFERENCES Customers(CustNo)
)
PARTITION BY REFERENCE (CustFK)
;CREATE SHARDED TABLE LineItems
( CustNo NUMBER NOT NULL
, LineNo NUMBER(2) NOT NULL
, OrderNo NUMBER(5) NOT NULL
, StockNo NUMBER(4)
, Quantity NUMBER(2)
, CONSTRAINT LinePK PRIMARY KEY (CustNo, OrderNo, LineNo)
, CONSTRAINT LineFK FOREIGN KEY (CustNo, OrderNo) REFERENCES Orders(CustNo, OrderNo)
)
PARTITION BY REFERENCE (LineFK)
;前述の例の文では、ファミリ内のすべての表の対応するパーティションが同じ表領域セットTS1に格納されます。ただし、各表に個別の表領域セットを指定できます。
前述の例の文では、シャーディング・キーとして使用されているパーティション化列CustNoは、3つの表のすべてに存在します。これは、参照パーティション化では一般に子表にキー列を複製することなく親表を使用して子表を等価パーティション化できるという事実と異なります。この理由は、子表をその親表にリンクするために使用される子表の外部キー制約には主キーを指定する必要があるので、参照パーティション化では親表に主キーが必要となるためです。ただし、シャード表の主キーは、シャーディング・キーと同じであるか、シャーディング・キーを含む必要があります。これにより、線形スケーラビリティの重要な要件である主キーのグローバルな一意性が、他のシャードと調整することなく維持されます。
要約すると、分散データベースで参照パーティション表を使用するには、次のルールに従う必要があります:
-
シャード表の主キーは、シャーディング・キーと同じであるか、シャーディング・キーを含む必要があります。他のシャードと調整することなく、主キーのグローバルな一意性を維持するためにこれが必要となります。
-
子表をその親表にリンクするための子表の外部キー制約には主キーを指定する必要があるため、参照パーティション化では親表に主キーが必要となります。親表に
UNIQUE制約のみがあり、PRIMARY KEYがない場合は、外部キー制約を設定することもできます。シャーディング・キーもNOT NULLである必要があります。たとえば、LineItems (子)表をOrders (親)表にリンクするには、Orders表に主キーが必要となります。2番目のルールは、Orders表の主キーに
CustNo値が含まれていることを意味します。(これは、Oracle Globally Distributed Databaseに固有ではない既存のパーティション化のルールです。)
同一レベル・パーティション化を使用した表間の親子関係の指定
場合によっては、参照パーティション化に必要な主キー制約と外部キー制約を作成することが不可能か望ましくないことがあります。このような場合、表ファミリで親子関係を指定するには、すべての表が明示的に同一レベル・パーティション化されている必要があります。各子表は、親の名前を含むCREATE SHARDED TABLEのPARENT句を使用して作成されます。次に、構文の例を示します。
CREATE SHARDED TABLE Customers
( CustNo NUMBER NOT NULL
, Name VARCHAR2(50)
, Address VARCHAR2(250)
, region VARCHAR2(20)
, class VARCHAR2(3)
, signup DATE
)
PARTITION BY CONSISTENT HASH (CustNo)
PARTITIONS AUTO
TABLESPACE SET ts1
;
CREATE SHARDED TABLE Orders
( OrderNo NUMBER
, CustNo NUMBER NOT NULL
, OrderDate DATE
)
PARENT Customers
PARTITION BY CONSISTENT HASH (CustNo)
PARTITIONS AUTO
TABLESPACE SET ts1
;
CREATE SHARDED TABLE LineItems
( LineNo NUMBER
, OrderNo NUMBER
, CustNo NUMBER NOT NULL
, StockNo NUMBER
, Quantity NUMBER
)
PARENT Customers
PARTITION BY CONSISTENT HASH (CustNo)
PARTITIONS AUTO
TABLESPACE SET ts1
;すべてのCREATE SHARDED TABLE文でパーティション化スキームが完全に指定されているため、任意の表を個別にサブパーティション化できます。ルート表のみにサブパーティションを指定でき、表ファミリのすべての表のサブパーティション化スキームが同じである参照パーティション化の場合、これは許可されません。
この方法は2レベルの表ファミリのみをサポートすることに注意してください。つまり、すべての子が同じ親を持つ必要があり、孫は存在できません。親表のパーティション化列がすべての子表に存在するかぎり、これは制限にはなりません。
関連項目:
参照パーティション化の詳細は、Oracle Database VLDBおよびパーティショニング・ガイドを参照
複数の表ファミリを使用したスキーマの設計
Oracle Globally Distributed Databaseスキーマには複数の表ファミリを含めることができます。この場合、異なる表ファミリのデータはすべて同じチャンクに存在し、これには同じハッシュ・キー範囲を共有する異なる表ファミリからのパーティションが含まれます。
ノート:
複数の表ファミリは、システム管理の分散データベースでのみサポートされます。コンポジットおよびユーザー定義の分散データベースでは、1つの表ファミリのみがサポートされます。新しい表ファミリを作成するには、ルート・シャード表を作成し、既存の表領域ファミリで使用されない表領域セットを指定します。各表ファミリは、ルート表によって識別されます。異なる表ファミリの表は、互いに関連付けないでください。
各表ファミリには独自のシャーディング・キー定義が必要ですが、子表に同じシャーディング・キー列があるという同じ制限が各表ファミリ内で当てはまります。つまり、異なる表ファミリからのすべての表は、コンシステント・ハッシュと同じ方法で同じ数のチャンクにシャーディングされ、各チャンクにはすべての表ファミリからのデータが含まれます。
異なる表ファミリ間で問い合せるような表ファミリは最小限になるように設計し、シャーディング・コーディネータでのみ実行されるようにします。このような結合の多くはパフォーマンスに影響するためです。
次の例は、システム管理シャーディング方式(PARTITION BY CONSISTENT HASH)でPARENT句を使用して複数の表ファミリを作成する方法を示しています。
CREATE SHARDED TABLE Customers <=== Table Family #1
( CustId NUMBER NOT NULL
, Name VARCHAR2(50)
, Address VARCHAR2(250)
, region VARCHAR2(20)
, class VARCHAR2(3)
, signup DATE
)
PARTITION BY CONSISTENT HASH (CustId)
PARTITIONS AUTO
TABLESPACE SET ts1
;
CREATE SHARDED TABLE Orders
( OrderNo NUMBER
, CustId NUMBER
, OrderDate DATE
)
PARENT Customers
PARTITION BY CONSISTENT HASH (CustId)
PARTITIONS AUTO
TABLESPACE SET ts1
;
CREATE SHARDED TABLE LineItems
( LineNo NUMBER
, OrderNo NUMBER
, CustId NUMBER
, StockNo NUMBER
, Quantity NUMBER
)
)
PARENT Customers
PARTITION BY CONSISTENT HASH (CustId)
PARTITIONS AUTO
TABLESPACE SET ts1
;
CREATE SHARDED TABLE Products <=== Table Family #2
( ProdId NUMBER NOT NULL,
CONSTRAINT pk_products PRIMARY KEY (ProdId)
)
PARTITION BY CONSISTENT HASH (ProdId)
PARTITIONS AUTO
TABLESPACE SET ts_2
;ノート:
表ファミリに表領域セットを使用しようとし、その表領域セットが既存の表ファミリですでに使用されている場合、ORA-3850がスローされます。
表ファミリ間の結合は効率がよくないこともあるため、そのような結合が多数ある場合、またはパフォーマンスが重視されている場合は、複数の表ファミリではなく重複表を使用する必要があります。
グローバル・サービスと複数の表ファミリの関連付け
各表ファミリは、異なるグローバル・サービスに関連付ける必要があります。異なる表ファミリからのアプリケーションにはそれぞれ独自の接続プールおよびサービスがあり、適切なシャードにルーティングするために独自のシャーディング・キーを使用します。
最初のルート表(つまり、最初の表ファミリ)を作成すると、すべての既存のグローバル・サービスがその表に自動的に関連付けられます。この例に示すように、GDSCTL MODIFY SERVICEコマンドを使用して、表ファミリの作成後に、表ファミリに関連付けられているサービスを変更できます。
GDSCTL> MODIFY SERVICE –GDSPOOL shdpool –TABLE_FAMILY sales.customer -SERVICE salesシャード表の作成
シャード表は、複数のデータベース間でより小さい管理しやすい断片にパーティション化された表であり、シャードと呼ばれます。
次のトピックでは、シャード表作成についての決定をガイドし、その手順を示します。
表領域セットのサイズ設定
シャード・カタログに表領域セットを作成する場合は、シャード・カタログおよび各シャードに作成された表領域に十分な領域があることを確認する必要があります。
これは、従量制の使用環境では特に重要です。
たとえば、構成にシャード・カタログと3つのシャードがある場合、次の文を発行します。
ALTER SESSION ENABLE SHARD DDL;
CREATE TABLESPACE SET TSP_SET_1 IN SHARDSPACE SHSPC_1 USING TEMPLATE
(DATAFILE SIZE 100M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED);たとえば、シャードごとにデフォルトの120個のチャンクがある場合、このコマンドはこれらの構成に次のオブジェクトを作成します:
-
システム・シャーディング:
120の表領域(各シャードで120個のチャンク用)
シャード・カタログ内で+ 1の表領域
=各シャードで120 + 1つの表領域、初期表領域は100M
-
Raftレプリケーション:
360の表領域(レプリケーション・ユニットごとに3つのチャンクが作成されるため、各シャードで360個のチャンク用)
シャード・カタログ内で+ 1の表領域
=各シャードで360 + 1つの表領域、初期表領域は100M
必要な量の記憶域が計画されていない場合、DDLの失敗につながる可能性があり、リカバリにかなりの労力が必要になります。
この問題を回避するには、データベース初期化パラメータDB_FILESをシャードに必要なチャンクまたは表領域セット(あるいはその両方)の合計数以上に設定する必要があります。シャード・データベースの作成でDB_FILESを計算する式を見つけます。
また、表領域セットのすべての表領域はビッグファイル表領域です。bigfile表領域は、単一で非常に大きい(最大40億ブロック)データファイルを持つ可能性がある表領域です。詳細は、ビッグファイル表領域(『Oracle Database管理者ガイド』)を参照してください。
システム管理シャーディング用のシャード表
システム管理の分散データベースでは、データはコンシステント・ハッシュによるパーティション化を使用してシャード間で自動的に分散されます。
シャード表を作成する前に、CREATE TABLESPACE SETを使用して表パーティションを格納する表領域セットを作成します。
CREATE TABLESPACE SET ts1;表領域属性をカスタマイズする必要がある場合は、この例に示すように、USING TEMPLATE句をCREATE TABLESPACE SETに追加します。
CREATE TABLESPACE SET ts1
USING TEMPLATE
( DATAFILE SIZE 10M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
SEGMENT SPACE MANAGEMENT AUTO
ONLINE
)
;CREATE SHARDED TABLEを使用してシャード表を作成し、シャーディング・キーcust_idに基づいてシャード間で表を水平方向にパーティション化します。
CREATE SHARDED TABLE customers
( cust_id NUMBER NOT NULL
, name VARCHAR2(50)
, address VARCHAR2(250)
, region VARCHAR2(20)
, class VARCHAR2(3)
, signup DATE
CONSTRAINT cust_pk PRIMARY KEY(cust_id)
)
PARTITION BY CONSISTENT HASH (cust_id)
PARTITIONS AUTO
TABLESPACE SET ts1
;システム管理のシャード表は、PARTITION BY CONSISTENT HASH (primary_key_column)を指定することで、コンシステント・ハッシュでパーティション化されます。
PARTITIONS AUTO句は、パーティションの数が表領域セットts1の表領域の数に自動的に設定され、各パーティションが別々の表領域に格納されることを指定します。
ユーザー定義シャーディングのシャード表
ユーザー定義の分散データベースでは、データを個々のシャードに明示的にマップします。ユーザー定義の分散データベースのシャード表は、範囲またはリストでパーティション化できます。
ユーザー定義のシャード表の表領域セットは作成しません。ただし、次に示すように、各表領域を個別に作成し、分散データベース構成にデプロイされたシャード領域に明示的に関連付ける必要があります。
CREATE TABLESPACE tbs1 IN SHARDSPACE west;
CREATE TABLESPACE tbs2 IN SHARDSPACE central;
CREATE TABLESPACE tbs3 IN SHARDSPACE east;シャード表を作成する場合は、次の例に示すように、各表領域に格納されるデータの範囲またはリストを使用してパーティションを定義します。
CREATE SHARDED TABLE accounts
( id NUMBER
, account_number NUMBER
, customer_id NUMBER
, branch_id NUMBER
, state VARCHAR(2) NOT NULL
, status VARCHAR2(1)
)
PARTITION BY LIST (state)
( PARTITION p_west VALUES ('OR', 'WA') TABLESPACE ts1
, PARTITION p_central VALUES ('SD', 'WI') TABLESPACE ts2
, PARTITION p_east VALUES ('NY', 'VM', 'NJ') TABLESPACE ts3
)
;コンポジット・シャーディングのシャード表
コンポジット・シャーディング方法を使用する分散データベースでは、コンシステント・ハッシュでパーティション化された表のキー値の範囲またはリストに対応するデータのサブセットをパーティション化できます。
コンポジット・シャーディングでは、他のシャーディング方法と同様に、表領域を使用してシャードへのパーティションのマッピングを指定します。シャード表のデータのサブセットをパーティション化するには、次の例に示すように、分散データベース構成にデプロイされたシャード領域ごとに個別の表領域セットを作成する必要があります。
CREATE TABLESPACE SET tbs1 IN SHARDSPACE shspace1;
CREATE TABLESPACE SET tbs2 IN SHARDSPACE shspace2;次の例に示す文では、サービスのクラスに基づいて、シャード表をgoldとsilverという2つのパーティション・セットにパーティション化しています。各パーティション・セットが個別の表領域に格納されます。次に、各パーティション・セットのデータが、顧客IDのコンシステント・ハッシュによってさらにパーティション化されます。
CREATE SHARDED TABLE customers
( cust_id NUMBER NOT NULL
, name VARCHAR2(50)
, address VARCHAR2(250)
, location_id VARCHAR2(20)
, class VARCHAR2(3)
, signup_date DATE
, CONSTRAINT cust_pk PRIMARY KEY(cust_id, class)
)
PARTITIONSET BY LIST (class)
PARTITION BY CONSISTENT HASH (cust_id)
PARTITIONS AUTO
(PARTITIONSET gold VALUES (‘gld’) TABLESPACE SET tbs1,
PARTITIONSET silver VALUES (‘slv’) TABLESPACE SET tbs2)
;ディレクトリベースのシャーディング用のシャード表
CREATE SHARDED TABLE文でPARTITION BY DIRECTORYを使用して、ディレクトリベースのシャード表を作成します。
たとえば:
CREATE SHARDED TABLE customers
( id NUMBER NOT NULL
, name VARCHAR2(30)
, address VARCHAR2(30)
, status VARCHAR2(1)
,
CONSTRAINT cust_pk PRIMARY KEY(id)
)
PARTITION BY DIRECTORY (id)
( PARTITION p1 TABLESPACE tbs1,
PARTITION p2 TABLESPACE tbs2,
PARTITION p3 TABLESPACE tbs3…);
ノート:
-
ユーザー定義シャーディングとは異なり、
CREATE TABLE文のパーティションにキー値は指定されません。 -
ディレクトリ表は、ルート表の作成時に自動的に作成されます。ディレクトリ表の定義は次のとおりです。
<shard_user_schema>.<root_table>$SDIR -
ルート表とは異なるスキーマで
PARENT句を使用して子表を作成する場合は、子表のスキーマ所有者に追加権限が必要です。(これはディレクトリベースのシャーディング専用であり、通常のユーザー定義シャーディングには必要ありません。)これは、ディレクトリ表のシャーディング・キー列に対して子表に外部キー制約が存在し、ディレクトリ・マッピングにシャーディング・キー値が存在せずに子表に行を挿入できないようにするためです。その結果、子表のスキーマには、ディレクトリ表のシャーディング・キー列に対する参照権限が必要です。
回避策については、ディレクトリによってシャードされた表の作成の参照の付与を参照してください。
重複表の作成
単一のシャードによって処理されるデータベース・リクエストの数は、すべてのシャード間で読取り専用または読取りの大部分の表を複製することで最大化できます。
頻繁には更新されず、シャード表とともにアクセスされることが多い比較的小さい表には、重複表を選択することをお薦めします。詳細な概念と図については、表の複製を参照してください。
重複表のタイプ
分散データベースには、次の3つのタイプの重複表を作成できます:
-
表に設定された「リフレッシュ間隔」でリフレッシュされる重複表。(重複表のグローバル・リフレッシュ率の設定および重複表リフレッシュ率のカスタマイズを参照)
-
オンデマンドでリフレッシュされる重複表。これらの表は、明示的にリフレッシュを試みるまではリフレッシュされません。(オンデマンドでの重複表のリフレッシュを参照)
-
コミット時にリフレッシュされる重複表。これらは同期重複表と呼ばれます。(次の例を参照)
最初の2つのタイプの重複表では、任意のシャードに接続し、シャード上の重複表を直接更新できます。その後、更新が他のすべてのシャードに非同期に伝播されます。
同期重複表は、シャード・カタログでシャード「コミット時」に同期される重複表です。重複表でDMLを実行するアクティブなトランザクションがコミットされると、シャード・カタログの重複表の行とシャード・カタログの重複表の行が自動的に同期されます。
詳細は、重複表の更新およびそれらのコンテンツの同期を参照してください。
重複表の作成
重複表Productsは、次の文を使用して作成できます。
CREATE DUPLICATED TABLE Products
( StockNo NUMBER PRIMARY KEY
, Description VARCHAR2(20)
, Price NUMBER(6,2))
;同期重複表の作成
この同じ表を同期重複表として作成するには、次に示すように、文でSYNCHRONOUSキーワードを使用します。
CREATE DUPLICATED TABLE Products
( StockNo NUMBER PRIMARY KEY
, Description VARCHAR2(20)
, Price NUMBER(6,2))
SYNCHRONOUS;DUPLICATED句の詳細は、CREATE TABLEに関する項(『Oracle Database SQL言語リファレンス』)を参照してください。
重複表の更新とその内容の同期
Oracle Globally Distributed Databaseは、マテリアライズド・ビュー・レプリケーションを使用して重複表のコンテンツを同期します。
各シャードの重複表がマテリアライズド・ビューとして表示されます。マテリアライズド・ビューのプライマリ表はシャード・カタログにあります。CREATE DUPLICATED TABLE文によって、プライマリ表、マテリアライズド・ビュー、およびマテリアライズド・ビューのレプリケーションに必要なその他のオブジェクトが自動的に作成されます。
同期重複表
同期重複表は、シャード・カタログからのコミット時に自動的にリフレッシュされます。
シャード・カタログでSYNCHRONOUSを使用して作成された重複表でアクティブなトランザクションがコミットされると、DMLで更新された同期重複表に対してマルチシャードDMLが開始されます。このコミットのパフォーマンスへの影響を最小限に抑えるために、これらの同期DMLはパラレルに実行されます。
ノート:
シャード・カタログでシャード「コミット時」にリフレッシュするには、同期重複表DMLに対してすべてのシャードが稼働している必要があります。非同期重複表
SYNCHRONOUSで作成されていない重複表の場合、任意のシャードに接続し、シャード上の重複表を直接更新できます。その後どうなるかは、自動リフレッシュを設定したかどうかによって異なります。
すべてのシャードのマテリアライズド・ビューは、次のいずれかのオプションを使用してリフレッシュできます。
- 表ごとの構成可能な頻度での自動リフレッシュ
- ストアド・プロシージャの実行によるオンデマンド・リフレッシュ
自動リフレッシュでは、リフレッシュのパフォーマンスを向上させるために、ストアド・プロシージャ・インタフェースを使用してマテリアライズド・ビューのリフレッシュ・グループを作成することもできます。
リフレッシュでは、更新はまずデータベース・リンクを介してシャードからシャード・カタログのプライマリ表に伝播されます。その後、マテリアライズド・ビューのリフレッシュの結果として、更新が他のすべてのシャードに非同期的に伝播されます。
重複表のグローバル・リフレッシュ率の設定
すべての重複表に対してグローバル・リフレッシュ率を設定できます。
デフォルトでは、重複表は60秒ごとにリフレッシュされます。次の例では、データベース・パラメータshrd_dupl_table_refresh_rateを設定して、リフレッシュ間隔を100秒に増やしています。
SQL> show parameter refresh
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
shrd_dupl_table_refresh_rate integer 60
SQL> alter system set shrd_dupl_table_refresh_rate=100 scope=both;
System altered.
SQL> show parameter refresh
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
shrd_dupl_table_refresh_rate integer 100重複表リフレッシュ率のカスタマイズ
個々の重複表に対して、より詳細なリフレッシュ率を設定できます。
表レベルのリフレッシュ率は、最初にCREATE TABLEで設定でき、ALTER TABLEを使用して更新できます。
REFRESH句の構文では、リフレッシュ間隔を秒、分、時間単位で指定することも、必要に応じて表のみをリフレッシュするように設定することもできます。
[REFRESH INTERVAL refresh_rate [SECOND|MINUTE|HOUR] | REFRESH ON DEMAND]たとえば、2分間のカスタマイズされたリフレッシュ率で重複表を作成するには、次のようにします。
CREATE DUPLICATED TABLE Products
( StockNo NUMBER PRIMARY KEY
, Description VARCHAR2(20)
, Price NUMBER(6,2))
REFRESH INTERVAL 2 MINUTE;(オンデマンド・リフレッシュを設定するには、オンデマンドでの重複表のリフレッシュを参照してください。)
1時間のカスタマイズされたリフレッシュ率で重複表を変更するには:
ALTER TABLE table_name MODIFY REFRESH INTERVAL 1 HOUR;DEFAULTを指定すると、データベース・パラメータshrd_dupl_table_refresh_rateで設定された値が使用されます。
ALTER TABLE table_name MODIFY REFRESH INTERVAL DEFAULT;オンデマンドでの重複表のリフレッシュ
リフレッシュ間隔ではなく、オンデマンドで複製した表をリフレッシュするように設定できます。
REFRESH ON DEMAND句を使用して構成した場合、重複表は自動的にはリフレッシュされません。これらの表を手動でリフレッシュする必要があります。
オンデマンド・リフレッシュの設定
オンデマンドでリフレッシュできる重複表を作成するには:
CREATE DUPLICATED TABLE Products
( StockNo NUMBER PRIMARY KEY
, Description VARCHAR2(20)
, Price NUMBER(6,2))
REFRESH ON DEMAND;重複表のリフレッシュ方法をオンデマンド・リフレッシュに更新するには:
ALTER TABLE table_name MODIFY REFRESH ON DEMAND;重複表のオンデマンドでのリフレッシュ
ON DEMAND句で作成された表をリフレッシュするために、シャード・カタログで実行できるユーティリティ・プロシージャが用意されています。
exec sys.refreshDuplicatedTable(table_name);ここで、table_nameはオプションでschema_nameで修飾できるため、schema_name.table_nameになります。
または、DBMS_MVIEW.REFRESHプロシージャを使用して、シャード上の重複表マテリアライズド・ビューを直接リフレッシュすることもできます。
重複表のサポートおよび制限
重複表を使用してスキーマを設計する場合は、次の考慮事項に注意してください。
次の操作は、重複表でサポートされています。
-
ALTER TABLE ADD/DROP CONSTRAINT(一度に1つの制約) -
ALTER TABLE ADD/DROP PRIMARY KEY -
inmemoryおよびparallelオプションを使用した重複表の作成および変更がサポートされています。
次の操作は、重複表ではサポートされていません。
- システム・パーティション表および参照パーティション表
LONGデータ型REFデータ型- 抽象(MDSYSデータ型がサポートされます)
- 主キーを除く列の最大数は999個です
- nologgingオプション
ノート:
シャードで実行されるトランザクションがシャード・カタログで削除された行を更新しようとすると、競合状態になる可能性があります。この場合、エラーが戻され、シャードのトランザクションがロールバックされます。
シャード上の重複表を更新する場合、次のユース・ケースはサポートされません。
- データベース・リンクでサポートされていないLOBまたはデータ型の更新
- 同じトランザクションによって挿入された行の更新または削除