Re: rowid problem

Comments embedded.
Osman Mavideniz wrote:
> hi,
>
> we have an asp application using oracle 9.2 database. rowid's are
used
> to reference the rows and they are stored as foreign keys.

Foreign keys? This implies you also have them stored as primary keys somewhere. One tends to wonder why you would do this?

> application
> is working fine but we are not sure about backing up database without
> getting the rows moved so the rowid's not changed. we looked for this
> in oracle documents and in the news groups but a little bit confused;
> its generally said that;
>
> {A rowid of a row can change in these cases:
> a) the table is an index organized table and you update the primary
> key.
> b) the table is a partitioned table and you "enable row movement" and
> you update
> the partition key and the update causes the row to physically move
>
> otherwise, it takes a complete rebuild of the table (export/import --
> alter
> table move -- dbms_redefinition for example) to "change" the rowid.}
>
>
> thus we appreciate who clarifies if its harmless(to rows and rowids)
> to backup/restore database for oracle 9.2?
>

Define what you mean by 'backup/restore', as it appears you think an export/import scenario is a backup/restore situation. A true backup/restore shouldn't change ROWID values, as the datafiles would be restored and any necesary redo applied to them during recovery. However, an export/import situation CAN change your ROWIDs, and very likely will. You say your application is running fine, but this folly of using Oracle ROWIDs as foreign keys is, well, ludicrous.

I would seriously re-think why you feel you must store ROWIDs in the database tables. This has disaster written all over it.

David Fitzjarrell
> thanks
Received on Thu May 12 2005 - 00:21:54 CDT