Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Possibility of changing Rowid because of UPDATE operations

RE: Possibility of changing Rowid because of UPDATE operations

From: Rognes, Sten <Sten.Rognes_at_schwab.com>
Date: Wed, 17 Mar 2004 13:09:55 -0800
Message-ID: <A252B2CDF6D2D4119DAB0002A51326DE20333D60@n1028smx.nt.schwab.com>

Further to what's been mentioned already... With 10g there is a "alter table <table_name> shrink space" command. To use this feature you need to enable row movement hence ROWIDs are very likely to change following the shrink.

Sten

-----Original Message-----

From: Prasada.Gunda_at_hartfordlife.com [mailto:Prasada.Gunda_at_hartfordlife.com]

Sent: Wednesday, March 17, 2004 8:40 AM
To: oracle-l_at_freelists.org
Subject: RE: Possibility of changing Rowid because of UPDATE operations

Thanks Justin, Mladen, Jay and Tim for your inputs and suggestions.

I agree with you Justin that we can not rely on ROWID behavior as it is internal to Oracle. I mentioned the same when one of our team member had came up with this suggestion. That was the reason I sent out an email to find more about how it works with 9i/10g releases and with different types of tables (like IOT, Cluster and Partitioned tables etc). I really got great inputs from all of you.

Justin, we are actually using 9i Change Data Capture(CDC) technique and it provides all the changes that happen on the source table in the change table. But, the problem is when we update our staging table on the DW end. We have persistent staging area where it maintains the history of all the changes of source. So, when we see a changed row in the change table (CDC), we need to terminate the existing row and insert a new row (it is Ralph Kimball Type 2 method) in the staging table (DW). The way the existing record gets terminated by using (natural) key of the source table. So, if the source table does not have a key, there is no easy way to update the existing row in the staging table except using the 'UU' record of the change table to update the existing row(by using all columns of 'UU' in the where clause of an update statement) in the staging table and using 'UN' record as a new record. So, one of the team member suggested to use the rowid (change table keeps track of the rowid) instead of using all 'UU' record values. I wasn't quite comfortable using rowid for the reasons of rowid changes and on top of that whenever source system does any kind of operations on even normal table that causes rowid change (export/import, alter table.. move etc), it would mess up the staging table since we can not update the existing row due to change in rowid. This the story behind sending my original email.

Thank you all again.

Best Regards,
Prasad
860 843 8377  

                      "Justin Cave

                      (DDBC)"                   To:
<oracle-l_at_freelists.org>
                      <jcave_at_ddbcinc.com        cc:

                      >                         Subject:  RE: Possibility of
changing Rowid because of UPDATE operations                
                      Sent by:

                      oracle-l-bounce_at_fr

                      eelists.org

 

 

                      03/16/2004 03:03

                      PM

                      Please respond to

                      oracle-l

 

 





The ROWID is certainly liable to change due to an UPDATE of an IOT. I can't think of a reason Oracle would change the ROWID of a row in a normal table because of an UPDATE, but Oracle certainly does not guarantee such a thing. It's always possible that some new feature will come along and cause ROWID's to change because of an update-- I would avoid designing a system that depended on hoping that didn't happen.

Have you looked into Oracle Change Data Capture (CDC)? It sounds like that's what you're after here. If so, it's a lot easier to use Oracle built-in functionality that to write it yourself.

Justin Cave
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Prasada.Gunda_at_hartfordlife.com Sent: Tuesday, March 16, 2004 11:53 AM
To: oracle-l_at_freelists.org
Subject: Possibility of changing Rowid because of UPDATE operations

Hello All,

Do you think of any situation where Oracle would change the rowid(or move the row that causes rowid change) under the hood in 8i/9i or even in 10g if there are simply Update operations happen on a row?

I know that the Rowid of the row is not going to change when there is a row chaining/migration. So, this is not an issue. And, I understand that the Rowid would change in other situations like row is deleted/inserted, table is exported/imported, truncated/reloaded or alter table..move and other similar operations.

But, I am only concerned with Update operations. Even in IOT and Cluster tables, I believe Oracle would maintain the same rowid if there is an Update to a row.

Please let me know your thoughts/suggestions.

Ours is a DW environment and would like to use the rowids to identify changes in the source table where there is no primary/unique key.

Thanks in advance,

Best Regards,
Prasad



PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.


Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
************************************************************************* PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *************************************************************************
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Wed Mar 17 2004 - 15:11:31 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US