RDC Standby Wizard manual reader's review

So after the spam posting from RDC, I went and checked the features of their "Standby Wizard." Here are my findings. Note that I did not use their product, but only read the manual, so they may not be as bad as they appear from the manual.

>From their user's manual it appears Standby Wizard:

• Can't perform graceful failover and fail back. They can only activate, then re-copy the database back to the primary. In other words, no graceful role reversal, which totally disqualifies this product for use in planned failovers for system maintenance. It also means that anyone relying on this product will have unnecessarily extented periods without a redundant site, and unnecessary use of disk and network I/O while the database is reinstatiated.
• Can't manage alias IP addresses. All redirection of client applications must be performed manually.
• Can't instantiate the standby in parallel. Unless I am mistaken, instantiation is performed in serial, meaning that copying a database of any significant size will take a very long time.
• Can't notify someone if the standby stops working. I don't find any references to a proactive notification feature. So if the standby encounters a severe problem, nobody will know unless they happen to check and find the standby 5000 logs behind.

It also appears that the Standby Wizard's course of action when a datafile is added is to require the operator to request an 'incremental rebuild' of the standby database, which stated more accurately means copying a datafile or datafiles from the primary to the standby. As many of us know, that is totally unnecessary to copy a newly created datafile to the standby. All we have to do is wait for the standby to fail with ORA-01670, then issue:

alter database create datafile '<primary filespec>' as '<standby filespec>';

Their method uses resources unnecessarily and requires operator intervention, both of which seem senseless.

In short, I would not use this product in any serious, mission-critical situation.

--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jeremiah Wilton
  INET: jwilton_at_speakeasy.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).