Switch from Oracle Dataguard to DBVISIT

[christophers]

Hi, We are going to switch our current local standby database from dataguard and add an additional standby on a remote site.
What is the process of switching from DG to dbvisit? do we have to turn off dataguard or can we have them running in parrallel until we are happy with dbvisit?
The DG and dbvisit standby's are on different servers in different buildings.

It would be nice to keep the DG standby going during the dbvisit install just for recovery purposes. We have a 24x7 database.

Thanks
Chris

[Arjen Visser]

Hello Chris,
It is possible to run Dbvisit Standby and DataGuard (DG) side by side for the same primary database if they are both managing a different standby database. So you can keep DG running for the first standby database while you configure and test Dbvisit Standby for the new (second) standby database.

To setup Dbvisit Standby along side DG, the setup is as per normal. DG will nor interfere with Dbvisit Standby and Dbvisit Standby will not interfere with DG. To install and configure Dbvisit Standby, you will not have to change any init.ora parameters or restart the primary database.

An overview of the setup is as follows. Please see http://www.dbvisit.com/support/resources/ for our complete documentation:
1) Install Dbvisit Standby as per normal on both the primary and the new standby server
2) Configure Dbvisit Standby as per normal on the primary server.
3) Create the new second standby database using Dbvisit Standby.
4) Setup the Dbvisit Standby schedule on both the primary server and the standby server to keep the new second standby database up to date.

One option you have to be aware of is to not use the default compression that comes with Dbvisit Standby. This is because Dbvisit Standby will compress the archive logs and as a result DG may not be able to find them as the files will end in .gz. We suggest that for compression, you use the "SSH" compression option that is available during the Dbvisit Standby setup. This will use ssh compression on the fly when transferring the archive logs to the standby servers.

Kind regards,

[christophers]

Thanks Arjen,
Thats great news. The reason we are looking at dbvisit is the out of the box compression of the logs. We have to transmitt about 100G a day of logs and we are worried the link will not keep up.

Ok here is a long shot question for you.... Can i convert the current DG instance so it is managed by dbvisit? Be nice to have all my DR standby monitoring in one place... The database is nearly 3TB so creating a new standby is time consuming.

thanks
Chris

[Arjen Visser]

Hi Chris,
Yes you can use your current DG standby database to be managed by Dbvisit Standby as Dbvisit Standby will work with existing standby databases.

Install and configure as above, but skip step 3 above (create the standby database). The first time Dbvisit Standby runs, it will inspect the (existing) standby database, and will pick up synching where DG stopped.
This can be forced with the following resynch command which is run on the primary server:
dbvisit -R DDC
Where DDC stands for Dbvisit Database Configuration and is most likely the same as your ORACLE_SID.
This command inspects the standby database, obtains the last sequence rom the standby database and instructs Dbvisit Standby on the primary database to start transferring from this last sequence.

You cannot run Dbvisit Standby and DG at the same time for the same standby database because both will interfere with applying the (archive) redo logs to the standby database. You can however switch between the 2.
If you have run DG for a while and want to active Dbvisit Standby again, just run the above resynch command again to resynchronize Dbvisit Standby with the standby database.

If you want to use regular compression (non SSH compression) with Dbvisit Standby, this is also possible. But you have to set the following variable:
LEAVE_COMPRESS_SOURCE=No
This will compress the archive log files to disk as a .gz file, then transfer the file to the standby server, and then uncompress it again on disk after the transfer so that RMAN and DG will be able to find it.

Regards,

[christophers]

Thats great news. thanks!
It actually helps a lot. DG has the ability to backup and recover one datafile at a time to the standby. So for a large database like ours we only need to have 32G of disk space free not the 3TB i was thinking i would need.

I can set them up as DG first then switch to dbvisit to take advantage of the log compression.

Thanks
Chris

[christophers]

Just another quick update...
I had to open a ticket with support about my achivelog file names being different from each RAC Node. But I can fix that at the weekend with a restart of production if necessary.

My question is - What are the steps required to turn off the current dataguard? I have stopped log shippment and apply. Do i need to deconfiure dataguard or any of the archivelog_Dests?
Also i have the dbvisit logs shipping the gzipped files to /arch the current dataguard instance looks for logs in +ARCH.
Is there a easy solution to this? I tried updating the archive_log_dest but it doesnt seem to work. I think there is still some DG congig i need to remove.
Thanks
Chris