Re: After Dataguard failover not able to make switchover back

  • From: Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx>
  • To: peter.mclarty@xxxxxxxxxxx
  • Date: Fri, 20 May 2005 08:35:27 +0200

On Fri, 2005-05-20 at 05:04, Peter McLarty wrote:
> Thanks for the info
> 
> I found out what is was when we did the failover the 1_0.dbf file was
> created as a standby redo log. There is nothing documented that they are
> needed that I have found. So after working this out and assessing the
> situation I dropped this from the primary and recreated it in a better
> location along with the other 3 in accordance with the doc's and then
> did the same to the standby and once it was done it was working.

Look at Paragraph 5.3.3 of the Oracle Data Guard Conecpts and
Administration doc. (9.2).  It explains the standby controlfile thing.
Actually, for no obvious reason Oracle recommends having 1 more standby
controlfile (group) than the number of online controlfiles. I've never
seen DG actually using more than 2 standby controlfiles.

I create the standby redo logs on both ends, and leave them there, no
drops. No hassle with them during switch/failover then. 

I saw you have a standby controlfile assigned by that name. It means you
have different initfiles for primary and standby. I also use two
init-files, just containing ifile= lines. The first includes a file with
all parameters that are the same for primary and standby, the second
line includes the role-dependent parameters. That way you cannot forget
changing a parameter in all (= 4) files too easy, making the setup more
robust.

The controlfile can be just the (redundant) set of controlfiles you
already have. Of course you create a standby controlfile, but that gets
the same name/location as soon as arrived at the standby, ans is copied
over to its redundant location as well. The 'commit to switchover'
commands, and activate commands, will take care of converting the
controlfile to a standby controlfile and back. Same thing, more
robustness.


> 
> Physical standby with maximum performance is the best solution for this
> customer. You don't want to know why.

On the contrary, I'm getting curious.

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok)
===

> 
> 
> Cheers
> 
> Peter
> 
> 
> Carel-Jan Engel wrote:
> > Hi Peter,
> > 
> > Sorry for not getting back on this earlier. I had to assist a customer
> > yesterday evening.
> > 
> > When a standby will not switchover to primary, several reasons can lead
> > to this.
> > 
> > First: did you create the standby controlfile from the primary _after_
> > you made the backup of the database? Otherwise it might not become a
> > proper standby.
> > 
> > Second: Did you verify that the standby catched up with the primary?
> > E.g. did you check that the logfiles were applied? (check the applied
> > column in v$archived_log)
> > 
> > Third: Did you commit to switchover to standby the primary first? The
> > primary needs to be switched first, before the standby can switchover.
> > Otherwise it is a failover again.
> > 
> > You are using the ..file_name_convert parameters. Why is that? Are both
> > databases on the same server? That is not much High Availability. And,
> > if not, I recommend to keep your systems as symmetric as possible, for
> > robustness. Otherwise the server you have to deal with all of a sudden
> > is a differente environment after a failover. That makes the situation
> > even more error-prone, when the system is more vulnerable. After the
> > failover you don't have your standby to protect you, unless you had two
> > of them.
> > 
> > Best regards,
> > 
> > Carel-Jan Engel
> > 
> > ===
> > If you think education is expensive, try ignorance. (Derek Bok)
> > ===
> > 
> > 
> > 
> > 
> > 
> > On Wed, 2005-05-18 at 12:32, Peter McLarty wrote:
> > 
> >>/Hi all DG gurus
> >>
> >>I have run some tests of dataguard and in the it all something has
> >>happened of which I am a little lost.
> >>
> >>After a number of configuration errors in the two databases I had the
> >>system making switchovers successfully. Then the client insisted that we
> >>do a fail over test. the failover went smoothly and all appeared well.
> >>No for the fun part I rebuilt the old primary as a standby to the new
> >>primary and have now had 4 attempts to successfully switchover none of
> >>which have worked.
> >>
> >>I have a problem that the switchover fails because the standby says
> >>there is incomplete recovery and as such cannot continue.
> >>I think i may have stuffed this one  and may have to export the data and
> >>rebuild a new clean primary but if anyone has any ideas as to how to
> >>recover I would appreciate it/
> >>
> > 
> >>/Oracle 9.2.0.5
> >>AIX 5.2
> >>
> >>
> >>Cheers
> >>
> >>Peter
> >>--/
> >>/_//www.freelists.org/webpage/oracle-l_/
> >>
> > 
> > 




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

Other related posts: