By: Juan Carlos Olamendy Turruellas
One of the most important regularly task done by any DBA is to back up the database. In short, a database backup involves making physical copies of your database files to a secure storage (maybe off-site) in order to re-create the database when there is some loss of data. In terms of Oracle database, we need to keep copies of the following files:
A backup is the key component in any disaster recovery strategy. It’s very important to note that “the more time we spend planning and testing backups, the less time we’ll spend recovering the database”.
This is the first article in a series where we’re being learning about the principles, concepts and real world scripts for doing backups to Oracle database.
In this first article, I’ll talk about the most important terms related to backups in Oracle databases. In the next article, I’ll talk about doing low-level manual backups in order to apply the principles and concepts of this article. In the last articles, I’ll talk about a tool that automates the backup process (no more low level tasks) named Recovery Manager (also know as RMAN).
First of all, let’s answer the existential question: What is backup and recovery?
Backup: It’s a mean for recovering a database from failures and disasters.
Common types of failures and disasters are:
There are mainly two types of backups:
Recovery: It’s a mean for reconstructing an Oracle database by copying backup files back to their original locations of an Oracle database and also updating the database files by applying redo log records from the redo log files in order to bring a database back to the point in time where a failure occurred. As a summary, when a database is recovered, it’s first restored from a physical backup, and then redo log records are used to roll forward to the point of failure.
Now let’s analyze the principal concepts related to backup in Oracle databases.
Archivelog mode: In this mode, Oracle database saves/archives the filled redo logs. So, if we’re running in archivelog mode, we can recover (we may execute the restore and update tasks in the recovery process) the database to any point in time using the archived logs.
Noarchivelog mode: In this mode, the filled redo logs are overwritten and not saved. Remember that redo logs works in a circular way. It implies that we can restore only the backup (we may run the first step in a recovery process and not the whole process), so we’ll lose all the changes made to the database after the backup was made. For example, if there is a media failure, a database in noarchivelog mode may be restored from a backup, but it’ll lose all changes made to the database since the backup was made.
Oracle instances in the production environment usually run in archivelog mode because:
In short, we may run an Oracle database in noarchivelog mode only when we don’t mind about the most recent data on recovering.
Whole backup: It’s also termed for offline/cold/closed backups. In this mode, we back up all files related to an Oracle instance. We can make a whole database backup in either archivelog or noarchivelog mode. In order to execute a whole backup, we need to shutdown the instance to get all files consistent. A database can be restored from this type of backup without performing the update step, so the recovery only points to the last backup (not to the point-of-last-committed-transaction).
Partial backup: Basically, it means that we may back up either a part of a database, such as a particular tablespace and database files. It’s remarkable to say that we can’t back up a database partially if the database is running in noarchivelog mode, unless all the tablespaces in the partial backup are read-only.
In this first part, I've talked about the key principles and terms related to backup and restore processes in Oracle databases. In next articles, I’ll illustrate these principles and concepts with real world examples.