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

To: <oracle-l@xxxxxxxxxxxxx>
Date: Wed, 20 Sep 2006 11:45:37 -0000

>From: Mark W. Farnham [mailto:mwf@xxxxxxxx] 
>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
--
//www.freelists.org/webpage/oracle-l

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

Other related posts: