Re: Oracle DataGuard and ORA-16099
Date: Wed, 22 Sep 2010 09:29:35 +0300
Message-ID: <OF025AEC16.ECA23A23-ONC22577A6.002322A8-C22577A6.0023AAFD_at_seb.lt>
>you need to copy the missing archivelogs to a location that is readable by
the standby server, then run the ' alter system register logfile 'file name with path';.
you can probably do that.
But what worked for me is rman and a proper DG setup:
- restore archive logs (on primary)
- they get pushed and registered onto standby by DG
May be the restore may work on standby host too but I've never tested it.
As for this particular issue (incremental restore and ora-600) it may make
sense to create a new standby control file on primary and move it into
standby.
Just remember one thing - backup all your controlfiles before doing
anything to them.
As one clever man said" There are never too many backups of control files"
Please consider the environment before printing this e-mail
Andrew Kerber
<andrew.kerber_at_gm
ail.com> To
Sent by: gus.spier_at_gmail.com
oracle-l-bounce_at_f cc
reelists.org oracle-l <oracle-l_at_freelists.org>
Subject
Re: Oracle DataGuard and ORA-16099
2010.09.22 05:09
Please respond to
andrew.kerber_at_gma
il.com
I dont like the looks of that particular error, but when you have a fal gap, you need to copy the missing archivelogs to a location that is readable by the standby server, then run the ' alter system register logfile 'file name with path';.� At that point, you can tail fhe alert log and see if it begins to bring and apply the logs normally.� However, this looks like an ora-600 error, and I dont know how that affects the process.
On Tue, Sep 21, 2010 at 8:56 PM, Gus Spier <gus.spier_at_gmail.com> wrote:
Solaris 10
Oracle 10.2.0
I've inherited the STANDBY database portion of a� DataGuard lash-up
and only now have the resources to take a look at it.� The previous
custodian appeared to have better things to do.
DataGuard is not one of my strong points.� I'm clever enough to read
(or at least, start to read) the documentation before mission urgency
demands that I "do something".� I check the alert log and attempt to
foIlow what the database thinks it's doing.� It appears the STANDBY
db is applying archived redo logs, but runs into a gap.� We have
taken an incremental backup from the PRIMARY and recovered it on the
STANDBY; copied control files from PRIMARY to STANDBY; STARTUP MOUNT;
and altered the db to recover managed standby database disconnect
from session but it seems to run into the same obstacle.� After
metalink (MOS) and google fail to point towards a solution, I need
help.
From the alert log:
<TIMESTAMP>
Errors in file <background dump dest>/<SID>_mrp0_%d.trc
ORA-16099: internal error ORA-00600 occurred in standby database.
<REPEATS>
From the trace file:
FAL[client,MRP0]: Error 16099 fetching archived redo log from
<Primary DB SID>
subsequent lines referenced "kccr", which I assume refers to an
oracle function that deals with control files ...
The trace file also seems to be making a recommendation to
increase ?CONTROL_FILE_RECORD_KEEP? value.� But it doesn't say where,
either on the STANDBY database or the PRIMARY.
I am not at work at the moment and am trying to fill in more details
from my admittedly imprecise memory.
Can anyone drop a clue for where to start looking next?
Thanks in advance.
Gus
-- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' -- http://www.freelists.org/webpage/oracle-lReceived on Wed Sep 22 2010 - 01:29:35 CDT