|< Day Day Up >|| |
Up to this point we have learned how a correct Real Application Clusters (RAC) implementation can make a highly available database system. We learned how to configure a system so that most failures that occur at the instance level will be nearly transparent to the end-user community. With RAC, our database will scale out while simultaneously providing us with a maximized availability solution. Once we have our clustered database up and running, we can sit back in our chair and smile, basking in the glow of our own cleverness. Surely upper management is noticing. Surely the raise will be big this year!
And then it happens. Just ask Horatio's DBA.
Let's just suppose that the building that houses our RAC cluster burns to the ground in a fiery death. Or better yet, let's suppose that an earthquake knocks out the entire city where our data center resides. How long will it take for us to buy a new cluster and have it installed and configured? How long will it take for us to install all of the software and restore the database (you did keep the tapes at a different location, right?)? Days? Weeks? A month? Thoughts of big fat raises turn quickly to thoughts of updated resumes.
Relax. RAC can't save you from everything, but there is a solution. Oracle Data Guard has been designed from the ground up to provide an efficient disaster recovery solution that will save you from the fiery death or the crippling earthquake. Data Guard gives you the ability to failover in the event of a disaster so that your users have access to your data in minutes instead of days or weeks. Data Guard can be configured to guarantee no data loss, to minimize downtime of the production database, and to reduce the workload of the production database by offloading reports and backups. In this chapter we will learn how to take advantage of Data Guard's rich feature set and how to build a configuration that will give us safety and security while making efficient use of the additional resources.
|< Day Day Up >|| |