5 シャード・データベース・スキーマの設計
シャーディングの利点を活用するには、1つのシャードで実行されるデータベース・リクエストの数が最大になるように、シャード・データベースのスキーマを設計する必要があります。
シャード・データベース・スキーマの設計に関する考慮事項
データベース・スキーマの設計はシャード・データベースのパフォーマンスとスケーラビリティに大きく影響します。スキーマの設計が不適切な場合、データおよびワークロードがシャード間にバランスよく分散されず、マルチシャード操作の割合が大きくなります。
データ・モデルは、単一のルート表を持つ階層ツリー構造である必要があります。Oracle Shardingは任意のレベル数の階層をサポートします。
シャーディングの利点を活用するには、1つのシャードで実行されるデータベース・リクエストの数が最大になるように、シャード・データベースのスキーマを設計する必要があります。
シャード・データベース・スキーマは、次の特性を持つシャード表ファミリおよび重複表で構成されます。
シャード表ファミリ
- シャーディング・キーによって等価パーティション化された一連の表。
- 関連するデータは、常にまとめて格納および移動されます。
- 結合および整合性制約チェックはシャード内で実行されます。
- シャーディング方法およびキーは、アプリケーションの要件に基づいています。
- シャーディング・キーは、主キーに含まれている必要があります。
重複表
- すべてのシャードにレプリケートされる非シャード表。
- 通常、共通参照データが含まれます。
- 各シャードで読取りおよび更新できます。
シャード・データベース・スキーマの設計の計画
シャード・データーベースにデータを移入した後では、表をシャーディングするのか複製するのか、シャーディング・キーなど、スキーマの属性の多くは変更できません。したがって、シャード・データベースをデプロイする前に次の点を慎重に考慮してください。
-
どの表をシャーディングするか?
-
どの表を複製するか?
-
どのシャード表をルート表にするか?
-
他の表をルート表にリンクするためにどの方法を使用するか?
-
どのシャーディング方法を使用するか?
-
どのシャーディング・キーを使用するか?
-
使用するスーパー・シャーディング・キー(シャーディング方法がコンポジットである場合)
シャーディング・キーの選択
シャード表パーティションはシャーディング・キーに基づいて表領域レベルでシャード間に分散されます。キーの例として顧客ID、アカウント番号、国IDなどがあります。
シャーディング・キーは、次の特性に従う必要があります。
-
シャーディング・キーが非常に安定していて、その値がほとんど変更されることがない必要があります。
-
シャーディング・キーはすべてのシャード表に存在する必要があります。これにより、シャーディング・キーに基づく等価パーティション表のファミリを作成できます。
-
表ファミリ内の表の結合は、シャーディング・キーを使用して実行する必要があります。
システム管理シャード・データベースのシャーディング・キー
システム管理のシャーディング方法の場合、シャーディング・キーはカーディナリティが高い列に基づいている必要があります。この列の一意の値の数は、シャードの数より大幅に多い必要があります。たとえば、顧客IDはシャーディング・キーのよい候補ですが、米国の州名は適していません。
シャーディング・キーには、単一列または複数列を指定できます。複数の列が存在する場合、列のハッシュが連結されてシャーディング・キーが形成されます。
次の例では、Customersというシャード表を作成し、列cust_idおよびnameが表のシャーディング・キーを構成するように指定します。
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, name))
PARTITION BY CONSISTENT HASH (cust_id,name)
PARTITIONS AUTO
TABLESPACE SET ts1;CREATE SHARDED TABLE Orders
( OrderNo NUMBER NOT NULL
, CustNo NUMBER NOT NULL
, Name VARCHAR2(50) NOT NULL
, OrderDate DATE
, CONSTRAINT OrderPK PRIMARY KEY (CustNo, Name, OrderNo)
, CONSTRAINT CustFK FOREIGN KEY (CustNo, Name) REFERENCES Customers(Cust_ID, Name)
)
PARTITION BY REFERENCE (CustFK);コンポジット・シャード・データベースのシャーディング・キー
コンポジット・シャーディングを使用すると、2つのレベルのシャーディング(リストまたは範囲によるシャーディングとコンシステント・ハッシュによるシャーディング)を行うことができます。これは、2つのキー(スーパー・シャーディング・キーおよびシャーディング・キー)を提供するアプリケーションによって実現されます。
コンポジット・シャーディングは、次に示すように、複数列のLISTパーティション・セットをサポートしていません。
CREATE SHARDED TABLE customers (
cust_id NUMBER NOT NULL,
Name VARCHAR2(50) NOT NULL,
class VARCHAR2(3) NOT NULL ,
class2 number not null,
CONSTRAINT cust_pk PRIMARY KEY(cust_id,name,class))
PARTITIONSET BY LIST (class, class2)
PARTITION BY CONSISTENT HASH (cust_id,name)
PARTITIONS AUTO (
PARTITIONSET silver VALUES (('SLV',1),('BRZ',2)) TABLESPACE SET ts1
PARTITIONSET gold VALUES (('GLD',3),('OTH',4)) TABLESPACE SET ts2);
PARTITION BY CONSISTENT HASH (cust_id,name)
*
ERROR at line 8:
ORA-02514: list PARTITIONSET method expects a single partitioning column
次に示すように、複数列のRANGEパーティション・セットがサポートされています。
CREATE SHARDED TABLE customers (
cust_id NUMBER NOT NULL,
Name VARCHAR2(50) NOT NULL,
class number NOT NULL ,
class2 number not null,
CONSTRAINT cust_pk PRIMARY KEY(cust_id,name,class))
PARTITIONSET BY RANGE (class, class2)
PARTITION BY CONSISTENT HASH (cust_id,name)
PARTITIONS AUTO (
PARTITIONSET silver VALUES LESS THAN (10,100) TABLESPACE SET ts1,
PARTITIONSET gold VALUES LESS THAN (20,200) TABLESPACE SET ts2);
Table created.
前述のいずれの場合も、シャーディング・キー(パーティション・セット・キーではありません)は複数列にできます。
ユーザー定義シャード・データベースのシャーディング・キー
ユーザー定義シャーディングのリストによるパーティション化の場合、Oracle Shardingは単一のシャーディング・キー列を想定しています。リスト・パーティション化されたシャード表に複数の列が指定されている場合、エラーがスローされます。
CREATE SHARDED TABLE accounts
( id NUMBER
, account_number NUMBER
, customer_id NUMBER
, branch_id NUMBER
, state VARCHAR(2) NOT NULL
, state2 VARCHAR(2) NOT NULL
, status VARCHAR2(1)
)
PARTITION BY LIST (state,state2)
( PARTITION p_northwest VALUES ('OR', 'WA') TABLESPACE ts1
, PARTITION p_southwest VALUES ('AZ', 'UT', 'NM') TABLESPACE ts2
, PARTITION p_northcentral VALUES ('SD', 'WI') TABLESPACE ts3
, PARTITION p_southcentral VALUES ('OK', 'TX') TABLESPACE ts4
, PARTITION p_northeast VALUES ('NY', 'VM', 'NJ') TABLESPACE ts5
, PARTITION p_southeast VALUES ('FL', 'GA') TABLESPACE ts6
);
ERROR at line 1:
ORA-03813: list partition method expects a single partitioning column in
user-defined shardingレンジ・パーティション化されたシャード表の場合、シャーディング・キー列として複数の列を指定できます。
CREATE SHARDED TABLE accounts
( id NUMBER
, account_number NUMBER
, customer_id NUMBER
, branch_id NUMBER
, state NUMBER NOT NULL
, state2 NUMBER NOT NULL
, status VARCHAR2(1)
)
PARTITION BY RANGE (state, state2)
( PARTITION p_northwest VALUES LESS THAN(10, 100) TABLESPACE ts1
, PARTITION p_southwest VALUES LESS THAN(20,200) TABLESPACE ts2);
Table created.ただし、どちらの場合も、シャーディング・キー(パーティションセット・キーではありません)は複数列にできます。
シャーディング・キー・タイプのサポート
シャーディング・キーでは次のデータ型がサポートされています。
-
NUMBER -
INTEGER -
SMALLINT -
RAW -
(N)VARCHAR -
(N)VARCHAR2 -
(N)CHAR -
DATE -
TIMESTAMP
主キーおよび外部キーの制限事項
シャーディング環境では、主キーの制約および外部キーの制約は次のルールによって制御されます。
-
主キーの場合、シャード表に一意制約および一意索引があり、列リストにシャーディング・キー列が含まれている必要があります。以前のOracleリリースでは、シャーディング・キーはこのような列の接頭辞である必要がありましたが、このルールはより緩和されました。
-
あるシャード表から別のシャード表への外部キーにもシャーディング・キーが含まれている必要があります。外部キーは参照表の主キーまたは一意の列を参照するため、これは自動的に強制されます。
-
シャード表の外部キーは、同じ表ファミリ内にある必要があります。異なる表ファミリには異なるシャーディング・キー列があるため、これは必須です。
-
ローカル表を参照するシャード表の外部キーは許可されていません。
-
重複表を参照するシャード表の外部キーは許可されていません。
-
シャード表を参照する重複表の外部キーは許可されていません。
シャード表の索引
シャード表に作成できるのはローカル索引のみです。シャード表の一意のローカル索引にはシャーディング・キーを含める必要があります。
シャード表のグローバル索引は、オンライン・チャンク移動のパフォーマンスを損なう可能性があるため、許可されません。
次の例では、account表のid列にid1というローカル索引を作成します。
CREATE INDEX id1 ON account (id) LOCAL;次の例では、account表のid列およびstate列に対して、id2というローカル一意索引を作成します。
CREATE UNIQUE INDEX id2 ON account (id, state) LOCAL;シャード・データベースでのDDLの実行
シャード・データベースにスキーマを作成するには、シャード・カタログ・データベースでDDLコマンドを発行する必要があります。シャード・カタログ・データベースは、DDLを検証し、シャードで実行する前にそれらをローカルで実行します。
シャード・カタログ・データベースには、シャード・データベースに存在するすべてのオブジェクトのローカル・コピーが含まれており、シャード・データベースのスキーマのマスター・コピーとして機能します。シャード・カタログの検証およびDDLの実行が成功した場合、そのDDLはすべてのシャードに自動的に伝播され、シャード・カタログで発行された順序で適用されます。
DDLの伝播中にシャードが停止しているか、アクセスできない場合、シャード・カタログはそのシャードに適用できなかったDDLを追跡し、そのシャードがアクセス可能になったときにそれらを適用します。
新しいシャードがシャード・データベースに追加された場合、クライアントがアクセスできるようになる前に、シャード・データベースで実行されたすべてのDDLがそのシャードに同じ順序で適用されます。
シャード・データベースでDDLを発行するには、次の2つの方法があります。
-
GDSCTL SQLコマンドを使用します。次の例に示すように、
GDSCTL SQLコマンドを使用してDDLを発行すると、GDSCTLはすべてのシャードがDDLの実行を終了するまで待機し、実行のステータスを返します。GDSCTL> sql “create tablespace set tbsset” -
GDS$CATALOG.sdbnameサービスを使用し、SQL*Plusを使用してシャード・カタログ・データベースに接続します。シャード・カタログ・データベースに対してDDLを発行すると、ローカルでの実行が完了したときにステータスが返されますが、すべてのシャードへのDDLの伝播はバックグラウンドで非同期に行われます。
SQL> create tablespace set tbsset;
ノート:
SYSアカウントを使用したシャードDDLの実行はお薦めしません。その目的のための特権アカウントを作成します。Oracle ShardingのDDL構文拡張の詳細は、Oracle ShardingのDDL構文拡張を参照してください。
ローカルまたはグローバルでのオブジェクトの作成
GDSCTLを使用して作成されたオブジェクトは、グローバルでシャード・データベース・オブジェクトを作成しますが、SQL*Plusを使用してシャード・カタログに接続することで、ローカルまたはグローバル・オブジェクトを作成できます。
オブジェクトを作成するDDLがGDSCTLのsqlコマンドを使用して発行された場合、オブジェクトがすべてのシャードで作成されます。オブジェクトのマスター・コピーが、シャード・カタログ・データベースにも作成されます。すべてのシャードおよびシャード・カタログ・データベースに存在するオブジェクトは、シャード・データベース・オブジェクトと呼ばれます。
SQL*Plusを使用してシャード・カタログに接続する場合、2つのタイプのオブジェクト(シャード・データベース・オブジェクトおよびローカル・オブジェクト)を作成できます。ローカル・オブジェクトは、シャード・カタログにのみ存在する従来のオブジェクトです。ローカル・オブジェクトは、管理のために使用したり、シャード・カタログ・データベースから発行されるマルチシャード問合せで(たとえば、レポートを生成および格納するために)使用したりできます。
シャード・オブジェクトは、ローカル・オブジェクトに対する依存性を持つことができません。たとえば、ローカル表に全シャード表示は作成できません。
SQL*Plusセッションで作成されるオブジェクトのタイプ(シャード・データベースまたはローカル)は、セッションでSHARD DDLモードが有効にされているかどうかによって異なります。全シャード・ユーザー(すべてのシャードおよびシャード・カタログ・データベースに存在するユーザー)の場合、このモードは、シャード・カタログ・データベースではデフォルトで有効になっています。セッションでSHARD DDLが有効になっている間に作成されるすべてのオブジェクトは、シャード・データベース・オブジェクトです。
セッションでSHARD DDLを有効にするには、全シャード・ユーザーが次を実行する必要があります。
ALTER SESSION ENABLE SHARD DDLSHARD DDLが無効であるときに作成されたすべてのオブジェクトは、ローカル・オブジェクトです。ローカル・オブジェクトを作成するには、最初に全シャード・ユーザーを実行する必要があります
ALTER SESSION DISABLE SHARD DDLSHARD DDLセッション・パラメータの詳細は、ALTER SESSIONを参照してください。
Oracle ShardingのDDL構文の機能拡張
Oracle Shardingには、シャード・データベースに対してのみ実行できる構文を持つSQL DDL文が含まれています。
Oracle Shardingをサポートするために問合せおよびDML文を変更する必要はなく、DDL文の変更も非常に限られています。ほとんどの既存のDDL文は、非シャード・データベースと同じ構文およびセマンティクスを使用して、シャード・データベースで同様に機能します。
CREATE TABLESPACE SET
この文は、1つ以上のシャード表および索引の論理ストレージ・ユニットとして使用できる表領域セットを作成します。表領域セットは、シャード領域のシャード間に分散された複数のOracle表領域で構成されます。
CREATE TABLESPACE SET文はOracle Sharding専用です。構文はCREATE TABLESPACEと似ています。
CREATE TABLESPACE SET tablespace_set
[IN SHARDSPACE shardspace]
[USING TEMPLATE (
{ MINIMUM EXTENT size_clause
| BLOCKSIZE integer [ K ]
| logging_clause
| FORCE LOGGING
| ENCRYPTION tablespace_encryption_spec
| DEFAULT [ table_compression ] storage_clause
| { ONLINE | OFFLINE }
| extent_management_clause
| segment_management_clause
| flashback_mode_clause
}...
)];システム管理のシャーディングでは、シャード・データベースにデフォルトの1つのシャード領域のみがあります。表領域セット内の表領域の数は自動的に決定され、対応するシャード領域内のチャンクの数と同じです。
表領域セット内のすべての表領域はビッグファイル表領域であり、プロパティが同じです。プロパティはUSING TEMPLATE句で指定され、表領域セット内の単一の表領域のプロパティを記述します。この句は、通常の表領域のpermanent_tablespace_clauseと同じですが、datafile_tempfile_spec句にデータファイル名を指定できないことが異なります。表領域セット内の各表領域のデータファイル名は自動的に生成されます。
表領域セットは永続表領域のみで構成され、システム、UNDOまたは一時表領域セットはありません。また、次の例では、表領域セットのデータファイルの合計サイズは100mx Nです(Nは表領域セット内の表領域の数です)。
例
CREATE TABLESPACE SET TSP_SET_1 IN SHARDSPACE sgr1
USING TEMPLATE
( DATAFILE SIZE 100m
EXTEND MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
);ALTER TABLESPACE SET
この文は、1つ以上のシャード表および索引の論理ストレージ・ユニットとして使用できる表領域セットを変更します。
表領域セットのSHARDSPACEプロパティは変更できません。表領域セットの他のすべての属性は、通常の永続表領域と同様に変更できます。表領域セット内の表領域はビッグファイルであるため、ADD DATAFILE句およびDROP DATAFILE句はサポートされません。
DROP TABLESPACE SETおよびPURGE TABLESPACE SET
これらの文は、1つ以上のシャード表および索引の論理ストレージ・ユニットとして使用できる表領域セットを削除またはパージします。
これらの文の構文およびセマンティクスは、DROP文およびPURGE TABLESPACE文と似ています。
CREATE TABLE
CREATE TABLE文は、シャード表および複製表を作成するために拡張され、表ファミリを指定します。
構文
CREATE [ { GLOBAL TEMPORARY | SHARDED | DUPLICATED} ]
TABLE [ schema. ] table
{ relational_table | object_table | XMLType_table }
[ PARENT [ schema. ] table ] ;CREATE TABLE文の次の部分は、Oracle Shardingをサポートするためのものです。
-
SHARDEDキーワードおよびDUPLICATEDキーワードは、表のコンテンツがシャード間でパーティション化されるか、すべてのシャードで複製されることをそれぞれ示します。DUPLICATEDキーワードは、重複表を作成するための唯一の構文の変更です。以降で説明する他のすべての変更はシャード表にのみ適用されます。 -
PARENT句は、シャード表を表ファミリのルート表にリンクします。 -
システムおよび複合シャーディングでは、シャード表を作成するために、
TABLESPACEのかわりにTABLESPACE SETが使用されます。TABLESPACEが含まれるすべての句は、TABLESPACE SETが含まれるように拡張されました。 -
3つの句:
table_partitioning_clauses内のconsistent_hash_partitions、consistent_hash_with_subpartitionsおよびpartition_set_clause。table_partitioning_clauses ::= {range_partitions | hash_partitions | list_partitions | composite_range_partitions | composite_hash_partitions | composite_list_partitions | reference_partitioning | system_partitioning | consistent_hash_partitions | consistent_hash_with_subpartitions | partition_set_clause }
例
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 ts2,
PARTITIONSET silver VALUES (‘slv’) TABLESPACE SET ts1)
;consistent_hash_with_subpartitionsの例
CREATE SHARDED TABLE Customers
( "custi_id" NUMBER NOT NULL
, name VARCHAR2(50)
, class VARCHAR2(3) NOT NULL
, signup_date DATE
,
CONSTRAINT cust_pk PRIMARY KEY("custi_id",name,signup_date,class)
)
PARTITIONSET BY LIST (class)
PARTITION BY CONSISTENT HASH ("custi_id",name)
SUBPARTITION BY RANGE (signup_date)
SUBPARTITION TEMPLATE
( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY'))
, SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY'))
, SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY'))
, SUBPARTITION future VALUES LESS THAN (MAXVALUE))
PARTITIONS AUTO
(
PARTITIONSET "gold" VALUES ('Gld','BRZ') TABLESPACE SET ts1 SUBPARTITIONS STORE IN(TBS1,TBS2,TBS3,TBS4)
, PARTITIONSET "silver" VALUES ('Slv','OTH') TABLESPACE SET ts2 SUBPARTITIONS STORE IN(TBS5,TBS6,TBS7,TBS8)
) ;制限事項
現在のリリースでのシャード表に関する制限:
-
シャード表のデフォルトの表領域セットはありません。
-
一時表はシャーディングまたは複製できません。
-
索引構成シャード表はサポートされません。
-
シャード表には、ネストした表の列またはアイデンティティ列を含めることはできません。
-
シャード表に定義される主キー制約には、シャーディング列を含める必要があります。重複表の列を参照するシャード表の列の外部キー制約はサポートされていません。
-
システム・パーティション化および間隔レンジ・パーティション化は、シャード表ではサポートされません。個別のハッシュ・パーティションの指定は、コンシステント・ハッシュによるパーティション化ではサポートされません。
-
PARTITION BY句またはPARTITIONSET BY句に使用されるシャード表の列には、仮想列を指定できません。
現在のリリースの重複表では、次のことはサポートされません。
-
システム・パーティション表および参照パーティション表
-
LONG、抽象(MDSYSデータ型はサポートされています)、REFデータ型
-
主キーを除く列の最大数は999個です
-
nologgingおよびinmemoryオプション -
重複表のXMLType列は非ASSM表領域で使用できません
Oracle Shardingをサポートする句の使用方法の詳細は、CREATE TABLEを参照してください。
ALTER TABLE
ALTER TABLE文は、シャード表および重複表を変更するために拡張されています。
シャード・データベースに対してALTER TABLEを使用する場合は、制限事項があります。
次のオプションは、システム管理またはコンポジット・シャード・データベースのシャード表ではサポートされません。
-
名前変更
-
外部キー制約の追加
-
個々のパーティションおよびサブパーティションに対するすべての操作
-
シャードに対するすべてのパーティション関連の操作(
TRUNCATEPARTITION、UNUSABLE LOCAL INDEXESおよびREBUILD UNUSABLE LOCAL INDEXESを除く)
次の操作は、重複表ではサポートされていません。
-
データ型: LONG、抽象(
MDSYSデータ型はサポートされています)、REF -
列のオプション: ベクトル・エンコード、不可視の列、ネストした表
-
オブジェクト型
-
クラスタ化表
-
外部表
-
ILMポリシー
-
PARENT句 -
表のフラッシュバック操作
-
システムおよび参照パーティション化
-
NOLOGGINGオプションの有効化 -
重複表のマテリアライズド・ビュー・ログの削除
-
シャード上の重複表のマテリアライズド・ビューの削除
-
シャード上の(重複表の)マテリアライズド・ビューの変更
ALTER SESSION
ALTER SESSION文は、シャード・データベースをサポートするように拡張されています。
セッションレベルのSHARD DDLパラメータは、シャード・カタログ・データベースに対して発行されたDDLのスコープを設定します。
ALTER SESSION { ENABLE | DISABLE } SHARD DDL;SHARD DDLを有効にした場合、セッションで発行されたすべてのDDLはシャード・カタログおよびすべてのシャードで実行されます。SHARD DDLを無効にした場合、DDLはシャード・カタログ・データベースに対してのみ実行されます。シャード・データベース・ユーザー(すべてのシャードおよびカタログに存在するユーザー)の場合、SHARD DDLはデフォルトで有効にされます。シャード・データベース・ユーザーを作成するには、CREATE USERを実行する前に、SHARD DDLパラメータを有効にする必要があります。
シャード・データベースでのPL/SQLプロシージャの実行
構成内のすべてのシャードでDDL文を実行するのと同じ方法で、特定のOracle提供のPL/SQLプロシージャも実行できます。これらの特定のプロシージャ・コールは、シャードDDL文であるかのように動作します。この場合、それらはすべてのシャードに伝播され、カタログによって追跡され、新しいシャードが構成に追加されるたびに実行されます。
次のプロシージャはすべて、シャードDDL文であるかのように動作します。
- DBMS_FGAパッケージのプロシージャ
- DBMS_RLSパッケージのプロシージャ
- DBMS_STATSパッケージの次のプロシージャ:
- GATHER_INDEX_STATS
- GATHER_TABLE_STATS
- GATHER_SCHEMA_STATS
- GATHER_DATABASE_STATS
- GATHER_SYSTEM_STATS
- DBMS_GOLDENGATE_ADMパッケージの次のプロシージャ:
- ADD_AUTO_CDR
- ADD_AUTO_CDR_COLUMN_GROUP
- ADD_AUTO_CDR_DELTA_RES
- ALTER_AUTO_CDR
- ALTER_AUTO_CDR_COLUMN_GROUP
- PURGE_TOMBSTONES
- REMOVE_AUTO_CDR
- REMOVE_AUTO_CDR_COLUMN_GROUP
- REMOVE_AUTO_CDR_DELTA_RES
シャードDDL文と同じ方法でいずれかのプロシージャを実行するには、次のステップを実行します。
- gsm_pooladmin_roleを持つデータベース・ユーザーとしてSQL*Plusを使用して、シャード・カタログ・データベースに接続します。
alter session enable shard ddlを使用してシャードDDLを有効にします。SYS.EXEC_SHARD_PLSQLという名前のシャーディング固有のPL/SQLプロシージャを使用して、ターゲット・プロシージャを実行します。このプロシージャは、単一のCLOB引数を取ります。これは、完全修飾プロシージャ名とその引数を指定する文字列です。
EXEC_SHARD_PLSQLを使用せずにターゲット・プロシージャを実行すると、そのプロシージャはカタログでのみ実行され、すべてのシャードに伝播されません。完全修飾名(たとえば、SYS.DBMS_RLS.ADD_POLICY)を指定せずにプロシージャを実行すると、エラーが発生します。
たとえば、すべてのシャードでDBMS_RLS.ADD_POLICYを実行するには、シャードDLLを有効にした後にSQL*Plusから次を実行します。
exec sys.exec_shard_plsql('sys.dbms_rls.add_policy(object_schema =>
''testuser1'',
object_name => ''DEPARTMENTS'',
policy_name => ''dept_vpd_pol'',
function_schema => ''testuser1'',
policy_function => ''authorized_emps'',
statement_types => ''INSERT, UPDATE, DELETE, SELECT, INDEX'',
update_check => TRUE)'
) ;コール仕様自体はexec_shard_plsqlへの文字列パラメータであるため、ターゲット・プロシージャ・コール仕様内に2つの一重引用符が必要なことに注意してください。
ターゲット・プロシージャがシャード・カタログ・データベースで正しく実行されると、現在デプロイされているすべてのシャードでの処理用にキューに入れられます。カタログでのターゲット・プロシージャ実行のエラーは、SQL*Plusセッションに戻されます。シャードでの実行時のエラーは、DDLの場合と同じ方法で追跡できます。
シャード・データベースのスキーマ・オブジェクトの作成
次のトピックでは、シャード・データベースにスキーマ・オブジェクトを作成する方法を示します。これらのオブジェクトの概念については、第2章のシャード・データベースのスキーマ・オブジェクトに関する項を参照してください。
全シャード・ユーザーの作成
シャード・カタログ・データベースにのみ存在するローカル・ユーザーには、シャード・データベースにスキーマ・オブジェクトを作成するための権限がありません。シャード・データベース・スキーマを作成する最初のステップは、全シャード・ユーザーを作成することです。
権限のあるユーザーとしてシャード・カタログ・データベースに接続して、SHARD DDLを有効にし、CREATE USERコマンドを実行して全シャード・ユーザーを作成します。全シャード・ユーザーがシャード・カタログ・データベースに接続すると、SHARD DDLモードがデフォルトで有効になります。
ノート:
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 Shardingに固有ではない既存のパーティション化のルールです。)
同一レベル・パーティション化を使用した表間の親子関係の指定
場合によっては、参照パーティション化に必要な主キー制約と外部キー制約を作成することが不可能か望ましくないことがあります。このような場合、表ファミリで親子関係を指定するには、すべての表が明示的に同一レベル・パーティション化されている必要があります。各子表は、親の名前を含む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およびパーティショニング・ガイドを参照
シャード表の作成
シャード表は、複数のデータベース間でより小さい管理しやすい断片にパーティション化された表であり、シャードと呼ばれます。
表領域セットのサイズ設定
システム管理およびコンポジットのシャーディング方法では、シャード・カタログに表領域セットを作成するときに、シャード・カタログおよび各シャードに作成されたすべての表領域に対して十分な領域があることを確認する必要があります。これは、従量制の使用環境では特に重要です。
たとえば、構成にシャード・カタログと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個のチャンクを想定すると、このコマンドは、シャード・カタログおよび各シャードにそれぞれ初期表領域100Mの360個の表領域を作成します。これは大量の記憶域のようには聞こえませんが、データベース管理者が最初に100Gを割り当てるときにはシャード当たり3.6TBとは想定していません。その量の記憶域が計画されていない場合、DDLの失敗につながる可能性があり、リカバリにかなりの労力が必要になります。
システム管理のシャード・データベースでのシャード表の作成
システム管理のシャード・データベースでは、データはコンシステント・ハッシュによるパーティション化を使用してシャード間で自動的に分散されます。
シャード表を作成する前に、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 west;
CREATE TABLESPACE tbs3 IN SHARDSPACE central;
CREATE TABLESPACE tbs4 IN SHARDSPACE central;
CREATE TABLESPACE tbs5 IN SHARDSPACE east;
CREATE TABLESPACE tbs6 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_northwest VALUES ('OR', 'WA') TABLESPACE ts1
, PARTITION p_southwest VALUES ('AZ', 'UT', 'NM') TABLESPACE ts2
, PARTITION p_northcentral VALUES ('SD', 'WI') TABLESPACE ts3
, PARTITION p_southcentral VALUES ('OK', 'TX') TABLESPACE ts4
, PARTITION p_northeast VALUES ('NY', 'VM', 'NJ') TABLESPACE ts5
, PARTITION p_southeast VALUES ('FL', 'GA') TABLESPACE ts6
)
;コンポジット・シャード・データベースでのシャード表の作成
コンポジット・シャーディング方法を使用するシャード・データベースでは、コンシステント・ハッシュでパーティション化された表のキー値の範囲またはリストに対応するデータのサブセットをパーティション化できます。
コンポジット・シャーディングでは、他のシャーディング方法と同様に、表領域を使用してシャードへのパーティションのマッピングを指定します。シャード表のデータのサブセットをパーティション化するには、次の例に示すように、シャード・データベース構成にデプロイされたシャード領域ごとに個別の表領域セットを作成する必要があります。
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)
;重複表の作成
単一のシャードによって処理されるデータベース・リクエストの数は、すべてのシャード間で読取り専用または読取りの大部分の表を複製することで最大化できます。この方法は、頻繁には更新されず、シャード表とともにアクセスされることが多い比較的小さい表に適しています。
重複表にはいくつかの制限事項があります。次の操作は、重複表ではサポートされていません。
-
NOLOGGING -
ALTER TABLE ADD/DROP CONSTRAINT: 主キーのみ ALTER TABLE ADD/DROP PRIMARY KEY-
ALTER TABLE RENAME COLUMN -
PARTITION BY REFERENCE -
PARTITION BY SYSTEM -
CLUSTERED TABLE - 非最終
UDTまたはNESTED TABLE -
LONG DATATYPE -
COLUMN VECTOR ENCODE -
INVISIBLE COLUMN - 列の暗号化
- 情報ライフサイクル管理(ILM)ポリシー
- CTASパラレル
- 通常、重複表とシャード表の間の外部キー制約は許可されませんが、ユーザー定義のシャーディングでは、シャード表と重複表の間に
DISABLE NOVALIDATE外部キー制約を作成できます。
重複表Productsは次の文を使用して作成できます。
CREATE DUPLICATED TABLE Products
( StockNo NUMBER PRIMARY KEY
, Description VARCHAR2(20)
, Price NUMBER(6,2))
;重複表の更新とその内容の同期
Oracle Shardingは、マテリアライズド・ビュー・レプリケーションを使用して重複表の内容を同期します。
各シャードの重複表がマテリアライズド・ビューとして表示されます。マテリアライズド・ビューのマスター表はシャード・カタログにあります。CREATE DUPLICATED TABLE文によって、マスター表、マテリアライズド・ビュー、およびマテリアライズド・ビューのレプリケーションに必要なその他のオブジェクトが自動的に作成されます。
任意のシャードに接続し、シャード上の重複表を直接更新できます。更新は、まずデータベース・リンクを介してシャードからシャード・カタログのマスター表に伝播されます。その後、マテリアライズド・ビューのリフレッシュの結果として、更新が他のすべてのシャードに非同期的に伝播されます。
すべてのシャードのマテリアライズド・ビューは、次のいずれかのオプションを使用してリフレッシュできます。
- 表ごとの構成可能な頻度での自動リフレッシュ
- ストアド・プロシージャの実行によるオンデマンド・リフレッシュ
自動リフレッシュでは、リフレッシュのパフォーマンスを向上させるために、ストアド・プロシージャ・インタフェースを使用してマテリアライズド・ビューのリフレッシュ・グループを作成することもできます。
ノート:
シャードで実行されるトランザクションがシャード・カタログで削除された行を更新しようとすると、競合状態になる可能性があります。この場合、エラーが戻され、シャードのトランザクションがロールバックされます。
シャード上の重複表を更新する場合、次のユース・ケースはサポートされません。
- データベース・リンクでサポートされていないLOBまたはデータ型の更新
- 同じトランザクションによって挿入された行の更新または削除
スキーマの作成例
次の例は、システム管理、ユーザー定義方法およびコンポジット・シャーディング方法を使用してシャード・データベースのスキーマを作成するステップを示しています。
システム管理シャード・データベース・スキーマの作成
システム管理シャーディング方法を使用するシャード・データベースの表領域セット、シャード表および重複表を作成します。
次に、DDL実行を監視し、表領域セット、表およびチャンクがすべてのシャードで正しく作成されたことを確認する必要があります。
DDL実行の監視およびオブジェクト作成の検証
GDSCTLおよびSQLを使用してDDL実行を監視し、DDLがすべてのシャードに伝播されていることを確認できます。
DDL実行のモニター
シャードへのDDLの伝播のステータスを確認するには、GDSCTLのshow ddlコマンドおよびconfig shardコマンドを使用できます。
シャード・カタログでSQL*Plusを使用してDDLを実行した場合、SQL*Plusではすべてのシャードの実行ステータスが返されないため、この確認は必須です。
show ddlコマンドの出力は切り捨てられることがあります。出力内容の完全なテキストを表示するには、シャード・カタログでSELECT ddl_text FROM gsmadmin_internal.ddl_requestsを実行します。
シャード・ディレクタ・ホストから次のコマンドを実行します。
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------
5 grant connect, resource to app_schema
6 grant dba to app_schema
7 grant execute on dbms_crypto to app_s...
8 CREATE TABLESPACE SET TSP_SET_1 usin...
9 CREATE TABLESPACE products_tsp datafi...
10 CREATE SHARDED TABLE Customers ( Cu...
11 CREATE SHARDED TABLE Orders ( Order...
12 CREATE SEQUENCE Orders_Seq;
13 CREATE SHARDED TABLE LineItems ( Or...
14 CREATE MATERIALIZED VIEW "APP_SCHEMA"...
ここに示すように、構成内の各シャードでconfig shardコマンドを実行し、コマンド出力の「Last Failed DDL」行を書き留めます。
GDSCTL> config shard -shard sh1
Name: sh1
Shard Group: primary_shardgroup
Status: Ok
State: Deployed
Region: region1
Connection string: shard_host_1:1521/sh1_host:dedicated
SCAN address:
ONS remote port: 0
Disk Threshold, ms: 20
CPU Threshold, %: 75
Version: 18.0.0.0
Last Failed DDL:
DDL Error: ---
Failed DDL id:
Availability: ONLINE
Supported services
------------------------
Name Preferred Status
---- --------- ------
oltp_ro_srvc Yes Enabled
oltp_rw_srvc Yes Enabled 表領域セット作成の検証
シャード表ファミリのために作成した表領域セットの表領域、および重複表のために作成した表領域が、すべてのシャードに作成されたことを確認します。
C006TSP_SET_1を介してC001TSP_SET_1として次に示す表領域セットの表領域の数は、シャード・データベース構成がデプロイされたときにGDSCTL create shardcatalogコマンドで指定されたチャンクの数に基づきます。
重複Products表領域をPRODUCTS_TSPとして次に示します。
次に示すように、構成内のすべてのシャードでSELECT TABLESPACE_NAMEを実行します。
$ sqlplus / as sysdba
SQL> select TABLESPACE_NAME, BYTES/1024/1024 MB from sys.dba_data_files
order by tablespace_name;
TABLESPACE_NAME MB
----------------------- ----------
C001TSP_SET_1 100
C002TSP_SET_1 100
C003TSP_SET_1 100
C004TSP_SET_1 100
C005TSP_SET_1 100
C006TSP_SET_1 100
PRODUCTS_TSP 100
SYSAUX 650
SYSTEM 890
SYS_SHARD_TS 100
TSP_SET_1 100
TABLESPACE_NAME MB
------------------------ ----------
UNDOTBS1 105
USERS 5
13 rows selected.
チャンクの作成および分散の検証
チャンクおよびチャンク表領域がすべてのシャードに作成されたことを確認します。
ここに示すようにGDSCTL config chunksコマンドを実行し、各シャードのチャンクIDの範囲をノートにとります。
GDSCTL> config chunks
Chunks
------------------------
Database From To
-------- ---- --
sh1 1 6
sh2 1 6
sh3 7 12
sh4 7 12次に示すように、構成内の各シャードで次のSQL文を実行します。
SQL> show parameter db_unique_name
NAME TYPE VALUE
---------------- ----------- ------------------------------
db_unique_name string sh1
SQL> select table_name, partition_name, tablespace_name
from dba_tab_partitions
where tablespace_name like 'C%TSP_SET_1'
order by tablespace_name;
TABLE_NAME PARTITION_NAME TABLESPACE_NAME
---------------- ---------------- --------------------
ORDERS CUSTOMERS_P1 C001TSP_SET_1
CUSTOMERS CUSTOMERS_P1 C001TSP_SET_1
LINEITEMS CUSTOMERS_P1 C001TSP_SET_1
CUSTOMERS CUSTOMERS_P2 C002TSP_SET_1
LINEITEMS CUSTOMERS_P2 C002TSP_SET_1
ORDERS CUSTOMERS_P2 C002TSP_SET_1
CUSTOMERS CUSTOMERS_P3 C003TSP_SET_1
ORDERS CUSTOMERS_P3 C003TSP_SET_1
LINEITEMS CUSTOMERS_P3 C003TSP_SET_1
ORDERS CUSTOMERS_P4 C004TSP_SET_1
CUSTOMERS CUSTOMERS_P4 C004TSP_SET_1
TABLE_NAME PARTITION_NAME TABLESPACE_NAME
---------------- ---------------- --------------------
LINEITEMS CUSTOMERS_P4 C004TSP_SET_1
CUSTOMERS CUSTOMERS_P5 C005TSP_SET_1
LINEITEMS CUSTOMERS_P5 C005TSP_SET_1
ORDERS CUSTOMERS_P5 C005TSP_SET_1
CUSTOMERS CUSTOMERS_P6 C006TSP_SET_1
LINEITEMS CUSTOMERS_P6 C006TSP_SET_1
ORDERS CUSTOMERS_P6 C006TSP_SET_1
18 rows selected.シャード・カタログ・データベースに接続し、次に示すようにチャンクが均一に分散されていることを確認します。
$ sqlplus / as sysdba
SQL> SELECT a.name Shard, COUNT(b.chunk_number) Number_of_Chunks
FROM gsmadmin_internal.database a, gsmadmin_internal.chunk_loc b
WHERE a.database_num=b.database_num
GROUP BY a.name
ORDER BY a.name;
SHARD NUMBER_OF_CHUNKS
------------------------------ ----------------
sh1 6
sh2 6
sh3 6
sh4 6表の作成の検証
シャード表および重複表が作成されたことを確認するには、シャード・カタログ・データベースおよび各シャードにアプリケーション・スキーマ・ユーザーとしてログインし、次のapp_schemaユーザーの例に示すように、データベース・シャードの表を問い合せます。
$ sqlplus app_schema/app_schema_password
Connected.
SQL> select table_name from user_tables;
TABLE_NAME
-----------------------------------------------------------------------
CUSTOMERS
ORDERS
LINEITEMS
PRODUCTS
4 rows selected.DDL実行の失敗およびリカバリの例
次の例は、DDLを発行して実行ステータスを監視するステップ、およびエラーが発生した場合の対処方法を示しています。
シャードでDDLが失敗した場合、その失敗が解決されてGDSCTLのrecover shardコマンドが実行されるまで、そのシャードに対するその後のすべてのDDLはブロックされます。
これらのGDSCTLコマンドを実行するには、GSM_ADMIN権限が必要です。
次の例では、SQL*Plusを使用してDDLが発行されたが、GDSCTL SQLコマンドを使用した場合に同じステータス・チェックおよび修正処理が適用される場合を示します。
例5-1 シャード・カタログでのDDL実行エラー
この例では、ユーザーがCREATE USERコマンドで入力ミスをしています。
SQL> alter session enable shard ddl;
Session altered.
SQL> CREATE USER example_user IDENTRIFIED BY out_standing1;
CREATE USER example_user IDENTRIFIED BY out_Standing1
*
ERROR at line 1:
ORA-00922: missing or invalid optionシャード・カタログでDDLの実行が失敗し、すべてのシャードでDDLが実行されなかったことがGDSCTLのshow ddlコマンドに予想どおり表示されます。
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------その後、ユーザーが正しいスペリングでコマンドを実行し直します。同じセッションを使用しているため、alter session enable shard ddlを再度実行する必要はありません。
SQL> CREATE USER example_user IDENTIFIED BY out_Standing1;
User created.今度は、DDLがシャード・カタログ・データベースで正常に実行され、オンラインのシャードで失敗していないことがshow ddlに示されます。
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------
1 create user example_user identified by *****ノート:
DDLの実行時に停止していたシャードの場合、DDLはそのシャードがアクセス可能になったときに自動的に適用されます。
例5-2 シャードで修正のための対処を実行することによって、シャードでのエラーをリカバリする
この例では、ユーザーはシステム管理のシャード表のための表領域セットを作成しようとします。ただし、1つのシャードのデータファイル・ディレクトリが書込み可能ではないため、DDLはカタログでは正常に実行されますが、そのシャードでは失敗します。
SQL> connect example_user/out_Standing1
Connected
SQL> create tablespace set tbsset;
Tablespace created.ユーザーexample_userはSDBユーザーとして作成され、SHARD DDLがデフォルトで有効にされるため、alter session enable shard ddlを実行する必要はありません。
GDSCTLのshow ddlを使用してステータスを確認します。
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------
1 create user example_user identified by *****
2 create tablespace set tbsset shard01 このコマンド出力は、シャードshard01でDDLが失敗したことを示しています。GDSCTLのconfig shardコマンドを実行して、詳細情報を取得します。
GDSCTL> config shard -shard shard01
Conversion = ':'Name: shard01
Shard Group: dbs1
Status: Ok
State: Deployed
Region: east
Connection string: (DESCRIPTION=(ADDRESS=(HOST=shard01-host)(PORT=1521)(PROTOCOL=tcp))
(CONNECT_DATA=(SID=shard01)))
SCAN address:
ONS remote port: 0
Disk Threshold, ms: 20
CPU Threshold, %: 75
Version: 18.0.0.0
Failed DDL: create tablespace set tbsset
DDL Error: ORA-02585: create tablepsace set failure, one of its tablespaces not created
ORA-01119: error in creating database file \'/ade/b/3667445372/oracle/rdbms/dbs/
SHARD01/datafile/o1_mf_tbsset_%u_.dbf\'
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 13: Permission denied
Additional information: 1 \(ngsmoci_execute\)
Failed DDL id: 2
Availability: ONLINE「Failed DDL:」で始まるテキストは問題を示しています。それを解決するには、ユーザーはシャード・データベースのホストにログインして、そのディレクトリを書込み可能にする必要があります。
ディレクトリの権限を表示します。
cd $ORACLE_HOME/rdbms/dbs
ls –l ../ | grep dbs
dr-xr-xr-x 4 oracle dba 102400 Jul 20 15:41 dbs/
ディレクトリを書込み可能に変更します。
chmod +w .
ls –l ../ | grep dbs
drwxrwxr-x 4 oracle dba 102400 Jul 20 15:41 dbs/GDSCTL コンソールに戻って、recover shardコマンドを発行します。
GDSCTL> recover shard -shard shard01ステータスを再度確認します。
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------
1 create user example_user identified by *****
2 create tablespace set tbsset
GDSCTL> config shard -shard shard01
Conversion = ':'Name: shard01
Shard Group: dbs1
Status: Ok
State: Deployed
Region: east
Connection string: (DESCRIPTION=(ADDRESS=(HOST=shard01-host)(PORT=1521)(PROTOCOL=tcp))
(CONNECT_DATA=(SID=shard01)))
SCAN address:
ONS remote port: 0
Disk Threshold, ms: 20
CPU Threshold, %: 75
Version: 18.0.0.0
Last Failed DDL:
DDL Error: ---
DDL id:
Availability: ONLINEこの出力に示されているように、失敗したDDLエラーが表示されなくなりました。
例5-3 他のすべてのシャードで修正のための対処を実行することによって、シャードでのエラーをリカバリする
この例では、ユーザーは別の表領域セットtbs_setを作成しようとしますが、同じ名前の既存のローカル表領域がすでに存在するため、シャードでDDLが失敗します。
シャード・カタログで次のコマンドを実行します。
SQL> create tablespace set tbs_set;
Tablespace created.GDSCTLのshow ddlコマンドを使用してステータスを確認します。
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------
1 create user example_user identified by *****
2 create tablespace set tbsset
3 create tablespace set tbs_set shard01
GDSCTL> config shard -shard shard01
Conversion = ':'Name: shard01
……
Failed DDL: create tablespace set tbs_set
DDL Error: ORA-02585: create tablespace set failure, one of its tablespaces not created
ORA-01543: tablespace \'TBS_SET\' already exists \(ngsmoci_execute\)この問題を解決するには、ローカル・データベース管理者としてshard01にログインし、表領域TBS_SETを削除して、GDSCTLのrecover shard -shard shard01を実行します。ただし、この表領域を維持して、かわりに名前が競合している新しく作成した表領域セットを削除し、別の名前(tbsset2など)を持つ別の表領域セットを作成するとします。次の例では、シャード・カタログで実行する方法を示します。
SQL> drop tablespace set tbs_set;
SQL> create tablespace set tbs_set2;GDSCTLを使用してステータスを確認します。
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------
1 create user example_user identified by *****
2 create tablespace set tbsset
3 create tablespace set tbs_set shard01
4 drop tablespace set tbs_set
5 create tablespace set tbsset2 DDL 3がshard01で失敗したため、DDL 4および5はshard01で実行されなかったことがわかります。このシャードがシャード・カタログと整合性を持つようにするには、GDSCTLのrecover shardコマンドを実行する必要があります。ただし、DDL 3は再び失敗し、実際には表領域セットtbs_setをもう作成するつもりがないため、このシャードでDDL 3を実行することは意味がありません。DDL 3をスキップするために、–ignore_firstオプションを指定してrecover shardを実行します。
GDSCTL> recover shard -shard shard01 –ignore_first
GSM Errors: dbs1 shard01:ORA-00959: tablespace \'TBS_SET\' does not exist
(ngsmoci_execute)
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------
1 create user sidney identified by *****
2 create tablespace set tbsset
3 create tablespace set tbs_set
4 drop tablespace set tbs_set shard01
5 create tablespace set tbsset2 DDL 3がスキップされたため、今度はDDL 3で失敗しません。ただし、次のDDL (4 - drop tablespace set tbs_set)が適用され、削除する表領域セットがシャードに存在しないため、エラーとなります。
–ignore_firstオプションは最初のDDLのみをスキップするため、recover shardを再び実行してdrop文もスキップする必要があります。
GDSCTL> recover shard -shard shard01 –ignore_first
GDSCTL> show ddl
id DDL Text Failed shards
-- -------- -------------
1 create user sidney identified by *****
2 create tablespace set tbsset
3 create tablespace set tbs_set
4 drop tablespace set tbs_set
5 create tablespace set tbsset2 失敗は表示されなくなり、すべてのDDLがシャードに正常に適用されました。
–ignore_firstオプションを指定してrecover shardを実行した場合、失敗したDDLは増分デプロイメントで無視とマークされます。このため、新しいシャードがSDBに追加されたとき、DDL番号3および4はスキップされ、DDL番号1、2および5のみが適用されます。
シャード間の一意の順序番号の生成
Oracle Shardingを使用すると、主キー以外の列に対してシャード間でグローバルに一意の順序番号を生成できます。これはシャード・データベースで処理されます。
customer_idがシャーディング・キーの場合、顧客は大抵、主キー以外の列(order_idなど)に対して一意のIDを生成する必要があります。この場合、この機能を使用してシャード間で一意の順序番号を生成できますが、アプリケーション内の主キー以外の特定の列のグローバルな一意性を管理する必要はありません。
この機能は、新しいオブジェクトSHARDED SEQUENCEでサポートされています。シャード順序はシャード・カタログに作成されますが、各シャード上にインスタンスがあります。各インスタンスは、他のシャードで使用される範囲とオーバーラップしない範囲に属する、単調に増加する番号を生成します。したがって、生成されたすべての番号はグローバルに一意になります。
たとえば、シャード順序を使用すると、顧客IDでシャーディングされた表に対して一意の順序番号を生成できます。顧客IDをキーとして使用してシャードへの接続を確立するアプリケーションでは、シャード順序のローカル・インスタンスを使用して、グローバルに一意の順序番号を生成できます。
シャード順序で生成された番号は、このシャードに挿入される新しい行のシャーディング・キーとしてすぐに使用できません。これは、キー値が別のシャードに属している場合に、挿入によってエラーが発生するためです。新しい行を挿入するには、まずアプリケーションでシャーディング・キーの値を生成し、それを使用して適切なシャードに接続する必要があります。シャーディング・キーの新しい値を生成する一般的な方法は、シャード・カタログで通常の(シャーディングされていない)順序を使用することです。
単一のシャーディング・キー・ジェネレータがボトルネックになっている場合、シャード順序をこの目的で使用できます。この場合、アプリケーションは(シャーディング・キーを指定せずにグローバル・サービスを使用して)ランダムなシャードに接続し、シャード順序から一意のキー値を取得してから、キー値を使用して適切なシャードに接続する必要があります。
この機能をサポートするために、次のCREATE文の構文に示すように、新しいSEQUENCEオブジェクト句、SHARDおよびNOSHARDがSEQUENCEオブジェクトのDDL構文に含まれます。
CREATE | ALTER SEQUENCE [ schema. ]sequence
[ { INCREMENT BY | START WITH } integer
| { MAXVALUE integer | NOMAXVALUE }
| { MINVALUE integer | NOMINVALUE }
| { CYCLE | NOCYCLE }
| { CACHE integer | NOCACHE }
| { ORDER | NOORDER }
| { SCALE {EXTEND | NOEXTEND} | NOSCALE}
| { SHARD {EXTEND | NOEXTEND} | NOSHARD}
]NOSHARDは、順序のデフォルトです。SHARD句を指定すると、このプロパティは順序オブジェクトのディクショナリ表に登録され、DBA_SEQUENCES、USER_SEQUENCESおよびALL_SEQUENCESビューを使用して表示されます。
SHARDを指定すると、EXTENDおよびNOEXTEND句によってシャード順序の動作が定義されます。EXTENDを指定すると、生成された順序値はすべての長さ(x+y)になります。xは順序値の先頭に付加されるサイズ4のSHARDオフセット(最大シャード数の幅に対応、つまり1000)の長さ、yは順序MAXVALUE/MINVALUEの最大桁数です。
SHARD句のデフォルト設定はNOEXTENDです。NOEXTENDが設定されていると、生成される順序値の幅は最大でも順序内の数字の最大数(MAXVALUE/MINVALUE)です。この設定は、固定幅の列を移入するために順序が使用される、既存のアプリケーションとの統合に役立ちます。SHARD NOEXTENDを指定した順序でNEXTVALを呼び出すと、生成された値に順序のMAXVALUE/MINVALUEよりも多くの桁数の表現が必要な場合は、ユーザー・エラーがスローされます。
SCALE句もSHARD句で指定されている場合、順序によって、グローバルに一意である複数のインスタンスおよびセッションに対してシャード内でスケーラブルな値が生成されます。EXTENDをSHARDキーワードとSCALEキーワードの両方で指定する場合、生成された順序値はすべての長さ(x+y+z)になります。xは先頭に付加されるサイズ4のSHARDオフセットの長さ、yはスケーラブルなオフセットの長さ(デフォルトは6)、zは順序MAXVALUE/MINVALUEの最大桁数です。
ノート:
SHARD句を使用する場合は、順序にORDERを指定しないでください。SHARDを使用すると、グローバルに順序付けされていない値が生成されます。ORDERが必要な場合は、各ノードでローカルに順序を作成します。
SHARDキーワードは、CACHEおよびNOCACHEモードの操作と組み合せて使用できます。