one correction, its alter database register logfile, not alter system. On Tue, Sep 21, 2010 at 9:08 PM, Andrew Kerber <andrew.kerber@xxxxxxxxx>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 <gus.spier@xxxxxxxxx> 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.' > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'