Re: Oracle DataGuard and ORA-16099

From: Andrew Kerber <>
Date: Tue, 21 Sep 2010 21:12:06 -0500
Message-ID: <>

one correction, its alter database register logfile, not alter system.

On Tue, Sep 21, 2010 at 9:08 PM, Andrew Kerber <>wrote:

> 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 <> 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:
>> Errors in file <background dump dest>/<SID>_mrp0_%d.trc
>> ORA-16099: internal error ORA-00600 occurred in standby database.
>> 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.'

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Received on Tue Sep 21 2010 - 21:12:06 CDT

Original text of this message