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

  • From: "Laimutis Nedzinskas" <Laimutis.Nedzinskas@xxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 20 Sep 2006 12:04:32 -0000

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@xxxxxxxxxxxxx
Sent: 20. september 2006 11:46
To: oracle-l@xxxxxxxxxxxxx
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@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 -
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.



Other related posts: