Oracle Rman Restore and Recovery Tutorial (v) How to recover a database in archive mode

1, the failure Point database recovery

For a recovery of the point of failure (Point-of-failure), also known as full database recovery, the online redo log must be required to be complete and undamaged. If you lose the online redo log, you must do a incomplete recovery of the database.

Let's assume that the online redo logs and control files are intact, and that we can recover the database completely by following these steps:

Shutdown immediate;

Startup Mount;

Restore database;

Recover database;

Alter database open;

This recovery operation is relatively simple, but there are a few points to note. First, if a file already exists and does not need to be restored, Oracle will not recover the file. Oracle determines whether the file being restored exists. If it already exists, and the existing file is the same as the file being restored, RMAN will not restore the file again. If the file on the backup image differs from the existing database file, RMAN restores the file. Therefore, if you lose one or two data files, you may need to perform a data file or tablespace recovery operation.

These steps are very similar for any archivelog-mode restore operation. After you recover the directory server parameter files and control files, you can perform the RESTORE Database command so that Rman begins to restore all the database data files. Note that in this case, the database must be closed because we want to restore the critical table space (the system tablespace). Although you can perform a archivelog-mode restore operation online, you cannot perform a full time recovery operation online.

Once the data file is restored, Oracle executes the next command (recover database), which enables the Oracle RDBMS to begin restoring the database to the point of failure by applying the archived redo log (which performs full point-in-time recovery). In addition, another advantage of RMAN is that it restores the required archived redo logs from disk so that the redo logs of these archives can be applied in the recovery process. Once the recovery is complete, you can open the database.

2. Table Space Recovery

Sometimes, we only lose a table space data file, at this point, we can choose to restore only this table space, rather than restore the entire database. Tablespace recovery can take place without shutting down the database. Example:

Sql>alter tablespace tablespace_name offline;

Rman>restore tablespace tablespace_name;

Rman>recover tablespace tablespace_name;

Sql>alter tablespace tablespace_name Online;

Note: You cannot restore a single tablespace or data file to a point in time that is different from the other parts of the database.

You can also restore multiple table spaces at the same time:

Sql>alter tablespace tablespace_name1 offline;

Sql>alter tablespace tablespace_name2 offline;

Rman>restore tablespace tablespace_name1,tablespace_name2;

Rman>recover tablespace tablespace_name1,tablespace_name2;

Sql>alter tablespace tablespace_name1 Online;

Sql>alter tablespace tablespace_name2 Online;

3. Data File Recovery

Data file recovery is similar to tablespace recovery, except for the path to the data file. Here we only replace data files that have lost data, while keeping the rest of the table space online so that users can access those parts.

Add a little knowledge:

We can look at the relationship between file IDs and files through SQL. Usually in the error, there will be ID. This is also more convenient in the recovery time.

Sql> select File_id,file_name from Dba_data_files;

file_id file_name

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

4 d:/app/administrator/oradata/orcl/users01. Dbf

3 d:/app/administrator/oradata/orcl/undotbs01. Dbf

2 d:/app/administrator/oradata/orcl/sysaux01. Dbf

1 d:/app/administrator/oradata/orcl/system01. Dbf

5 d:/app/administrator/oradata/orcl/dave0. Dbf

Recovery example:

Sql>alter database datafile 5 offiline;

Sql>alter database DataFile ' d:/app/administrator/oradata/orcl/users01. DBF ' offline;

Rman>restore datafile 5;

Rman>restore datafile ' d:/app/administrator/oradata/orcl/users01. DBF ';

Rman>recover datafile 3;

Rman>recover datafile ' d:/app/administrator/oradata/orcl/users01. DBF ';

Sql>alter database datafile 3 online;

Sql>alter database DataFile ' d:/app/administrator/oradata/orcl/users01. DBF ' online;

4. Restore operations using incremental backups

Oracle automatically determines whether an incremental backup strategy is in use when restoring data files, and automatically applies the required incremental backup sets as needed. In this case, there is no need to perform a different recovery operation.

During a restore operation that uses an incremental backup, the RESTORE command restores only the basic backup. Once this restore operation is complete, you can perform the recover command to apply the incremental backup and archived redo logs to the database. Once the restore operation is complete, we can open the database normally. In all cases, Oracle tries to restore the basic backup and the most recent incremental backup. This reduces the restore time by reducing the redo logs that are applied to the full recovery database.

It is important to note that since the database is likely to have multiple backup sets during the recovery process, the recovery operation will take more time than we expected. However, depending on a variety of factors, the rate of data change is an important factor, and applying an incremental backup set is faster than applying a large number of redo logs, and this incremental backup solution is a quick solution. Therefore, the advantage of an incremental backup is that it is a quick backup strategy and requires a smaller space to save the backup set. But the price is that recovery time is likely to be longer.