Configuring dataguard to manage the standby database

post info
By Nicolas de Fontenay Categories: High Availability Tags: 10g, configuration, dataguard, DGMGRL, Oracle Its possible to have dataguard configured using a grid controller but today I will explain how to configure using command lines. To anyone using this how-to, I strongly suggest reading this post. You will find a list of parameters which have a big impact on the smoothness of the configuration of dataguard client (DGMGRL) pre-requisites are: 1) You got a standby database synchronizing with you primary DB without any problem. 2) The parameters listed in the link above are specified. Create dataguard configuration The command can be run on either the primary or the standby server because the parameter files for dataguard will then be transfered to the standby databases host. Ive choosed to perform it on the primary server. C:\>set oracle_sid=<SID> C:\>DGMGRL / DGMGRL> Connected. DGMGRL>create configuration somename as primary database is primary connect identifier is primary.world; In this command, the word primary is the db_unique_name value specified in your parameter file. If you are not sure about it, you can connect to sqlplus as sysdba and type: SQL>show parameter db_unique_name; note: If you are not sure about the exact parameter name, type only a part of it. It will display any parameter featuring that piece of string typed. DGMGRL>show configuration; This command will display the configuration of dataguard for the specified primary DB. Obviously the status is DISABLED

Adding the standby to the configuration DGMGRL>add database standby as connect identifier is standby.world maintained as physical; Database standby added. DGMGRL>show configuration; The configuration will now display both the primary and standby databases in your configuration but the status is still disabled. Its now time to enable the configuration. DGMGRL>enable configuration; Enabled. DGMGRL> Show configuration; The status is now turned to SUCCESS. But this is a perfect world How to configure dataguard again if the first try fails In a world where your first trial fails for some reason, returning to the initial state (a primary, a standby, no dataguard configuration) is required and its not easy. If you are trying to enable the configuration and the command hangs, then you have a problem. All the previous steps, including the modification of parameters in the SPFILE dont require a shutdown of the DB. But to reset the configuration, a shutdown of the DB will be required. If you are working on a critical system, a shutdown will have to be scheduled off peak hours etc etc What the command enable configuration did is the generation of configuration files, located in ORACLE_HOME\database. Its the same folder as the SPFILE. It will also transfer those files to the standby host. The reason is simple, when the production server fails, I would love to be able to still use what is left. And what is left is my standby database and server. The files are named as follow: DR1<INSTANCE>.DAT DR2<INSTANCE>.DAT hc_<instance>.dat

Deleting those files would mess up with a dataguard configuration at best but will not harm a critical system. But as it turns out, they are not easy to delete because they are accessed by oracle services. DR1 and DR2 are easily removed. To remove this hc_ file: connect to SQLplus: C:\>sqlplus / as sysdba SQL>alter system set dg_broker_start=false scope=both; When this is done, shutdown the database and delete all the .dat files specified above. The same process must be performed on the standby server and database. When the files are deleted: Connect to sqlplus again and set the parameter back to TRUE SQL>alter system set dg_broker_start=true scope=both; Perform the same on the standby. It is now possible to try again to enable the configuration. To complete this explanation on the configuration of DGMGRL, here is a list of parameters which were very important to the success of the configuration *.db_unique_name=TESTDG *.local_listener=(ADDRESS=(PROTOCOL=tcp)(HOST=standbyserver)(PORT=1911)) *.log_archive_config=dg_config=(TEST10,TESTDG) *.LOG_ARCHIVE_DEST_1=location=g:\oradata\TEST10\arch VALID_FOR=(ALL_LOGFILES, ALL_ROLES)db_unique_name=TESTDG *.log_archive_dest_2=SERVICE=TEST10 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=THTES T10 *.dg_broker_start=TRUE *.standby_file_management=AUTO *.fal_server=TEST10.WORLD *.fal_client=TESTDG.WORLD On my first configuration, all the parts marked in Orange were absent of my parameter files. That was all I had in the how-to I used. The synchronization of the primary and the standby worked that way. But when it comes to configuring Dataguard, it was a complete failure. As it turns out, the primary cause of all my problems were the missing parameters and options. Adding the databases to the Grid controller

If later on , for more control a grid controller is installed (makes sense isnt it ^^). All that will be needed is to install the controller agent on the primary and the standby server. The grid controller will detect right away that there is a standby database managed by dataguard and it will be possible to view it through the grid controller. Enjoy! It has been a great project. Ive enjoyed a lot going through this. There has been a lot of frustration on the way due to the difficulty of getting information on how to do this. Particularly after it failed the first time. I sincerely hope that this document will be useful to a lot of people. Succeeding gave a great feeling of achievement. If theres anything wrong or unclear, just let me know in the comments. Let me know as well how it went for you too.