Description
RMAN (Recovery Manager) is Oracle’s flagship backup and recovery tool. Although RMAN’s main purpose is the backup and recovery of Oracle databases, there are other features that make this utility invaluable to an organization. One salient feature of RMAN is that it allows you to efficiently copy a database from one location to another. The copy of the database can be placed on the same server as the source database or placed on a remote destination server. RMAN can use as its source either a live production database or an RMAN backup of a database. This is all effortlessly achieved through the RMAN DUPLICATE command. With just a few lines of code you can replicate a database from one environment to another. Furthermore this process is easily scripted for automation and repeatability.
I was a latecomer to using RMAN’s duplication functionality. The genesis for my using this technology started a few years ago when I was assigned to work with a development team that required fairly frequent refreshes of development and testing environments from a copy of the production database. At first I grumbled about having to refresh environments for them. I’d tell them that there were several complicated steps involved in making a copy of a database. Indeed, for large databases it takes a great deal of time to copy data files and/or backups from server to server. Additional time is required to perform the restore and recovery of the copied database. I mandated that the team provide me at least a two-day warning when they required an environment to be replicated. The development manager then proposed that we duplicate various environments at a set time each week.
This is when I started using the DUPLICATE command. I figured out the DUPLICATE syntax required for each environment. I then encapsulated that logic in operating system shell scripts and additionally automated the running of these duplication jobs through an operating system scheduling utility (cron). Now each week this complex task of duplicating various environments has been reduced to processes automatically running and subsequent emails from the cron job informing me the duplication was successful.
I’ve also come across other scenarios wherein RMAN’s duplicate functionality has vastly simplified what would otherwise be quite complex tasks. For instance, my manager asked me what it would take to replicate an Oracle real application cluster (RAC) database running on Oracle automatic storage management (ASM) to a non-RAC and non-ASM environment. He also asked if it would be possible to replicate the other way, to RAC/ASM from non-RAC/non-ASM. Given the complexity of RAC and ASM environments, this task at first seemed impossible. But the RMAN duplicate functionality turns it into a one-command operation.
Another situation I faced was replicating databases where the source database server was on a different operating system from the destination host; for example, having to duplicate from a Solaris-based system to a Linux server. Here again the RMAN duplicate functionality takes a seemingly difficult task and turns it into a few lines of code.
The purpose of this book is to provide clear and precise examples of how to take advantage of RMAN-based duplication in your work environment. Most examples will include a diagram that details the configuration for each scenario. The most commonly encountered problems for each situation are also explained.
This chapter starts by introducing the reasons for using RMAN duplication. Then I discuss the advantages and disadvantages of this feature. I also cover the basic setup that I use for the examples in this book. This information will form the basis for moving on to simple and then advanced RMAN duplication scenarios.
Use Cases for Duplicating
In many instances it’s a requirement to replicate a database from one environment to another. There are many important reasons for this. Listed next are typical business requirements that drive the duplicating of a database.
• Offload reporting to a periodically refreshed copy of production
• Build development/test/quality assurance/beta environments
• Test database upgrades and migrations
• Test new application code
• Troubleshoot production issues
• Exercise backup and recovery strategy
• Create a Data Guard standby database used for disaster recovery and reporting
Database administrators (DBAs) add value by being able to quickly and effectively replicate a copy of one database to another. Manually duplicating a database is not difficult; however, it requires that the DBA perform about a dozen separate steps. This manual process can be time consuming and prone to error. RMAN vastly simplifies the database duplication operation by reducing it to a one-line command.
Methods for Replicating
Over the years, DBAs have devised many methods for transferring data from one database to another. Each method has its merits. Table 1-1 describes at a high level the most basic advantages and disadvantages of each replication technique. Not all possible replication tools are listed, nor are every single pro and con listed. Rather this table serves as a starting point for discussing when it is appropriate to use the RMAN duplicate functionality.