チャンク管理

Oracle Enterprise Manager Cloud ControlおよびGDSCTLを使用して、デプロイのチャンクを管理できます。

再シャーディングおよびホット・スポット回避

シャード数の変化によってトリガーされてデータがシャード間に再分散されるプロセスを再シャーディングと呼びます。自動再シャーディングは、システム管理のシャーディング方法の機能であり、シャード・データベースに柔軟なスケーラビリティを提供します。

ときには、シャード・データベースのデータを1つのシャードから他のシャードに移行する必要があります。シャード間のデータ移行は次のような場合に必要です。

• シャード・データベースに対して1つ以上のシャードを追加または削除した場合

• シャード間のデータ分散またはワークロード分散にスキューがある場合

シャード間のデータ移行の単位はチャンクです。チャンクでデータを移行することにより、異なるシャード・データベースの関連するデータが確実に一緒に移動されます。

シャード・データベースに対してシャードを追加または削除すると、複数のチャンクが移行されて、シャード間のチャンクとワークロードのバランスのとれた分散が維持されます。

シャーディング方法に応じて、再シャーディングが自動的に行われるか(システム管理)、ユーザーが指示します(コンポジット)。次の図は、3つのシャードを含むシャード・データベースにシャードを追加したときの自動再シャーディングの段階を示しています。

図7-7 シャード・データベースの再シャーディング

「図7-7 シャード・データベースの再シャーディング」の説明

データまたはワークロードのスキューが発生したときに、シャード数を変更せずに、特定のチャンクを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概要および管理ガイドを参照してください

• Oracle Enterprise Manager Cloud Controlを使用したチャンクの移動

進行中のチャンク移動操作の更新

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サポートが使用されます。

複数の表のパーティションにわたるチャンク間のオンラインDDLを使用したトランザクション一貫性のあるデータ移動により、シャーディング・キーを使用して表ファミリの複数の表に分散するデータに対してオンライン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. ターゲット・シャード領域のチャンク数は、ソース・シャード領域と同じである必要があります。

4. 1つのソース・パーティションセットから使用できるパーティションセットは2つのみです。そのため、このコマンドには最大3つのパーティションセットを指定できます。

5. STORAGE句またはTABLESPACE SET句は、1つの結果パーティションセットのみで指定でき、両方は指定できません。

6. TABLESPACE SET句またはSTORAGE句のいずれかのパーティションセットがターゲット・パーティションセットとみなされます。つまり、異なるシャード領域の新しいパーティションセットとみなされます。この句で指定するすべての表領域セットは、ターゲットまたは新しいシャード領域に存在する必要があります。

7. TABLESPACE SET句のないPARTITIONSETはローカルとみなされます。つまり、既存のソース・シャード領域と同じシャード領域に配置されます。

8. VALUES句は、常にリストの最初のPARTITIONSETで指定する必要があります。これにより、パーティションセットに対してレンジ・パーティション化を行う場合に、範囲の上限または下限をターゲット・シャード領域に移動できます。この句は、2つ目の結果パーティションセットに対して指定できないか、暗黙的です。

9. 結果のパーティションセットには固有の名前が必要です。

パーティションセット・キーのレンジ・パーティション化の場合、コマンドは、目的のターゲット・パーティションセットでstorage句を指定することで、元のパーティションセット内の範囲の上限または下限を保持できます。たとえば、

ALTER TABLE employees SPLIT PARTITIONSET employees
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を使用して、シャード・データベース・チャンクを管理できます。

次のトピックでは、Oracle Enterprise Manager Cloud Controlを使用したチャンク管理について説明します。

Oracle Enterprise Manager Cloud Controlを使用したチャンクの移動

Oracle Enterprise Manager Cloud Controlを使用して、デプロイ内の1つのシャードから他のシャードにチャンクを移動できます。

1. シャード領域管理ページから、シャード・データベース・ターゲット・ページの左上隅にある「シャード領域」メニューを開き、「シャードグループの管理」を選択します。
2. リストのシャードグループを選択して、「チャンクの移動」をクリックします。
3. 「チャンクの移動」ダイアログで、チャンクを移動するソース・シャードと宛先シャードを選択します。
4. オプションのいずれかを選択して、移動するチャンクを選択します。

   • IDリストの入力: チャンクID番号のカンマ区切りリストを入力します

   • 表からIDを選択: 表のチャンクIDをクリックします

5. チャンクの移動が発生する時間を示します。

   • 即時: 確認後にチャンクの移動がプロビジョニングされます

   • 後で: 隣接しているフィールドのカレンダ・ツールを使用して、チャンクを移動するタイミングをスケジュールします

6. 「OK」をクリックします。
7. ページ上部にある「情報」ボックスのリンクをクリックして、チャンク移動のプロビジョニング・ステータスを表示します。

Oracle Enterprise Manager Cloud Controlを使用したチャンクの分割

Oracle Enterprise Manager Cloud Controlを使用して、デプロイのチャンクを分割できます。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「シャード領域」を選択します。
2. 要求された場合、シャード・カタログ資格証明を入力し、「シャード・ディレクタ資格証明」で管理するシャード・ディレクタを選択し、シャード・ディレクタ・ホスト資格証明を選択してログインします。
3. リストのシャード領域を選択して、「チャンクの分割」をクリックします。
4. オプションのいずれかを選択して、分割するチャンクを選択します。

   • IDリストの入力: チャンクID番号のカンマ区切りリストを入力します

   • 表からIDを選択: 表のチャンクIDをクリックします

5. チャンクの分割が発生する時間を示します。

   • 即時: 確認後にチャンクの分割がプロビジョニングされます

   • 後で: 隣接しているフィールドのカレンダ・ツールを使用して、チャンクを分割するタイミングをスケジュールします

6. 「OK」をクリックします。
7. ページ上部にある「情報」ボックスのリンクをクリックして、チャンク分割のプロビジョニング・ステータスを表示します。

チャンクを正常に分割すると、チャンクの数が「シャード領域」リストで更新されます。更新内容を参照するには、ページのリフレッシュが必要な場合があります。