[Laskey99] Section 4.2. Database Backup

来源：百度文库编辑：神马文学网时间：2024/04/28 02:09:33

4.2.
This section describes the available backup techniques you can use toback up your database.

4.2.1. Cold Backup

A coldbackup (also known as an offlinebackup) is a physical backup that is taken when thedatabase is not operational—it is "cold." Acomplete cold backup of the database, including the control files andredo logs, can be used to recreate the database to the time of thecold backup.

4.2.1.1. Benefits

There are two major benefits of performing cold backups:

A cold backup is the easiest mechanism for performing backups. Any mechanism for creating a copy of the datafiles will work.
A cold backup can be used with the database in either archivelog or noarchivelog mode.

4.2.1.2. Limitations

For cold backups, the database must be down for the time it takes toback up the entire database. For sites that have an availabilityrequirement, this may not be viable. Unless you are in archivelogmode, the entire database must be backed up at the same time andrestored as a whole. Oracle refers to this operation as afull backup.

In our discussion, the assumption is generally that you want to recover the entire database. However, it is possible to recover a subset of the tablespaces. A procedure for doing this is provided in the following sections.

4.2.2. Hot Backup

A hot backup(also known as an online backup) is a physicalbackup that is taken when the database is operational—that is,"hot." Oracle provides specific support for hot backupsthrough archivelog mode and the ALTER TABLESPACE BEGIN/END BACKUPcommands. Tablespaces are placed into backup mode, backed up, thentaken out of backup mode. Oracle performs a checkpoint of alldatafiles in a tablespace when a tablespace is placed into backupmode, and records the checkpoint number in the header of alldatafiles.

Before you back up a datafile, its tablespace must be placed inbackup mode with the command:

ALTER TABLESPACE BEGIN BACKUP

At this point, the database marks the datafile(s) as being in backupmode and starts writing information to the redo log at the blocklevel, rather than at the byte level. You may then back up thedatafile using any mechanism you choose. Once the datafile has beenbacked up, you issue the command:

ALTER TABLESPACE END BACKUP

This tells the database to resume normal operation.

When performing hot backups, it is imperative that you follow the procedure we describe here. Standard operating system backups of the database files while the tablespace is not in backup mode will not work.

4.2.2.1. Benefits

Hot backups are the most flexible of the backup facilities. Thedatabase does not have to be down during the backup, and you do nothave to back up all the datafiles at one time. Individual datafilescan even be backed up on different days. Oracle refers to this typeof backup as a partialbackup.

4.2.2.2. Limitations

You must be in archivelog mode to perform a hot backup.

4.2.3. EXPort/IMPort

EXP (Export) is an Oracle utility thatcreates a logical backup of the database. IMP (Import) is thecorresponding utility that reads the logical backup and inserts thedata into the database. The powerful Export/Import facility is themost mature of the various mechanisms supported by Oracle forperforming backups, and it supplies unique benefits. However, someDBAs see it as an obsolete mechanism for performing backups becauseof its various limitations.

4.2.3.1. Benefits

The Export/Import facility was designed to move table data in and outof Oracle in various ways. You may export or import at the table,user, or database level.

4.2.3.2. Limitations

Largely because Export/Import is the most mature of the backupfacilities, it also has the most serious restrictions:

The size of the export file may be limited by operating system restrictions (the limit is typically 2GB in many Unix systems).
You cannot explicitly export or import objects other than tables. However, these objects are processed automatically when doing user or full database exports or imports.
After a table is imported, its indexes must be rebuilt. (Import can do this automatically.)
Each table exported is a separate transaction. In order to get a consistent backup, you need to specify the CONSISTENT=Y parameter in the control file. However, for large or active databases, you then run the risk of getting a "snapshot too old" error message.

4.2.3.3. Using incremental exports

Exporthas the ability to perform three levels of exports: full, cumulative,and incremental. This is similar to the approach used by operatingsystem backup utilities. You specify which level you are selectingvia the INCTYPE parameter. See Chapter 16, for more information on how to specify exportparameters.

Oracle has announced that it is dropping support for incremental and cumulative exports effective December 31, 1999.

To select the type of export, specify one of the following keywordsas the value of INCTYPE:

FULL: Processes all objects in the database.
CUMULATIVE: Processes all objects modified since the last cumulative or fullexport.
INCREMENTAL: Processes all objects modified since the last export.

In cumulative and incremental exports, the entire table is exportedeven if only one row has changed. In Oracle8, individual partitionsin a partitioned table can be separately exported.

4.2.3.4. Direct path versus conventional path

The conventional pathexport method, which is the Export default,uses the standard SQL buffer to fetch rows. It simply issues a SELECT* FROM TABLE to retrieve all the rows. The direct pathexportmethod, on the other hand, bypasses thenormal processing and retrieves the data blocks directly into its ownbuffer. In most cases, the direct path export is noticeably fasterthan the conventional path export. Other than a notation in theexport file, there are no differences in the file generated by thesetwo methods.

Since the direct path export bypasses the SQL buffer, character set translation is not performed. The user process performing the export must have the same character set specified as the database. This limitation does not apply to the import.

In Oracle8 Release 8.0, tables with large objects (LOBs) cannot be processed using the direct path export method.

4.2.3.5. Using the EXP tables

The following data dictionary views can be used to identify whichexport file is required to restore a given table. The information isstored if the Export RECORD parameteris set to Y. See Chapter 16, for more details onspecifying export parameters.

DBA_EXP_FILES: This view has one row for each successful export since (andincluding) the last full export.
DBA_EXP_OBJECTS: This view has one row for each exported object in the database. Itspecifies the last export version that contained that object.
DBA_EXP_VERSION: This view has one row and one column, EXP_VERSION, which contains thelast successful export.

By joining DBA_EXP_OBJECTS and DBA_EXP_FILES, you can locate theexport file necessary to restore a given table. These data dictionaryviews are updated every time an export occurs. If you need historicalinformation beyond the last time an object was exported, copy thesedata dictionary views into a permanent table.

4.2.3.6. Other uses for Export

Because the Export utility provides a logical backup of the database,it can be used to move data in and out of the database. As a DBA, youcan use Export/Import as follows:

To move data between operating systems or versions of Oracle. If you do move data between computer systems, use a binary mode file copy rather than a record-based copy (see Chapter 16 for details).
To assist in changing some of the storage attributes of a table. Once you have exported a table, you can drop it, recreate it with different storage parameters, or even place it in a new tablespace and then reimport the table. If you are doing this, make sure that you specify IGNORE=Y in the Import control file.
To change the owner of the table. Any export file written by a non-DBA user can be imported by any other user. The userid specified when invoking Import will become the owner of the objects. If the export was performed by a DBA, then the import can only be performed by a DBA, but the FROM-OWNER and TOOWNER clauses can be used to change the owner of the objects.

The Export/Import facility is not the only way to accomplish thesetasks; you can use a series of SQL statements and SQL*Net to performall of these actions. However, in many cases, using Export/Import iseasiest, and requires less storage within the database.

Create Bookmark (Key: b)Create Bookmark
Create Note or Tag (Key: t)Create Note or Tag
Download (Key: d)Download
Email This Page (Key: e)Email This Page
PrintPrint

Html View (Key: h)Html View
Zoom Out (Key: -)Zoom Out
Zoom In (Key: +)Zoom In
Toggle to Full Screen (Key: f)
Previous (Key: p)Previous
Next (Key: n)Next