If you ENABLE ROW MOVEMENT on a partitioned table, then the rowid of a row can change if the partitioning or sub-partitioning key is updated such that the row must be moved into a different partition or sub-partition. However, this is not the default, so you are probably safe in this regard.

However, you cannot assume that the rowids of deleted rows will not be reused by subsequent inserts to the same table. In fact, once the delete transaction has been cleaned out, you can almost guarantee that they will be. So you will need to find another way of doing your deletes (possibly using the primary key).

Of course, there are numerous other ways of doing this that would be much more efficient.

I have to purge the data from my database and, at the same time, save it in other place. For this task I developed some procedures that execute some steps :

1) Select all the data that is about to be purged and save it in a formated text file (ready for loader "load", if necessary) and insert in a table (called table_rowid) the corresponding ROWID's row.

2) Purgue all the data that matches its rowid with the rowid saved on the table_rowid.

I have some questions:

1) I know that ROWID never changes for a row unless you change it using EXP/IMP utilities, that is, change its location on the database phisically. So, I don't need to be concerned about a change in the value of ROWID during this process, am I?

2) Let's think that, for any reason, the deletion process cancel. For example, in my table_rowid there is 1.000.000 row (rowid's) and I have deleted only 400.000. After one week (on the next weekend, in general), I will start the process again, running only the second part (the deletion). So, I have to purge 600.000 rows and I execute the deletion for 1.000.000 rows. I was wondering how Oracle assign NEW rowid's and if there is any risk on deleting all those lines again (if Oracle assign a rowid already deleted - one week ago - to a new line)? This is the main QUESTION...