cubrid scripts

unloaddb.sh script

To shorten the execution time of unloaddb of a large size database, it is possible to run cubrid unloaddb processes concurrently over groups of different tables. unloaddb.sh is a shell script that automates this process.

To evenly distribute unloaddb load over multiple child processes, the unloadb.sh gets the size information of the tables to be unloaded from the system catalog (this requires dba privileges).

Tables to be unloaded are allocated to each child process based on the table size, and each child process simultaneously unloads the allocated tables.

Warning

restrictions:

  • Require Linux Environments

  • Only users with DBA privileges can run this script

The following is [options] used in unloaddb.sh.

-u user

Specify a user account of a database to be unloaded. If this is not specified, the default is DBA (The user must have DBA privileges).

sh unloaddb.sh -u dba demodb
-t no-process

Number of child processes to run concurrently (default: 8, maximum 16)

sh unloaddb.sh -t 4 demodb
-i input-class-file

Unload schemas, indexes and data of specified tables in the file. (default: all tables in the database)

sh unloaddb.sh -i table_list.txt demodb

The following example shows an input file (table_list.txt).

public.table_1
public.table_2
..
public.table_n
-D output-directory

Specifies the directory in which to create schema and object files. If it is not specified, files are created in the current directory.

sh unloaddb.sh -D /tmp demodb
-s

Specifies only the schema file will be created (schema only).

sh unloaddb.sh -s demodb
-d

Specifies only the data file will be created (data only).

sh unloaddb.sh -d demodb
-v

Verbose mode. Show additional information during process (for example size of tables) (verbose mode).

sh unloaddb.sh -v demodb

Files/Directory created by unloaddb.sh

  • single schema file for all tables unloaded: {database name}_schema

  • object files (as many as the number of child processes, suffix starts from 0)

    • {database name}_0_objects, {database name}_1_objects, …, {database name}_n-1_objects

  • LOG files / Directory:

    • {database name}_unloaddb.log will be created.

    • Various log-files will be created here.

    unloaddb.sh example

    sh unloaddb.sh -t 4 demodb

    Files/Directory created by the result of this command:

    * demodb_schema: schema file for all tables unloaded
* demodb_0_objects: object files unloaded by the 1st child process
* demodb_1_objects: object files unloaded by the 2nd child process
* demodb_2_objects: object files unloaded by the 3rd child process
* demodb_3_objects: object files unloaded by the 4th child process
* demodb_unloaddb.log/demodb_0.files: table names unloaded by 1st child process
* demodb_unloaddb.log/demodb_0.pid: process id of 1st child process
* demodb_unloaddb.log/demodb_0_unloaddb.log: 'cubrid unloaddb' log of the 1st child process
* demodb_unloaddb.log/demodb_0.status: execution result of the 1st child process (success/fail)

Note

  • If the interrupt key (CTRL-C) is pressed before termination of unloaddb.sh, all in-progress unloaddb object files will be deleted (object files that unload completed will not be deleted).

restore_to_newdb.sh script

When data recovery is required due to user errors or system failures, the recovery process typically involves restoring a backup to the production server. This often requires additional steps such as creating new user accounts or installing database engines, making the process cumbersome.

The restore_to_newdb.sh script allows you to restore a backup and create a new database instance under a new database name without any additional setup, using the existing CUBRID environment.

Warning

Restrictions:

  • Only available on Linux environments.

  • The backup files for the target database must exist.

  • The new database name must differ from the original database name.

  • The new database name must not already be registered in $CUBRID/databases.txt.

Basic Usage

sh restore_to_new.sh [options] backuped-database-name new-database-name

  • restore_to_new.sh : A script that restores a backup and creates a new DBMS instance.

  • backup-database-name : Name of the backed-up database to be restored.

  • new-database-name : Name of the newly created database after restoration.

[Options] for restore_to_new.sh

-F path

Specifies the absolute path for the new database. If not specified, the current path is used by default.

sh restore_to_newdb.sh -F /home/cubrid/newdbpath backuped-database-name new-database-name
-B path

Specifies the absolute path where the backup files are located. If not specified, the current path is used by default.

sh restore_to_newdb.sh -B /home/cubrid/backupdbpath backuped-database-name new-database-name
-d date

Restores the database up to a specific point in time. The format must be dd-mm-yyyy:hh:mi:ss (e.g., 14-10-2008:14:10:00).

This option works the same as the -d option in cubrid restoredb.

sh restore_to_newdb.sh backuped-database-name new-database-name -F /home/cubrid -B /home/cubrid/DB/backupdbpath -d 30-10-2025:12:20:00
-l level

Specifies the backup level (0, 1, or 2) to restore from. This option function the same as the -l option in cubrid restoredb.

sh restore_to_newdb.sh -B /home/cubrid/DB/backupdbpath -l 1 backuped-database-name new-database-name
-p

Performs a partial restore when log archives are unavailable. Refer to the -p option in cubrid restoredb for more details.

sh restore_to_newdb.sh -B /home/cubrid/DB/backupdbpath -p backuped-database-name new-database-name
-k path

Specifies the path of the key file required for restoration. Refer to the -k option in cubrid restoredb for more details.

sh restore_to_newdb.sh -B /home/cubrid/DB/backupdbpath -k /home/cubdev/DB/backupdbpath/backupdb_bk1_keys backuped-database-name new-database-name

Example of Running restore_to_newdb.sh

sh restore_to_newdb.sh -B /home/cubrid/DB/backupdbpath backuped-database-name new-database-name

Validation passed: newdb_path and vol-path are different.
Validation passed: 'new-database-name' does not exist in /home/cubrid/CUBRID-11.4-Linux.x86_64/databases/databases.txt.

Confirmed: Files found for pattern (/home/cubrid/DB/backupdbpath/backuped-database-name_bk0v*).
file: /home/cubrid/DB/backupdbpath/backuped-database-name_bk0v*
Warning: /home/cubrid/CUBRID-11.4-Linux.x86_64/databases/databases.txt already exists.
Existing databases.txt backed up as databases.txt.bak.
Restoring... /

CUBRID 11.4

Restoring... |Updated CUBRID-11.4-Linux.x86_64/databases/databases.txt
successfully.
database restoration completed successfully.

Once the database is successfully restored, start the new DBMS as follows:

[cubrid ~]$ cubrid server start new-database-name
@ cubrid server start: new-database-name

This may take a long time depending on the amount of recovery works to do.

CUBRID 11.4

++ cubrid server start: success
Calling java stored procedure is allowed

Note

  • Since the recovery process using this script modifies $CUBRID_DATABASES, it is recommended to verify that the newly created database has been properly registered after the script finishes

  • It is recommended to delete recovered DBMS instances that are no longer in use using the deletedb command.

Checking the Log File After Running restore_to_newdb.sh

After the restoration, a log file named restoredb_YYYYMMDDhhmiss.log will be created in the same directory where the script was executed. If any issues occur, you can check this log file to review the restoration history.

[cubrid ~]$ cat restoredb_20250411185128.log

[ Database(db1) Restore (level = 0) start ]

- restore start time: Fri Api 11 18:51:28 2025

- restore steps: 1
 step 1) restore using (level = 0) backup data

- restore progress status (using level = 0 backup data)
 -----------------------------------------------------------------------------
 volume name                  | # of pages |  restore progress status  | done
 -----------------------------------------------------------------------------
 dbms_keys                     |          1 | ######################### | done
 dbms_vinf                     |          1 | ######################### | done
 dbms                          |      32768 | ######################### | done
 dbms_lgar001                  |      32768 | ######################### | done
 dbms_lgar002                  |      32768 | ######################### | done
 dbms_lginf                    |          1 | ######################### | done
 dbms_lgat                     |      32768 | ######################### | done
 -----------------------------------------------------------------------------

- restore end time: Fri Api 11 18:51:30 2025

[ Database(db1) Restore (level = 0) end ]