Home » Server Options » Data Guard » 10g dataguard slow apply and reset log issue (oracle 10.2.0.4,Sun OS 5.1)
10g dataguard slow apply and reset log issue [message #530663] Wed, 09 November 2011 09:28 Go to next message
snowball
Messages: 229
Registered: April 2006
Location: China
Senior Member

Hi, guys
We are facing a strange problem.
We have a dataguard, primary + logical standby.
Due to some reason, hundreds of archived log are not applied.
And then we start the logical apply, then we found after applied 100 archive logs.
The apply state became idle, but there are at lease 200 logs are not applied and no error report on dba_logstdby_events view.
After checking the minning scn, we found it changes.
From the alert log of standby, we found it's minning other archive log which means that it's probably the archive log generated by standby itself.

Here is what we see from alert log from standby
Tue Nov  8 07:43:08 2011
Logmnr Session 1:
Start processing redo logs from a new log branch:
resetlogs_change# :  [0x0000.07ca60d7]
resetlogs_id :  764419099
Tue Nov  8 07:43:08 2011
LOGMINER: Turning ON Log Auto Delete
Tue Nov  8 07:43:09 2011
LOGMINER: Error 308 encountered, failed to read missing logfile /arch/1_1_764419099.dbf
Tue Nov  8 07:43:15 2011
RFS[1]: Archived Log: '/arch/1_1_764419099.dbf'
Tue Nov  8 07:43:15 2011
RFS LogMiner: Registered logfile [/arch/1_1_764419099.dbf] to replace corrupted copy in LogMiner session id [1]
Tue Nov  8 07:43:15 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1, /arch/1_1_764419099.dbf
Tue Nov  8 07:43:15 2011
LOGMINER: End mining logfile: /arch/1_1_764419099.dbf
Tue Nov  8 07:43:15 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1, /arch/1_1_764419099.dbf
Tue Nov  8 07:43:15 2011
LOGMINER: End mining logfile: /arch/1_1_764419099.dbf
Tue Nov  8 07:43:15 2011
LOGMINER: Error 308 encountered, failed to read missing logfile /arch/1_2_764419099.dbf
Tue Nov  8 07:43:21 2011
RFS LogMiner: Client enabled and ready for notification
Tue Nov  8 07:43:21 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[5]: Successfully opened standby log 7: '/oracle/accdb/lstandby03.log'
Tue Nov  8 07:43:23 2011
RFS LogMiner: Registered logfile [/arch/1_2917_689941847.dbf] to LogMiner session id [1]
Tue Nov  8 07:44:15 2011
RFS[1]: Archived Log: '/arch/1_2_764419099.dbf'
Tue Nov  8 07:44:16 2011
RFS LogMiner: Registered logfile [/arch/1_2_764419099.dbf] to replace corrupted copy in LogMiner session id [1]
Tue Nov  8 07:44:16 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 2, /arch/1_2_764419099.dbf
Tue Nov  8 07:44:16 2011
LOGMINER: End mining logfile: /arch/1_2_764419099.dbf
Tue Nov  8 07:44:16 2011
LOGMINER: Error 308 encountered, failed to read missing logfile /arch/1_3_764419099.dbf


See this? auto delete 1_2668_689941847.dbf.
Tue Nov  8 07:44:16 2011
LOGMINER: Log Auto Delete - deleting: /arch/1_1_764419099.dbf
Deleted file /arch/1_1_764419099.dbf
Tue Nov  8 07:44:16 2011
LOGMINER: Log Auto Delete - deleting: /arch/1_2668_689941847.dbf
Deleted file /arch/1_2668_689941847.dbf
Tue Nov  8 07:44:16 2011
LOGMINER: Log Auto Delete - deleting: /arch/1_2669_689941847.dbf
Deleted file /arch/1_2669_689941847.dbf


The sequence# is 2668, but the former one is 1_1_764419099.dbf.
Does anyone know why this issue happened?

Thanks very much.

[Updated on: Wed, 09 November 2011 09:36]

Report message to a moderator

Re: 10g dataguard slow apply and reset log issue [message #530786 is a reply to message #530663] Thu, 10 November 2011 08:26 Go to previous message
snowball
Messages: 229
Registered: April 2006
Location: China
Senior Member

Some update from this issue.
We can't find any "resetlogs" keyword with statement "alter database", so it should not be manual resetlogs.
And I have checked both archive log sequence, both of them larger than 2000.
So why there is a resetlogs id is very puzzling.

Previous Topic: CLEARING Status for logs
Next Topic: changing password on primary database
Goto Forum:
  


Current Time: Wed Sep 17 16:57:42 CDT 2014

Total time taken to generate the page: 0.10903 seconds