RE: Logical Standby Issues (cont.)

These numbers by themselves don't make a whole lot of sense to me, either.

If these numbers are from the same AWR period as the second set of Top 5 Timed Events, it doesn't seem to be a parsing problem. I was wondering where the CPU time was going during apply and parsing ain't the whole story [1176/(141*60)=~12% of the total CPU time, 1176/8118=~12%].

This is a single column update, right?

Is this column indexed?

What is the size (in blocks) of the table?

What is the description of the table (columns, types, sizes, nullable)?

Was there anything else going on during the test?

Would you be able to post or attach the whole AWR report? Both for the mining and the apply?

Would you be able to rerun the test with AWR set to capture every 5 min?

-----Original Message-----
From: Mark Strickland [mailto:strickland.mark_at_gmail.com] Sent: Thursday, August 10, 2006 4:16 PM
To: Rich Amick
Cc: oracle-l_at_freelists.org
Subject: Re: Logical Standby Issues (cont.)

The latch contention appears to have been fixed in 10.2.0.2. My tests in that version showed no latch contention. Here are the statistics you requested from the AWR report. This is for the time period after Log Mining completed and while SQL Apply was continuing, 141 minutes. The per Trans numbers don't make sense to me. In the Load Profile section, there isn't a value for Transactions. During this time period, the SQL update statement had 235,162 executions with 5.08 gets/exec and .02 physical reads/exec.

Statistic                            Total	per Second	 per Trans
===================================
parse time cpu                1,176 	  0.14 	                      45.23
db block gets    	    266,030 	31.36 	              10,231.92
consistent gets 	1,068,804   125.98                 41,107.85
physical reads direct    	192 	  0.02 	                       7.38

--
http://www.freelists.org/webpage/oracle-l