CUBRID uses log volumes/files and database backups to restore committed or uncommitted transactions when a system or media (disk) error occurs. Logs are also used to support the user-specified rollback. A log consists of a collection of sequential files created by CUBRID. The most recent log is called the active log, and the rest are called archive logs. A log file refers to both the active log and archive logs.
All updates of the database are written to the log. Actually, two copies of the updates are logged. The first one is called a before image and used to restore data during execution of the user-specified ROLLBACK WORK statement or during media or system errors. The second copy is an after image and used to re-apply the updates when a media or system error occurs.
When the active log is full, CUBRID copies it to an archive log to store in the disk. The archive log is needed to restore the database when a system failure occurs. You don't need to maintain archive logs if there is no need for system failure restore. This configuration can be set by using the media_failure_support system parameter. For more information on this parameter, see Logging-Related Parameters.
CUBRID restores the database if it restarts due to a normal termination or a device error. The restore process re-applies the committed changes that have not been applied to the database and removes the uncommitted changes stored in the database. The general operation of the database resumes after the restore is completed. This restore process does not use any archive logs or database backup.
In a client/server environment, the database can restart by using server utilities.
The user's intervention is somewhat needed to restart the database after a media error occurs. The first step is to restore the database by installing a backup of a known good state. In CUBRID, the most recent log file (the one after the last backup) must be installed. This specific log (archive or active) is applied to a backup copy of the database. As with normal termination, the database can restart after restoration is committed.
It is important to back up the database periodically. Backup periods differ depending on the frequency of database updates. Once a database backup is created, CUBRID uses the current database backup to specify the archive log that is not needed any more. However, CUBRID does not delete the archive log. The database administrator must take extra care when deleting the database backup or archive log. In some cases, the latest database backup may fail.
Note To minimize the possibility of losing database updates, it is recommended to create a snapshot of the archive log and backup the log to a disk before it is deleted from the disk. The DBA can backup and restore the database by using the cubrid backupdb and cubrid restoredb utilities. For more information on these utilities, see Database Backup.