Comments on: Transportable tablespaces and ROWID uniqueness

By: Rajorshi

Rajorshi — Thu, 19 Mar 2009 10:31:13 +0000

Thank you so much Tanel.

It works for me. I wanted this to write a procedure that will give me the density of rows in a block for a table.
So, that I can have a count of rows in a block before and after a purge job.

regards Raj

By: Tanel Poder

Tanel Poder — Tue, 24 Feb 2009 22:12:17 +0000

Hi Raj,

DBMS_ROWID package does this for you.

You can run something like this:

select
dbms_rowid.ROWID_RELATIVE_FNO(rowid) rfile#
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block#
, dbms_rowid.ROWID_ROW_NUMBER(rowid) row#
from
mytable
where
id = 100
/

By: Rajorshi

Rajorshi — Tue, 24 Feb 2009 18:56:40 +0000

Hi Tanel

A very interesting revelation which even Oracle would be surprised to know.

I have very trivial question for you. Is there a way to decode the blockid that a row resides in from its rowid by using x$ table or v$ view and without restoring to block dumps?

thanks and regards
Raj

By: Pavan Kumar N

Pavan Kumar N — Mon, 24 Nov 2008 14:59:36 +0000

H Tanel,

I heard you name from some many posters and referred your Blog. You are like “Jonathan Lewis”.

I am very inspired by your posts.

Really Great… !!

Thanks

By: Js

Js — Mon, 17 Nov 2008 14:31:15 +0000

Hi Tanel,

I have been a silent reader of your blog.

Today, I am curious to know that how much time you just spend to explore all these things apart your job.

Or you job gives you all this exposure :)

Actually, I am also interested but very much occupied with daily routine jobs at office and could not spend time to upgrade myself.

But when I saw people like you … I am happy but want to know . how you manage ?

Thanks -

By: tanelp

tanelp — Fri, 24 Oct 2008 10:44:02 +0000

Mladen,

I think you misunderstood the point of my article.

Oracle concepts guide apparently doesn’t state this uniqueness thing clearly enough – as I hadn’t noticed it :)

Btw, rowids are actually stored – in indexes for example. As I mentioned, global indexes on partitioned tables store extended rowid. However as there’s no uniqueness across tablespaces, then more information is needed for rowid -> physical file block translation in addition to just rowid. And this info probably comes from dictionary cache (dc_segments).

Also there are next-rowpiece pointers for chained and migrated rows which have only *relative* DBA + row# in them, so these need little logic as well which would translate the relative file# to an absolute file#.

Transporting a tablespace to the same database was easiest and most straightforward test case – and it served its purpose, it proved a case how rowids can be non-unique.

If something is possible, it’s only matter of time before it happens.

So, to recap: the whole reason why we have rowids in Oracle is having secondary access paths like indexes – which DO have the rowids *stored* in them! If we didn’t store them, the index would be useless!

By: Stig

Stig — Thu, 23 Oct 2008 07:34:35 +0000

Mladen,
Yes, you’re right – the rowid IS computed. But the computation is a deterministic function as it would otherwise fail in a global index for a partitioned object, which can have multiple segments.
The computation is merely a rather simple function to break the old 1022 files limitation, so any rowid in Tanels exampel is internally transformed into a physical rowid for the desired physical file and data object.
Issues can still arise if you get tablespaces from several databases, which you comprise into a single partitioned table if the data object id (which is local to the tablespace and datafile) already exists as a segment in the partitioned table. This would give you the error I showed in my previous comment.
In other words: You can get into trouble even without having duplicate rowid’s in the database. You just need 2 tablespaces each with an object with the same physical data object id for inclusion into the same partitioned table.

By: Mladen Gogala

Mladen Gogala — Wed, 22 Oct 2008 18:52:34 +0000

Tanel, I was under the impression that ROWID column is computed and not stored. If the column is computed, then there is no need to recode it in the transported tablespace. The concepts manual clearly states that extended rowid is tablespace relative. That would explain the appearance of the same rowid in 2 different tablespaces.
You did transport the tablespace into the same database. That would preserve physical characteristics enough to allow the same rowid.
In other words, rowid pseudo-column is computed at the time of query and thus should couse no issue when the tablespace is transported.

By: tanelp

tanelp — Wed, 22 Oct 2008 15:06:10 +0000

@Tom: yep I sure would rebuild the indexes in alter table move case (which would make this post-processing step even longer)

@Stig: Very cool! I never had thought of that (and I didn’t know about this conflict error message before). Thanks for telling that.

By: Stig

Stig — Wed, 22 Oct 2008 08:49:48 +0000

Tried a little experiment just to see if this was watertight!

The question:
What if the same tablespace (with the same table renamed appropriately) was imported to the same database twice for being added to a partitioned table?
This construct could actually be interesting in datawarehousing although it would give duplicat rowid’s within the very same table.

Luckily Oracle thought on that as well, yeilding ORA-19728 “data object number conflict between table %s and partition %s in table %s”.
So we are prevented from having more than one partition (=segment) with the same data_object_id.

Just my 2c to demonstrate the difference between a data object and a table as a table may have more data objects (ie. segments) and to tie up a loose end that wasn’t tried.

Thanks for the inspiration for this little additional test.