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

A follow up:
The OS mirror issue means that system admin must unfortunetely be quite involved in the failover process or DBA must take some tasks from sysadmin. I used to work in such an environment, for example, for me as DBA it was no issue to keep in synch and activate all scripts, jobs, etc at the standby machine.

Regarding the routine:

First, if nothing is changed in the *Environment* then one initial failover test is fine.
However if new scripts, jobs are added, database is reconfigured then formally it must be tested again.
Some tests like network rerouting can be actually separated and executed w/o actual failover. It is enough just to restart database :-) for that.

As for routine tests just because to know that standby can be opened then in my expierence it definetely can be opened when need comes. Physical standby operates using fundamental Oracle redo mechanism which is well tested.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]
Sent: 20. september 2006 11:46
To: oracle-l_at_freelists.org
Subject: 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


Fyrirvari/Disclaimer
http://www.landsbanki.is/disclaimer
--
http://www.freelists.org/webpage/oracle-l