oracle-apps-dba

Recovery Manager Architecture

Monitoring RMAN Jobs
You can monitor the status of both an RMAN backup as well as a recovery job by using the
V$RMAN_STATUS view. This view shows all finished and ongoing RMAN jobs. Here’s a simple
example:
SQL> SELECT operation, status from V$RMAN_STATUS;
OPERATION STATUS
-----------------------------
REPORT COMPLETED
BACKUP COMPLETED
LIST COMPLETED
RESTORE PREVIEW COMPLETED
. . .
SQL>
Another highly useful data dictionary view for monitoring RMAN jobs is the in-memory V$RMAN_OUTPUT view, which displays all the messages being put out by RMAN during a backup or recovery job.

● High Availability
There are a number of them out there, include these:
Datagaurd
Real Application Cluster
Replication
RAID and Mirrored derives
Various other vendor provide HA solution as well

● System Change Number (SCN)
A counter that represent the current state of the database at a given point in time. Each SCN automatically represents a point in the life of the database.

● Large Pool
The large pool is used by RMAN in specific case and is not used by default, even if it is configured. If either of the database parameter, BACKUP_TAPE_IO_SLAVES or DBWR_IO_SLAVES is set to true. In these case, oracle can use the large pool memory rather than local memory (PGA). The use of the PGA is default.

● Recovery manager implements a type of server managed recovery (SMR)

RMAN is a standalone application that makes a client connection to the oracle database to access internal backup and recovery packages. It is at very core, nothing more than a command interpreter that takes simplified commands you type and turns those commands into remote procedure calls (RPC) that are executed at the database.

● With standard edition of oracle, RMAN can only allocate a single channel for backups.

● RMAN utility is made up of two pieces: the executable file and the recover.bsq. The recover.bsq file is essentially the library file, from which the executable file extracts code for creating pl/sql call to the target. These two files are invariably linked, and logically make up the RMAN utility. Both the pieces should be of same version otherwise RMAN will not work.

● The RMAN utility interprets commands you provide into pl/sql calls that are remotely executed at the target database. The commands are interpreted by the executables translator and then matched to pl/sql blocks in the recover.bsq file. RMAN then process these RPCs to the database to gather information based on what you have requested. If your command requires an I/O operation (i.e. backup or restore command), then RMAN prepares another block of procedures and passes it back to the target database. These blocks are responsible for engaging the system calls to the OS for specific read or write operation.

● RMAN needs to access package at the target database that exist in the SYS schema. In addition, RMAN requires the privileges necessary to startup and shutdown the target database. Therefore, RMAN always connects to the target database as a SYSDBA user, when you connect to the target database, RMAN automatically supplies the as sysdba to the connection.

● RMAN is a client application that attaches to the target database via an oracle net connection. If you are running the RMAN executable in the same ORACLE_HOME as your target database, then this oracle net connection can be a bequeath, or local connection, and won't require you to provide a net alias as long as you have appropriate ORACLE_SID variable set in your environment, otherwise, you will need to configure your tnsnames.ora file with an entry for your target database and you will need to do this from the location where you will be running RMAN.

● RMAN uses the controlfile to compile file list, obtain checkpoint information and determine recoverability. After RMAN completes a backup of any portion of the database, it writes a record of that backup to the controlfile, alongwith checkpoint information about when the backup was started and completed.

● The controlfile can grow exponentially to meet space demand, when new record is added for a new datafile, new logfile, or a new RMAN backup, it can expand to meet these demand. However, there are limitations for expansion, The controlfile thus separates its internal data into two types of records: Circular reuse records and non circular reuse records. The records og RMAN backups in the controlfile falls into the category of circular reuse records.

● The RMAN records will get aged out if the controlfile section that contains them becomes full, without the record of the backup in the controlfile, it is as though the backup never took place, if controfile does not have a record of your RMAN backup, the backup cannot be used by RMAN for recovery.

● You can also set a larger time frame for when the controlfile will age out records. This is controlled by init parameter CONTROLFILE_RECORD_KEEP_TIME. By default, this parameter is set 7 (in days). Setting this parameter to 0 means that the records are never reused. In addition, if you will be implementing a recovery catalog, you need not worry about circular reuse records. As long as resync your catalog at least once with in the time frame specified by the CONTROLFILE_RECORD_KEEP_TIME parameter and let those records age out, the recovery catalog will never ages records out.

● If you use RMAN, and you don't use recovery catalog, be very careful of the controlfile recreation from trace file backup. The scripts that is generated does not include these backup records and all RMAN information is lost. If you backup the controlfile to a binary file, instead of trace, then all backup information is preserved.

● RMAN needs to get a consistent view of the controlfile when it sets out to make a backup of every datafile. It only needs to know the most recent checkpoint information and file schematic information at the time the backup begins. After backup starts, it needs this information to stay consistent for the duration of backup operation, in other words, it needs a read consistent view of the controlfile. With constant updates from the database, this is nearly impossible, unless RMAN to lock the controlfile for the duration of backup, that would mean the database could not advance the checkpoint or switch log or produce new archivelog. To get around this, RMAN uses the snapshot controlfile, an exact copy of the controlfile that is only used by RMAN during backup and resync operation. At the beginning of these operation, RMAN refreshes the snapshot controlfile from the actual controlfile, thus putting a momentary lock on the snapshot controlfile. It has default name SNCF.ORA and can be changed at any time using configuring snapshot controlfile command. There are certain condition that might lead to the following error on the snapshot controlfile.

RMAN-08512:Waiting for snapshot controlfile enqueue
This error happens when the snapshot controlfile header is locked by a process other than one requesting for enqueue.

● RMAN makes a client connect to the target database and two server process are spawned. The primary process is used to make calls to package in the sys schema in order to perform backup & recovery operations. This process coordinates the work of the channel processes during backup & restore. The secondary or shadow, process polls any long-running transactions in the RMAN and logs the information internally.
● In addition to two default process, an individual process is created for every channel that you allocate during backup and restore operation.
● There are only two kind of channels : Disk and Tape Channels. you cannot allocate both kind of channels for a single backup operation.

● You cannot allocate both kind of channels for a single backup operation. Like the RMAN background process, the channel processes can be tracked from the data dictionary and then correlated with a sid at the OS level. It is the activity of these channel processes that gets logged by the polling shadow process into v$session_longops view.

● RMAN can utilize I/O slaves if they are configured on the target database. For the purpose of RMAN backups and restore, there are two kind of slaves that are used : Disk I/O and Tape I/O slaves.

● Disk I/O slaves are configured using parameter DBWR_IO_SLAVES. This parameter can be set to any number of values and its primary use in life is to wake up extra DBWR slaves for disk writes when dirty buffers are flushed to disk from buffer cache. However, if this parameter is set to any non-zero value, br it 1 or 12 or 32, RMAN throws a switch that will automatically engage four I/O slaves per channel to assist with reading data blocks into RMAN memory buffer. Using DBWR_IO_SLAVES is only important if your OS platform does not support Asynchronous I?O, or if you have disabled asynchronous I/O for oracle RDBMS. If you have asynchronous enabled, then, you need not to use disk I/O slaves.

● Tape I/O slaves assist with server process to the tape device. If you have the parameter BACKUP_TAPE_IO_SLAVES set to true, then RMAN will allocate a single I/O slaves per tape channel process. This parameter affects no part of the database other than RMAN tape backups.

● The RMAN server process that coordinates the work of the channels has access to two package in SYS schema: dbms_rcvman and dbms_backup_restore. These two packages comprise the entirety of RMAN functionality in the target database.

● The dbms_rcvman is the package that is used to access the table in the controlfile and pass this information to RMAN so it can build backup and restore operations that accurately reflect the database schematics. This package is responsible for setting time operator and verifying checkpoint information in the datafile headers prior to running any operation. It also checks file location and size, along with other information concerning node affinity ( in RAC ) and disk affinity.

● The sys.dbms_rcvman accesses the controlfile and verifies all the requisite information. It passes this information back to the RMAN server process, which can then create pl/sql blocks based on the code in the recover.bsq file. These pl/sql blocks are made up of calls to the package DBMS_BACKUP_RESTORE. DBMS_BACKUP_RESTORE is the actual package that creates system calls to backup datafiles, controlfiles, and archivelog files. RMAN server process take this information from dbms_rcvman, divvvies out the work among the channels based on the load-balancing algorithm, and then creates a series of calls to DBMS_BACKUP_RESTORE. It is the work of DBMS_BACKUP_RESTORE that you can track in v$session_longops. In addition, DBMS_BACKUP_RESTORE accesses the controlfile, but only in a very limited way. It accesses to backup it up (actually it backs up the snapshot controlfile) and to wirte backup information to it after backup have been complete. Once it has completed a backup set, it writes the information about when the backup was taken, how long it took to complete, and the size and name of the backup to table in controlfile.

● Both of these RMAN package are installed by default by running the catproc.sql script when database was created. These packages have another trait: they are hard-coded into the oracle software library files, so they can be called when the database is not open.

● The OS utility that ultimately made the backup was looking at the entire file and backing it up and because of this, we had to go extraordinary lengths to protect the integrity of the oracle data blocks. RMAN, however, is different. Because RMAN is integrated into the RDBMS, it has a access to data at the same level that the database itself uses: the data block. Block level access is what distinguishes RMAN from any other backup utility.

● RMAN complies the list of files to be backed up, based on the backup algorithm rules. Based on the number of channels and number of the files being simultaneously backed up, RMAN creates memory buffers in the oracle shared memory segment. This is typically the PGA. The channel server process then begins reading the datafiles and filling the RMAN input buffers with these blocks. When input buffer is full, it pushes the blocks to the output buffer. This memory-to-memory writes occurs for individual block in datafile. If the data block meets the criteria for being backed up, and the also detected no corruption, then it remains in output buffer until output buffer is full. |Once the outpur buffer is full, the output buffer is pushed to the backup locatioon – a disk to a tape.

● Null compression becomes an option when we have access to the data block. We can eliminate blocks that have never been used (have a zeroed header), and discarded them during the memory-to-memory write. Therefore, we only backup blocks that have been used and have a more efficient backup.

● Block level backup also provide performance gain from the preparation of redo generation. In hot backup methodology, tablespace has to be put into backup mode, which, in turn, causes excess redo log generation. RMAN, on the other hand, does not need to guarantee block consistency during a backup. RMAN's access to the data block allows it to coordinate with DBWR process writing dirty buffers, and can wait until the block is consistent before it reads the block into input memory of RMAN. So, blocks are not dumped into redo and we always have consistent blocks in our backup.

● RMAN builds buffers in memory through which it streams data blocks for potential backup. This memory utilization counts against the total size of PGA and sometimes, the SGA. There are two kind of memory buffers. Input buffer are the buffers that are filled with data block read from files that are being backed up. Output buffers are the buffers that are filled when memory-to-memory write occurs to determine whether or not particular block need to be backed up. When the output buffer is filled, it is written to the backup location. There is a difference in memory buffers depending on whether you are backing up to, or restoring from, disk or tape.

● The size size and number of input memory buffer depends on the exact backup command being executed. Primarily, it depends on number of files being multiplexed into single backup. Multiplexing refers to the number of files that will have their blocks backed up to the same backup piece. The following rules applied to the input buffer:
● If the number of files into the backup set is four or less, then RMAN allocates four buffers per file at 1MB per buffer. The total will be 16MB or less.
● If the number of files going into the backup set is greater than four and upto eight, then each file gets four buffer, each of size 512KB. This will ensure the total remains to at 16MB or less.
● If the number of files multiplexed in greater than eight then RMAN allocates four buffer of size 128KB. This ensures that each file being backed up will account for 512KB of buffer memory.

● Bear in mind that these memory amounts are on per channel basis. So, if you allocate two channel to backup a database with 32 datafiles, for instance, then RMAN will load-balance the files between the two channel and may not end up with 16 files per channel. If some files are significantly larger than the others, we may end up with only 8 files going into one backup set and 24 going into the other. If this were the case, then the buffer for the first channel with 8 files would allocate 16 MB of memory for input buffers (4 buffers multiplied by 512KB each multiplied by 8 files) and the second channel would allocate 128MB of memory buffers ( 128KB multiplied by 4 and multiplied by 24).

● In addition to input buffer, RMAN allocates output buffers, depending on what the output source is. If you are backing up to disk, then RMAN allocates 4 output buffers, each of which is 1MB in size. So, the memory footprint per channel will always e 4MB. Memory allocation is different when backing up to tape, to account for the slower I/O rates that we expect from tape devices. When you are backing up or restoring from tape, RMAN allocates four buffers per channel process, each of which is 256KB in size, so that the total memory footprint per channel is 1MB.

● Memory utilization during restore operation is slightly different than during backups. During restore from disk backup, the input buffer will be 1Mb in size, and RMAN will allocate 4 buffers per channel. When restoring from tape, RMAN allocates 4 input buffers with a size of BLKSIZE, which defaults to 256KB. The output buffers on restore are always 128KB and there will be four of them per channel.

● The large pool is a specific area in the SGA. Large pool is utilized for certain memory activities that requires shared space. It occupants are primarily restricted to RMAN memory buffers, if I/O slaves are used, shared servers for connection pooling, JDBC connection pooling and it will also house parallel query slaves if you set PARALLEL_AUTOMATIC_TUNING to true. The large pool size should be considered keeping in view the all potential occupants. In case of RMAN, size is based on the total number of channels you expect to allocate for your backups, plus 1MB for overhead.

● There is a misconception that we eliminate empty blocks. RMAN access the database by accessing the file header and block header, ad not through space management as space management is only available when database is open. So, if you truncate a table, all the blocks that had information but are now empty will be backed up, because RMAN only knows that the block has been initialized by the segment. It does not know that the block is empty.

● The other misconception is about null compression that incremental backup can save time during backup, as less is being backed up. This is true to certain extent, but only if your backup device is an extremely bad bottleneck. If you stream very quickly to your disk or tape backup location, then the act of eliminating blocks in memory save little time, because RMAN is still reading every block in the file into memory and it just not writing every block to the output device. Even during incremental backups, still have to check the header of each block to discover if it has changed since last incremental backup. Incremental backups, save space in our backup location and they provide a faster form of recovery, but they are not meant to be sigificant or reliab;e time saver during backup.

● The recovery catalog is a repository for meta data about RMAN backups. In a sense, you can think of catalog as merely a copy of the pertinent information out of the control file that RMAN requires for backup and recovery purposes. It is no more than a few packages, tables, indexes and views. These tables contain data that is refreshed from target database control file upon resync command from with RMAN or whenever backup are taken.

● In the connect string to the catalog, you pass the username and password for the user that owns the RMAN catalog. Unlike target, the connection to the catalog is not a SYSDBA connection and does not this privilege granted to it. In Oracle 8i, there were a number of extremely useful operations that could only be performed if you used a recovery catalog. However, there is only one set of operations that now require the recovery catalog: using different database incarnations.

● Inside of the recovery catalog, there are two packages: DBMS_RCVMAN & DBMS_RCVCAT. The first one, DBMS_RCVMAN, is identical to that same package in the SYS schema. The existence of the package DBMS_RCVMAN in the recovery catalog can lead to some confusion on the database that houses the recovery catalog. It is in this way that the RMAN utility ca use either the recovery catalog or target database control file for information about backup and recovery and not worry about different implementation. The second package in the recovery catalog is DBMS_RCVCAT, and is only used to perform operations specific to recovery catalog during RMAN operations. In essence, you can think of this package as being the recovery catalog implementation of DBMS_BACKUP_RESTORE; whereas DBMS_BACKUP_RESTORE writes backup completion information to the target database control file, DBMS_RCVCAT does this in the recovery catalog.

● Starting from version 9.0.1, the default database that get copied to your system, when oracle is installed all contain a user schema named RMAN. This is a pre-built recovery recovery catalog with no database currently registered. By default, this account is locked. Once unlocked, you can utilize this schema for recovery catalog purposes or you can build your own user.

● The auxiliary database refers to the instance that will become host to restored files from the target database in the event of a tablespace point in time recovery (TSPITR), a duplication operation or the creation of a standby database using RMAN backups. When you perform any of these tasks, you will be connecting to the target database and auxiliary database to the same time from within RMAN.

● RMAN makes a simultaneous connect to each database, and require access to the sys.dbms_backup_restore and sys.dbms_rcvman package in both the target and auxiliary database. RMAN requires sysdba privileges at auxiliary, just as it does at the target.

● There are different component of RMAN that we have to work with are: The RMAN executable, The Target Database, The auxiliary database. The easiest answer, of course, is to make sure all of these components are on the same version.

The RMAN Process : From start to Finish

● The target database PROD has 20 datafiles, and is running in ARCHIVELOG mode. The database is up and running during this operation.
$>rman
RMAN> connect target /
RMAN> backup database;

● RMAN makes the bequeath connection to the target database that we have setup on our environment. This means it checks the variable ORACLE_SID for an instance name and then spawns a server process at the instance, logging as a SYSDBA user. This connects us as the internal database user SYS.

● RMAN immediately spawns the channel processes that will used to perform the backup. In this case, we are using default setting, so only one channel is allocated. We are not using I/O slaves, so the process allocates memory in PGA.

● Rman complies a call to SYS.DBMS_RCVMAN to request database schematic information from the target database control file, starting with a determination of the target database version. It gather version information from the control file, along with control file information itself: what type of controlfile is it? what is the sequence number current in it? when was it created?

● We have specified a full database backup, RMAN requests information for each datafile in the database and determine if any files are offline. As a part of this information, it gathers which disk each file is on and how to dole out the work. Because we are using default settings, there will be only one channel and only one backupset. Therefore, RMAN ignores all disk affinity information and concentrates on compiling the list of files for inclusion in the backupset.

● After the list is complied, RMAN is ready to begin the backup process itself. To guarantee consistency, it then builds the snapshot control file. If one already exists, it over writes it with a new one.

● Then RMAN creates the call to the DBMS_BACKUP_RESTORE package to create the backup piece. The backup piece will be built in the default location if not specified othrwise (ORACLE_HOME/dbs or database), only checks the physical location.

● Now RMAN has the file list, so it can allocate the memory buffers for performing the read/write from/to disk. with 20 files, RMAN allocates input buffer of size 128KB. There will be four buffer per file, for a total memory utilization of 10MB for input buffers. RMAN will only allocate four output buffers, each of size 1MB. This brings our total memory utilization to 14MB for the backup.

● After memory is allocated, RMAN initializes the backup piece. The backup piece will be given a default name that guarantees uniqueness. RMAN then determines if there will be enough space for backup to be successful. It does this by using a pessimistic algorithm that assumes the backup will be the same size as the sum of all the datafiles. Due to null compression, this will not be the case. But it checks to see if this much space exists prior to running the backup. Be aware that RMAN initializes the backup piece with this initial size and will not be shrunk to the actual size until the backup completes, so you will see an overly large backup piece. This holds true on 9.0.1 and lower versions; in 9.2 and above, the backup piece does not preallocate space for backups and is built inclemently as the buffers are filled.

● Once the backup piece is initiated, then the channel process can begin the database backup process. In version 9.2, RMAN determines if you are using an spfile,and if so, it backs it up automatically as part of your backup set. Then RMAN will backup the current control file to the backup set. This control file backup is automatic whenever the SYSTEM tablespace is backed up. This behavior is changed if you have control file auto back up turned on.

● The backup of spfile and controlfile has been completed, now it is the time to begin the datafile reads to pull the data blocks into memory. The channel process does this by doing a read-ahead on the disk and pulling several blocks into memory at the same time. Then, memory-to-memory write from input buffer to output buffer occurs. During this write, RMAN determines if the block has ever been initialized or if the block header information is still zeroed out. If it is an unused block, the write to the output buffer never occurs and the block is discarded.If the block has been used, RMAN performs a checksum on the block. If the header and footer of the block do not match, RMAN indicates a corrupt block and aborts the backup otherwise it means the block has been initialized and passes the checksum, then block is written to the output buffer. Once the output buffer fills to capacity, RMAN dumps the buffer to the backup file location.

● While the blocksare being written out to the backup piece, the status of the backup is being polled by RMAN shadow process. It checks in on the RPCs at the target and passes that information to V$SESSION_LONGOPS for your review. Based on the information gathered at the beginning of backup operation, RMAN has an estimated completion percentage for each channel process.

SQL> SELECT SID,SERIAL#,CONTEXT,SOFAR,TOTALWORK,
ROUND(SPFAR/TOTALWORK*100,2) “% COMPLETE”
FROM V$SESSION_LONGOPS
WHERE OPNAME LIKE 'RMAN%'
AND OPNAME NOT LIKE '%aggregate'
AND TOTALWORK !=0 AND SPFAR <> TOTALWORK

● Once every block in a datafile has been read into an input buffer and its status determine, then RMAN completes the file backup by writing the datafile header out to the backup piece. After all the files have their file header written to the backup piece, RMAN makes a final call to sys.dbms_backup_restore, which writes backup information to the control file. The information includes the name of the backup piece, the checkpoint SCN at the time it started and the time it complted and this is the entire process.

● The entire process gets more complex, if we exercise more backup options, such as using multiple channels, using the fileperset and backing up to tape. But each of these configuration shares same fundamental process as perviously described. You can also turn the debug option on for the backup and get a complete list of the entire process but it can hamper the backup performance.
RMAN> connect target / debug trace='u01/oracle/backup/rmanbkup.out'

Recovery Case Studies

1. Recovering database to the particular time
2. Recovering database to the particular scn
3. Recovering database to the particular log sequence number
4. Recovering from complete database loss in noarchivelog mode (with Recovery Catalog)
5. Recovering from complete database loss in noarchivelog mode (w/o Recovery Catalog)
6. Recovering from complete database loss in archivelog mode (With Recovery Catalog)
7. Recovering from complete database loss in archivelog mode (w/o Recovery Catalog)
8. Recovering from the loss of the SYSTEM tablespace
9. Recovering online from loss of datafile
10. Recovering from loss of an unarchived online redo logg
11. Recovering from a tablespace dropped unintentionally
12. Re-creating control file without losing metadata.
13. Recovering spfile without recovery catalog & with autobackup
14. Recovering spfile with recovery catalog & autobackup
15. Recovering spfile without recovery catalog & without autobackup
16. Recovering to previous incarnation without recovering catalog
17. Recovering to previous incarnation with recovery catalog
18. Recovering corrupted data blocks

oracle-apps-dba

Tuesday, August 23, 2011

* Rafi ORACLE DBA & APPS DBA Blog*: Oracle Apps R12 installation step by step and plan...

Tuesday, May 31, 2011

RMAN

Monday, May 30, 2011

RMAN DATABASE BACKUPS TO TAPE