テーブルレベルの復元を実行する

このセクションでは、テーブルレベルの復元の方法について説明します。

テーブルレベル復元の方法

テーブルレベル復元における物理復元支援テナント段階では、フル復元と高速復元の2つの方法があります。

テーブルレベル復元プロセスは、物理復元支援テナント、テナント間テーブル導入、および支援テナントのクリーンアップの3つの段階で構成されています。以前のバージョンでは、物理復元支援テナント段階でフル復元方式が採用されていました。この方式では、ソーステナントのすべてのデータをバックアップメディアから支援テナントに復元する必要があり、以下の2つの問題が生じていました：

1. 一時的な支援テナントの復元をサポートするために、クラスタ上に十分なCPU、メモリ、およびディスクリソースを予約しておく必要がありました。
2. すべてのデータをバックアップメディアから支援テナントに復元するプロセスでは、大量の時間とネットワーク帯域幅を消費します。

上記の問題を解決するため、OceanBaseデータベースは高速復元方式による支援テナントの復元をサポートしています。この方式で支援テナントを復元する場合、読み取り専用の支援テナントを1つ復元するだけで済みます。テナント内のユーザーデータはバックアップメディアから復元する必要がなく、テナント間テーブル導入段階でバックアップメディアから復元対象テーブルのバックアップマクロブロックデータを直接読み取るだけで済みます。この方式により、テーブルレベル復元における一時的な支援テナントのリソース使用量が削減され、復元タスクの時間コストが短縮されます。

テーブルレベル復元を実行した後、sysテナントでビューCDB_OB_RESTORE_HISTORYのRESTORE_TYPE列を照会することで、支援テナントの復元方式を確認できます。

使用制限と注意事項

• ユーザーテーブルのみの復元をサポートしており、一時テーブル、ビュー、マテリアライズドビュー、マテリアライズドビューのログ、インデックスなどの個別復元はサポートしていません。

• テーブル復元時には、全文インデックス、JSON複数値インデックス、またはベクトルインデックスを持つテーブルの復元をサポートします。

• カラムストアおよび行列混合形式のテーブルの復元をサポートします。

• テーブル復元のソーステナントとターゲットテナントの互換性は一致している必要があります。例えば、どちらもOracle互換テナント、またはどちらもMySQL互換テナントである必要があります。

• テーブル復元時に指定するテーブル名は、システムが実際に格納しているテーブル名と一致している必要があります。例えば、Oracleモードのテナントでテーブルtestを作成した場合、システム内部で実際に格納されるテーブル名はTESTとなります。そのため、テーブルを復元する際にはテーブル名としてTESTを指定する必要があります。そうでない場合、システムはエラーを返し、テーブルが存在しないことを示します。

• テナントレベル復元でサポートされているバックアップデータのバージョンと同様に、テーブルレベル復元も現在は、低バージョンのバックアップデータから同じバージョンまたは高いバージョンへのテーブル復元のみをサポートしており、同じバージョン内のマイナーバージョン間での逆方向復元もサポートしていません。テナントレベル復元でサポートされているバックアップデータのバージョンの詳細については、復元前の準備を参照してください。

• テーブルレベル復元では、テーブルの復元に加えて、そのテーブルに関連付けられた多くの情報も復元されますが、一部の情報は復元されません。具体的に復元可能な情報については、テーブルレベル復元のSchema復元説明を参照してください。

前提条件

指定したテーブルの復元プロセスでは支援テナントを使用する必要があるため、テーブル復元を行う前に、ターゲットテナントが存在するクラスタ内で支援テナント用の必要なリソースプールを作成する必要があります。支援テナント用の必要なリソースプールを作成する詳細な操作については、テーブルレベル復元前の準備を参照してください。

手順

1. rootユーザーで、対象テナントが存在するクラスタのsysテナントにログインします。

2. （オプション）指定したテーブルを復元する際に使用されたバックアップデータに暗号化機能が設定されている場合は、バックアップセットの暗号化情報を設定する必要があります。

   データバックアップ時にパスワードが追加された場合にのみ、バックアップの復元パスワードを設定する必要があります。

   SET DECRYPTION IDENTIFIED BY 'password';
   

   ここで、passwordはバックアップ時に追加されたパスワードに置き換えてください。フルバックアップと増分バックアップで設定されたパスワードが異なる場合は、複数のパスワードを入力し、パスワードの間に半角カンマ（,）で区切ります（フルバックアップのパスワードを先頭に、増分バックアップのパスワードを後方に配置します）。

   フルバックアップと増分バックアップで設定されたパスワードが同じ場合の例：

   SET DECRYPTION IDENTIFIED BY '******';
   

   フルバックアップと増分バックアップで設定されたパスワードが異なる場合の例：

   SET DECRYPTION IDENTIFIED BY '******','******';
   

3. （オプション）テーブルレベルの復元並列度を設定します。

   • 単一テーブルの並列復元

     テーブルレベルの復元を実行する前に、パラメータrecover_table_dopで並列度を設定できます。設定後、システムは以下の2つの段階でこの並列度を使用します：

     • メインテーブルデータ復元段階：システムはメインテーブルの各パーティションを複数のサブタスクに分割し、並列して実行します。
     • インデックス復元段階：システムは復元されたメインテーブルデータに基づき、並列実行（Parallel Execution, PX）を利用してテーブルのインデックスを再構築します。

     構文は以下のとおりです：

     -- tenant_name は対象テナント
     ALTER SYSTEM SET recover_table_dop=INT_VALUE tenant=tenant_name;
     

   • 複数テーブルの並列復元（オプション）

     複数テーブルのテーブルレベル復元を実行する前に、パラメータrecover_table_concurrencyで並列度を設定できます。設定後、複数のテーブルを並列して実行し、復元性能を向上させることができます。

     構文は以下のとおりです：

     -- tenant_name は対象テナント
     ALTER SYSTEM SET recover_table_concurrency=INT_VALUE tenant=tenant_name;
     

   • テナント内の各observerノード上のメインテーブルデータ復元ワーカースレッド数の設定

     単一テーブルの並列度 recover_table_dop と複数テーブルの並列度 recover_table_concurrency を設定した後、テナント内の各observerノード上のデータ補完ワーカースレッド数も ddl_thread_score パラメータで設定する必要があります。テーブルレベル復元のテナント間データ導入段階では、メインテーブルデータの復元は対象テナント上の特定のDAGスレッドに依存します。

     構文は以下のとおりです：

     -- tenant_name は対象テナント
     ALTER SYSTEM SET ddl_thread_score=INT_VALUE tenant=tenant_name;
     

     注意

     • 物理復元補助テナント実行段階では、ha_high_thread_score パラメータを調整することで、復元の並列度を動的に変更できます。変更は即時に反映されます。補助テナント名は、テーブルレベル復元のタスク進捗表 CDB_OB_RECOVER_TABLE_JOBS で確認できます。具体的な調整方法については、物理復元を参照してください。
     • テナント間データ導入段階では、対象テナントの recover_table_concurrency または recover_table_dop パラメータを調整することで、複数テーブル/単一テーブルの復元並列度を動的に変更できます。変更は即時に反映されます。

4. 以下のコマンドを実行して、指定したテーブルを復元します。

   SQL文は以下のとおりです：

   ALTER SYSTEM
   RECOVER TABLE table_name_list
   TO [TENANT [=]] dest_tenant_name
   FROM uri
   [UNTIL {TIME='timestamp'} | {SCN=scn} ]
   WITH 'restore_option'
   [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password']
   [REMAP TABLE remap_table_name_list]
   [REMAP TABLEGROUP remap_tablegroup_list]
   [REMAP TABLESPACE remap_tablespace_list]
   [DESCRIPTION [=] description];
   

   関連パラメータの説明は以下のとおりです：

   • table_name_list：復元するテーブル。形式は database_name.table_name1,database_name.table_name2,... で、複数のテーブルは半角カンマ（,）で区切ります。

     database_name と table_name を指定する場合：

     • table_name はシステムが実際に格納するテーブル名と一致している必要があります。例えば、Oracleテナントでテーブル test を作成した場合、システム内部で実際に格納されるテーブル名は TEST となります。そのため、テーブルを復元する際には TEST という名前を指定する必要があります。そうでない場合、システムはエラーを返し、テーブルが存在しないことを示します。

     • database_name または table_name に特殊文字が含まれる場合、特殊文字を含む database_name または table_name はバッククォート（``）で囲む必要があります。

     • データベース内のすべてのテーブルを復元する場合は、database_name.* と表現できます。

     • テナント内のすべてのユーザーテーブルを復元する場合は、*.* と表現できます。

   • dest_tenant_name：テーブルを復元する対象テナント名。テーブルの復元はユーザーテナントへのみサポートされており、sys テナントやMetaテナントへの復元はサポートされていません。

   • uri：データバックアップとログアーカイブのパスをそれぞれ指定します。これはテナントレベルの物理復元コマンドのパラメータと同じです。データバックアップがPLUS ARCHIVELOG方式で開始された場合は、一方のパスのみを入力する必要があります。そうでない場合は、データバックアップとログアーカイブの少なくとも2つのパスをそれぞれ入力する必要があります。例：'file:///backup/archive, file:///backup/data'。

   • {TIME='timestamp'} \| {SCN=scn}：指定された復元終点。このポイントまで復元し、このポイントを含みます。TIME または SCN に復元する場合は、= で指定値を結合する必要があります。UNTIL 句を指定しない場合、デフォルトで最新のポイントまで復元されます。

   • restore_option：補助テナントの pool_list、locality、primary_zone、concurrency を指定します。異なるパラメータは & で区切ります。locality と primary_zone を指定する際は、可能な限りソーステナントと同型に保つことを推奨します。

     concurrency を指定しない場合、デフォルトでその補助テナントに割り当てられたMAX_CPUに等しくなります。例えば、このドキュメントでは、システムテナントが補助テナントに割り当てるMAX_CPUは16です。

     各パラメータの詳細については、テーブルレベル復元関連パラメータ紹介を参照してください。

   • WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'：テナントの秘密鍵バックアップ情報を指定します。ソーステナントで透過的データ暗号化が設定されている場合にのみ、復元時に秘密鍵バックアップ関連情報を指定する必要があります。

     • backup_key_path：秘密鍵のバックアップパス。

     • password：秘密鍵をバックアップする際に設定した暗号化パスワード。

     秘密鍵バックアップに関する操作については、バックアップ前の準備の 秘密鍵のバックアップ を参照してください。

   • remap_table_name_list：復元後のテーブル名を変更します。テーブル名のみを変更し、所属するデータベースを変更しない場合、テーブル名を変更せずに他のデータベースに移行する場合、テーブル名を変更し、所属するデータベースも他のデータベースに変更する場合をサポートします。ソースオブジェクトと変更後のオブジェクトは、半角コロン（:）で結合します。具体的な形式の例は以下のとおりです：

     • テーブル名を student から student2 に変更し、所属するデータベースを変更しない場合：REMAP TABLE school.student:student2。

       所属するデータベースを変更しない場合、対象テナントにテーブルを作成する際、システムはデフォルトでテーブルを対象テナントの同名データベースに復元します。同名のデータベースが存在しない場合、テーブルの復元は失敗します。

     • テーブル名を変更せず、所属するデータベースを school から college に変更する場合：REMAP TABLE school.student:college.student。

     • テーブル名を student から student2 に変更し、所属するデータベースを school から college に変更する場合：REMAP TABLE school.student:college.student2。

     • school データベースのすべてのテーブルを college データベースに復元する場合：REMAP TABLE school.*:college.*

     説明

     変更する database_name または table_name に特殊文字が含まれる場合、特殊文字を含む database_name または table_name をバッククォート（``）で囲む必要があります。

   • remap_tablegroup_list：テーブルが所属するテーブルグループの名前を変更します。ソーステーブルがテーブルグループに紐づけられている場合、対象テナントにテーブルを作成する際、システムはデフォルトでテーブルを対象テナントの同名テーブルグループに復元します。同名のテーブルグループが存在しない場合、テーブルの復元は失敗します。対象テナントに他のテーブルグループがある場合、このステートメントを使用してテーブルを他のテーブルグループに復元できます。ソースオブジェクトと変更後のオブジェクトは、半角コロン（:）で結合します。

     例えば、ソーステーブルグループ tg1 内のテーブルをすべて対象テナントのテーブルグループ newtg1 に復元する場合：REMAP TABLEGROUP tg1:newtg1。

   • remap_tablespace_list：テーブルが所属するテーブルスペースの名前を変更します。テーブルスペースはOceanBaseデータベースにおける論理的単位で、現在は主にデータ暗号化に使用されます。ソーステーブルがテーブルスペースに紐づけられている場合、対象テナントにテーブルを作成する際、システムはデフォルトでテーブルを対象テナントの同名テーブルスペースに復元します。同名のテーブルスペースが存在しない場合、テーブルの復元は失敗します。対象テナントに他のテーブルスペースがある場合、このステートメントを使用してテーブルを他のテーブルスペースに復元できます。ソースオブジェクトと変更後のオブジェクトは、半角コロン（:）で結合します。

     例えば、ソーステーブルスペース ts1 内のテーブルをすべて対象テナントのテーブルスペース newts1 に復元する場合：REMAP TABLESPACE ts1:newts1。

   テーブル復元関連パラメータの詳細については、テーブルレベル復元関連パラメータ紹介を参照してください。

   infodbライブラリ内のテーブル tbl1、tbl2 を対象テナントの infodbライブラリに復元し、テーブル tbl1 の名前を newtbl に変更します。同時に、テーブルが所属するテーブルグループを newtg1 に、テーブルが所属するテーブルスペースを newts1 にリダイレクトします。例：

   ALTER SYSTEM
   RECOVER TABLE infodb.tbl1,infodb.tbl2
   TO TENANT oracle001
   FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive'
   UNTIL TIME='2023-09-30 00:00:00'
   WITH 'pool_list=restore_pool'
   REMAP TABLE infodb.tbl1:newtbl
   REMAP TABLEGROUP tg1:newtg1
   REMAP TABLESPACE ts1:newts1;
   

次のステップ

• 指定したテーブルの復元を開始した後、ビューを使用してテーブル復元の進捗状況と結果を確認できます。具体的な操作については、テーブルレベル復元の進捗状況の確認およびテーブルレベル復元結果の確認を参照してください。

• 指定したテーブルの復元が終了した後、補助テナントが存在するクラスタで以下のコマンドを実行し、補助テナント用に作成されたリソースプールを手動で解放する必要があります。

  DROP RESOURCE POOL restore_pool;
  

  ここで、restore_pool は復元前の準備時に補助テナント用に作成されたリソースプール名を表します。

  リソースプールの削除に関する詳細な操作と説明については、リソースプールの削除を参照してください。

関連ドキュメント

テーブルレベル復元における各スキーマ情報の復元状況については、テーブルレベル復元のスキーマ復元の説明を参照してください。