指定したバックアップまたはアーカイブデータの手動クリーンアップ

業務上の必要により、特定のバックアップやアーカイブをクリーンアップしたい場合は、本記事を参照して指定したデータバックアップセットやログアーカイブPieceを手動でクリーンアップできます。

使用上の制限

• 指定したバックアップまたはアーカイブデータを手動でクリーンアップする場合、操作対象となるユーザーテナントに自動クリーンアップ戦略が設定されている必要があります。設定されていない場合は、クリーンアップを実行できません。

• ログアーカイブのみを有効にし、データバックアップパスを設定していない場合、指定したログアーカイブPieceを手動でクリーンアップすることはできません。ユーザーは自動クリーンアップ戦略を log_only に設定することでのみ、ログアーカイブPieceのクリーンアップを実現できます。

  自動クリーンアップ戦略の設定手順の詳細については、期限切れバックアップの自動クリーンアップを参照してください。

指定したデータバックアップセットのクリーンアップ

注意事項

指定したデータバックアップセットをクリーンアップする際には、以下の点に注意してください：

• データバックアップ間の依存関係を破壊してはなりません。あるデータバックアップが関連する増分バックアップに依存している場合、その依存されているデータバックアップは、それに依存するすべての増分バックアップが削除された後でなければ削除できません。

• クリーンアップで複数の BACKUP_SET_ID を同時に指定する必要がある場合、すべての BACKUP_SET_ID が同一のバックアップパス下にある必要があります。同一コマンド内で複数のパス下のデータバックアップをクリーンアップすることはサポートされていません。

• 現在使用中のバックアップパスについては、リストアに使用可能な最新のフルデータバックアップを少なくとも1セット保持する必要があります。つまり、リストア用のフルバックアップを1セット保持した上で、そのバックアップセットより前の他のバックアップセットを削除できます。

• 削除対象のデータバックアップセットが現在使用中のバックアップパスにない場合、OceanBaseデータベースが該当バックアップパスへのアクセス権限を持っていることを確認する必要があります。

システムテナントが指定ユーザーテナントの指定データバックアップセットをクリーンアップする

1. root ユーザーでクラスタの sys テナントにログインします。

   接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。

   obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
   

2. テナント情報を確認し、テナントの TENANT_ID を取得します。

   このドキュメントでは、テナント mysql001 を例に説明します。クエリ例は以下のとおりです：

   obclient(root@sys)[(none)]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'mysql001';
   

   クエリ結果は次のとおりです：

   +-----------+-------------+-------------+
   | TENANT_ID | TENANT_NAME | TENANT_TYPE |
   +-----------+-------------+-------------+
   |      1002 | mysql001    | USER        |
   +-----------+-------------+-------------+
   1 row in set
   

   クエリ結果によると、このテナントの TENANT_ID は1002です。

3. クリーンアップ対象のバックアップセットの backup_set_id を取得します。

   obclient(root@sys)[(none)]> SELECT TENANT_ID, BACKUP_SET_ID, BACKUP_TYPE, PREV_FULL_BACKUP_SET_ID, PREV_INC_BACKUP_SET_ID, STATUS, FILE_STATUS, START_REPLAY_SCN, START_REPLAY_SCN_DISPLAY, MIN_RESTORE_SCN, MIN_RESTORE_SCN_DISPLAY, PATH FROM oceanbase.CDB_OB_BACKUP_SET_FILES WHERE TENANT_ID = 1002;
   

   クエリ結果は次のとおりです：

   +-----------+---------------+-------------+-------------------------+------------------------+---------+-------------+---------------------+----------------------------+---------------------+-------------------------------+-------------------------------+
   | TENANT_ID | BACKUP_SET_ID | BACKUP_TYPE | PREV_FULL_BACKUP_SET_ID | PREV_INC_BACKUP_SET_ID | STATUS  | FILE_STATUS | START_REPLAY_SCN    | START_REPLAY_SCN_DISPLAY   | MIN_RESTORE_SCN     | MIN_RESTORE_SCN_DISPLAY       | PATH                          |
   +-----------+---------------+-------------+-------------------------+------------------------+---------+-------------+---------------------+----------------------------+---------------------+-------------------------------+-------------------------------+
   |      1002 |             1 | FULL        |                       0 |                      0 | SUCCESS | AVAILABLE   | 1757326402739265000 | 2025-09-08 18:13:22.739265 | 1757326563751672000 | 2025-09-08 18:16:03.751672000 |  file:///data/nfs/backup/data |
   |      1002 |             2 | INC         |                       1 |                      1 | SUCCESS | AVAILABLE   | 1757326402739265000 | 2025-09-08 18:13:22.739265 | 1757326695246191000 | 2025-09-08 18:18:15.246191000 |  file:///data/nfs/backup/data |
   |      1002 |             3 | FULL        |                       0 |                      0 | SUCCESS | AVAILABLE   | 1757326402739265000 | 2025-09-08 18:13:22.739265 | 1757326826319880000 | 2025-09-08 18:20:26.319880000 |  file:///data/nfs/backup/data |
   |      1002 |             4 | FULL        |                       0 |                      0 | SUCCESS | AVAILABLE   | 1757326402739265000 | 2025-09-08 18:13:22.739265 | 1757326961311034000 | 2025-09-08 18:22:41.311034000 |  file:///data/nfs/backup/data |
   |      1002 |             5 | FULL        |                       0 |                      0 | SUCCESS | AVAILABLE   | 1757326402739265000 | 2025-09-08 18:13:22.739265 | 1757327092469081000 | 2025-09-08 18:24:52.469081000 |  file:///data/nfs/backup/data |
   |      1002 |             6 | FULL        |                       0 |                      0 | SUCCESS | AVAILABLE   | 1757326402739265000 | 2025-09-08 18:13:22.739265 | 1757327219591390000 | 2025-09-08 18:26:59.591390000 |  file:///data/nfs/backup/data |
   +-----------+---------------+-------------+-------------------------+------------------------+---------+-------------+---------------------+----------------------------+---------------------+-------------------------------+-------------------------------+
   6 rows in set
   

   クエリ結果によると、テナントIDが 1002 のテナント配下には、5つのフルバックアップと1つの増分バックアップがすべて同じバックアップパスに存在します。そのうち：

   • BACKUP_SET_ID が1、3、4、5、6のバックアップはフルバックアップです。
   • BACKUP_SET_ID が2のバックアップは増分バックアップであり、BACKUP_SET_ID が1のフルバックアップに依存しています。

   クリーンアップ要件に従って：

   • BACKUP_SET_ID が2の増分バックアップを削除する前に、BACKUP_SET_ID が1のフルバックアップを削除することはできません。

   • 削除対象のバックアップセットが配置されているバックアップパスが、テナントが現在使用中のバックアップパスである場合、最新のリストア可能なフルバックアップデータを1つ保持する必要があります。それ以前のデータバックアップは削除できます。

     バックアップが「リストアに使用可能」かどうかの鍵は、必要なログアーカイブが完全であるかどうかにあります。例えば、この例では、フルバックアップ BACKUP_SET_ID 6がリストアに使用可能かどうかは以下の方法で判断できます：

     • BACKUP_SET_ID 6自体に補償ログが含まれている場合（データバックアップの開始時に PLUS ARCHIVELOG パラメータを指定した場合）、そのバックアップセットは直接リストアに使用できます。バックアップセットを削除する際は BACKUP_SET_ID 6を保持し、そのバックアップより前の他のバックアップセットを削除できます。
     • BACKUP_SET_ID 6に補償ログが含まれていない場合（データバックアップの開始時に PLUS ARCHIVELOG パラメータを指定しなかった場合）、現在のアーカイブパス下のログアーカイブPieceを確認し、そのバックアップセットの START_REPLAY_SCN から MIN_RESTORE_SCN までの完全で連続したログアーカイブPieceが存在することを確認する必要があります。条件を満たすログアーカイブPieceが存在しない場合、BACKUP_SET_ID 6はリストアに使用できません。同じ方法で直前のフルバックアップ BACKUP_SET_ID 5がリストアに使用可能かどうかを確認し、これを繰り返します。

4. 以下のコマンドを実行して、指定されたデータバックアップを削除します。

   ステートメントは以下のとおりです：

   ALTER SYSTEM DELETE BACKUPSET backup_set_id[,backup_set_id,...] TENANT [=] tenant_name;
   

   そのうち：

   • backup_set_id：削除対象のバックアップセットのIDを指定します。単一のコマンドで複数のデータバックアップセットを同時に指定することができます。複数の backup_set_id を指定してクリーンアップする場合、すべての backup_set_id が同じバックアップパス下にある必要があります。同一コマンド内で複数パス下のデータバックアップをクリーンアップすることはサポートされていません。

   • tenant_name：削除対象のバックアップセットのテナントを指定します。

   例：

   • テナント mysql001 の backup_set_id が3のデータバックアップセットを削除します。

     obclient(root@sys)[(none)]> ALTER SYSTEM DELETE BACKUPSET 3 TENANT = mysql001;
     

   • テナント mysql001 の backup_set_id が1、2、4の3つのデータバックアップセットを同時に削除します。

     obclient(root@sys)[(none)]> ALTER SYSTEM DELETE BACKUPSET 1,2,4 TENANT = mysql001;
     

ユーザーテナントが自身のテナントで指定されたデータバックアップセットをクリーンアップする

1. ユーザーテナントのテナント管理者がデータベースにログインします。

   説明

   MySQLテナントの管理者ユーザーはrootユーザー、Oracleテナントの管理者ユーザーはSYSユーザーです。

   接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。

   obclient -h10.xx.xx.xx -P2883 -uroot@mysql001#obdemo -p***** -A
   

2. クリーンアップ対象のバックアップセットの backup_set_id を取得します。

   MySQLモード

   Oracleモード

   MySQLモードでのクエリ例は以下のとおりです。

   obclient(root@mysql001)[(none)]> SELECT BACKUP_SET_ID, BACKUP_TYPE, PREV_FULL_BACKUP_SET_ID, PREV_INC_BACKUP_SET_ID, STATUS, FILE_STATUS, START_REPLAY_SCN, START_REPLAY_SCN_DISPLAY, MIN_RESTORE_SCN, MIN_RESTORE_SCN_DISPLAY, PATH FROM oceanbase.DBA_OB_BACKUP_SET_FILES;
   

   Oracleモードでのクエリ例は以下のとおりです：

   obclient(SYS@oracle001)[SYS]> SELECT BACKUP_SET_ID, BACKUP_TYPE, PREV_FULL_BACKUP_SET_ID, PREV_INC_BACKUP_SET_ID, STATUS, FILE_STATUS, START_REPLAY_SCN, START_REPLAY_SCN_DISPLAY, MIN_RESTORE_SCN, MIN_RESTORE_SCN_DISPLAY, PATH FROM SYS.DBA_OB_BACKUP_SET_FILES;
   

3. 以下のコマンドを実行して、指定されたデータバックアップを削除します。

   ステートメントは以下のとおりです：

   ALTER SYSTEM DELETE BACKUPSET backup_set_id[,backup_set_id,...];
   

   そのうち：

   • backup_set_id：削除対象のバックアップセットのIDを指定します。単一のコマンドで複数のデータバックアップセットを同時に指定できます。異なる backup_set_id 間は半角カンマで区切ります。複数の backup_set_id を指定してクリーンアップする場合、すべての backup_set_id が同一のバックアップパス下にある必要があります。同一コマンド内で複数のパス下のデータバックアップをクリーンアップすることはサポートされていません。

   • tenant_name：削除対象のバックアップセットのテナントを指定します。

   例：

   • テナント内の backup_set_id が3のデータバックアップセットを削除します。

     obclient> ALTER SYSTEM DELETE BACKUPSET 3;
     

   • テナント内の backup_set_id が1、2、4の3つのデータバックアップセットを同時に削除します。

     obclient> ALTER SYSTEM DELETE BACKUPSET 1,2,4;
     

指定されたログアーカイブPieceのクリーンアップ

注意事項

指定したログアーカイブPieceをクリーンアップする際には、以下の点に注意してください：

• ログアーカイブPieceは順序に従ってクリーンアップする必要があります。

• 現在のアーカイブパス内のPieceをクリーンアップする際、クリーンアップ対象のPieceが現在のデータバックアップパス内のいずれのデータバックアップにも依存していないことが必要です。

  クリーンアップ対象のPieceが特定のデータバックアップセットに依存しているかどうかを判断する方法は以下のとおりです：

  1. テナントの現在のバックアップパスから、比較的古い時期のデータバックアップセットを見つけます。

  2. そのデータバックアップセットの START_REPLAY_SCN を確認します。

     • システムテナント

       obclient(root@sys)[(none)]> SELECT * FROM oceanbase.CDB_OB_BACKUP_SET_FILES WHERE TENANT_ID = tenant_id AND BACKUP_SET_ID = set_id;
       

     • ユーザーテナント

       obclient(root@mysql001)[(none)]> SELECT * FROM oceanbase.DBA_OB_BACKUP_SET_FILES WHERE BACKUP_SET_ID = set_id;
       

       obclient(SYSt@oracl001)[SYS]> SELECT * FROM SYS.DBA_OB_BACKUP_SET_FILES WHERE BACKUP_SET_ID = set_id;
       

     詳細な操作手順と説明については、データバックアップ結果の確認を参照してください。

  3. クリーンアップ対象のPieceの END_SCN を確認します。

     • システムテナント

       obclient(root@sys)[(none)]> SELECT * FROM oceanbase.CDB_OB_ARCHIVELOG_PIECE_FILES WHERE TENANT_ID = tenant_id AND PIECE_ID = piece_id;
       

     • ユーザーテナント

       obclient(root@mysql001)[(none)]> SELECT * FROM oceanbase.DBA_OB_ARCHIVELOG_PIECE_FILES WHERE PIECE_ID = piece_id;
       

       obclient(SYSt@oracl001)[SYS]> SELECT * FROM SYS.DBA_OB_ARCHIVELOG_PIECE_FILES WHERE PIECE_ID = piece_id;
       

     詳細な操作手順と説明については、Piece情報の確認を参照してください。

  4. 取得した情報を比較し、クリーンアップ対象のPieceの END_SCN が現在のバックアップパス内のあるデータバックアップの START_REPLAY_SCN 以上である場合、そのPieceはそのデータバックアップセットに依存していることを意味します。

• 同時に複数の PIECE_ID を指定してクリーンアップする必要がある場合、すべての PIECE_ID が同じアーカイブパス下にある必要があります。同一コマンドで複数のパス下のログアーカイブPieceをクリーンアップすることはサポートされていません。

システムテナントが指定テナントの指定されたログアーカイブPieceをクリーンアップする

1. rootユーザーでクラスタのsysテナントにログインします。

   接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。

   obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
   

2. テナント情報を確認し、テナントのTENANT_IDを取得します。

   このドキュメントでは、テナントmysql001を例に説明します。クエリ例は以下のとおりです：

   obclient(root@sys)[(none)]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'mysql001';
   

   クエリ結果は次のとおりです：

   +-----------+-------------+-------------+
   | TENANT_ID | TENANT_NAME | TENANT_TYPE |
   +-----------+-------------+-------------+
   |      1002 | mysql001    | USER        |
   +-----------+-------------+-------------+
   1 row in set
   

   クエリ結果によると、このテナントのTENANT_IDは1002です。

3. クリーンアップ対象のログアーカイブPieceのpiece_idを取得します。

   obclient(root@sys)[(none)]> SELECT TENANT_ID, ROUND_ID, PIECE_ID, STATUS, FILE_STATUS, START_SCN, START_SCN_DISPLAY, END_SCN, END_SCN_DISPLAY, PATH FROM oceanbase.CDB_OB_ARCHIVELOG_PIECE_FILES WHERE TENANT_ID = 1002;
   

   クエリ結果は次のとおりです：

   +-----------+----------+----------+--------+-------------+---------------------+----------------------------+---------------------+----------------------------+----------------------------------+
   | TENANT_ID | ROUND_ID | PIECE_ID | STATUS | FILE_STATUS | START_SCN           | START_SCN_DISPLAY          | END_SCN             | END_SCN_DISPLAY            | PATH                             |
   +-----------+----------+----------+--------+-------------+---------------------+----------------------------+---------------------+----------------------------+----------------------------------+
   |      1002 |        1 |        1 | FROZEN | AVAILABLE   | 1757333158537074000 | 2025-09-08 20:05:58.537074 | 1757333218537074000 | 2025-09-08 20:06:58.537074 | file:///data/nfs/backup/archive1 |
   |      1002 |        1 |        2 | FROZEN | AVAILABLE   | 1757333218537074000 | 2025-09-08 20:06:58.537074 | 1757333278537074000 | 2025-09-08 20:07:58.537074 | file:///data/nfs/backup/archive1 |
   |      1002 |        1 |        3 | FROZEN | AVAILABLE   | 1757333278537074000 | 2025-09-08 20:07:58.537074 | 1757333338537074000 | 2025-09-08 20:08:58.537074 | file:///data/nfs/backup/archive1 |
   |      1002 |        1 |        4 | ACTIVE | AVAILABLE   | 1757333338537074000 | 2025-09-08 20:08:58.537074 | 1757333398537074000 | 2025-09-08 20:09:58.537074 | file:///data/nfs/backup/archive1 |
   |      1002 |        2 |        5 | FROZEN | AVAILABLE   | 1757333589335423000 | 2025-09-08 20:13:09.335423 | 1757333649335423000 | 2025-09-08 20:14:09.335423 | file:///data/nfs/backup/archive2 |
   |      1002 |        3 |        6 | FROZEN | AVAILABLE   | 1757333769705693000 | 2025-09-08 20:16:09.705693 | 1757333829705693000 | 2025-09-08 20:17:09.705693 | file:///data/nfs/backup/archive3 |
   |      1002 |        3 |        7 | FROZEN | AVAILABLE   | 1757333829705693000 | 2025-09-08 20:17:09.705693 | 1757333889705693000 | 2025-09-08 20:18:09.705693 | file:///data/nfs/backup/archive3 |
   |      1002 |        3 |        8 | ACTIVE | AVAILABLE   | 1757333889705693000 | 2025-09-08 20:18:09.705693 | 1757333949705693000 | 2025-09-08 20:19:09.705693 | file:///data/nfs/backup/archive3 |
   |      1002 |        3 |        9 | FROZEN | AVAILABLE   | 1757333949705693000 | 2025-09-08 20:19:09.705693 | 1757334009705693000 | 2025-09-08 20:20:09.705693 | file:///data/nfs/backup/archive3 |
   |      1002 |        3 |       10 | FROZEN | AVAILABLE   | 1757334009705693000 | 2025-09-08 20:20:09.705693 | 1757334069705693000 | 2025-09-08 20:21:09.705693 | file:///data/nfs/backup/archive3 |
   +-----------+----------+----------+--------+-------------+---------------------+----------------------------+---------------------+----------------------------+----------------------------------+
   10 rows set
   

   クエリ結果から、テナントIDが1002のテナントには10個のログアーカイブPieceがあることがわかります。そのうち：

   • PIECE_IDが1、2、3、4のログアーカイブPieceは、同じアーカイブパスfile:///data/nfs/backup/archive1に由来します。
   • PIECE_IDが5のログアーカイブPieceは、アーカイブパスfile:///data/nfs/backup/archive2に由来します。
   • PIECE_IDが6、7、8、9、10のログアーカイブPieceは、アーカイブパスfile:///data/nfs/backup/archive3に由来します。

   クリーンアップ要件に基づき：

   • Pieceは順序通りにクリーンアップする必要があります。例えば、PIECE_IDが2、3、4のいずれか1つまたは複数のPieceを先にクリーンアップしてから、PIECE_IDが1のPieceをクリーンアップすることはできません。同様に、PIECE_IDが7、8、9、10のいずれか1つまたは複数のPieceを先にクリーンアップしてから、PIECE_IDが6のPieceをクリーンアップすることもできません。

     複数のPieceを順序通りに同時にクリーンアップすることは可能です。例えば、1、2、3を同時にクリーンアップできます。

   • 複数のPIECE_IDを指定する場合、すべてのPIECE_IDが同じアーカイブパス下にある必要があります。例えば、PIECE_IDが1、2、5または5、6、7のPieceを同時にクリーンアップすることはできません。

4. 以下のコマンドを実行して、指定されたログアーカイブPieceを削除します。

   ステートメントは以下のとおりです：

   ALTER SYSTEM DELETE ARCHIVELOG_PIECE piece_id[,piece_id,...] TENANT [=] tenant_name;
   

   このうち：

   • piece_id：削除対象のログアーカイブPieceのIDを指定します。単一のコマンドで複数のPieceを同時に指定することができます。複数のpiece_idを指定してクリーンアップする場合、すべてのpiece_idが同じバックアップパス下にある必要があります。同一コマンド内で複数のパス下のログアーカイブPieceをクリーンアップすることはサポートされていません。

   • tenant_name：削除対象のログアーカイブPieceのテナントを指定します。

   例：

   • テナントmysql001のpiece_idが5のログアーカイブPieceを削除します。

     obclient(root@sys)[(none)]> ALTER SYSTEM DELETE ARCHIVELOG_PIECE 5 TENANT = mysql001;
     

   • テナントmysql001のpiece_idが6、7、8、9の4つのログアーカイブPieceを同時に削除します。

     obclient(root@sys)[(none)]> ALTER SYSTEM DELETE ARCHIVELOG_PIECE 6,7,8,9 TENANT = mysql001;
     

ユーザーテナントが自身のテナントで指定されたログアーカイブPieceをクリーンアップする

1. ユーザーテナントのテナント管理者がデータベースにログインします。

   説明

   MySQLテナントの管理者ユーザーはrootユーザー、Oracleテナントの管理者ユーザーはSYSユーザーです。

   接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。

   obclient -h10.xx.xx.xx -P2883 -uroot@mysql001#obdemo -p***** -A
   

2. クリーンアップ対象のログアーカイブPieceのpiece_idを取得します。

   MySQLモード

   Oracleモード

   MySQLモードでのクエリ例は以下のとおりです：

   obclient(root@mysql001)[(none)]> SELECT ROUND_ID, PIECE_ID, STATUS, FILE_STATUS, START_SCN, START_SCN_DISPLAY, END_SCN, END_SCN_DISPLAY, PATH FROM oceanbase.DBA_OB_ARCHIVELOG_PIECE_FILES;
   

   Oracleモードでのクエリ例は以下のとおりです。

   obclient(SYS@oracle001)[SYS]> SELECT ROUND_ID, PIECE_ID, STATUS, FILE_STATUS, START_SCN, START_SCN_DISPLAY, END_SCN, END_SCN_DISPLAY, PATH FROM SYS.DBA_OB_ARCHIVELOG_PIECE_FILES;
   

3. 以下のコマンドを実行して、指定されたログアーカイブPieceを削除します。

   ステートメントは以下のとおりです：

   ALTER SYSTEM DELETE ARCHIVELOG_PIECE piece_id[,piece_id,...];
   

   そのうち：

   • piece_id：削除対象のログアーカイブPieceのIDを指定します。単一のコマンドで複数のPieceを同時に指定できます。複数のpiece_idを指定してクリーンアップする場合、すべてのpiece_idが同一のバックアップパス下にある必要があります。同一コマンド内で複数のパス下のログアーカイブPieceをクリーンアップすることはサポートされていません。

   • tenant_name：削除対象のログアーカイブPieceのテナントを指定します。

   例：

   • テナント内のpiece_idが5のログアーカイブPieceを削除します。

     obclient> ALTER SYSTEM DELETE ARCHIVELOG_PIECE 5;
     

   • テナント内のpiece_idが6、7、8、9の4つのログアーカイブPieceを同時に削除します。

     obclient> ALTER SYSTEM DELETE ARCHIVELOG_PIECE 6,7,8,9;
     

関連ドキュメント

• バックアップクリーンアップの進捗状況を確認する

• バックアップクリーンアップの結果を確認する

• クリーンアップタスクをキャンセルする