One of the advantages of open database backup is its flexibility. A DBA can choose to backup all datafiles for a tablespace or just one datafile for that tablespace. An additional advantage is that the database remains accessible during the backup process. Tablespace and datafile backups should only be performed when the database is operating in ARCHIVELOG mode. Such backups cannot be used to restore a database running in NOARCHIVELOG mode.
Backing up a tablespace
It is important to frequently back up tablespaces with rollback segments and tablespaces that contain important data such as system data. Tablespaces containing only temporary segments do not need to be backed up.
Backing up an individual datafile
One reason a DBA may choose to frequently backup the datafiles of extensively used tablespaces is to reduce database recovery time.
If recovery is required and a more recent copy of the datafile is used to restore the damaged one, the amount of time a datafile remains in "Fuzzy" state is minimized. Because of this, fewer archived redo logs need to be applied to the restored datafiles to roll them forward to the time of the failure.
The "Fuzzy" backup problem often appears during the process of an open database backup. For example, let us say a situation arises
where the operating system backup starts at the beginning of the datafile and midway through the copy operation, a change occurs with bytes
behind the read/write head. Bytes behind the head are missed but are vital to the change. The resulting imperfect copy must be recovered using the Redo Logs in use at the time of the backup. The following series of images demonstrate the Fuzzy problem in an open database backup.
Due to electric failure my database server went down. When I restarted it returned an ORA-00214 as shown below:
ORACLE instance started.
Total System Global Area 83605532 bytes
Fixed Size 75804 bytes
Variable Size 57016320 bytes
Database Buffers 26435584 bytes
Redo Buffers 77824 bytes
ORA-00214: controlfile 'D:\ORACLE\ORADATA\DATA\CONTROL01.CTL' version 11541
inconsistent with file 'D:\ORACLE\ORADATA\DATA\CONTROL03.CTL' version 11538
What is the cause of ORA-00214 and what is the solution?
The docs note this on the ORA-00214 error:
ORA-00214: control file "string" version string inconsistent with file "string" version string.
An inconsistent set of control files, datafiles/logfiles, and redo files was used.
Action: Use a consistent set of control files, datafiles/logfiles, and redo log files.
That is, all the files must map to the same database and be from the same time period.
The primary reasons an ORA-00214 error include forgetting to replace ALL OF the current control files in all locations specified in the
init.ora control_files parameter
. Remember, all of the control files, in all locations, must match exactly.
All copies of the control file must have the same internal sequence number
for Oracle to start up the database or shut it down in normal or immediate mode.
If the database is running and the checkpoint in the file header could not be advanced the datafile will be taken offline.
Typical scenarios in which you may receive an ORA-00214 include:
- You have restored the control file from backup, but forgot to copy it onto all of the mirrored copies of the control file as listed in the "CONTROL_FILES" parameter in the init.ora file for this instance
- You have moved one or more copies of the control file to a different location while the database was up and running.
- You accidentally overwrote one of the copies of the control file with an old copy.
- The database or the system crashed while the mirrored copies of the control file were being updated, causing them to be out of sync.
- You are restoring a database backup that was improperly taken with the database up and running ("fuzzy" backup).