OceanBase logo

OceanBase

A unified distributed database ready for your transactional, analytical, and AI workloads.

Product Overview
DEPLOY YOUR WAY

OceanBase Cloud

The best way to deploy and scale OceanBase

OceanBase Enterprise

Run and manage OceanBase on your infra

TRY OPEN SOURCE

OceanBase Community Edition

The free, open-source distributed database

OceanBase seekdb

Open source AI native search database

Customer Stories

Real-world success stories from enterprises across diverse industries.

View All
BY USE CASES

Mission-Critical Transactions

Global & Multicloud Application

Elastic Scaling for Peak Traffic

Real-time Analytics

Active Geo-redundancy

Database Consolidation

Resources

Comprehensive knowledge hub for OceanBase.

Blog

Live Demos

Training & Certification

Documentation

Official technical guides, tutorials, API references, and manuals for all OceanBase products.

View All
PRODUCTS

OceanBase Cloud

OceanBase Database

Tools

Connectors and Middleware

QUICK START

OceanBase Cloud

OceanBase Database

BEST PRACTICES

Practical guides for utilizing OceanBase more effectively and conveniently

Company

Learn more about OceanBase – our company, partnerships, and trust and security initiatives.

About OceanBase

Partner

Trust Center

Contact Us

International - English
中国站 - 简体中文
日本 - 日本語
Sign In
Start on Cloud

OceanBase

A unified distributed database ready for your transactional, analytical, and AI workloads.

Product Overview
DEPLOY YOUR WAY

OceanBase Cloud

The best way to deploy and scale OceanBase

OceanBase Enterprise

Run and manage OceanBase on your infra

TRY OPEN SOURCE

OceanBase Community Edition

The free, open-source distributed database

OceanBase seekdb

Open source AI native search database

Customer Stories

Real-world success stories from enterprises across diverse industries.

View All
BY USE CASES

Mission-Critical Transactions

Global & Multicloud Application

Elastic Scaling for Peak Traffic

Real-time Analytics

Active Geo-redundancy

Database Consolidation

Comprehensive knowledge hub for OceanBase.

Blog

Live Demos

Training & Certification

Documentation

Official technical guides, tutorials, API references, and manuals for all OceanBase products.

View All
PRODUCTS
OceanBase CloudOceanBase Database
ToolsConnectors and Middleware
QUICK START
OceanBase CloudOceanBase Database
BEST PRACTICES

Practical guides for utilizing OceanBase more effectively and conveniently

Learn more about OceanBase – our company, partnerships, and trust and security initiatives.

About OceanBase

Partner

Trust Center

Contact Us

Start on Cloud
编组
All Products
    • Databases
    • iconOceanBase Database
    • iconOceanBase Cloud
    • iconOceanBase Tugraph
    • iconInteractive Tutorials
    • iconOceanBase Best Practices
    • Tools
    • iconOceanBase Cloud Platform
    • iconOceanBase Migration Service
    • iconOceanBase Developer Center
    • iconOceanBase Migration Assessment
    • iconOceanBase Admin Tool
    • iconOceanBase Loader and Dumper
    • iconOceanBase Deployer
    • iconKubernetes operator for OceanBase
    • iconOceanBase Diagnostic Tool
    • iconOceanBase Binlog Service
    • Connectors and Middleware
    • iconOceanBase Database Proxy
    • iconEmbedded SQL in C for OceanBase
    • iconOceanBase Call Interface
    • iconOceanBase Connector/C
    • iconOceanBase Connector/J
    • iconOceanBase Connector/ODBC
    • iconOceanBase Connector/NET
icon

OceanBase Database

SQL - V4.6.0

    Download PDF

    OceanBase logo

    The Unified Distributed Database for the AI Era.

    Follow Us
    Products
    OceanBase CloudOceanBase EnterpriseOceanBase Community EditionOceanBase seekdb
    Resources
    DocsBlogWhite PaperLive DemosTraining & CertificationTicket
    Company
    About OceanBaseTrust CenterLegalPartnerContact Us
    Follow Us

    © OceanBase 2026. All rights reserved

    Cloud Service AgreementPrivacy PolicySecurity
    Contact Us
    Document Feedback
    1. Documentation Center
    2. OceanBase Database
    3. SQL
    4. V4.6.0
    iconOceanBase Database
    SQL - V 4.6.0
    Databases
    • OceanBase Database
    • OceanBase Cloud
    • OceanBase Tugraph
    • Interactive Tutorials
    • OceanBase Best Practices
    Tools
    • OceanBase Cloud Platform
    • OceanBase Migration Service
    • OceanBase Developer Center
    • OceanBase Migration Assessment
    • OceanBase Admin Tool
    • OceanBase Loader and Dumper
    • OceanBase Deployer
    • Kubernetes operator for OceanBase
    • OceanBase Diagnostic Tool
    • OceanBase Binlog Service
    Connectors and Middleware
    • OceanBase Database Proxy
    • Embedded SQL in C for OceanBase
    • OceanBase Call Interface
    • OceanBase Connector/C
    • OceanBase Connector/J
    • OceanBase Connector/ODBC
    • OceanBase Connector/NET
    SQL
    KV
    • V 4.6.0
    • V 4.4.2
    • V 4.3.5
    • V 4.3.3
    • V 4.3.1
    • V 4.3.0
    • V 4.2.5
    • V 4.2.2
    • V 4.2.1
    • V 4.2.0
    • V 4.1.0
    • V 4.0.0
    • V 3.1.4 and earlier

    Validate a backup set or log archive piece in a specified path

    Last Updated:2026-06-17 06:18:59  Updated
    Share
    What is on this page
    Limitations and considerations
    Validate a backup set at a specified path
    Validate a backup set in the specified path of a user tenant
    Validate a backup set in the specified path of the current tenant
    Validate the log archive piece in a specified path
    Validate the log archive piece in a specified path of a user tenant from the sys tenant
    Validate the log archive piece in a specified path of a user tenant from the user tenant
    References

    folded

    Share

    OceanBase Database allows you to validate a backup set or log archive piece in a specified path. This method is suitable for validating cross-cluster backups or cold backups.

    Limitations and considerations

    • Since verification tasks frequently access backup media to read data, which may interfere with backup tasks, it is recommended to execute verification tasks when no backup tasks are running and the system is under low load.

    • When specifying the verification level for backup verification:

      • For backup sets and log archive pieces from versions earlier than V4.6.0 (excluding V4.4.2 but including V4.4.2 BP2), Basic verification is not supported, which means file integrity verification is not supported.

      • For backup sets from versions earlier than V4.3.4, Physical verification is not supported, which means physical data correctness and logical consistency verification are not supported.

    • If the specified backup set for verification includes an incremental backup set, under the Physical verification level, the specified path must contain the full backup set that the incremental backup set depends on. Otherwise, the verification will fail.

    Validate a backup set at a specified path

    Validate a backup set in the specified path of a user tenant

    1. Log in to the sys tenant of the cluster as the root user.

      The following example shows how to connect to the database. Please replace the actual environment variables with the correct values.

      obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
      
    2. Execute the following command to validate the backup set in the specified path of a user tenant.

      The statement is as follows:

      ALTER SYSTEM VALIDATE BACKUPSET [= 'backup_set_id[,backup_set_id,...]'] DATA_BACKUP_DEST = 'data_backup_path' [LEVEL = { 'basic' | 'physical' }] TENANT = tenant_name;
      

      The parameters in the statement are described as follows:

      • BACKUPSET: specifies the backup set to be validated. You can validate all backup sets in the backup path specified by the user tenant or a specified list of backup sets. If you specify a list of backup sets, separate the backup_set_id values of the backup sets with commas (,). If you do not specify the backup_set_id value, all backup sets in the backup path specified by the user tenant are validated by default.

        In cross-cluster or cold backup scenarios, you can obtain the backup_set_id value of a backup set from the file name in the backup directory. For more information about the backup directory structure, see Data backup directory in Overview of physical backup and restore.

        Notice

        If you do not specify backup_set_id, the system will validate all backup sets in the current backup path, which will generate a large number of validation tasks and take a long time. If you do not need to validate all backup sets, we recommend that you specify backup_set_id in the validation command.

      • DATA_BACKUP_DEST: specifies the path where the backup set is stored.

        Notice

        OceanBase Database does not support specifying multiple paths in a single command. Therefore, when you specify backup_set_id to validate an incremental backup set, an error may occur because the incremental backup set depends on other backup sets. The error code is 9159.

      • LEVEL: an optional parameter that specifies the validation level. The default value is physical. The options are as follows:

        • basic: validates only the integrity of the file list.

        • physical: validates the correctness and logical consistency of the physical data.

      • TENANT: specifies the user tenant to execute the validation task.

      Here are some examples:

      • The sys tenant validates all backup sets in the specified backup path of the mysqltenant user tenant in Basic mode.

        obclient(root@sys)[(none)]> ALTER SYSTEM VALIDATE BACKUPSET DATA_BACKUP_DEST = 'file:///data/nfs/backup/data' LEVEL = 'basic' TENANT = mysqltenant;
        
      • The sys tenant validates the backup sets with backup_set_id values of 1 and 2 in the specified backup path of the mysqltenant user tenant in Physical mode.

        obclient(root@sys)[(none)]> ALTER SYSTEM VALIDATE BACKUPSET = '1,2' DATA_BACKUP_DEST = 'file:///data/nfs/backup/data' LEVEL = 'physical' TENANT = mysqltenant;
        
    3. After the statement is successfully executed, you can view the status, progress, and execution result of the validation task by querying the CDB_OB_BACKUP_VALIDATE_JOBS, CDB_OB_BACKUP_VALIDATE_TASKS, CDB_OB_BACKUP_VALIDATE_JOB_HISTORY, and CDB_OB_BACKUP_VALIDATE_TASK_HISTORY views.

      For more information about how to view the backup validation progress, see View the backup validation progress.

      For more information about how to view the backup validation result, see View the backup validation result.

    Validate a backup set in the specified path of the current tenant

    1. Log in to the database as the tenant administrator of the user tenant.

      Note

      The administrator user of a MySQL tenant is root, and the administrator user of an Oracle tenant is SYS.

      The following example shows how to connect to the database. Please replace the parameters with those in your actual environment.

      obclient -h10.xx.xx.xx -P2883 -uroot@mysql001#obdemo -p***** -A
      
    2. Execute the following statement to validate the backup set in the specified path.

      The statement is as follows:

      ALTER SYSTEM VALIDATE BACKUPSET [= 'backup_set_id[,backup_set_id,...]'] DATA_BACKUP_DEST = 'data_backup_path' [LEVEL = { 'basic' | 'physical' }];
      

      The parameters in the statement are described as follows:

      • BACKUPSET: specifies the backup set to be validated. You can validate all backup sets in the specified backup path of the tenant or a specified list of backup sets. If you specify a list of backup sets, separate the backup_set_id values of the backup sets with commas. If you do not specify the backup_set_id value, all backup sets in the specified backup path of the tenant are validated by default.

        In a cross-cluster or cold backup scenario, you can obtain the backup_set_id value of a backup set from the filename in the backup directory. For more information about the backup directory structure, see Data backup directory in Overview of physical backup and restore.

        Notice

        If you do not specify backup_set_id, the system will validate all backup sets in the current backup path, which will generate a large number of validation tasks and take a long time. If you do not need to validate all backup sets, we recommend that you specify backup_set_id in the validation command.

      • DATA_BACKUP_DEST: specifies the storage path of the backup set.

        Notice

        OceanBase Database does not support specifying multiple paths in a single statement. Therefore, when you specify backup_set_id to validate an incremental backup set in the specified path, an error may occur because the incremental backup set depends on other backup sets. The error code is 9159.

      • LEVEL: an optional parameter that specifies the validation level. If you do not specify this parameter, the default value is physical. The parameter can take the following values:

        • basic: validates only the completeness of the file list.

        • physical: validates the correctness and logical consistency of the physical data.

      Here are some examples:

      • Validate all backup sets in the specified backup path of the current tenant by using the basic validation level.

        obclient> ALTER SYSTEM VALIDATE BACKUPSET DATA_BACKUP_DEST = 'file:///data/nfs/backup/data' LEVEL = 'basic';
        
      • Validate the backup sets with backup_set_id values of 1 and 2 in the specified backup path of the current tenant by using the physical validation level.

        obclient> ALTER SYSTEM VALIDATE BACKUPSET = '1,2' DATA_BACKUP_DEST = 'file:///data/nfs/backup/data' LEVEL = 'physical';
        
    3. After the statement is successfully executed, you can query the DBA_OB_BACKUP_VALIDATE_JOBS, DBA_OB_BACKUP_VALIDATE_TASKS, DBA_OB_BACKUP_VALIDATE_JOB_HISTORY, and DBA_OB_BACKUP_VALIDATE_TASK_HISTORY views to view the status, progress, and execution result of the validation task.

      For more information about how to view the validation progress, see View the backup validation process.

      For more information about how to view the validation result, see View the backup validation history.

    Validate the log archive piece in a specified path

    Validate the log archive piece in a specified path of a user tenant from the sys tenant

    1. Log in to the sys tenant of the cluster as the root user.

      The following example shows how to connect to the database. Replace the actual environment variables.

      obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
      
    2. Execute the following command to validate the log archive piece in the specified path of the user tenant.

      The statement is as follows:

      ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE [= 'piece_id[,piece_id,...]'] LOG_ARCHIVE_DEST = 'log_archive_path' [LEVEL = { 'basic' | 'physical' }] TENANT = tenant_name;
      

      The parameters in the statement are described as follows:

      • ARCHIVELOG_PIECE: specifies the log archive piece to be validated. You can specify the log archive piece in the specified archive path of the tenant or the specified list of log archive pieces. If you specify the list of log archive pieces, separate the piece_id values with commas. If you do not specify piece_id, the system validates all log archive pieces in the archive path specified by the tenant.

        In a cross-cluster or cold backup scenario, you can obtain the piece_id of the log archive piece from the file name in the archive directory. For more information about the archive directory structure, see Log archive directory in Overview of physical backup and restore.

        Notice

        If you do not specify piece_id, the system validates all log archive pieces in the specified archive path, which generates a large number of validation tasks and takes a long time. If you do not need to validate all log archive pieces, we recommend that you specify piece_id in the validation command.

      • LOG_ARCHIVE_DEST: specifies the path where the log archive piece is stored.

      • LEVEL: an optional parameter that specifies the validation level. If you do not specify this parameter, the default value is physical. The following table describes the validation levels.

        • basic validation: only checks the integrity of the file list.

        • physical validation: checks the correctness and logical consistency of the physical data.

      • TENANT: specifies the user tenant to be validated.

      Here are some examples:

      • Validate all log archive pieces in the specified archive path of the sys tenant in basic mode.

        obclient(root@sys)[(none)]> ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE LOG_ARCHIVE_DEST = 'file:///data/nfs/backup/archive' LEVEL = 'basic' TENANT = tenant1;
        
      • Validate the log archive pieces with piece_id values of 1 and 2 in the specified archive path of the sys tenant in physical mode.

        obclient(root@sys)[(none)]> ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE = '1,2' LOG_ARCHIVE_DEST = 'file:///data/nfs/backup/archive' LEVEL = 'physical' TENANT = tenant1;
        
    3. After the statement is successfully executed, you can query the status, progress, and execution result of the validation task from the CDB_OB_BACKUP_VALIDATE_JOBS, CDB_OB_BACKUP_VALIDATE_TASKS, CDB_OB_BACKUP_VALIDATE_JOB_HISTORY, and CDB_OB_BACKUP_VALIDATE_TASK_HISTORY views.

      For more information about how to view the backup validation progress, see View the backup validation progress.

      For more information about how to view the backup validation result, see View the backup validation result.

    Validate the log archive piece in a specified path of a user tenant from the user tenant

    1. Log in to the database as the administrator of the user tenant.

      Note

      The administrator of a MySQL tenant is the root user. The administrator of an Oracle tenant is the SYS user.

      The following example shows how to connect to the database. Replace the actual environment variables.

      obclient -h10.xx.xx.xx -P2883 -uroot@mysql001#obdemo -p***** -A
      
    2. Execute the following command to validate the log archive piece in the specified path of the user tenant.

      The statement is as follows:

      ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE [= 'piece_id[,piece_id,...]'] LOG_ARCHIVE_DEST = 'log_archive_path' [LEVEL = { 'basic' | 'physical' }];
      

      The parameters in the statement are described as follows:

      • ARCHIVELOG_PIECE: specifies the log archive piece to be validated. You can specify the log archive piece in the current archive path of the tenant or the specified list of log archive pieces. If you specify the list of log archive pieces, separate the piece_id values with commas. If you do not specify piece_id, the system validates all log archive pieces in the current archive path of the tenant.

        In a cross-cluster or cold backup scenario, you can obtain the piece_id of the log archive piece from the file name in the archive directory. For more information about the archive directory structure, see Log archive directory in Overview of physical backup and restore.

        Notice

        If you do not specify piece_id, the system validates all log archive pieces in the specified archive path, which generates a large number of validation tasks and takes a long time. If you do not need to validate all log archive pieces, we recommend that you specify piece_id in the validation command.

      • LOG_ARCHIVE_DEST: specifies the path where the log archive piece is stored.

      • LEVEL: an optional parameter that specifies the validation level. If you do not specify this parameter, the default value is physical. The following table describes the validation levels.

        • basic validation: only checks the integrity of the file list.

        • physical validation: checks the correctness and logical consistency of the physical data.

      Here are some examples:

      • Validate all log archive pieces in the specified archive path of the user tenant in basic mode.

        obclient> ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE LOG_ARCHIVE_DEST = 'file:///data/nfs/backup/archive' LEVEL = 'basic';
        
      • Validate the log archive pieces with piece_id values of 1 and 2 in the specified archive path of the user tenant in physical mode.

        obclient> ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE = '1,2' LOG_ARCHIVE_DEST = 'file:///data/nfs/backup/archive' LEVEL = 'physical';
        
    3. After the statement is successfully executed, you can query the status, progress, and execution result of the validation task from the DBA_OB_BACKUP_VALIDATE_JOBS, DBA_OB_BACKUP_VALIDATE_TASKS, DBA_OB_BACKUP_VALIDATE_JOB_HISTORY, and DBA_OB_BACKUP_VALIDATE_TASK_HISTORY views.

      For more information about how to view the backup validation progress, see View the backup validation progress.

      For more information about how to view the backup validation result, see View the backup validation result.

    References

    • Cancel Backup Validation

    • View Backup Validation Progress

    • View Backup Validation History

    • Validate the Data Backup Destination and Log Archive Destination

    • Validate a Specific Backup Set or Log Archive Piece

    Previous topic

    Validate a specified backup set or log archive piece
    Last

    Next topic

    Cancel a backup validation task
    Next
    What is on this page
    Limitations and considerations
    Validate a backup set at a specified path
    Validate a backup set in the specified path of a user tenant
    Validate a backup set in the specified path of the current tenant
    Validate the log archive piece in a specified path
    Validate the log archive piece in a specified path of a user tenant from the sys tenant
    Validate the log archive piece in a specified path of a user tenant from the user tenant
    References