Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to use RMAN to restore and restore the database". In the daily operation, I believe that many people have doubts about how to use RMAN to restore and restore the database. The editor consulted all kinds of information and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "how to restore and restore the database using RMAN". Next, please follow the editor to study!

I. the use of DRA, a data recovery consultant

Data recovery Advisor (Data Recovery Advisor,DRA) is a new tool in Oracle 11g to diagnose and fix database problems. There are two kinds of interfaces: RMAN executable program interface and enterprise manager Enterprise Manager interface. DRA can generate scripts to repair corruption in data files and (in some environments) control files. It does not recommend issues with server parameter files and online log files. The decision of DRA depends on automatic diagnosis knowledge base (Automatic Diagnostic Repository,ADR) and health examination Health Monitor.

Health Monitor is a set of checks whose results are not stored in the database but in the file system. The reason is that the nature of some errors determines that the database is no longer available, so an external knowledge base is needed to store the results of Health Monitor. This knowledge base is the automatic diagnosis knowledge base (ADR), which is located in the directory specified by the diagnostic_dest instance parameter.

Show parameter diagnostic_dest

NAME TYPE VALUE

Diagnostic_dest string C:\ ORACLE

You can see that the default is in the base directory of the Oracle installation, and there is a diag subdirectory where ADR is stored.

The health check Health Monitor runs different check contents at different schema stages of the database:

In nomount mode, only the integrity of the control file can be checked because the database is not loaded yet

In mount mode, the integrity of the control file, online redo log file, and data file header is checked, as well as the integrity of the archived log file

In open mode, each data file block can be scanned for corruption and the integrity of data dictionaries and undo segments can be checked.

The function of DRA has some limitations. For example, DRA works only if the instance is in nomount or higher mode. If there is a problem with the initialization file, it will not help. But once in nomount mode, it can diagnose problems with the control file and generate a script for restore using an existing valid copy (if it doesn't exist, try to extract a copy from the backup set). Once the database enters mount mode, DRA can diagnose problems with missing or corrupted data files, as well as missing online log filegroups, and generate repair scripts. DRA can only be used in a single instance database environment, cannot be used in a RAC cluster environment, and cannot be used in a Data Guard standby database. If the RAC database fails, you can load it in single instance mode, use DRA to repair the corrupted content, and then close it and reopen it in RAC mode.

The use of data recovery Advisor DRA is very simple, and the following three steps are included in the RMAN environment:

1) use the list failure command to list faults

2) use advise failure command to give advice on fault handling.

3) use the repair failure command to fix the fault.

DRA, the data recovery consultant, uses the information collected by the health check Health Monitor to find the problem and build a RMAN script to fix it. If you do not first ask DRA to list faults, DRA does not generate recommendations. DRA does not provide any advice for failures that occur after the last list.

The following is an example of the use of a data recovery consultant (DRA).

1) enter the RMAN program at the operating system prompt

C:\ Users\ Administrator > rman target /

Recovery Manager: Release 11.2.0.4.0-Production on Thursday May 3 10:33:33 2018

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

Connected to the target database: MES (DBID=2056489697)

2) confirm that a full backup of the SYSAUX tablespace exists

RMAN > list backup of tablespace sysaux

Replace the recovery directory with the target database control file

Backup set list

=

BS keyword type LV size device type elapsed time completion time

241 Incr 0 312.86M DISK 00:01:00 2018-05-03 10:31:49

BP keyword: 241status: AVAILABLE compressed: YES tag: TAG20180503T103048

Paragraph name: e:\ RMAN_BAK\ MES\ MES_85T1V56P_1_20180503

List of data files in backup set 241

File LV type Ckp SCN Ckp time name

20 Incr 1640735 2018-05-03 10:30:49 D:\ ORADATA\ MES\ SYSAUX01.DBF

If there is no backup, create one.

RMAN > backup as backupset tablespace sysaux

3) close the instance and exit

RMAN > shutdown immediate

RMAN > exit

4) use the operating system program to delete the data files in the sysaux tablespace

5) use SQL*Plus to connect to the database and try to start

C:\ Users\ Administrator > sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Thursday May 3 10:42:42 2018

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to an idle routine.

10:42:42 SYS @ mes AS SYSDBA > startup

The ORACLE routine has been started.

Total System Global Area 1286066176 bytes

Fixed Size 2280896 bytes

Variable Size 771752512 bytes

Database Buffers 503316480 bytes

Redo Buffers 8716288 bytes

The database is loaded.

ORA-01157: unable to identify / lock data file 2-see DBWR trace file

ORA-01110: data file 2: d:\ ORADATA\ MES\ SYSAUX01.DBF'

Prompt that the sysaux01.dbf file is missing at startup and stay in mount load mode.

6) start RMAN again and diagnose the problem

C:\ Users\ Administrator > rman target /

Recovery Manager: Release 11.2.0.4.0-Production on Thursday May 3 10:44:17 2018

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

Connected to the target database: MES (DBID=2056489697, not open)

RMAN > list failure

Replace the recovery directory with the target database control file

Database failure list

=

Summary of time for failed ID priority status detection

--

4932 HIGH OPEN 2018-05-02 23:01:58 one or more non-system data files are missing

4908 HIGH OPEN 2018-05-02 23:01:58 one or more non-system data files require media recovery

Returns a message indicating the absence of a non-system data file.

7) generate suggestions about the fault

RMAN > advise failure

Database failure list

=

Summary of time for failed ID priority status detection

--

4932 HIGH OPEN 2018-05-02 23:01:58 one or more non-system data files are missing

4908 HIGH OPEN 2018-05-02 23:01:58 one or more non-system data files require media recovery

Analyzing automatic repair options; this may take some time

Assigned channel: ORA_DISK_1

Channel ORA_DISK_1: SID=221 device type = DISK

Analysis of automatic repair options completed

Necessary manual operation

=

There are no manual operations available

Can be operated by contestants

=

1. If you inadvertently rename or move the file D:\ ORADATA\ MES\ SYSAUX01.DBF, restore the file

two。 If you restore the wrong version of the data file D:\ ORADATA\ MES\ SYSAUX01.DBF, replace it with the correct version

Automatic repair option

=

Option repair description

--

1 restore and restore data files 2

Policy: repair operations include full media recovery without data loss

Repair script: C:\ ORACLE\ diag\ rdbms\ mes\ mes\ hm\ reco_339425269.hm

8) Open the repair script and study its contents, and you can see that the following repair statements are included

Restore datafile 2

Recover datafile 2

Sql 'alter database datafile 2 online'

10) to run the script, use the following command

RMAN > repair failure

Policy: repair operations include full media recovery without data loss

Repair script: C:\ ORACLE\ diag\ rdbms\ mes\ mes\ hm\ reco_339425269.hm

Fix the contents of the script:

# restore and recover datafile

Restore datafile 2

Recover datafile 2

Sql 'alter database datafile 2 online'

Are you sure you want to perform the above fixes (enter YES or NO)? Y

Execute repair script

Start restore at 10:50:36 on 2018-05-03

Use channel ORA_DISK_1

Channel ORA_DISK_1: starting to restore data file backup set

Channel ORA_DISK_1: specifying data files to restore from the backup set

Channel ORA_DISK_1: restore the data file 00002 to D:\ ORADATA\ MES\ SYSAUX01.DBF

Channel ORA_DISK_1: reading backup fragment E:\ RMAN_BAK\ MES\ MES_85T1V56P_1_20180503

Channel ORA_DISK_1: segment handle = E:\ RMAN_BAK\ MES\ MES_85T1V56P_1_20180503 tag = TAG20180503T103048

Channel ORA_DISK_1: backup fragment 1 restored

Channel ORA_DISK_1: restore completed. Time: 00:00:35

Completion of restore at 10:51:12 in 2018-05-03

Start recover at 10:51:12 on 2018-05-03

Use channel ORA_DISK_1

Starting media recovery

Media recovery complete, time: 00:00:01

Completion of recover at 10:51:13 in 2018-05-03

Sql statement: alter database datafile 2 online

Repair of the fault has been completed

Do you want to open the database (enter YES or NO)? Y

The database is open

As you can see, the system automatically locates the latest backup files and prompts you to open the database after data restore and media recovery.

II. Complete recovery after missing data files

In the Oracle database, some files are critical, which means that the database instance will be terminated and cannot be reopened until the corruption has been repaired. Some files are noncritical, and if these files are damaged, the database can remain open or can be opened.

The data files that make up the SYSTEM table space and the currently active undo table space (specified by the undo_tablespace parameter) are considered critical, as is any copy of the control file, and corruption of such files will cause the instance to terminate. The files that make up the user data tablespace are non-critical, and the corruption of these files usually does not cause the instance to crash. Take the damaged file offline and make its contents inaccessible, leaving the rest of the database open.

In general, the corruption of any number of data files can be repaired by full recovery and there is no data loss. Restore corrupted files and apply redo to keep them up to date. Of course, the prerequisite is that all archive log files generated since the last backup of the data file are available. An incomplete recovery means that the database is restored and only redone to a specific point is applied, after which all work done is lost. Why not recover completely? There is usually only one reason: user error. If there is an error in the user's operation, you need to return the entire database to before the error occurred. The second reason for incomplete recovery is that a full recovery was attempted but failed. This occurs when the archive log file is missing or all copies of the current online log filegroup are missing.

1. Recovery of data files in non-archived log mode

In non-archived log mode, there is no technology to support recovery because the archive logs required for recovery do not exist, so they can only be restored, but this also loses all the work done since the backup was created.

The restore process can only be run in load mode

Shutdown abort

Startup mount

Restore database

Recover database

Alter database open resetlogs

2. Recovery when non-critical files are lost in archive log mode

In archive mode, if a non-critical data file is corrupted, the restore and recovery process consists of the following four steps:

1) take the damaged data file offline (maybe the system is automatically complete). If it is not offline, you can execute the following command, such as specifying the 1percent file offline.

RMAN > sql'alter database datafile 10 offline'

After the damaged files are offline, the database should be ready to open.

2) restore data files

RMAN > restore datafile 10

3) restore data files

RMAN > recover datafile 10

4) bring data files online

RMAN > sql'alter database datafile 10 online'

Some of the above commands are SQL commands rather than RMAN commands, so when executed in a RMAN environment, you need to add the sql prefix.

If an incremental backup strategy is used when backing up, restore and restore operations will first take advantage of the level 0 backup, then apply the level 1 backup, and finally apply the redo data to complete the restore. The logic behind this approach (minimizing the use of redo) is that it is always faster to apply incremental backups than to apply redo. The presence or absence of incremental backups does not lead to syntax differences when using the recover command, and RMAN will calculate the best way to perform the operation by asking its repository.

3. Recovery when key data files are lost

If the database crashes because of a corrupt critical data file, the first action is to try to start it. This stops in load mode and writes an error message to the alarm log. To restore, you can follow the same process as non-critical files, except that restore and restore can only be done in load mode because the database can no longer be opened. For example, to restore the resume file, restore and restore include the following four steps:

1) the database starts to load mode

RMAN > startup mount

2) restore data files

RMAN > restore datafile 3

3) restore data files

RMAN > recover datafile 3

4) Open the database

RMAN > alter database open

III. Incomplete recovery after missing data files

There are only two reasons for performing an incomplete recovery: a full recovery is not feasible or data loss is intentional. "if the archive log is missing or all copies of the current online redo log filegroup are missing, an incomplete recovery must be performed." For user errors, you can restore the entire database and restore it to the point before the error occurred, but also lose all the correct work done since then.

The special case of incomplete recovery is the recovery of control files. Ideally, all restore operations will be booted with the current control file, but sometimes it is not possible and a backup of the control file must be restored. There are two possible reasons: 1) all copies of the current control files have been lost and cannot be recreated by running the create controlfile command.

2) the current control file can no longer accurately describe the version of the database you want to restore, such as the structure of tablespaces and data files has changed since the last backup. At this time, when you restore the data file, you must first restore the control file.

Incomplete recovery is divided into four steps:

1) load the database

2) restore all data files

3) restore the database to a certain point (including three specified methods as described below)

4) Open the database with the reset log

"compared to a full recovery, an incomplete recovery differs in the following ways:"

1) at the beginning, full recovery can occur when the database is open, unless the corrupted file is critical and incomplete recovery can only be done in load mode.

2) when restoring, for complete recovery, only the damaged data files need to be restored, while incomplete recovery needs to restore all data files, which must be restored earlier than the point you want to restore.

3) when restoring, you need to apply the redo data from archived and online logs to the desired point, and there are several options for specifying the point to which you want to restore.

4) when you open it, you need to open the database with RESETLOGS, which will reinitialize the online redo log file and create a new avatar of the database. The avatar of the database is the version of the database with a new redo thread (the log sequence number starts at 1). Backup and archive logs are specific to one avatar, and the backup and archive logs generated by different avatars are logically separate from each other and cannot be used with each other. For this reason, when you reset the log files using RESETLOGS, you should immediately re-perform a full database backup.

After loading the database and restoring all data files (including restore control files if necessary), there are three options for incomplete recovery operations:

1) UNTIL TIME

This option applies the redo roll forward data file to a specific time with a precision of seconds. This option is usually used to correct user errors, and if the user makes an irreversible error but knows when the error was made, it can be restored to before the error occurred based on time.

2 、 UNTIL SCN

If you know the exact system change number SCN at the time of the error, you can use this option to accurately stop the recovery before the error occurs, thus losing as little data as possible. This requires the use of an advanced tool such as Log Miner or the flashback feature to determine the SCN when the transaction is committed.

3 、 UNTIL SEQUENCE

"if the archive log file or online log filegroup is missing, use this option to stop the recovery to the specified archive log sequence number."

By default, RMAN should be restored according to the most recent backup and redo applied. However, incomplete recovery is different, you must restore from a backup that is earlier than the recovery point, and then roll forward to the point in time to which you need to restore. The best way to ensure that restore and restore use the same UNTIL TIME is to complete both restore and restore commands in a run block.

RMAN > run {

Startup mount

Set until time = "to_date ('2015-11-01 10 yyyy-mm-dd hh34:mi:ss')"

Restore database

Recover database

Alter database open resetlogs

}

The command set until time specifies a time when all subsequent commands will be applied, and the database will eventually be restored and restored to the state at that point in time. Of course, you can also specify the UNTIL value separately.

RMAN > restore database until time 'sysdate-7'

RMAN > recover database until time '27Mutual OCTMUR 08'

If the time format is not specified here as in the previous run block, then time recognition depends on the initialization parameter NLS_DATE_FORMAT, as the command above assumes that NLS_DATE_FORMAT is set to dd-MON-rr.

Control the automatic backup and recovery of files

The database relies heavily on the control file, and if the control file is damaged, the database will crash. The RMAN situation is even worse, where the RMAN repository for backup information is stored in the control file. Therefore, if the control file is corrupted, the database will crash on the one hand, and RMAN will not be able to recover it on the other because the information needed by RMAN is not available. This is a recursive problem, and the solution is to use the RMAN catalog database or enable automatic backup of control files.

To enable automatic backup of control files, execute the following command at the RMAN prompt

RMAN > CONFIGURE CONTROLFILE AUTOBACKUP ON

After this command is executed, each RMAN operation automatically backs up the control file and spfile file to a backup set in a known location. Specify the path of the automatic backup. If it is not specified, it is saved in the flashback recovery area by default. The file name is based on DBID. The ID of the database is a 10-digit number. DBID can be seen when it starts RMAN, or it can be learned through the field DBID of the query view v$database. The following settings control the save path for automatic backup of files

RMAN > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO'e:\ rman_bak\ mes\ control_bak\% F'

To restore the control file, execute the following command while the database is in unloaded mode

RMAN > restore controlfile from autobackup

This command extracts the control file from the most recent automatic backup and restores it to the location specified in the spfile initialization parameter file. The database can then be loaded with the restored control file, and RMAN will be able to locate the desired backup to restore the rest of the database. Since the control file has not been loaded in non-load mode, RMAN does not know the location of the automatic backup control file, so it restores the control file (including spfile) from the default location, which is% ORACLE_HOME%\ database for Windows and $ORACLE_HOME\ dbs for Unix systems. Therefore, you should first copy the control file (including spfile) of the last automatic backup to this path before restoring.

If the spfile file is also missing, you can start the instance with a dumb initialization parameter file: a pfile file with only one parameter db_name (such as an one-line db_name=mes). Then connect with RMAN and issue the following command to replace it with your own DBID

RMAN > set dbid 1979336967

RMAN > restore spfile from autobackup

This command restores the spfile file to the system default location (Windows is% ORACLE_HOME%\ database,Unix is $ORACLE_HOME\ dbs). Then restart the instance in non-load mode to restore the control file and the subsequent database.

The ID number of the database can generally be obtained from the control file name of the backup. For example, the backup of the control file Cmuri 1979336967-20151116-00Bing 1979336967 is DBID. DBID is also prompted when RMAN connects to the target database. The view v$database also contains information about the DBID field.

RMAN only these two restore commands for spfile files and control files can be executed in unloaded mode, and all other commands can only be executed in load mode or open mode.

The following script starts the instance with the dumb initialization parameter file dummy.ora, and gradually completes the complete restore and recovery of the database (assuming that all data files, control files, and spfile files have been lost)

Run {

Startup nomount pfile = C:\ oracle\ product\ 11.2.0\ dbhome_1\ database\ dummy.ora

Set dbid = 1979336967

Restore spfile from autobackup

Shutdown abort

Startup nomount

Restore controlfile from autobackup

Alter database mount

Restore database

Recover database

Alter database open resetlogs

}

If automatic backup of control files is not previously enabled, but there is a backup set that contains spfile and controlfile, the command can specify a backup that contains that content

Restore spfile from'e:\ rman_bak\ mes\ control_bak\ Cmurf 2056489697-20180502-06'

5. Incomplete recovery experiment

1. Construction of pre-experiment backup.

Change the backup configuration of the control file, set it to automatic backup, and specify the destination path for the backup

RMAN > configure controlfile autobackup on

RMAN > configure controlfile autobackup format for device type disk to'e:\ rman_bak\ mes\ control_bak\% F'

Change the target location and naming convention of the data file backup set

RMAN > configure channel device type disk format'e:\ rman_bak\ mes\% dudes% ubiquitous% cations% T'

Perform a full database incremental level 1 compressed backup and delete the previous (no longer needed) archive log files

RMAN > backup incremental level 1 as compressed backupset database plus archivelog delete all input

2. Be clear about the point in time that you need to recover

When the fault occurs, we need to restore the system to a certain time before the fault occurs. The closer this time is to the fault time, the more we can ensure that the user data will not be lost after recovery, so let's make clear the current time before the experiment.

Select sysdate from dual

SYSDATE

-

2018-05-03 12:09:34

3. Fault simulation

Suppose that the CMES tablespace is accidentally deleted due to user misoperation, resulting in the loss of important data.

Drop tablespace cmes including contents and datafiles

4. Restore control files

Due to the deletion of the tablespace, the structure of the database has changed, and the change has been recorded in the current control file. Therefore, if you want to return to the state before the failure, you must first restore the control file before the tablespace was deleted, load the database with the original control file, and then restore the tablespace and data files.

Log in to RMAN, build a run block, set the restore time, and then restore the control file to a specified path

RMAN > run {

2 > shutdown abort

3 > startup mount

4 > set until time = '2018-05-03 12 purl 09Frev 34'

5 > restore controlfile to'd:\ control.ctl'

6 >}

Oracle instance is closed

Connected to the target database (not started)

Oracle instance has been started

The database is mounted

The total system global area is 1286066176 bytes

Fixed Size 2280896 byt

Variable Size 771752512 byt

Database Buffers 503316480 byt

Redo Buffers 8716288 byt

Executing command: SET until clause

Start restore at 12:18:35 on 2018-05-03

Assigned channel: ORA_DISK_1

Channel ORA_DISK_1: SID=189 device type = DISK

Channel ORA_DISK_1: starting to restore data file backup set

Channel ORA_DISK_1: restoring control files

Output file name = D:\ CONTROL.CTL

Channel ORA_DISK_1: reading backup fragment E:\ RMAN_BAK\ MES\ CONTROL_BAK\ Cmury 2056489697-20180503-02

Channel ORA_DISK_1: segment handle = E:\ RMAN_BAK\ MES\ CONTROL_BAK\ Cmur2056489697-20180503-02 tag = TAG20180503T105757

Channel ORA_DISK_1: backup fragment 1 restored

Channel ORA_DISK_1: restore completed. Time: 00:00:01

Completion of restore at 12:18:37 in 2018-05-03

5. Reload the database with the restored control file

Alter system set control_files ='D:\ control.ctl' scope = spfile

Shutdown abort

Startup mount

6. Restore and restore the database according to the set point in time

Build the following run blocks in the RMAN session, set the point in time for restore and recovery, then restore and restore the database, and open the database

RMAN > run {

Allocate channel c1 type disk

Allocate channel c2 type disk

Set until time = '2018-05-03 12 purl 09purl 34'

Restore database

Recover database

Alter database open resetlogs

}

Replace the recovery directory with the target database control file

Assigned channel: C1

Channel C1: SID=221 device type = DISK

Assigned channel: c2

Channel c2: SID=3 device type = DISK

Executing command: SET until clause

Start restore at 12:25:41 on 2018-05-03

Start implicit crosscheck backup at 12:25:41 on 2018-05-03

5 objects that have been cross checked

Completion of implicit crosscheck backup at 12:25:41 in 2018-05-03

Start implicit crosscheck copy at 12:25:41 on 2018-05-03

Completion of implicit crosscheck copy at 12:25:42 in 2018-05-03

Search for all files in the recovery area

A catalogue of documents is being compiled.

No cataloging of files

Channel C1: starting to restore data file backup set

Channel C1: specifying data files to restore from the backup set

Channel C1: restore the data file 00001 to D:\ ORADATA\ MES\ SYSTEM01.DBF

Channel C1: restore the data file 00002 to D:\ ORADATA\ MES\ SYSAUX01.DBF

Channel C1: restore the data file 00003 to D:\ ORADATA\ MES\ UNDOTBS01.DBF

Channel C1: restore the data file 00004 to D:\ ORADATA\ MES\ USERS01.DBF

Channel C1: restore the data file 00005 to D:\ ORADATA\ MES\ EXAMPLE01.DBF

Channel C1: reading backup fragment E:\ RMAN_BAK\ MES\ MES_85T1V56P_1_20180503

Channel c2: starting to restore data file backup set

Channel c2: specifying data files to restore from the backup set

Channel c2: restore the data file 00006 to D:\ ORADATA\ MES\ CMES01.DBF

Channel c2: restore the data file 00007 to D:\ ORADATA\ MES\ RMES01.DBF

Channel c2: restore the data file 00008 to D:\ ORADATA\ MES\ HMES01.DBF

Channel c2: restore the data file 00009 to D:\ ORADATA\ MES\ INDX01.DBF

Channel c2: restore the data file 00010 to D:\ ORADATA\ MES\ FDA01.DBF

Channel c2: reading backup fragment E:\ RMAN_BAK\ MES\ MES_86T1V58Q_1_20180503

Channel c2: segment handle = E:\ RMAN_BAK\ MES\ MES_86T1V58Q_1_20180503 tag = TAG20180503T103048

Channel c2: backup fragment 1 restored

Channel c2: restore complete, time: 00:00:15

Channel C1: segment handle = E:\ RMAN_BAK\ MES\ MES_85T1V56P_1_20180503 tag = TAG20180503T103048

Channel C1: backup fragment 1 restored

Channel C1: restore complete, time: 00:00:46

Completion of restore at 12:26:30 in 2018-05-03

Start recover at 12:26:30 on 2018-05-03

Starting media recovery

The archive log of thread 1 sequence 7 already exists on disk as a file D:\ ORADATA\ MES\ REDO01.LOG

The archive log of thread 1 sequence 8 already exists on disk as a file D:\ ORADATA\ MES\ REDO02.LOG

Archive log file name = D:\ ORADATA\ MES\ REDO01.LOG thread = 1 sequence = 7

Archive log file name = D:\ ORADATA\ MES\ REDO02.LOG thread = 1 sequence = 8

Media recovery complete, time: 00:00:03

Completion of recover at 12:26:36 in 2018-05-03

The database is open

Released channel: C1

Released channel: c2

7. Restore the reuse status of control files

After the database is opened, view the currently enabled control files

Show parameter control_files

NAME TYPE VALUE

-

Control_files string D:\ CONTROL.CTL

Modify the parameters of the control file to return to the original multiplexing state

Alter system set control_files='d:\ oradata\ mes\ control01.ctl','e:\ fast_recovery_area\ mes\ control02.ctl' scope=spfile

Shut down the database

Shutdown immediate

Copy the control file d:\ control.ctl to d:\ oradata\ mes\ control01.ctl and e:\ fast_recovery_area\ mes\ control02.ctl respectively.

Restart the database

Startup

Reconfirm the enabled control file after the database is opened

Show parameter control_files

NAME TYPE VALUE

-

Control_files string D:\ ORADATA\ MES\ CONTROL01.CTL

E:\ FAST_RECOVERY_AREA\ MES\ CONT

ROL02.CTL

Because the restore uses RESETLOGS to reset the online log files (the log sequence number starts again at 1), a new avatar of the database is created, and the previous backup and archive logs have been separated from the current database, so you can delete the previous backup and archive logs under RMAN and perform a full database backup as soon as possible.

6. Restore using a copy of the image

If the backup strategy includes a copy of the image, then another restore option is actually no restore at all. Because the copy of the image is exactly the same as the original data file, you can use it immediately if it is on disk. All you need to do is tell the database the location of the copy of the image, and then restore the copy. Restoring an image copy can save a lot of time compared to the delay caused by extracting data files from the backup set.

You can create an image copy of the entire database using the following RMAN command

RMAN > backup as copy database

If the default backup location parameter is not changed, the command copies all data files to the flashback recovery area as a copy of the image. To use an image copy, first take the original data file offline (which may have occurred automatically), then update the direction of the data file in the control file, and then restore the copy file. For example, there is a copy created as follows

RMAN > backup as copy datafile 5 format'e:\ rman_bak\ mes\ cmes01.dbf'

You can use it through the following script

RMAN > run {

Sql'alter database datafile 5 offline'

Set newname for datafile 5 to'e:\ rman_bak\ mes\ cmes01.dbf'

Switch datafile 5

Recover datafile 5

Sql'alter database datafile 5 online'

}

If you have created an image copy of the entire database, you can restore the entire database with one command

RMAN > switch database to copy

Another way to use an image copy is to update the copy through an incremental backup to maintain the newer state of the copy. This requires that you take a full copy of the database as a starting point, then create an incremental backup and apply it to the copy. The following two channels are opened for parallel backup and the copy is updated to the flashback recovery area. The file name format will be OMF.

RMAN > run {

Allocate channel c1 type disk

Allocate channel c2 type disk

Backup incremental level 1 for recover of copy with tag 'inc_copy' database

Recover copy of database with tag 'inc_copy'

Release channel c1

Release channel c2

}

When the command was first run, RMAN attempted an incremental level 1 backup, but since there was no previous level 0 backup, a level 0 backup was performed. This statement produces a copy of the image. The recover command will fail the first time it is executed because there are no copies and incremental backups available. When the script runs for the second time, the first command performs an incremental level 1 backup, extracting all the change blocks since the last backup, and the second command applies the incremental change to the copy. This behavior is continued with each subsequent run. This strategy of updating replicas incrementally can make the recovery process very fast.

At this point, the study on "how to use RMAN to restore and restore the database" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.