next up previous contents index
Next: 13. Database Security Up: Ovrimos version 3.0 On-line Previous: 11. Replication

Subsections

   
12. Database Maintenance

Backup and recovery are two of the most critical activities the dbman performs. While the database files are backed up automatically every time the database is shut down, the best protection against system failures (i.e. failures where the database is not physically damaged) or media failures (i.e. failures where some portion of the database has been physically damaged) is safekeeping the database backups. The frequency of the database backups determines how little (or how much) work will be lost in the event of a failure.

To understand the role of Ovrimos parameters in the backup and recovery process, you should read Appendix A about Ovrimos Parameters.

  
12.1 Database Backup

It is highly recommended that when the dbman creates a database, the transaction log ($LOGFILE) and the backup ($BACKUPDIR)  are placed on a different volume.

   
12.2 Database Recovery

Recovery should protect the databases and associated users from unnecessary problems and avoid or reduce the possibility of having to duplicate work manually. Several problems can halt the normal operation of a database or affect database I/O to disk, such as errors when trying to write or read a file that is required to operate an Ovrimos database or user errors.

In case of an abnormal termination , the database is restored from the directory $BACKUPDIR  and the program $PLAYBACK  is run. The transaction log ($LOGFILE ) contains all the changes made to the database as they occur so that all committed transactions are executed and the uncommitted ones are rolled back. This process is performed automatically to restore the database to the situation it was before the failure.

In case of a hard disk failure, the dbman should copy the most recent backup and log file to the appropriate locations.

In case of a user error (for example, accidentally dropping a table), the dbman should copy the most recent backup to the directory $DIR.

The dirty file  specifies if an abnormal termination has taken place, so that the database recovery can start automatically. When the database data change after an UPDATE, INSERT or DELETE statement, the dirty file is created automatically. If the database's server shuts down normally, the dirty file is removed automatically while an abnormal termination is assumed when the dirty file is found in the directory $TEMPDIR.

  
12.3 Periodic Maintenance

As explained in section 4.8, the error log  records all the changes made in the database and displays three kinds of messages (info, warning and error). The error log (.logerr) is created automatically when it doesn't exist and a message has to be logged in the $TEMPDIR. Thus, it is recommended that users remove the error log and $HTTPLOG periodically to save wasted space as they grow in size with time.


next up previous contents index
Next: 13. Database Security Up: Ovrimos version 3.0 On-line Previous: 11. Replication