RMAN is one of the key important utility that every Oracle DBA is dependent on for regular day to day backup and restoration activities. It is proven to be the best utility for hot backups, in-consistent backups while database is running and processing user sessions. With all that known, as an Oracle DBA it will be a great a knowledge when you know how and what steps does RMAN performs when you issue “Backup Database” command.
Though this is an outline of the backup process and not covering each granular tasks that RMAN does in the way to achieve this, it gives you a glimpse of understanding RMAN’s relation with Control file, Disks, Datafiles and channels and why REDO is important for RMAN. We will also look into other RMAN backup jobs workflow like level 0, level 1 backups in other blogs in OrSkl.
Below is the description of the numbered blocks in the image to get a clear view on the picture.
- You issue “rman target /” to connect to RMAN console. It uses OS authentication to establish RMAN client-server connection.
- RMAN client process will be created in order to process the backup which acts like the source to channel and write the backups on to disk.
- Concurrently RMAN server process is also created which is a DB session, this session is used by the RMAN to get database details when you issue any command in the console.
- All the checks in terms of compatibility, parameters, RMAN configuration settings will be done in this stage before RMAN console is open to accept any user commands. In case of any void in this process, RMAN errors out.
- Consider you issue “backup database;” command.
- All that RMAN needs to run the backup are the information from control file the most. To do this RMAN locks out control file to read. To avoid database SCN locks when locking control file, RMAN creates snapshot of the control file and uses it for consistent read operations to perform the backup. This snapshot is the only file RMAN uses until it completes the backup issued.
- Then RMAN reads current database SCN, timestamp, current redo log sequence, list of datafiles to be backed up as per the command. Yes, this is from the snapshot control file now.
- Consider RMAN starts with one channel and starts with backing up DataFile #1 and it has 123 blocks in it. We already knew that RMAN backups at block level, let us understand it at that level. At this moment consider the SCN at each block level is 1001 for all the blocks which is ideal case. But in reality, each block will be at different SCN number.
- Every block that RMAN picks to backup, it performs LOGICAL and PHYSICAL corruption test and backups only if it passes the test.
- Imagine by the time RMAN reaches Block #123 its SCN number is 1007.
- RMAN doesn’t throw any error here, it backups up the block with 1007 as SCN number.
- RMAN will only check if block is corruption less and then includes in the backup, that’s it. So now a datafile which is backed with blocks of different SCN numbers in this process. This is what termed as IN-CONSISTENT backup in real. Though the backup started with one SCN number, as backup progresses SCN in the blocks also progresses and by the end blocks are of different SCN numbers in the backup piece. Huge in-consistency.
- The same continues for all the datafiles, now that datafiles are in-consistent, blocks are in-consistent with respect to the SCN numbers.
- This is the reason why RMAN will need REDO information while the backup is in progress as to give you option to perform POINT-IN-TIME recovery.
- As it completes the backup, information on the backup is updated in the control file. If you have configured control file auto backup, then it backups updated control file as a backup set.
- With this consider BACKUP IS COMPLETED.