• Making User-Managed Backups of the Whole Database

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.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.

1. Making Consistent Whole Database Backups

To make a consistent whole database backup:

1. If the database is open, then use SQL*Plus to shut down the database with the NORMAL, IMMEDIATE, or TRANSACTIONAL options.
2. 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.

% cp $ORACLE_HOME/oradata/trgt/*.dbf /disk2/backup

% cp $ORACLE_HOME/oradata/trgt/arch/* /disk2/backup/arch

1. Restart the database with the STARTUP command in SQL*Plus.

1. Making Inconsistent Whole Database Backups

2.1 About the Suspend/Resume Feature

如果你是使用磁盘镜像来备份数据库需要把数据库置于SUSPEND状态

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.

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.

一般RAID磁盘也有在镜像时挂起磁盘的功能(否则镜像备份会出现fractured block)，但如果你想在镜像前把数据库cache的脏块写入磁盘需要把数据库置于SUSPEND状态

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.

SUSPEND状态会把当前I/O完成之后停止新的I/O操作.SUSPEND并不是立即生效，它会把当前数据库脏块刷新到磁盘

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.

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.

只在使用磁盘镜像备份时才将数据库置于SUSPEND，因为SUPEND对数据库影响较大

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.

在SUSPEND状态的数据库无法进行RMAN备份只能手动备份

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. 

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.

Note the following restrictions for the SUSPEND/RESUME feature:

1. In an Oracle RAC configuration, do not start a new instance while the original nodes are suspended.
2. No checkpoint is initiated by the ALTER SYSTEM SUSPEND or ALTER SYSTEM RESUME statements.
3. You cannot issue SHUTDOWN with IMMEDIATE, NORMAL, or TRANSACTIONAL options while the database is suspended.
4. 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. 在suspended状态可以使用shutdown abort来重新激活数据库

2.2 Making Inconsistent Whole Database Backups

1. Place the database in backup mode:

ALTER DATABASE BEGIN BACKUP;

1. (Option)If your mirror system has problems with splitting a mirror while disk writes are occurring, then suspend the database:

ALTER SYSTEM SUSPEND;

Verify that the database is suspended by querying the V$INSTANCE view. For example:

SELECT DATABASE_STATUS FROM V$INSTANCE;

DATABASE_STATUS

-----------------

SUSPENDED

1. Split the mirrors at the operating system or hardware level.
2. (Option)End the database suspension. For example, issue the following statement:

ALTER SYSTEM RESUME;

Establish that the database is active by querying the V$INSTANCE view. For example, enter:

SELECT DATABASE_STATUS FROM V$INSTANCE;

DATABASE_STATUS

-----------------

ACTIVE

1. Take the database end of backup mode::

ALTER DATABASE END BACKUP;

1. Copy the control file and archive the online redo logs as usual for a backup.

1. Making User-Managed Backups of CDBs and PDBs

To make a consistent whole database backup for a CDB:

1. Open SQL*Plus. Connect to the root as a user with the SYSDBA or SYSBACKUP system privilege
2. If the database is open, then use SQL*Plus to shut down the database with the NORMAL, IMMEDIATE, or TRANSACTIONAL options.
3. 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.

% cp $ORACLE_HOME/oradata/cdb1/*.dbf /disk3/backup

% cp $ORACLE_HOME/oradata/cdb1/arch/* /disk3/backup/arch

1. Restart the database with the STARTUP command in SQL*Plus.

To make a consistent backup of a PDB:

1. Open SQL*Plus. Connect to the PDB as a user with the SYSDBA or SYSBACKUP system privilege
2. Begin the backup with the SQL ALTER DATABASE command.

ALTER DATABASE BEGIN BACKUP;

1. Use an operating system utility to copy the data files belonging to the PDB to a backup device.
2. End the backup with the SQL ALTER DATABASE command.

ALTER DATABASE END BACKUP;

• Making User-Managed Recovery of the Whole Database

This procedure assumes the following:

1. The current control file is available.
2. You have backups of all needed data files.
3. All necessary archived redo logs are available.

To restore and recover damaged or missing data files:

1. Determine which data file need recovery using V$RECOVER_FILE

SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME

FROM V$RECOVER_FILE;

1. Determine which archivelogs are needed using V$RECOVERY_LOG and V$ARCHIVED_LOG

V$ARCHIVED_LOG lists file names for all archived redo logs, whereas V$RECOVERY_LOG lists only the archived redo logs that the database needs to perform media recovery. V$RECOVERY_LOG view also includes the probable names of the files based on the naming convention specified by using the LOG_ARCHIVE_FORMAT parameter.

如果需要使用归档日志备份，则在恢复前需要先还原归档日志

1. If the database is open, then shut it down. For example:

SHUTDOWN IMMEDIATE

1. Inspect the media to determine the source of the problem.

If the hardware problem that caused the media failure was temporary, and if the data was undamaged (for example, a disk or controller power failure occurred), then no media recovery is required: start the database and resume normal operations.

If you cannot repair the problem, then proceed to the Step 5.

1. If the files are permanently damaged, then identify the most recent backups for the damaged files. Restore only the data files damaged by the media failure: do not restore undamaged data files or any online redo log files.

For example, if ORACLE_HOME/oradata/trgt/users01.dbf is the only damaged file, then you may find that /backup/users01_10_24_02.dbf is the most recent backup of this file.

1. Use an operating system utility to restore the data files:

% cp /backup/users01_10_24_06.dbf $ORACLE_HOME/oradata/trgt/users01.dbf

Use the following guidelines when determining where to restore data file backups:

1. If the hardware problem is repaired and you can restore the data files to their default locations, then restore the data files to their default locations and begin media recovery.
2. If the hardware problem persists and you cannot restore data files to their original locations, then restore the data files to an alternative storage device. Indicate the new location of these files in the control file with the ALTER DATABASE RENAME FILE statement.

1. Connect to the database with administrator privileges. Then start a new instance and mount, but do not open, the database. For example, enter:

STARTUP MOUNT

1. If you restored one or more damaged data files to alternative locations, then update the control file of the database to reflect the new data file names:

ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO

                           '/disk2/users01.dbf';

1. Obtain the data file names and statuses of all data files by checking the list of data files that normally accompanies the current control file or by querying the V$DATAFILE view:

SELECT NAME,STATUS FROM V$DATAFILE;

1. Ensure that all data files requiring recovery are online. The only exceptions are data files in an offline tablespace that was taken offline normally or data files in a read-only tablespace:

ALTER DATABASE DATAFILE '/oracle/dbs/tbs_10.f' ONLINE;

If a specified data file is already online, then the database ignores the statement. If you prefer, create a script to bring all data files online simultaneously, as in the following example:

SPOOL onlineall.sql

SELECT 'ALTER DATABASE DATAFILE '''||name||''' ONLINE;' FROM V$DATAFILE;

SPOOL OFF

SQL> @onlineall

1. If you restored archived redo logs to an alternative location, then specify the location before media recovery with the LOGSOURCE parameter of the SET command in SQL*Plus:

SET LOGSOURCE /tmp

Alternatively, you can skip Step 11 and use the FROM parameter on the RECOVER command as in Step 12. For example, if the logs are staged in /tmp, you can enter the following command:

RECOVER AUTOMATIC FROM '/tmp' DATABASE

1. Issue a statement to recover the database, tablespace, or data file. For example, enter one of the following RECOVER commands:

RECOVER AUTOMATIC DATABASE   # whole database

RECOVER AUTOMATIC TABLESPACE users   # specific tablespace

RECOVER AUTOMATIC DATAFILE '?/oradata/trgt/users01.dbf'; # specific data file

If you choose not to automate the application of archived redo logs, then you must accept or reject each prompted log.

Recovery continues until all required archived and online redo logs have been applied to the restored data files. The database notifies you when media recovery is complete:

Media recovery complete.

If no archived redo logs are required for complete media recovery, then the database applies all necessary online redo log files and terminates recovery.

RECOVER时可将不想或无法恢复(如表空间存于只读或读写慢的磁盘)的表空间数据文件OFFLINE(无法将表空间在MOUNT下OFFLINE)，之后可以在OPEN下单独恢复

SQL>ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/orcl/tools01.dbf' OFFLINE;

SQL> RECOVER AUTOMATIC DATABASE;

SQL> ALTER DATABASE OPEN;

SQL> RECOVER AUTOMATIC DATAFILE '/u01/app/oracle/oradata/orcl/tools01.dbf';

SQL> ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/orcl/tools01.dbf' ONLINE;

1. After recovery terminates, open the database for use:

ALTER DATABASE OPEN;

1. After archived logs are applied, and after making sure that a copy of each archived log group still exists in offline storage, delete the restored copy of the archived redo log file to free disk space. For example:

% rm /tmp/*.arc