I'm looking at a client application which retrieves several columns including ROWID
, and
later uses ROWID
to identify rows it needs to update:
update some_table t set col1=value1
where t.rowid = :selected_rowid
Is it safe to do so? As the table is being modified, can ROWID
of a row change?
"From Oracle 8 the ROWID
format and size changed from 8 to 10 bytes. Note that ROWID
's will change when you reorganize or export/import a table. In case of a partitioned table, it also changes if the row migrates from a partition to another one during an UPDATE
."
http://www.orafaq.com/wiki/ROWID
I'd say no. This could be safe if for instance the application stores ROWID
temporarily(say generating a list of select-able items, each identified with ROWID
, but the list is routinely regenerated and not stored). But if ROWID
is used in any persistent way it's not safe.
Assuming that you are using the ROWID
a short period of time after you SELECT
it, that the table is a standard heap-organized table, and that the DBA isn't doing something to the table (which is a reasonably safe assumption if the application is online), the ROWID
will be stable. It would be preferable to use the primary key but when the primary key isn't available, plenty of Oracle-developed tools and frameworks will use the ROWID
for short periods of time. It would not be safe if you intended to use the ROWID
a long period of time after you SELECT
it-- for example, if you allow users to edit data locally and then synchronize with the master database some arbitrary length of time later.
The ROWID
is just a physical location of a row so anything that causes that location to change will change the ROWID
.
ROWID
.INSERT
might insert data with completely different data that happens to use the same ROWID
the deleted row previously had.ROWID
to change. Exporting and importing the table will change the ROWID
for example, but so will doing something like the new-ish online shrink command. These administrative tasks will not normally be done while the application is up, however, and will almost certainly not be done during the day. But it could lead to problems if the application isn't shut down when a DBA does this sort of thing or if the application persists the data.Over time, it has become more and more common for new features to introduce new possibilities for ROWID
s to change. Index-organized tables and the online shrink option, for example, are relatively new features. In the future, it is likely that there will be more features that will involve the potential at least for a ROWID
to change.
Of course, if we're being pedantic, it's also not safe to rely on the primary key. It is perfectly possible that some other session comes along and updates the primary key of the row after you read it or that some other session deletes the row after you select it and inserts a new row with the same data and a different primary key. In either case, it helps to have some local knowledge about what the applications using the database are actually supposed to be doing. It would be extremely uncommon, for example, to allow updates to primary keys or to reuse primary keys so you can generally determine that it's safe to use a primary key. Similarly, it is relatively common to conclude that given the way you're using partitioning or given the way you've defined the index in your index-organized table that updates won't actually change the ROWID
. If you know that the table is partitioned by the LOAD_DATE
, for example, and that you never update the LOAD_DATE
, you won't actually experience changes to the ROWID
because of an update. If you know that the table is index-organized but that you're not updating a column that is part of that index, the ROWID
won't change on an UPDATE
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With