High Availability and Flexibility with Data Guard
The purpose of this blog entry is to show you how to create a physical standby database. I am going to do a few posts actually.
The first will be a basic data guard setup on 2 different machines. In this case, I used VMWARE. There are things I am not going to cover in order to keep things very basic and simple. If you want to do data guard on the same machine, you will need to do some renaming of things dynamically. It’s in the data guard documentation that I encourage you to read.
The second post will deal with enabling flashback database and how it works. We will enable it on our primary and secondary.
Next, we will integrate the two. We will be able to open our DB in read only mode for reporting purposes. We will also look at keeping a testing environment in sync with production. We will take it out of standby mode, do our testing, then flashback to an SCN before it came out of standby. It will then sync back up with the primary. Flashback also works in turning your primary into a new standby in certain situations.
On another post, I will look at the different production modes and discuss what we could have done differently in our setup to meet our needs and some of the pitfalls to watch out for.
Last, I will discuss how you can backup your standby DB with RMAN so you can minimize the impact to your production system. These backups can then be used to restore production since it is an exact block for block copy of your production database. If I get the itch, I will even add a final post on logical standby.
We also have a RAC environment that is new where we will be implementing data guard. As soon as I set that up, I will come up with a post.
First, you need a database. I will assume that you have already done this. I will also assume that you have installed the Oracle binaries on your standby host. Please make sure it is at the same version as your production system and has all the same patches applied. If all that is done, then proceed.
Your database needs to be in archivelog mode. While logged in as sysdba, issue “archive log list” command. If it is not enabled, then enable it. If you don’t have log_archive_dest_1 set to anything, then it will use your flash recovery area by default . If you are going to use this, then make sure you have ample room by setting the db_recovery_file_dest_size parameter. Also make sure you physically have the diskspace. You also need to enable forced logging. This will not allow anything to run without it being logged.