Re: C++ equivalent type to Oracle's rowid.

From: Randolf Geist <>
Date: Wed, 25 Mar 2009 03:28:47 -0700 (PDT)
Message-ID: <>

On Mar 24, 5:00 am, Shane <> wrote:
> As aside I was benchmarking a design which uses a unique primary index
> to perform the updates like this:
>   update ... ser where order_id=ord_id and order_date=ord_date;
> vs. a design in which there were NO/ZERO indexes and the update was
> done like:
>   update ... set .. where rowid=id;
> Unexpectedly the indexed version generally out performs the rowid
> approach. I was thinking that passing around 19 byte rowids and/or
> implicit chartorowid()/rowidtochar() were slowing down the rowid
> version.


unfortunately I can't answer your question regarding the equivalent type in C++ for the ROWID. I'm only aware of e.g. the OCIRowid type provided by the Oracle C++ call interface and some ancient reference to some OTL_ROWID class.

My question is: How have you determined which version (index, rowid) performed better? You should consider tracing your sessions in Oracle to get the actual number of logical I/Os/work performed for both variants to make sure that your test results are not influenced by some external factors.

You can enable extended SQL tracing by using "alter session set events '10046 trace name context forever, level 8';". It can be disabled using "alter session set events '10046 trace name context off';".

This will generate a trace file in the USER_DUMP_DEST of your server. You can simplify the identification of the trace file by using "alter session set tracefile_identifier = 'mytrace'" which means that "mytrace" will be part of the trace file name generated.

You can then analyze the generated trace file by using the TKPROF trace file analyzer utility. The text file generated will show you various statistics and details about the execution and ultimately allows you to understand the differences between the two approaches.


Oracle related stuff blog:

SQLTools++ for Oracle (Open source Oracle GUI for Windows): Received on Wed Mar 25 2009 - 05:28:47 CDT

Original text of this message