指定したバックアップまたはアーカイブデータの手動クリーンアップ|V4.4.2|OceanBaseデータベース|OceanBaseデータベースドキュメント|分散データベース

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

使用上の制限

指定したバックアップまたはアーカイブデータを手動でクリーンアップする場合、操作対象となるユーザーテナントに自動クリーンアップポリシーが設定されている必要があります。設定されていない場合は、クリーンアップを実行できません。
ログアーカイブのみを有効にし、データバックアップパスを設定していない場合、指定したログアーカイブピースを手動でクリーンアップすることはできません。ユーザーは自動クリーンアップポリシーを log_only に設定することでのみ、ログアーカイブピースのクリーンアップを実現できます。

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

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

注意事項

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

データバックアップ間の依存関係を破壊してはなりません。あるデータバックアップが関連する増分バックアップに依存している場合、その依存されているデータバックアップは、それに依存するすべての増分バックアップが削除された後でなければ削除できません。
クリーンアップで複数の BACKUP_SET_ID を同時に指定する必要がある場合、すべての BACKUP_SET_ID が同一のバックアップパス下にある必要があります。同一コマンド内で複数のパス下のデータバックアップをクリーンアップすることはサポートされていません。
現在使用中のバックアップパスについては、復元に使用可能な最新のフルデータバックアップを少なくとも1セット保持する必要があります。つまり、復元用のフルバックアップを1セット保持した上で、そのバックアップセットより前の他のバックアップセットを削除できます。
削除対象のデータバックアップセットが現在使用中のバックアップパスにない場合、OceanBaseデータベースが該当バックアップパスへのアクセス権限を持っていることを確認する必要があります。

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

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

接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。
```
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
```

テナント情報を確認し、テナントの 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です。

クリーンアップ対象のバックアップセットの 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 パラメータを指定しなかった場合）、現在のアーカイブパス下のログアーカイブピースを確認し、そのバックアップセットの START_REPLAY_SCN から MIN_RESTORE_SCN までの完全で連続したログアーカイブピースが存在することを確認する必要があります。条件を満たすログアーカイブピースが存在しない場合、BACKUP_SET_ID 6は復元に使用できません。同じ方法で直前のフルバックアップ BACKUP_SET_ID 5が復元に使用可能かどうかを確認し、これを繰り返します。

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

ステートメントは以下のとおりです：
```
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;
```

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

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

説明

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

接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。
```
obclient -h10.xx.xx.xx -P2883 -uroot@mysql001#obdemo -p***** -A
```

クリーンアップ対象のバックアップセットの 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;

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

ステートメントは以下のとおりです：
```
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;
```

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

注意点

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

ログアーカイブピースは順序に従ってクリーンアップする必要があります。
現在のアーカイブパス内のピースをクリーンアップする際、クリーンアップ対象のピースが現在のデータバックアップパス内のいずれのデータバックアップにも依存していないことが必要です。

クリーンアップ対象のピースが特定のデータバックアップセットに依存しているかどうかを判断する方法は以下のとおりです：
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. クリーンアップ対象のピースの 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;
```
  詳細な操作手順と説明については、ピース情報の確認を参照してください。
4. 取得した情報を比較し、クリーンアップ対象のピースの END_SCN が現在のバックアップパス内のあるデータバックアップの START_REPLAY_SCN 以上である場合、そのピースはそのデータバックアップセットに依存していることを意味します。
同時に複数の PIECE_ID を指定してクリーンアップする必要がある場合、すべての PIECE_ID が同じアーカイブパス下にある必要があります。同一コマンドで複数のパス下のログアーカイブピースをクリーンアップすることはサポートされていません。

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

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

接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。
```
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
```

テナント情報を確認し、テナントの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です。

クリーンアップ対象のログアーカイブピースの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_IDが1、2、3、4のログアーカイブピースは、同じアーカイブパスfile:///data/nfs/backup/archive1から来ています。
PIECE_IDが5のログアーカイブピースは、アーカイブパスfile:///data/nfs/backup/archive2から来ています。
PIECE_IDが6、7、8、9、10のログアーカイブピースは、アーカイブパスfile:///data/nfs/backup/archive3から来ています。

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

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

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

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

ステートメントは以下のとおりです：
```
ALTER SYSTEM DELETE ARCHIVELOG_PIECE piece_id[,piece_id,...] TENANT [=] tenant_name;
```
ここで：
- piece_id：削除対象のログアーカイブピースのIDを指定します。単一のコマンドで複数のピースを同時に指定することができます。複数のpiece_idを指定してクリーンアップする場合、すべてのpiece_idが同じバックアップパス下にある必要があります。同一コマンド内で複数のパス下のログアーカイブピースをクリーンアップすることはサポートされていません。
- tenant_name：削除対象のログアーカイブピースのテナントを指定します。
例：
- テナントmysql001のpiece_idが5のログアーカイブピースを削除します。
```
obclient(root@sys)[(none)]> ALTER SYSTEM DELETE ARCHIVELOG_PIECE 5 TENANT = mysql001;
```
- テナントmysql001のpiece_idが6、7、8、9の4つのログアーカイブピースを同時に削除します。
```
obclient(root@sys)[(none)]> ALTER SYSTEM DELETE ARCHIVELOG_PIECE 6,7,8,9 TENANT = mysql001;
```

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

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

説明

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

接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。
```
obclient -h10.xx.xx.xx -P2883 -uroot@mysql001#obdemo -p***** -A
```

クリーンアップ対象のログアーカイブピースの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;

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

ステートメントは以下のとおりです：
```
ALTER SYSTEM DELETE ARCHIVELOG_PIECE piece_id[,piece_id,...];
```
ここで：
- piece_id：削除対象のログアーカイブピースのIDを指定します。単一のコマンドで複数のピースを同時に指定できます。複数のpiece_idを指定してクリーンアップする場合、すべてのpiece_idが同一のバックアップパス下にある必要があります。同一コマンド内で複数のパス下のログアーカイブピースをクリーンアップすることはサポートされていません。
- tenant_name：削除対象のログアーカイブピースのテナントを指定します。
例：
- テナント内のpiece_idが5のログアーカイブピースを削除します。
```
obclient> ALTER SYSTEM DELETE ARCHIVELOG_PIECE 5;
```
- テナント内のpiece_idが6、7、8、9の4つのログアーカイブピースを同時に削除します。
```
obclient> ALTER SYSTEM DELETE ARCHIVELOG_PIECE 6,7,8,9;
```

OceanBase

顧客事例

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

使用上の制限

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

注意事項

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

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

説明

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

注意点

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

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

説明

関連ドキュメント