This blog is to share the DBA knowledge for Oracle DBA beginners and experienced. The information is shared as mostly referred from oracle documentation and MOS with real-time experience and scenarios with Demos.
Proud to be a DBA...! Happy to Share...!!!
In this video, we're going to see a few quick and easy steps you can follow to start implementing RMAN backups in Oracle 19c. The Oracle documentation is a great source for those who would like to get into all the details of backup and recovery using RMAN, but here I will focus on a few of the basics steps to get the RMAN Backup and Configuration gets done.
One area that is critical to any database environment is backup and recovery, but too many times we have seen DBA's neglecting backups. A perfect example of this is when backups are implemented but never tested. Then six months later when a production database needs to be restored the DBA realizes that something is actually wrong with the backups, and a full recovery is not possible.
Did You Know that some DBAs are Scared of Using RMAN?
In older versions, when Oracle introduced RMAN and it was in its 'infancy', it is fair to say that occasionally it did create havoc, and some DBA's simply refused to use it. Instead they preferred the “online backup” method of placing tablespaces in backup mode, copying the datafiles to a backup location and then ending the tablespace backup mode.
But since Oracle 10g RMAN has improved, with more DBA's starting to use it and Oracle have done an amazing job with new features implemented as part of all the versions since. So if you are using Oracle 12c and above, you no longer have any excuses for not using RMAN. Some might say it is too complex; but did you know that you can perform a backup of your database with a simple commands such as:
RMAN> backup database;
RMAN> backup database plus archivelog;
Does not look that complex does it? But sometimes, we, the DBA’s, complicate matters by writing long and elaborate scripts to perform backups when in most environments it is not needed (although in some cases there are good reasons for this). Just implementing a basic solution might be a good starting point. You can always refine it and make it more sophisticated as you become more familiar with RMAN and all the extra options it provides. With a few easy steps you can have backups in place with ease.
When performing backups you may prefer using backups to local disk based storage. The disk location where the database backups are stored should then be included as part of the database server backup cycle (which could just be a normal daily file system backup). This is a quick and easy way and no special database backup software agents are required.
There are a few reasons for using disk based backups, and one of the main ones is that you do not have to wait for tapes to be loaded or returned from secure storage when a restore or recovery is required. Then you can just start the restore process with your latest backups being directly available on disk.
In this examples, I am configuring RMAN Backup and Recovery and testing in Oracle 19c on Oracle Linux 7.9.
Step 1: Setting The Environment:
One of the first things to do when setting up new backup scripts or even just setting up a new Oracle environment, is to update your environment variables to include "NLS_DATE_FORMAT". By setting this environment variable, the dates being displayed will be in a more readable format, including the time, not just the date. I normally add this variable to my oracle user account .bash_profile.
For example, just add the following two lines to the oracle .bash_profile:
NLS_DATE_FORMAT="DD-MM-YYYY HH24:MI:SS"
export NLS_DATE_FORMAT
To give you an idea of what effect this parameter has, if a "list backup" command is executed to show known backups, you'll see the following:
Without NLS_DATE_FORMAT:
With NLS_DATE_FORMAT set:
As you can see above, the dates are showing the time as well when this parameter is set. I usually have a small function setting the environment and this is one variable that I always set.
Step 2: Default RMAN Configuration:
One of the hidden "gems" of RMAN is that you can update your default configuration to make use of specific values. To see the default values you can execute the "show all" command when connected to your database. Below is an example:
[oracle@srlab ~]$ rman target /
connected to target database: SRLAB (DBID=25965068)
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name SRLAB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/19.0.0.0/db_1/dbs/snapcf_srlab.f'; # default
Note: do not just update these values without doing a full review and understanding the implications of altering these values. One of the most important values you might want to specify is to enable auto backup of the controlfile, which by default is set to OFF in earlier database versions, but in 19c it is ON which is perfect. When you update this to ON, RMAN will automatically backup the control file at the end of every backup. This is the first configuration worth a review and if it is not set to ON, I will update it. This can easily be done with:
RMAN> configure controlfile autobackup on;
Following the above, update the controlfile autobackup location. In our example we are using local disk based backups, and we are updating the configuration to create the control file backup in my backup location which in my example is: /backups/DEV/. To do this, execute the following command:
RMAN> configure controlfile autobackup format for device type disk to '/backup/srlab/%F’;
To configure RMAN to make use of a specific location for disk based backups, you can update the default channel configuration to include the disk location where the backups should be stored. In this example we are using /backups/DEV as the backup destination. I will update the default RMAN configuration to reflect this:
RMAN> configure channel device type disk format '/backup/srlab/%U';
The final configuration change I make is to ensure RMAN is making use of compressed backup sets by default. Creating compressed backups is one of the best features of RMAN (since 10g). This is extremely useful as you can now, in most cases, keep multiple backups on disk. This means that you have a larger recovery window. With Oracle Standard Edition 2 only the “BASIC” compression algorithm can be used, for more details on this and the compression algorithm please review the Oracle Documentation. Configuring the use of compressed backup sets when using disk based backups can be done with the following command:
RMAN> configure device type disk backup type to compressed backupset;
Once this is done, by default my disk-based backups will be compressed. Now to show you the configuration following the above changes:
RMAN> show all;
Step 3: Creating A Backup:
Now let’s assume you are following the above and have changed the default configuration as described. With this in place, you can just execute a one-line set of commands to back up the database. Below is an example, including output.
RMAN> backup database plus archivelog;
A quick and easy script that can be used regularly, taking into account the default values set as above, is:
RMAN> run {
backup database filesperset 5;
sql 'alter system archive log current';
backup archivelog all filesperset 10;
}
If you did not configure the default RMAN values above (step 2), you can achieve similar results by running the following backup script:
RMAN> run {
backup as compressed backupset filesperset 5 database format '/backup/srlab/dbf-%U';
sql 'alter system archive log current';
backup as compressed backupset filesperset 10 archivelog all format '/backup/srlab/arc-%U';
backup current controlfile format '/backup/srlab/cf-%U’;
}
And as we mentioned earlier, once you have the basics working, you can start looking at more complex scripts and scenarios.
Next Steps:
The above was just a quick example of how you can utilize the default RMAN configuration to get backups in place quickly. It is however important to remember that when you are looking at implementing a backup solution for a production environment, that you implement a backup retention period that fits in with your environment backup and recovery policies. Retention periods weren't covered in this post, but we recommend you to read up on retention policies and use of the list, report, crosscheck and delete commands.
The most important recommendation we can give you when implementing backups, is to TEST it. Always test your backups and recovery procedures and document them. Yes we know everyone hates documentation, but if you have an urgent restore at 3am, having documentation to follow will make it easier. To test your backups, you can easily perform backups on your production system, then copy the backups to another server and perform a restore there. It is crucial that your production backups are tested on a regular basis.
Some of the RMAN Configuration Setting are :
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/srlab/%F';
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/srlab/%U';
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
References:
See Oracle Support Note 1472171.1 for more details. (The original Note 1268725.1 was removed from Oracle Support)
Post a Comment: