Una copia de seguridad ( backup) es una copia de los datos de su base de datos que pueden ser utilizados para reconstruir los datos. Las copias de seguridad se pueden dividir en backup físico y backup lógio.
Respaldos físicos son copias de seguridad de los archivos físicos utilizados en el almacenamiento y la recuperación de la base de datos, como archivos de datos, archivos de control y los registros de rehacer archivados. En última instancia, cada copia de seguridad física es una copia de los archivos de almacenamiento de información de base de datos a otra ubicación, ya sea en algunos de almacenamiento fuera de línea de disco o como una cinta.
Las copias de seguridad lógicas contienen datos lógicos (por ejemplo, tablas o procedimientos almacenados) exportados desde una base de datos con una utilidad de exportación de Oracle y almacenados en un archivo binario, para después volver a importar en una base de datos mediante la correspondiente utilidad de importación de Oracle.
Respaldos físicos son la base de cualquier estrategia de copia de seguridad y recuperación. Las copias de seguridad lógicas son un complemento útil de las copias de seguridad físicas en muchas circunstancias, pero no son suficiente protección contra la pérdida de datos. sin respaldos físicos.
A menos que se especifique lo contrario, el término backup como se usa en la documentación de respaldo y recuperación se refiere a las copias de seguridad físicas, y una copia de seguridad de parte o la totalidad de su base de datos es tomar algún tipo de copia de seguridad física. El epicentro en la copia de seguridad y recuperación de conjunto de la documentación será casi exclusivamente un backup físico.
While there are several types of problem that can halt the normal operation of an Oracle database or affect database I/O operations, only two typically require DBA intervention and media recovery: media failure, and user errors.
Other failures may require DBA intervention to restart the database (after an instance failure) or allocate more disk space (after statement failure due to, for instance, a full datafile) but these situations will not generally cause data loss or require recovery from backup.
User errors occur when, either due to an error in application logic or a manual mis-step, data in your database is changed or deleted incorrectly. Data loss due to user error includes such missteps as dropping important tables or deleting or changing the contents of a table. While user training and careful management of privileges can prevent most user errors, your backup strategy determines how gracefully you recover the lost data when user error does cause data loss.
A media failure is the failure of a read or write of a disk file required to run the database, due to a physical problem with the disk such as a head crash. Any database file can be vulnerable to a media failure.
The appropriate recovery technique following a media failure depends on the files affected and the types of backup available.
For performing backup and recovery based on physical backups, you have two solutions available:
Both methods are supported by Oracle Corporation and are fully documented. Recovery Manager is, however, the preferred solution for database backup and recovery. It can perform the same types of backup and recovery available through user-managed methods more easily, provides a common interface for backup tasks across different host operating systems, and offers a number of backup techniques not available through user-managed methods.
Most of the backup and recovery documentation set will focus on RMAN-based backup and recovery. User-managed backup and recovery techniques are covered in the later chapters of Oracle Database Backup and Recovery Advanced User's Guide.
Whether you use RMAN or user-managed methods, you can supplement your physical backups with logical backups of schema objects made using data export utilities. Data thus saved can later be imported to re-create this data after restore and recovery. However, logical backups are for the most part beyond the scope of the backup and recovery documentation.
The physical structures of the database and the role each plays in the database recovery process determine the forms of backup and recovery available through user-managed techniques and through RMAN.
The files and other structures that make up an Oracle database store data and safeguard it against possible failures. This discussion introduces each of the physical structures that make up an Oracle database and their role in the reconstruction of a database from backup. This section contains these topics:
An Oracle database consists of one or more logical storage units called tablespaces. Each tablespace in an Oracle database consists of one or more files called datafiles, physical files under the host operating system which collectively contain the data stored in the tablespace.The simplest Oracle database would have one tablespace, stored in one datafile.
The database manages the storage space in the datafiles of a database in units called data blocks. Data blocks are the smallest units of storage that the database can use or allocate.
Modified or new data is not written to datafiles immediately. Updates are buffered in memory and written to datafiles at intervals. If a database has not gone through a normal shutdown (that is, if it is open, or exited abnormally, as in an instance failure or a SHUTDOWN ABORT) then there are typically changes in memory that have not been written to the datafiles. Datafiles that were restored from backup, or were not closed during a consistent shutdown, are typically not completely up to date.
Copies of the datafiles of a database are a critical part of any backup.
Redo logs record all changes made to a database's data files. Each time data is changed in the database, that change is recorded in the online redo log first, before it is applied to the datafiles.
An Oracle database requires at least two online redo log groups, and in each group there is at least one online redo log member, an individual redo log file where the changes are recorded.
At intervals, the database rotates through the online redo log groups, storing changes in the current online redo log .
Because the redo log contains a record of all changes to the datafiles, if a backup copy of a datafile from some point in time and a complete set of redo logs from that time forward are available, the database can reapply changes recorded in the redo logs, in order to re-construct the datafile contents at any point between the backup time and the end of the last redo log. However, this is only possible if the redo log has been preserved.
Therefore, preserving the redo logs is a major part of most backup strategies. The first level of preserving the redo log is through a process called archiving. The database can copy online redo log groups that are not currently in use to one or more archive locations on disk, where they are collectively called the archived redo log. Individual files are referred to as archived redo log files. After a redo log file is archived, it can be backed up to other locations on disk or on tape, for long term storage and use in future recovery operations.
Without archived redo logs, your database backup and recovery options are severely limited. Your database must be taken offline before it can be backed up, and if you must restore your database from backup, the database contents are only available as of the time of the backup. Reconstructing the state of the database at a point in time between backups is impossible without the archived log.
The control file contains the record of the physical structures of the database and their status. Several types of information stored in the control file are related to backup and recovery:
The recovery process for datafiles is in part guided by status information in the control file, such as the database checkpoints, current online redo log file, and the datafile header checkpoints for the datafiles. Loss of the control file makes recovery from a data loss much more difficult.
In general, when data in a datafile is updated, "before images" of that data are written into undo segments. If a transaction is rolled back, this undo information can be used to restore the original datafile contents.
In the context of recovery, the undo information is used to undo the effects of uncommitted transactions, once all the datafile changes from the redo logs have been applied to the datafiles. The database is actually opened before the undo is applied.
You should not have to concern yourself with undo segments or manage them directly as part of your backup and recovery process.
Reconstructing the contents of all or part of a database from a backup typically involves two phases: retrieving a copy of the datafile from a backup, and reapplying changes to the file since the backup from the archived and online redo logs, to bring the database to a desired SCN since the backup (usually, the present).
To restore a datafile or control file from backup is to retrieve the file onto disk from a backup location on tape, disk or other media, and make it available to the database server.
To recover a datafile (also called performing recovery on a datafile), is to take a restored copy of the datafile and apply to it changes recorded in the database's redo logs. To recover a whole database is to perform recovery on each of its datafiles.
Figure 1 illustrates the basic principle of backing up, restoring, and recovering a database. Most of the data recovery procedures supported by the Oracle database are variations on the process described here.
|Figure 1 Restoring and Recovering a Database|
In this example a full backup of a database (copies of its datafiles and control file) is taken at SCN 100. Redo logs generated during the operation of the database capture all changes that occur between SCN 100 and SCN 500. Along the way, some logs fill and are archived. At SCN 500, the datafiles of the database are lost due to a media failure. The database is then returned to its transaction-consistent state at SCN 500, by restoring the datafiles from the backup taken at SCN 100, then applying the transactions captured in the archived and online redo logs and undoing the uncomitted transactions