チャンク管理
Oracle Enterprise Manager Cloud ControlおよびGDSCTLを使用して、デプロイのチャンクを管理できます。
再シャーディングおよびホット・スポット回避
シャード数の変化によってトリガーされてデータがシャード間に再分散されるプロセスを再シャーディングと呼びます。自動再シャーディングは、システム管理のシャーディング方法の機能であり、分散データベースに柔軟なスケーラビリティを提供します。
場合によっては、分散データベースのデータを1つのシャードから別のシャードに移行する必要があります。シャード間のデータ移行は次のような場合に必要です。
-
分散データベースに対して1つ以上のシャードを追加または削除した場合
-
シャード間のデータ分散またはワークロード分散にスキューがある場合
シャード間のデータ移行の単位はチャンクです。チャンクでデータを移行することにより、異なるシャード・データベースの関連するデータが確実に一緒に移動されます。
分散データベースに対してシャードを追加または削除すると、複数のチャンクが移行されて、シャード間のチャンクとワークロードのバランスのとれた分散が維持されます。
シャーディング方法に応じて、再シャーディングが自動的に行われるか(システム管理)、ユーザーが指示します(コンポジット)。次の図は、3つのシャードを含む分散データベースにシャードを追加したときの自動再シャーディングの段階を示しています。
データまたはワークロードのスキューが発生したときに、シャード数を変更せずに、特定のチャンクを1つのシャードから他へ移動することもできます。この場合、ホット・スポットを回避するために、データベース管理者がチャンクの移動を開始できます。
RMAN増分バックアップ、トランスポータブル表領域およびOracle Notification Serviceテクノロジを使用して、アプリケーションの可用性へのチャンク移行の影響を最小限に抑えます。チャンク移行中、チャンクはオンラインのままです。短時間(数秒間)は、チャンクに格納されたデータが読取り専用アクセスのみになります。
FAN対応クライアントは、ソース・シャードでチャンクが読取り専用になる直前に通知を受信し、チャンク移行が完了して宛先シャードでチャンクが完全に使用可能になると、再度、通知を受信します。chunk read-only
イベントを受信すると、クライアントはチャンク移行が完了するまで接続の試行を繰り返すか、ソース・チャンクの読取り専用チャンクにアクセスできます。後者の場合、チャンクに書き込もうとすると、ランタイム・エラーが発生します。
ノート:
分散データベースの再シャーディング中にマルチシャード問合せを実行すると、エラーが発生する可能性があるため、マルチシャードのワークロード中に新しいシャードをデプロイしないことをお薦めします。
チャンクの移動
チャンクをあるシャードから別のシャードに移動することが必要となる場合があります。分散データベース環境のスケーラビリティを維持するには、すべてのシャード間で負荷とアクティビティが均等に分散されるように維持することが重要です。
コンポジット分散データベースの環境が長期間使用されると、一部のシャードがよりアクティブになり、他のシャードよりデータが多くなります。環境内のバランスを保つために、よりアクティブなサーバーからアクティブではないサーバーにチャンクを移動する必要があります。チャンクを移動する理由は他にもあります。
-
あるシャードが他のシャードよりアクティブになった場合は、よりアクティブではないシャードにチャンクを移動して、環境内で負荷が均等に配分されるようにできます。
-
範囲、リストまたはコンポジット・シャーディングを使用しているときに、シャードをシャードグループに追加する場合。
-
範囲、リストまたはコンポジット・シャーディングを使用しているときに、シャードグループからシャードを削除する場合。
-
チャンクを分割したら、分割されたチャンクのいずれかを新しいシャードに移動することを多くの場合お薦めします。
スケーラビリティを維持するためにシャードを移動する場合、チャンクの最適なターゲットはよりアクティブではないシャード、またはより少ないデータがあるシャードです。Oracle Enterprise ManagerおよびAWRのレポートは、シャード間のアクティビティの配分を識別するため、およびチャンクの移動のよい候補となるシャードを識別するために役立ちます。
ノート:
チャンクをあるシャードから別のシャードに移動する場合は、その操作に関係するデータベース(チャンクの移動のソースおよびターゲットの両方)のフル・バックアップを取得する必要があります。
GDSCTLまたはOracle Enterprise Manager Cloud Controlを使用してチャンクを管理できます。
-
GDSCTL MOVE CHUNK
コマンドの使用方法の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください - チャンクの移動
進行中のチャンク移動操作の更新
MOVE CHUNK
操作の進行中は、GDSCTL ALTER MOVE
コマンドを使用して、操作で移動がスケジュールされている(移動がまだ開始されていない)すべてのチャンクを一時停止、再開または取消しできます。
このコマンドには3つのバリエーションがあります。-SUSPEND
を使用してチャンク移行操作を延期し、-RESUME
を使用して移動プロセスを再起動し、-CANCEL
によってチャンク移行を取り消します。
また、-CHUNK
および-SHARD
オプションを使用して、スケジュールされたチャンク移動のリストをフィルタします。CONFIG CHUNKS -SHOW_RESHARD
コマンドを使用して、スケジュール済チャンク移動のリストを取得できます。
チャンク移動の一時停止
ALTER MOVE -SUSPEND
は、操作を再開または取消しを実行するまで、指定されたスコープのチャンク移行を延期します。操作を一時停止するシャードを指定し、ソース・シャードとターゲット・シャードをリストできます。一時停止する特定のチャンクのリストを指定することもできます。
定義したスコープ内のチャンクがすでに移動されている場合(スケジュール済以外の状態)、そのチャンクは一時停止されません。
たとえば、次のコマンドは、shard1との間でスケジュールされたすべてのチャンク移動を一時停止します。
GDSCTL> alter move -suspend -shard shard1
チャンク移動の再起動
ALTER MOVE -RESUME
は、指定されたシャード上の「move failed」フラグをリセットし、停止中または一時停止中のチャンク移動をすべて再起動します。
オプションで、移動の再起動前に「move failed」フラグがリセットされるソースおよびターゲット・シャードのリストを指定できます。シャードが指定されていない場合、進行中の移動が完了すると、一時停止された移動が再開されます。
たとえば、次のコマンドは、shard1との間でスケジュールされた一時停止または失敗したチャンク移動で、チャンク移動を再起動します。
GDSCTL> alter move -resume -shard shard1
チャンク移動の取消し
ALTER MOVE -CANCEL
は、移動チャンク・スケジュールから指定されたチャンクを削除します。
-CHUNK
オプションは、リストされたすべてのチャンクをスケジュールから削除することを指定し、-SHARD
は、このデータベースとの間のすべてのチャンク移動をスケジュールから削除することを指定します。チャンクまたはシャードが指定されていない場合、まだ処理されていないチャンク移動はすべて取り消されます。
定義したスコープ内のチャンクが現在移動されている場合(スケジュール済以外の状態)、そのチャンク移動は取り消されません。
取り消されたチャンクは再開/再起動できません。これらのチャンクを移動するには、新しいMOVE CHUNK
コマンドを発行する必要があります。
たとえば、チャンク1、2および3がまだ移動されていない場合は、次のコマンドによってチャンク移動スケジュールから削除されます。
GDSCTL> alter move -cancel -chunk 1,2,3
チャンクの分割
チャンクが大きくなりすぎた場合や、チャンクの一部のみを別のシャードに移行する必要がある場合は、分散データベースのチャンクを分割する必要があります。
Oracle Globally Distributed Databaseは、チャンクのオンライン分割をサポートしています。理論上は、各シャードに1つのチャンクを作成し、データ移行が必要になるたびに分割できます。ただし、チャンクの分割はデータの可用性に影響しないものの、分割するパーティションのすべての行をスキャンしてから、1行ずつ新しいパーティションに挿入するため、時間がかかり、CPUにも負荷がかかる操作です。コンポジット・シャーディングの場合、チャンクの分割には時間がかかり、シャード・キーまたはスーパー・シャード・キーの新しい値を再定義するために停止時間が必要となることがあります。
したがって、各シャードに事前に複数のチャンクを作成し、次のいずれかの場合に分割することをお薦めします。再シャーディング中にデータをバランスよく分散するにはチャンク数が足りない場合、または特定のチャンクがホット・スポットになっている場合です。
システム管理のシャーディングの場合でも、単一のチャンクが他のチャンクより大きくなったり、よりアクティブになったりすることがあります。この場合は、そのチャンクを分割し、分割されたチャンクのいずれかが自動再シャーディングによって別のシャードに移動されることを許可すると、環境内のデータおよびアクティビティがより均等に配分されるように維持されます。
Oracle Enterprise Managerのヒート・マップには、どのチャンクが他のチャンクよりもアクティブになっているかが表示されます。この機能を使用してどのチャンクを分割できるかを識別し、分割されたチャンクのいずれかを別のシャードに移動して環境をリバランスできます。
GDSCTLまたはOracle Enterprise Manager Cloud Controlを使用してチャンクを管理できます。
-
GDSCTL SPLIT CHUNK
コマンドの使用方法の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください - 「Oracle Enterprise Manager Cloud Controlを使用したチャンクの分割」を参照してください
スーパー・キーに基づいたシャード領域へのチャンクの分割
コンポジット・シャーディング・データ分散方法を使用する分散データベースでは、データはスーパー・シャード・キー列の値に基づいて異なるシャード領域に編成できます。スーパー・シャード・キー値ごとに既存のデータ・チャンクを新しいシャード領域に分割できます。
スーパー・シャーディング・キーによるチャンクの分割は、パーティション/チャンク分割の一意の操作であり、データの再編成および移動も必要です。この操作の過程での多くの内部ステップでは、再シャーディング操作中にアプリケーションをオンラインのままにできるように、オンラインDDLサポートが使用されます。
ユースケース
たとえば、参照キーおよびシャーディング・キーとしてcustomer_id
を介して相互に関連する表Customers、Orders、Lineitemsを含む分散データベースがあるとします。この分散データベースは、スーパー・シャード・キーとして顧客のClassを持つコンポジット・シャーディング・データ分散方法を使用します。
将来的に、プレミアム・クラスの顧客に異なるレベルのサービスやリソースを提供するためにデータを再配置できるように、顧客のClass別にデータの場所を配置します。
ビジネス・ニーズのため、GoldとSilver Classの顧客のみのデータが将来存在する新しいシャード領域が必要になりますが、現在そのデータはその方法で配布されていません。たとえば、追加のレポートやビジネス・サービス、データ・セキュリティ・サービスを追加コストでプレミアム顧客にのみ提供でき、これらの顧客をクラウド内の別の可用性ドメインまたはリージョンでホストされる別のシャード領域で分離することで、より便利になります。または、より効率的なもののコストがかかるハードウェアがあり、これが一部のシャードのみをホストでき、すべてのシャードをホストできるわけではない場合、プレミアム・クラスに割り当てるのが適することがあります。
スーパー・キーに基づいたシャード領域へのデータの分割
このALTER TABLE
構文に示すように、スーパー・シャーディング・キーによるチャンクの分割をサポートするために、PARTITIONSET
演算子SPLIT
が導入されています。
ALTER TABLE tablename
SPLIT PARTITIONSET partitionset_name
INTO
(partitionset partitionset_name
values [(list of values)] | [LESS THAN (value)]
[lob_column1 store as (tablespace set_name1),
lob_column2 store as (tablespace set_name2) … ]
[[SUBPARTITIONS store in (<tablespace set_name1,
tablespace set_name2, …]|[tablespace_set
tablespaceset_name]],
partitionset partitionset_name
[lob_column1 store as (tablespace set_name1),
lob_column2 store as (tablespace set_name2) … ]
[[SUBPARTITIONS store in (<tablespace set_name1,
Tablespace set_name2, …]|[tablespace_set
tablespaceset_name]]) ;
たとえば、customersパーティションセットをGoldの顧客とGold以外の顧客に分割するには:
ALTER TABLE customers
SPLIT PARTITIONSET all_customers
INTO (PARTITIONSET gold_customers
VALUES (‘gold’)
TABLESPACE SET ts2,
PARTITIONSET non_gold_customers)
前述のとおり、コマンドはALTER TABLE SPLIT PARTITION
に似ていますが、SPLIT PARTITIONSET
の場合、この構文には次のような特定のルールがあります。
-
ターゲット・シャード領域のシャード数は、ソース・シャード領域と同じである必要があります。
-
ターゲット・シャード領域はクリーンで、チャンクを持たない必要があります。
-
ターゲット・シャード領域のチャンク数は、ソース・シャード領域と同じである必要があります。
-
1つのソース・パーティションセットから使用できるパーティションセットは2つのみです。そのため、このコマンドには最大3つのパーティションセットを指定できます。
-
STORAGE
句またはTABLESPACE SET
句は、1つの結果パーティションセットのみで指定でき、両方は指定できません。 -
TABLESPACE SET
句またはSTORAGE
句のいずれかのパーティションセットがターゲット・パーティションセットとみなされます。つまり、異なるシャード領域の新しいパーティションセットとみなされます。この句で指定するすべての表領域セットは、ターゲットまたは新しいシャード領域に存在する必要があります。 -
TABLESPACE SET
句のないPARTITIONSET
はローカルとみなされます。つまり、既存のソース・シャード領域と同じシャード領域に配置されます。 -
VALUES
句は、常にリストの最初のPARTITIONSET
で指定する必要があります。これにより、パーティションセットに対してレンジ・パーティション化を行う場合に、範囲の上限または下限をターゲット・シャード領域に移動できます。この句は、2つ目の結果パーティションセットに対して指定できないか、暗黙的です。 -
SPLIT PARTITIONSET
を発行するときに、DEPENDENT TABLES
句を使用して依存表の特定のプロパティを設定することはできません。 -
結果のパーティションセットには固有の名前が必要です。
パーティションセット・キーのレンジ・パーティション化の場合、コマンドは、目的のターゲット・パーティションセットでstorage句を指定することで、元のパーティションセット内の範囲の上限または下限を保持できます。たとえば、
ALTER TABLE employees SPLIT PARTITIONSET P1
into (PARTITIONSET junior_employees values less than 10,
PARTITIONSET senior_employees TABLESPACE SET ts4)
前述のコマンドは、新しいパーティションセットまたはターゲット・パーティションセットとして'senior_employees'を持ちます。パーティションセットのキー列の値が10未満であるパーティションセットの従業員の行は元のパーティションセットに残り、このパーティションセットは操作の最後にjunior_employeesという名前に変更されます。
パーティションセット・キー列の値が10以上のパーティションセット従業員の行は、パーティションセット'employees'とは異なるシャード領域を持つ新しいパーティションセット'senior_employees'に移動されます。ターゲット・シャード領域にあるパーティションセット'senior_employees'および表領域セット'ts4'に関連付けられている表領域セット句は、このパーティションセットが新しいターゲット・シャード領域にあることを示します。
Oracle Enterprise Manager Cloud Controlを使用したチャンクの管理
Oracle Enterprise Manager Cloud Controlを使用して、グローバル分散データベース・チャンクを管理できます。
Cloud Controlを使用してチャンクを管理するには、そのチャンクが存在するシャード・データベースを最初に検出する必要があります。各データベース・シャードはデータベース自体であるため、標準のCloud Controlデータベース検出プロシージャを使用できます。
次のトピックでは、Oracle Enterprise Manager Cloud Controlを使用したチャンク管理について説明します。