29 Making User-Managed Database Backups
This chapter describes methods of backing up an Oracle database in a user-managed backup and recovery strategy, that is, a strategy that does not depend on using Recovery Manager (RMAN).
This chapter contains the following topics:
29.1 Querying V$ Views to Obtain Backup Information
Before making a backup, you must identify all the files in your database and decide what to back up. You can use V$ views to obtain this information.
This section contains the following topics:
29.1.1 Listing Database Files Before a Backup
Use the V$DATAFILE
and V$CONTROLFILE
views to identify the data files and control files for your database. This same procedure works whether you named these files manually or allowed Oracle Managed Files to name them.
Caution:
Never back up online redo log files.
To list data files and control files:
29.1.2 Determining Data File Status for Online Tablespace Backups
To check whether a data file is part of a current online tablespace backup, query the V$BACKUP
view.
This view is useful only for user-managed online tablespace backups, because neither RMAN backups nor offline tablespace backups require the data files of a tablespace to be in backup mode. Some user-managed backup procedures require you to place the tablespace in backup mode to protect against the possibility of a fractured block. However, updates to the database create more than the usual amount of redo in backup mode.
The V$BACKUP
view is most useful when the database is open. It is also useful immediately after an instance failure because it shows the backup status of the files at the time of the failure. Use this information to determine whether you have left any tablespaces in backup mode.
V$BACKUP
is not useful if the control file currently in use is a restored backup or a new control file created after the media failure occurred. A restored or re-created control file does not contain the information that the database needs to populate V$BACKUP
accurately. Also, if you have restored a backup of a file, this file's STATUS
in V$BACKUP
reflects the backup status of the older version of the file, not the most current version. Thus, this view can contain misleading data about restored files.
For example, the following query displays which data files are currently included in a tablespace that has been placed in backup mode:
SELECT t.name AS "TB_NAME", d.file# as "DF#", d.name AS "DF_NAME", b.status FROM V$DATAFILE d, V$TABLESPACE t, V$BACKUP b WHERE d.TS#=t.TS# AND b.FILE#=d.FILE# AND b.STATUS='ACTIVE';
The following sample output shows that the tools
and users
tablespaces currently have ACTIVE
status:
TB_NAME DF# DF_NAME STATUS ---------------------- ---------- -------------------------------- ------ TOOLS 7 /oracle/oradata/trgt/tools01.dbf ACTIVE USERS 8 /oracle/oradata/trgt/users01.dbf ACTIVE
In the STATUS
column, NOT
ACTIVE
indicates that the file is not currently in backup mode (that is, you have not executed the ALTER
TABLESPACE
...
BEGIN
BACKUP
or ALTER DATABASE BEGIN BACKUP
statement), whereas ACTIVE
indicates that the file is currently in backup mode.
29.2 Making User-Managed Backups of the Whole Database
You can make a consistent whole database backup of all files in a database after the database has been shut down with the NORMAL
, IMMEDIATE
, or TRANSACTIONAL
options. A whole database backup taken while the database is open or after an instance failure or SHUTDOWN
ABORT
command is inconsistent. In such cases, the files are inconsistent with the database checkpoint SCN.
You can make a whole database backup if a database is operating in either ARCHIVELOG
or NOARCHIVELOG
mode. If you run the database in NOARCHIVELOG
mode, however, then the backup must be consistent; that is, you must shut down the database cleanly before the backup.
The set of backup files that results from a consistent whole database backup is consistent because all files are checkpointed to the same SCN. You can restore the consistent database backup without further recovery. After restoring the backup files, you can perform additional recovery steps to recover the database to a more current time if the database is operated in ARCHIVELOG
mode. Also, you can take inconsistent whole database backups if your database is in ARCHIVELOG
mode.
Control files play a crucial role in database restore and recovery. For databases running in ARCHIVELOG
mode, Oracle recommends that you back up control files with the ALTER
DATABASE
BACKUP
CONTROLFILE
TO
'
filename
'
statement.
See Also:
"Making User-Managed Backups of the Control File" for more information about backing up control files
Making Consistent Whole Database Backups
To make a consistent whole database backup:
29.3 Making User-Managed Backups of CDBs and PDBs
The information in this chapter applies to multitenant container databases (CDBs) and pluggable databases (PDBs) with only slight changes, as described in the following section.
To make a consistent whole database backup for a CDB:
-
Open SQL*Plus.
-
Connect to the root as a user with the
SYSDBA
orSYSBACKUP
system privilege as described in "Connecting as Target to the Root". -
If the database is open, then use SQL*Plus to shut down the database with the
NORMAL
,IMMEDIATE
, orTRANSACTIONAL
options. -
Use an operating system utility to make backups of all data files and all control files specified by the
CONTROL_FILES
parameter of the initialization parameter file. Also, back up the initialization parameter file and other Oracle product initialization files. To find these files, do a search for*.ora
starting in your Oracle home directory and recursively search all of its subdirectories.For example, you can back up the data files, control files, and archived logs to
/disk3/backup
as follows:% cp $ORACLE_HOME/oradata/cdb1/*.dbf /disk3/backup % cp $ORACLE_HOME/oradata/cdb1/arch/* /disk3/backup/arch
-
Restart the database with the
STARTUP
command in SQL*Plus.
See Also:
-
Oracle Database SQL Language Reference for more information about using
ALTER DATABASE
command for CDBs -
Oracle Database Administrator’s Guide for more information about starting up and shutting down a database
To make a consistent backup of a PDB:
29.4 Making User-Managed Backups of Tablespaces and Data Files
The technique for making user-managed backups of tablespaces and data files depends on whether the files are offline or online.
This section contains the following topics:
29.4.1 Making User-Managed Backups of Offline Tablespaces and Data Files
-
You cannot take offline the
SYSTEM
tablespace or a tablespace with active undo segments. The following technique cannot be used for such tablespaces. -
Assume that a table is in tablespace
Primary
and its index is in tablespaceIndex
. Taking tablespaceIndex
offline while leaving tablespacePrimary
online can cause errors when data manipulation language (DML) is issued against the indexed tables located inPrimary
. The problem appears only when the access method chosen by the optimizer must access the indexes in theIndex
tablespace.
To back up offline tablespaces:
29.4.2 Making User-Managed Backups of Online Tablespaces and Data Files
You can back up all or only specific data files of an online tablespace while the database is open. The procedure differs depending on whether the online tablespace is read/write or read-only.
Note:
Do not back up temporary tablespaces.
This section contains the following topics:
29.4.2.1 Making User-Managed Backups of Online Read/Write Tablespaces
You must put a read/write tablespace in backup mode to make user-managed data file backups when the tablespace is online and the database is open. The ALTER
TABLESPACE
...
BEGIN
BACKUP
statement places a tablespace in backup mode. In backup mode, the database copies whole changed data blocks into the redo stream. After you take the tablespace out of backup mode with the ALTER
TABLESPACE
...
END
BACKUP
or ALTER
DATABASE
END
BACKUP
statement, the database advances the data file checkpoint SCN to the current database checkpoint SCN.
When restoring a data file backed up in this way, the database asks for the appropriate set of redo log files to apply if recovery is needed. The redo logs contain all changes required to recover the data files and make them consistent.
To back up online read/write tablespaces in an open database:
29.4.2.2 Making Multiple User-Managed Backups of Online Read/Write Tablespaces
When backing up several online tablespaces, you can back them up either serially or in parallel. Use either of the following procedures depending on your needs:
29.4.2.2.1 Backing Up Online Tablespaces in Parallel
You can simultaneously create data file copies of multiple tablespaces requiring backups in backup mode. Note, however, that by putting all tablespaces in online mode together, you can generate large redo logs if there is heavy update activity on the affected tablespaces, because the redo must contain a copy of each changed data block in each changed data file. Be sure to consider the size of the likely redo before using the procedure outlined here.
To back up online tablespaces in parallel:
29.4.2.2.2 Backing Up Online Tablespaces Serially
You can place all tablespaces requiring online backups in backup mode one at a time. Oracle recommends the serial backup option because it minimizes the time between ALTER
TABLESPACE
...
BEGIN/END
BACKUP
statements. During online backups, more redo information is generated for the tablespace because whole data blocks are copied into the redo log.
To back up online tablespaces serially:
29.4.2.3 Ending a Backup After an Instance Failure or SHUTDOWN ABORT
-
The backup completed, but you did not run the
ALTER
TABLESPACE
...
END
BACKUP
statement. -
An instance failure or
SHUTDOWN
ABORT
interrupted the backup.
Whenever recovery from a failure is required, if a data file is in backup mode when an attempt is made to open it, then the database does not open the data file until either a recovery command is issued, or the data file is taken out of backup mode.
For example, the database may display a message such as the following at startup:
ORA-01113: file 12 needs media recovery ORA-01110: data file 12: '/oracle/dbs/tbs_41.f'
If the database indicates that the data files for multiple tablespaces require media recovery because you forgot to end the online backups for these tablespaces, then so long as the database is mounted, running the ALTER
DATABASE
END
BACKUP
statement takes all the data files out of backup mode simultaneously.
In high availability situations, and in situations when no database administrator (DBA) is monitoring the database, the requirement for user intervention is intolerable. Hence, you can write a failure recovery script that does the following:
- Mounts the database
- Runs the
ALTER
DATABASE
END
BACKUP
statement - Runs
ALTER
DATABASE
OPEN
, enabling the system to start automatically
An automated crash recovery script containing ALTER
DATABASE
END
BACKUP
is especially useful in the following situations:
-
All nodes in an Oracle Real Application Clusters (Oracle RAC) configuration fail.
-
One node fails in a cold failover cluster (that is, a cluster that is not an Oracle RAC configuration in which the secondary node must mount and recover the database when the first node fails).
Alternatively, you can take the following manual measures after the system fails with tablespaces in backup mode:
-
Recover the database and avoid issuing
END
BACKUP
statements altogether. -
Mount the database, then run the
ALTER
TABLESPACE
...
END
BACKUP
statement for each tablespace still in backup mode.
29.4.2.3.1 Ending Backup Mode with the ALTER DATABASE END BACKUP Statement
You can run the ALTER
DATABASE
END
BACKUP
statement when you have multiple tablespaces still in backup mode. The primary purpose of this command is to allow a crash recovery script to restart a failed system without DBA intervention. You can also perform the following procedure manually.
To take tablespaces out of backup mode simultaneously:
29.4.2.3.2 Ending Backup Mode with the SQL*Plus RECOVER Command
The ALTER
DATABASE
END
BACKUP
statement is not the only way to respond to a failed online backup; you can also run the SQL*Plus RECOVER
command. This method is useful when you are not sure whether someone has restored a backup, because if someone has indeed restored a backup, then the RECOVER
command brings the backup up-to-date. Only run the ALTER
DATABASE
END
BACKUP
or ALTER
TABLESPACE
...
END
BACKUP
statement if you are sure that the files are current.
Note:
The RECOVER
command method is slow because the database must scan redo generated from the beginning of the online backup.
To take tablespaces out of backup mode with the RECOVER command:
See Also:
Performing User-Managed Database Flashback and Recovery for information about recovering a database
29.4.2.4 Making User-Managed Backups of Read-Only Tablespaces
When backing up an online read-only tablespace, you can simply back up the online data files. You do not have to place the tablespace in backup mode because the database is not permitting changes to the data files.
If the set of read-only tablespaces is self-contained, then in addition to backing up the tablespaces with operating system commands, you can also export the tablespace metadata with the transportable tablespace functionality. If a media error or a user error occurs (such as accidentally dropping a table in the read-only tablespace), you can transport the tablespace back into the database.
See Also:
Oracle Database Administrator's Guide to learn how to transport tablespaces
To back up online read-only tablespaces in an open database:
29.5 Making User-Managed Backups of Tablespaces in CDBs
The procedures in the section "Making User-Managed Backups of Tablespaces and Data Files" are applicable to CDBs and PDBs with the modifications described in the following sections:
29.5.1 Making User-Managed Backups of Offline Tablespaces and Data Files in CDBs
The guidelines described in "Making User-Managed Backups of Offline Tablespaces and Data Files" are also applicable to tablespaces and data files in CDBs and PDBs.
To backup offline tablespaces in a multitenant environment:
29.5.2 Making User-Managed Backups of Online Tablespaces in CDBs and PDBs
The guidelines described in "Making User-Managed Backups of Online Tablespaces and Data Files" are also applicable to tablespaces and data files in CDBs and PDBs.
To back up online tablespaces in the root container:
-
Open SQL*Plus.
-
Connect to the root as a user with the
SYSDBA
orSYSBACKUP
system privilege. -
Follow the instructions in "Making User-Managed Backups of Online Tablespaces and Data Files".
To backup online tablespaces in a PDB:
- Open SQL*Plus.
- Connect to the PDB as a user with
SYSDBA
orSYSBACKUP
system privilege. - Follow the instructions in "Making User-Managed Backups of Online Tablespaces and Data Files".
29.6 Making User-Managed Backups of the Control File
Back up the control file of a database after making a structural modification to a database operating in ARCHIVELOG
mode. To back up a database's control file, you must have the ALTER
DATABASE
system privilege.
This section contains the following topics:
29.6.1 Backing Up the Control File to a Binary File
The primary method for backing up the control file is to use a SQL statement to generate a binary file. A binary backup is preferable to a trace file backup because it contains additional information such as the archived log history, offline range for read-only and offline tablespaces, and backup sets and copies (if you use RMAN). If COMPATIBLE
is 10.2 or higher, binary control file backups include temp file entries.
To back up the control file after a structural change:
29.6.2 Backing Up the Control File to a Trace File
You can back up the control file to a text file that contains a CREATE CONTROLFILE
statement. You can edit the trace file to create a script that creates a new control file based on the control file that was current when you created the trace file.
If you specify neither the RESETLOGS
nor NORESETLOGS
option in the SQL statement, then the resulting trace file contains versions of the control file for both RESETLOGS
and NORESETLOGS
options. Temp file entries are included in the output using ALTER TABLESPACE ... ADD TEMPFILE
statements.
To avoid recovering offline normal or read-only tablespaces, edit them out of the CREATE
CONTROLFILE
statement. When you open the database with the re-created control file, the database marks these omitted files as MISSING
. You can run an ALTER
DATABASE
RENAME
FILE
statement to rename them to their original file names.
The trace file containing the CREATE CONTROLFILE
statement is stored in a subdirectory determined by the DIAGNOSTIC_DEST
initialization parameter. You can look in the database alert log for the name and location of the trace file to which the CREATE CONTROLFILE
statement was written. See Oracle Database Administrator's Guide to learn how to locate the alert log.
To back up the control file to a trace file:
See Also:
"Recovery of Read-Only Files with a Re-Created Control File" for special issues relating to read-only, offline normal, and temporary files included in CREATE
CONTROLFILE
statements
29.7 Making User-Managed Backups of Archived Redo Logs
To save disk space in your primary archiving location, you may want to back up archived logs to tape or to an alternative disk location. If you archive to multiple locations, then only back up one copy of each log sequence number.
To back up archived redo logs:
29.8 Making User-Managed Backups in SUSPEND Mode
This section contains the following topics:
29.8.1 About the Suspend/Resume Feature
Some third-party tools allow you to mirror a set of disks or logical devices, that is, maintain an exact duplicate of the primary data in another location, and then split the mirror. Splitting the mirror involves separating the copies so that you can use them independently.
With the SUSPEND
/RESUME
functionality, you can suspend I/O to the database, then split the mirror and make a backup of the split mirror. By using this feature, which complements the backup mode functionality, you can suspend database I/Os so that no new I/O can be performed. You can then access the suspended database to make backups without I/O interference.
Usually, you do not need to use SUSPEND
/RESUME
to make split mirror backups, although it is necessary if your system requires the database cache to be free of dirty buffers before a volume can be split. Some RAID devices benefit from suspending writes while the split operation is occurring; your RAID vendor can advise you on whether your system would benefit from this feature.
The ALTER
SYSTEM
SUSPEND
statement suspends the database by halting I/Os to data file headers, data files, and control files. When the database is suspended, all preexisting I/O operations can complete; however, any new database I/O access attempts are queued.
The ALTER
SYSTEM
SUSPEND
and ALTER
SYSTEM
RESUME
statements operate on the database and not just the instance. If the ALTER
SYSTEM
SUSPEND
statement is entered on one system in an Oracle RAC configuration, then the internal locking mechanisms propagate the halt request across instances, thereby suspending I/O operations for all active instances in a given cluster.
29.8.2 Making Backups in a Suspended Database
After a successful database suspension, you can back up the database to disk or break the mirrors. Because suspending a database does not guarantee immediate termination of I/O, Oracle recommends that you precede the ALTER
SYSTEM
SUSPEND
statement with a BEGIN
BACKUP
statement so that the tablespaces are placed in backup mode.
You must use conventional user-managed backup methods to back up split mirrors. RMAN cannot make database backups or copies because these operations require reading the data file headers. After the database backup is finished or the mirrors are resilvered, then you can resume normal database operations using the ALTER
SYSTEM
RESUME
statement.
Backing up a suspended database without splitting mirrors can cause an extended database outage because the database is inaccessible during this time. If backups are taken by splitting mirrors, however, then the outage is nominal. The outage time depends on the size of cache to flush, the number of data files, and the time required to break the mirror.
Note the following restrictions for the SUSPEND/RESUME
feature:
-
In an Oracle RAC configuration, do not start a new instance while the original nodes are suspended.
-
No checkpoint is initiated by the
ALTER
SYSTEM
SUSPEND
orALTER
SYSTEM
RESUME
statements. -
You cannot issue
SHUTDOWN
withIMMEDIATE
,NORMAL
, orTRANSACTIONAL
options while the database is suspended. -
Issuing
SHUTDOWN
ABORT
on a database that is suspended reactivates the database. This prevents media recovery or failure recovery from getting into a unresponsive state.
To make a split mirror backup in SUSPEND mode:
29.9 Making User-Managed Backups to Raw Devices
A raw device is a disk or partition that does not have a file system. A raw device can contain only a single file. Backing up files on raw devices poses operating system specific issues. The following sections discuss some of these issues on UNIX, Linux, and Windows.
This section contains the following topics:
29.9.1 Backing Up to Raw Devices on Linux and UNIX
The dd
command on Linux and UNIX is the most common backup utility for backing up to or from raw devices. See your operating system-specific documentation for complete details about this utility.
Using dd
effectively requires that you specify the correct options, based on your database. Table 29-1 lists details about your database that affect the options you use for dd
.
Table 29-1 Aspects of the Database Important for dd Usage
Data | Explanation |
---|---|
Block size |
You can specify the size of the buffer that |
Raw offset |
On some systems, the beginning of the file on the raw device is reserved for use by the operating system. This storage space is called the raw offset. Oracle Database does not back up or restore these bytes. |
Size of Oracle Database block |
At the beginning of every Oracle database file, the operating system-specific code places an Oracle block called block 0. The generic Oracle code does not recognize this block, but the block is included in the size of the file on the operating system. Typically, this block is the same size as the other Oracle blocks in the file. |
The information in Table 29-1 enables you to set the dd
options specified in Table 29-2.
Table 29-2 Options for dd Command
This Option ... | Specifies ... |
---|---|
|
The name of the input file, that is, the file that you are reading |
|
The name of the output file, that is, the file to which you are writing |
|
The buffer size used by |
|
The number of |
|
The number of |
|
The number of blocks on the input raw device for Remember to include block |
Because a raw device can be the input or output device for a backup, you have four possible scenarios for the backup. The possible options for dd
depend on which scenario you choose, as illustrated in Table 29-3.
Table 29-3 Scenarios Involving dd Backups
Backing Up from ... | Backing Up to ... | Options Specified for dd Command |
---|---|---|
Raw device |
Raw device |
|
Raw device |
File system |
|
File system |
Raw device |
|
File system |
File system |
|
29.9.1.1 Backing Up with the dd Utility on Linux and UNIX: Examples
For these examples of dd
utility usage, assume the following:
-
You are backing up a 30720 KB data file.
-
The beginning of the data file has a block 0 of 8 KB.
-
The raw offset is 64 KB.
-
You set the
dd
block size to 8 KB when a raw device is involved in the copy.
In the following example, you back up from one raw device to another raw device:
% dd if=/dev/rsd1b of=/dev/rsd2b bs=8k skip=8 seek=8 count=3841
In the following example, you back up from a raw device to a file system:
% dd if=/dev/rsd1b of=/backup/df1.dbf bs=8k skip=8 count=3841
In the following example, you back up from a file system to a raw device:
% dd if=/backup/df1.dbf of=/dev/rsd2b bs=8k seek=8
In the following example, you back up from a file system to a file system, and set the block size to a high value to boost I/O performance:
% dd if=/oracle/dbs/df1.dbf of=/backup/df1.dbf bs=1024k
29.9.2 Backing Up to Raw Devices on Windows
Like Linux and UNIX, Windows supports raw disk partitions in which the database can store data files, online logs, and control files. Each raw partition is assigned either a drive letter or physical drive number and does not contain a file system. As in Linux and UNIX, each raw partition on Windows is mapped to a single file.
Windows differs from Linux and UNIX in the naming convention for Oracle files. On Windows, raw data file names are formatted as follows:
\\.\drive_letter: \\.\PHYSICALDRIVEdrive_number
For example, the following are possible raw file names:
\\.\G: \\.\PHYSICALDRIVE3
The procedure for making user-managed backups of raw data files is basically the same as for copying files on a Windows file system, except that you use the Oracle OCOPY
utility rather than the Windows-supplied copy.exe
or ntbackup.exe
utilities. OCOPY
supports 64-bit file I/O, physical raw drives, and raw files. The OCOPY
utility cannot back up directly to tape.
To display online documentation for OCOPY
, enter OCOPY
by itself at the Windows prompt. Sample output follows:
Usage of OCOPY: ocopy from_file [to_file [a | size_1 [size_n]]] ocopy -b from_file to_drive ocopy -r from_drive to_dir
Note the important OCOPY
options described in Table 29-4.
Table 29-4 OCOPY Options
Option | Action |
---|---|
|
Splits the input file into multiple output files. This option is useful for backing up to devices that are smaller than the input file. |
|
Combines multiple input files and writes to a single output file. This option is useful for restoring backups created with the |
29.9.2.1 Backing Up with OCOPY: Example
In this example, assume the following:
-
Data file
12
is mounted on the\\.\G:
raw partition. -
The
C:
drive mounts a file system. -
The database is open.
To back up the data file on the raw partition \\.\G:
to a local file system, you can run the following command at the prompt after placing data file 12
in backup mode:
OCOPY "\\.G:" C:\backup\datafile12.bak
29.9.2.2 Specifying the -b and -r Options for OCOPY: Example
In this example, assume the following:
-
\\.\G:
is a raw partition containing data file7
-
The
E:
drive is a removable disk drive. -
The database is open.
To back up the data file onto drive E:
, you can execute the following command at the Windows prompt after placing data file 7
in backup mode:
# first argument is file name, second argument is drive OCOPY -b "\\.\G:" E:\
When drive E:
fills up, you can use another disk. In this way, you can divide the backup of data file 7
into multiple files.
Similarly, to restore the backup, take the tablespace containing data file 7
offline and run this command:
# first argument is drive, second argument is directory OCOPY -r E:\ "\\.\G:"
29.10 Making Backups with Third-Party Snapshot Technologies
You can use Storage Snapshot Optimization to take third-party snapshots of the database, without placing the database in backup mode. The snapshots must conform to the requirements described in this section.
Storage Snapshot Optimization provides the following benefits:
-
Eliminates the complexity and overhead associated with placing the database in backup mode.
-
Performs the recovery in a single step by using the
RECOVER ... SNAPSHOT TIME
command. You can recover either to the current time or to a point in time after the snapshot was taken.
To use Snapshot Storage Optimization, the third-party snapshot technology must conform to the following requirements:
-
The database is crash consistent during the snapshot.
-
The snapshot preserves write order for each file.
-
The snapshot technology stores the time at which the snapshot is completed.
If the vendor cannot guarantee compliance with these requirements, then you must place your data files into backup mode by using the ALTER DATABASE
or ALTER TABLESPACE
statement with the BEGIN BACKUP
clause. Place your data files in backup mode just before you create the snapshot. When a tablespace is in backup mode, the database writes the before image for an entire block to the redo stream before modifying a block. The database also records changes to the block in the online redo log. Backup mode also freezes the data file checkpoint until the file is removed from backup mode. Oracle Database performs this safeguard because it cannot guarantee that a third-party backup tool copies the file header before copying the data blocks. Immediately after the snapshot is created, use the ALTER DATABASE
or ALTER TABLESPACE
command with the END BACKUP
clause to take the data files out of backup mode. You need not wait until the snapshot is actually copied to the backup media to end backup mode.
Note:
RMAN does not support storage-based replication technologies when the database being backed-up resides on Oracle Automatic Storage Management (Oracle ASM).
See Also:
Volume Shadow Copy Service (VSS) is a set of Windows APIs that enable applications to create consistent snapshots called shadow copies. The Oracle VSS writer runs as a service on Windows systems and is integrated with VSS-enabled applications. You can use these applications to create snapshots of database files managed by the Oracle instance. For example, you can make shadow copies of an Oracle database while it is open read/write.
See Also:
Oracle Database Platform Guide for Microsoft Windows to learn how to back up and recover the database with VSS-enabled applications
29.11 Verifying User-Managed Data File Backups
You must periodically verify your backups to ensure that they are usable for recovery.
This section contains the following topics:
29.11.1 Testing the Restoration of Data File Backups
The best way to test the usability of data file backups is to restore them to a separate host and attempt to open the database, performing media recovery if necessary. This option requires that you have a separate host available for the restore procedure.
See Also:
"Performing Complete Database Recovery" to learn how to recover files with SQL*Plus
29.11.2 Running the DBVERIFY Utility
The DBVERIFY
program is an external command-line utility that performs a physical data structure integrity check on an offline data file. Use DBVERIFY
to ensure that a user-managed backup of a data file is valid before it is restored or as a diagnostic aid when you have encountered data corruption problems.
The name and location of DBVERIFY
is dependent on your operating system. For example, to perform an integrity check on data file users01.dbf
on Linux or UNIX, run the dbv
command as follows:
% dbv file=users01.dbf
Sample dbv
output follows:
DBVERIFY - Verification starting : FILE = users01.dbf DBVERIFY - Verification complete Total Pages Examined : 250 Total Pages Processed (Data) : 1 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 0 Total Pages Failing (Index): 0 Total Pages Processed (Other): 2 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 247 Total Pages Marked Corrupt : 0 Total Pages Influx : 0
See Also:
Oracle Database Utilities to learn about DBVERIFY