1) Run the long-running query in one session
2) In another session run @snapper4 all 10 1 &sid_of_where_you_run_your_query

This should tell us how much data you send back per roundtrip etc…

Wondering if you could give me some advice…..I just upgraded one of our databases from Oracle EE 11.2.0.2 on exadata 1/4 rack X2 to Oracle 11.2.0.3 on a new exadata X3 rack.

All seemed good, except for the following query that now seems to indicate far more “SQL*Net message from client”, “SQL*Net break/reset to client” and “SQL*Net message to client” wait events that I’d expect.

The query takes 3 mins 37 sec to return 1823 rows.

I executed the query on the same exadata X3 system where the database resides via SQL*Plus. So the only client involved is the exadata system itself.

I also re-ran the query with “ALTER SESSION SET EVENTS ’10046 trace name context forever, level 8′…..but the trace file produced doesn’t seem to show any “break” messages like I though might be the cause as per one of your previous posts.

Also, “tnsping CTPROD 999″ doesn’t seem to show any large TNS packet delays.

SQL>
select
c.value as object_name,
d.type_name,
e.*,
f.*,
g.*,
h.*
from
cobjects a
inner join cobject_transactions b on a.cobject_uid=b.cobject_uid and b.most_recent=’Y’
inner join cobject_attributes c on c.cobject_transaction_uid = b.cobject_transaction_uid
inner join cobject_types d on d.name_field_uid=c.cobject_attribute_type_uid
inner join cobject_contacts e on e.cobject_uid=a.cobject_uid
inner join cbusiness_contacts f on f.business_contact_uid = e.business_contact_uid
inner join cbusinesses g on g.business_uid=f.business_uid
inner join business_details h on g.business_uid=h.business_uid and h.most_recent=’Y’
where
(role_effective_to is null or role_effective_to>=TO_DATE(’22/5/2013 0:00:00′,’DD/MM/YYYY HH24:MI:SS’))
order by type_name,object_name;

Event TOTAL_WAITS TIME_WAITED AVERAGE_WAIT
———————————– ———– ———– ————
SQL*Net message from client 32761 16407504 500.82
SQL*Net break/reset to client 32758 56 0
SQL*Net message to client 32762 3 0
cursor: pin S wait on X 1 1 1.09
cell multiblock physical read 1 0 .05
cell single block physical read 81 4 .05
gc current block 2-way 14 0 .02
gc cr multi block request 2 0 .02
gc cr disk read 1 0 .01
library cache lock 27 0 .02
row cache lock 498 4 .01
library cache pin 28 0 .01
latch: row cache objects 1 0 0
Disk file operations I/O 2 0 .01
enq: TM – contention 3 0 .01
gc cr grant 2-way 37 0 .01

Thanks,

Damion.

In Oracle 10.2.0.2+ the library cache pin latch us…

If you have any personal experience, or have contact with others that do, I am looking for someone with whom I can compare notes. I have a feeling I know exactly what I am seeing but I don’t want to draw any conclusions from a single customer and their experience. Add to that the inability to see cluster interconnect traffic inside IO Mux packets and I find I am also flying blind.

Thanks.

Dan