RE: Some Dataguard is good, lots more must be better? (specifically, when do most actual failovers really occur?)

>From: Mark W. Farnham [mailto:mwf_at_rsiz.com]
>I'm curious what others see in the field: Is fail over routine or
emergency only? Do you have trouble getting back?

On one hand you must avoid what happened during probably the most [in]famous training day in the history which was in Chernobyl, May 1986.

On the other hand failover must be tested.

My experience is:

There must be High Availability Environment design as such. I for example used just to change DNS/IP address on the standby server machine so that all database clients did not need to be reconfigured in any way. I did not care how. If VIP(virtual IP) can be used for that - fine.
Next, a standby must be *ready* to be run as primary. Sounds trivial but some parameters must be correctly set. This can be thoroughly tested in the test environment however.

Next comes the fact that there is another entity apart of the database - a database server machine. Which can run some other tasks except of db server: scripts, chron jobs, etc. If those can not be moved to a separate machine then failover of those must be tested as well. I try to keep a list of software which has to be activated at the standby and I try to keep the software in sync on both servers. This configuration sounds like a mirror at OS level which it actually is. In my eyes this OS level mirror is the biggest issue because it is not managed by DG in any way. It is managed by personal which introduces the human factor which is the biggest threat for the whole enterprise.  

Fyrirvari/Disclaimer
http://www.landsbanki.is/disclaimer

--
http://www.freelists.org/webpage/oracle-l