Hitachi

Hitachi Advanced Database Setup and Operation Guide


10.3.1 Backup acquisition method

This section explains the timing of backup acquisition, the types of backup, and the procedure for making a backup.

For details about the backup acquisition method for when the multi-node function is being used, see 16.8 Backing up a database (when the multi-node function is being used).

Organization of this subsection

(1) Backup acquisition timing

As a rule, make a backup on a regular basis so that the backup can be used for restoring the database in the event of an error. It is especially important to back up your database before you perform any of the following operations:

Important

When you back up a database, back up all necessary files including the data DB area file. This backup method is called full backup.

(2) Backup procedure

The following figure shows the procedure for backing up a database.

Figure 10‒1: Backup procedure

[Figure]

Each of the steps in the above figure is explained in detail below. Note that the numbers in the figure correspond to the step numbers shown below.

If you plan to use the Change the HADB server's operation mode to the quiescence mode in Suppress database updating in step 2, skip step 1 and start with step 2.

  1. Check for non-updatable base tables.

    Before backing up a database, you need to confirm that there is no non-updatable base table. Execute the adbdbstatus command with the -c table option specified. If you plan to change the HADB server's operation mode to the quiescence mode in step 2, this action in step 1 is not required. Proceed to step 2.

    The following specification example checks the status of all base tables:

    adbdbstatus -c table

    Confirm that non-updatable is not output in the Non-updatable column of the output result. If non-updatable is output, the base table is non-updatable. Release the non-updatable state of the base table based on the explanation in 15.8.1 Steps to take when a base table becomes non-updatable.

    Important

    If you make a backup while a base table is non-updatable and you then restore the database using that backup, you might not be able to release the base table from non-updatable status. If a base table is non-updatable, you cannot execute retrieval or updating.

  2. Suppress database updating.

    Before backing up a database, you need to prevent the database from being updated. To do so, use one of the following approaches:

    • Terminate the HADB server normally.

      If terminating the HADB server will not cause any problems, execute the adbstop command to terminate the HADB server normally.

    • Change the HADB server's operation mode to the quiescence mode.

      If the HADB server is running and cannot be terminated, execute the adbchgsrvmode --quiescence command to change the operation mode to the quiescence mode.

      Important

      If you change the operation mode to quiescence mode and make a backup, and if you then start the HADB server after the database is recovered, the HADB server restarts. In this case, if the server definition was changed after the backup acquisition, the HADB server might not be able to restart after it is restored from the backup that was made. Therefore, when making a backup after changing the operation mode to the quiescence mode, we recommend that you also back up the server definition file as described in step 6. If the HADB server cannot restart because a server definition was changed, take the necessary corrective actions based on messages KFAA50024-E and KFAA50025-E.

  3. Check the HADB server's status.

    When you have completed step 2, check the HADB server's status. Execute the following command to confirm that database updating has been suppressed.

    adbls -d srv

    Check the item STATUS in the execution result.

    • If the HADB server terminated normally

      Confirm that the output item STATUS shows STOP. Then proceed to step 5.

    • If you changed the HADB server's operation mode to the quiescence mode

      Confirm that the output item STATUS shows QUIESCE. Then proceed to step 4.

  4. Check for non-updatable base tables.

    Before backing up a database, you need to confirm that there is no non-updatable base table. Execute the adbdbstatus command with the -c table option specified.

    If the HADB server terminated normally in step 2, proceed to step 5.

    The following specification example checks the status of all base tables:

    adbdbstatus -c table

    Confirm that non-updatable is not output in the Non-updatable column of the output result. If non-updatable is output, the base table is non-updatable. Release the non-updatable state of the base table based on the explanation in 15.8.1 Steps to take when a base table becomes non-updatable.

  5. Back up the database.

    Once you have suppressed database updating, you can make a backup. Back up all files that need to be backed up. If you back up only some of the files, database compatibility cannot be achieved when the database is restored from the backup, and the validity of subsequent operations cannot be guaranteed.

    If the target file is a symbolic link file, also back up the linked file and block special file. Do not use the backed-up files as sparse files.

    The following table shows the files that need to be backed up.

    Table 10‒6: List of files that needed to be backed up

    No.

    File that needs to be backed up

    File storage location

    File type

    1

    Command status file

    $DBDIR/ADBSYS/ADBUTL

    Regular file

    2

    System log file

    $DBDIR/ADBSYS/ADBSLG

    Regular file

    3

    Status file

    $DBDIR/ADBSYS/ADBSTS

    Regular file

    4

    Master directory DB area file

    $DBDIR/ADBMST

    Regular file or block special file

    5

    Dictionary DB area file

    $DBDIR/ADBDIC

    Regular file or block special file

    6

    System-table DB area file

    $DBDIR/ADBSTBL

    Regular file or block special file

    7

    All files comprising the data DB area

    $DBDIR/DBAREA#1

    Regular file or block special file

    8

    Archive file

    Archive directory#2

    Regular file

    9

    Synonym dictionary file

    Directory for storing synonym dictionary files#3

    Regular file

    #1

    This is the name specified by the user in the adbinit or adbmodarea command.

    #2

    This is the directory specified for ARCHIVEDIR in the chunk-archive specification of the CREATE TABLE statement.

    #3

    This is the directory specified in the adb_syndict_storage_path operand in the server definition.

    You can re-create a synonym dictionary file from a synonym list definition file. Therefore, if a synonym list definition file is saved, you do not have to perform full backup for a synonym dictionary file. Note, however, that in this case, a database and a synonym dictionary file are not synchronized with each other when the database is restored. As a result, if a synonym dictionary is updated after full backup, the following search results might be different from each other:

    - Search result for synonyms immediately after full backup

    - Search result for synonyms when a database is restored to the state when full backup was performed

    Note

    The files under the following directories do not need to be backed up:

    • Work directory ($DBDIR/ADBWORK)

    • Output destination directory for error information (core files) ($DBDIR/SPOOL)

      This is the directory specified in the adb_core_path operand if the adb_core_path operand in the server definition is specified.

    Note that there is no problem if you back up these files along with the files listed in the table above, and recover them from a backup.

    Note

    There is no need to back up the audit trail files in the audit trail directory (the directory specified for the adb_audit_log_path operand in the server definition). Instead of backing up the audit trail files in the audit trail directory, you can move them to the audit trail storage directory. For details about this process, see 12.3.1 Moving audit trail files (to audit trail storage directory).

  6. Back up necessary files (such as files under the server directory).

    If a problem such as a disk error occurs, you will need to recover the server directory or client directory. Therefore, back up the files listed below as well. These files are not directly used in database recovery.

    For the HADB server

    • All definition files stored under the server directory ($ADBDIR/conf)

    • All user-created files under the server directory ($ADBDIR)

    For an HADB client

    • All definition files stored under the client directory (%ADBCLTDIR%\conf for Windows and $ADBCLTDIR/conf for Linux)

    • All user-created files under the client directory (%ADBCLTDIR% for Windows and $ADBCLTDIR for Linux)

  7. Release the database from update suppression.

    Once you have completed the backup acquisition operation, release the database from update suppression.

    • If the HADB server terminated normally in step 2

      Execute the adbstart command to start the HADB server.

    • If you changed the HADB server's operation mode to the quiescence mode in step 2

      Execute the adbchgsrvmode --normal command to change the operation mode to the normal mode.

    You have now completed backup acquisition.