Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: sql trace - XCTEND rlbk=1, rd_only=1
Thanks, Jared, Tanel.
I was a little supprised to see a combination
rlbk=1,rd_only=1. Why read-only bit is set here if it
rolls back anyway?
So I thought may be they mark their tx explicitly as
read-only (aka "set transaction read-only"). Reveiwing
OCI fine manual there seemed to be an option of doing
just that with the OCITransStart() call and setting
some flags...
But than simple test-case of tracing commit and rollback in SQL*Plus disproved the theory about read-only tx, as "normal" commit/rollback produce this combination regardless of the tx type:
commit - XCTEND rlbk=0, rd_only=1
rollback - XCTEND rlbk=1, rd_only=1
set transaction read only
commit - XCTEND rlbk=0, rd_only=1
rollback - XCTEND rlbk=1, rd_only=1
So much for my theory :-(
Another question I had here is whether or not having so many (implicit?) rollbacks on about every SELECT statement all over my trace file bears any overhead and proves deficiency of a stateless architecture used by this application - but again reviewing v$sesstat before and after I see user rollbacks count incremented, but no additional redo vectors generated. I guess I can try Tom Kyte's test harness, but it just doesn't sit well with me that 30 selects are as cheap as 30 selects with 30 rollbacks.
Thanks,
Boris Dali.
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Tue Nov 25 2003 - 16:14:27 CST