1. Recovery directory
The repository is kept in the control file, determined by controlfile_record_keep_time. The reply directory is external, and the space is not limited.
1) The necessity of recovering the directory: ① no longer depends on the control file; ② can store rman scripts; ③ can manage multiple databases in a unified manner and can be managed across platforms; ④ simplify operations without waiting for mount. ⑤ There is no time limit.
RMAN backups are called server-managed backups, and all work is done by the server process. RMAN uses a repository stored in the control file of the target database, this repository contains details of all backups performed, or a dedicated Catalog database can be created to manage this repository. This Catalog database can manage the backup information of multiple databases.
1.5) Space Requirements for Recovery Catalog Database
90MB for SYSTEM tablespace
5MB for TEMP tablespace 5MB
for UNDO tablespace
15MB for RMAN default tablespace for each database registered in the recovery catalog
1MB for each online redo log file
create tablespace catadat datafile '/u01/app/oracle/cata/catadat01.dbf' size 100m autoextend on;
create user cata indetified by *** cata default tablespace catadat;
grant connect,resource,recovery_catalog_owner to cata;
Connect to the target database and the Catalog database,
rman catalog cata/cata@cata;
rman target sys/oracle@orcl catalog cata/cata@cata;
rman target/nocatalog; -- same as rman target/
rman target sys/oracle@orcl catalog cata/cata@cata;
RMAN> create catalog tablespace catadat; -- create a recovery catalog, initialize the warehouse
RMAM> register database; -- register the database, the database to be backed up is in RMAN Register RMAN in the warehouse
> resync catalog; -- synchronize the recovery catalog
RMAN> unregister database; -- unregister the database
RMAN> drop catalog; -- delete the recovery catalog
RMAN> upgrade catalog; -- update the version
RMAN> catalog start with ''; -- The specified folder or path
contains the following file types:
Data file copy (datafile copy)
Backup piece (backup piece)
Control file copy (controlfile ) copy)
Archive log file (archivelog)
3) Use a virtual directory
First create a directory, the steps are the same as above ①②③.
④ 创建 新用户 SQL> create user vpc1 identified by "vpc1" default tablespace users quota unlimited on users temporary tablespace temp;
grant recovery_catalog_owner to vpc1;
⑤ Start RMAN and connect to the recovery catalog database as the basic recovery catalog user
[oracle11@oracle11g ~]$ rman
Recovery Manager: Release 11.2.0.4.0 - Production on Sun May 10 16:09:22 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
RMAN> connect catalog rman/rman@cs
connected to recovery catalog database
RMAN>
⑥ 授权。RMAN> grant catalog for database db to vpc1;
RMAN>grant register database to vpc1;
⑦ Start RMAN and use the virtual private catalog user (not the basic recovery catalog user) to connect to the recovery catalog database
Recovery Manager complete.
[oracle11@oracle11g ~]$ rman
Recovery Manager: Release 11.2.0.4.0 - Production on Sun May 10 16:19:26 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
RMAN> connect catalog vpc1/vpc1@cs
connected to recovery catalog database
⑧ Create a private directory
RMAN> create virtual catalog;
4) Protect and rebuild the directory
catalog datafilecopy ' /xxx.dbf'; -- a copy of the registration database
catalog backuppiece '/asdasd.bak' registers the backup machine of the database
catalog startup with '/as/asd' -- indicates the catalog (most powerful)
2. Stored scripts
create { global } script
replace{ global } script
print { global } script
list { global } script
execute { global } script
delete { global } script
The {globle} keyword is globally visible.
create script script_name from file ' file_name' -- create from file.
RMAN> create script script_name {script content}
RMAN> run { execute script script_name }
Third, use rman to create a database
1) Install the orale software on the secondary server.
2) Configure the static monitoring service.
3) Set the oracle _sid configuration parameter file and password file.
4) The auxiliary database is started to the nomount state, and the target database is started to the mount or above state.
5) Execute the copy.
$ rman target sys/oracle@A auxiliary sys/oracle@B
RMAN> duplicate target database to testdb from active database;
4. Point-in-time recovery of tablespaces
1) Automatic and manual
2) rman automatic mode
① Verify that it is self-contained.
② Verify the data object.
recover tablespace XXX until time 'XXX' auxiliary destination to '/asda/'
Then make it online.
Five, rman performance monitoring
1. Monitor rman sessions and jobs
1）v$session和v$process
v$session---Each channel occupies one line.
For example, assign two channels, then execute:
select sid，spid ，client_info
from v$process p join v$session s on ( p.addr=s.paddr)
where client_info like %rman% --- The command id is set as below. To use the id, there is no rman.
To distinguish you can use
run { set command id to 'asdasdasdasd'
ssssssss;} This will display the id information in client_info.
2）v$session_longops
The v$session_longops view displays information about long-running rman jobs only when the initialization parameter statistics_level is set to typical or all. The default value of statistics_level is typical
SQL> select sid,serial#,opname,sofar,totalwork from v$session_longops
2 where opname like 'RMAN%'
3 and sofar <> totalwork;
SID SERIAL# OPNAME SOFAR TOTALWORK
---------- ---------- ------------------------------ ---------- ----------
139 89 RMAN: aggregate input 0 198784
192 140 RMAN: full datafile backup 94396 198784
192 140 RMAN: full datafile backup 58719 0
SID SERIAL# corresponds to v$session.
where the sofar column measures the progress of the step, and its value varies by operation type:
* For image copies, it is the number of blocks read.
*For backup input lines, it is the number of blocks read from the backup file
*For backup output lines, it is the number of blocks written to the backup slice
*For restore operations, it is the blocks of the target file processed so far number.
*For proxy copies, it is the number of files that have been copied so far. The
TOTALWORK column is defined similarly, but it estimates the total amount of work that needs to be performed in the step.
*For image copies, it is the total number of blocks in the file
*For backup input lines, it is the total number of blocks read from all files in the step.
*For backup output lines, it is always 0
*For restore operations, it is the total number of blocks for all files restored in a single job step or rollup step.
*For proxy copies, it is the total number of files to copy in the job step.
Use round(sofat/totalwork*100, 1) to display percentages.
2. Adjust RMAN
1) Backup step Read phase -- file to input buffer,
Input buffer to output buffer---Complete operations such as encryption and compression and verification
Write operation ------ output buffer to file
2) Perform parallel backups
Up to 25 channels, up to 64 files per channel
backup as commpressed backupset incremental level 0
（datafile 1，2，3 channal c1）
（datafile 4，5，6 channal c2）
（datafile 7，8，9 channal c3）；
The default parallelism of the channel can also be configured.
3) Multiplexing:
filesperset The maximum number of files per backup machine. Default is 64
The multiplexing level (the number of input files written to, or read from, the same backup piece) is the minimum of MAXOPENFILES and the number of files in each backup set. The default value for MAXOPENHLES is 8. The calculation can be more easily understood by the following equation:
multiplexing_level = min(MAXOPENFILES, min(FILESPERSET, files__per_channel))
This example backs up 10 data files in one channel, the MAXOPENFILES value is 12, and the FILESPERSET default value is 64. Therefore, the multiplexing level is calculated using the following equation:
multiplexing_level=min(12, min(64, 10))=10
RMAN allocates different numbers and sizes of disk I/O buffers based on the multiplexing level in the RMAN job. After RMAN has determined the multiplexing level using the FILESPERSET and MAXOPENFILES parameters according to the equations mentioned earlier, the information provided in the table below can be used to determine the number and size of buffers that RMAN needs to perform the backup
| multiplexing level | Enter disk buffer size |
| <=4 | 16 1MB buffers, distributed across all input files |
| > 5 & < 8 | 512MB of buffers, the number of which varies to keep the total buffer size within 16MB |
| >8 | 4 128KB buffers (512KB for each input file) |
Oracle recommends setting the FILESPERSET value to a value less than or equal to 8 to optimize recovery performance. That is, if you put too many input files in a single backup set, the restore will be slower because the RESTORE or RECOVER command still needs to read the extra blocks of the big child in the backup set when restoring a single data file
4) Adjust the rman command
parameters above. plus
backup duartionCommand
You can use minimize time to specify the completion time so that the backup can be done as soon as possible;
The minimize load option can be used.
You can also specify partial to save backups terminated due to time constraints.
3. Use asynchronous I/O
Whether to use synchronous or asynchronous I/O in an RMAN environment depends on a variety of factors. These factors include the type of device used for the backup set (disk or tape), and whether the output device or host OS supports synchronous or asynchronous I/O, even if the host OS or device does not support native asynchronous I/O, still RMAN can be configured to simulate asynchronous I/O using initialization parameters such as DBWR_IO_SLAVES
1. Understand Asynchronous I/O and Synchronous I/O
When RMAN reads and writes data, the I/O operations are either synchronous or asynchronous. Synchronous I/O operations do not allow a server process to perform more than one operation at a time. Another operation can only be started after one operation is completed. Whereas asynchronous operations can initiate an I/O operation and then immediately perform other operations (including initiating another I/O operation)
the type of I/O operation can be controlled using initialization parameters:
for tape backups, BACKUP_TAPE_IO_SLAVES can be set to TRUE , to configure the backup to use asynchronous operations, otherwise, set it to FALSE to use synchronous operations. The default value is FALSE.
For disk backups, most modern operating systems support native asynchronous I/O. However, if the operating system does not support it, you can still set BACKUP_TAPE_IO_SLAVES to TRUE and instruct Oracle to emulate asynchronous I/O by setting DBWR_IO_SLAVES to a non-zero value, which allocates 4 slave backup disk I/Os in order to emulate RMAN asynchronous I/O operations
2. Monitor asynchronous I/O
To monitor asynchronous I/O operations, use the dynamic performance view V$BACKUP_ASYNC_IO. Important monitoring columns are as follows:
• IO_COUNT: The number of I/Os performed on the file.
• LONG_WAITS: The number of times the backup or restore process must tell the OS to wait for I/O to complete.
•SHORT_WAIT_TlME_TOTAL: The total time spent on non-blocking polling I/O completion (in 0.01 seconds)
• LONG_WAIT_TIME_TOTAL: The total time spent in blocking waiting for I/O to complete (in 0.01 seconds)
if the ratio of LONG_WAITS to IO_COUNT reaches the maximum , which is likely to be a bottleneck in the backup process. A bottleneck is also indicated if SHORT_WAIT_TIME_TOTAL and LONG_WAlT_TIME_TOTAL are non-zero values. This example determines two input files that contain nonzero ratios:
SQL> select long_waits / io_count waitcountratio, filename from v$backup_async_io where long_waits / io_count > 0 order by long_waits / io_count desc；
For this file, consider increasing the degree of multiplexing in order to reduce or eliminate backup wait times
3. Monitoring the synchronous I/O
dynamic performance view V$BACKUP_SYNC_IO will help identify bottlenecks in synchronous I/O operations and the progress of backup jobs. Use the DISCRETE_BYTES_PER_SECOND column to see the I/O ratio of the operation. This ratio is then compared to the maximum ratio of the output device (eg, tape device). If the ratio is much lower, the process can be tuned to maximize the throughput of backup operations by using parallelization or increasing the channel multiplexing level
SQL> select DISCRETE_BYTES_PER_SECOND from v$backup_sync_io;,
if you are using synchronous I/O, but set BACKUP_TAB_IO_SLAVES to TRUE, you can monitor I/O performance in V$BACKUP_ASYNC_IO
a