GG extract - what is excessive 'control file sequential reads'?

User713324-Oracle

Hi,

base SR - 3-2192225691, GG - 10.4.0.19, database - 11.2.0.1.0, running on Linux x86 64-bit

customer opened SR based on high number of control file sequential read

Top 5 Timed Foreground Events (over 13+ hrs)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file sequential read 13,843,266 80,952 6 48.3 User I/O
DB CPU 44,897 26.8
control file sequential read 12,793,822 10,978 1 6.6 System I/O
enq: TX - row lock contention 30,000 10,066 336 6.0 Applicatio
log file sync 959,602 9,276 10 5.5 Commit


However, extract traces do not appear to show any waits associated with control files. A 10046 trace has been requested but not done as of yet.

Are there any known issues we can test for, or is this expected behavior? Any further tests that could be run?

Thanks,
Steve

-joe

Steve,

There is an Oracle internal list you can use. I just sent you email on how to join.

Here's a shot in the dark: I've seen something similar with log sync waits on systems not moving a lot of data (usually a test system) and we're a little eager to get the next piece of data when at the logical end of file. That can be overcome using THREADOPTIONS EOFDELAYMS. Otherwise you'll need to start using the OGG trace commands.

Good luck,
-joe