Oracle 11g rename. Guaranteed to be atomic?

Question

Hi,

I have some (5) rename statements in a plsql script

drop table new;
rename old to new;

"old" tables hold very valuable information.

As I see it, if the rename command is guaranteed to be atomic, then I´d have one problem solved.

Is it atomic? If not, is there a way to do a "safe" rename ?

Thanks in advance

Answer 1

RENAME is a DDL command. So it is a single discrete transaction, if that's what you mean by atomic in this context. Consequently it is about as safe as anything could be. I can't imagine how a renaming would cause you to lose your data. But if you're feeling paranoid, just remember that's why Nature gave us backup and recovery.

edit

The way to be sure you don't lose data if the DROP succeeds and the RENAME fails is to deploy RENAME twice:

SQL>  rename old_table to something_else;
SQL>  rename new_table to old_table;
SQL>  drop table something_else;

That way you have your data online. This also minimises the downtime.

Answer 2

Rename will be atomic, so you should be fine. As APC has noted,

I can't imagine how a renaming would cause you to lose your data.

The only thing I can see in your script would be the time after the drop and before the rename, there is no new table, so potentially some SQL may fail. However, that time will be pretty short and anything more complicated (like an Insert From Select) would be even more problematic.

Answer 3

I'm guessing you're worried that concurrent DML (inserts/updates/deletes) on the old table might get missed during the rename? In which case, don't worry - RENAME is DDL and it locks the table for the duration.

Answer 4

Given your comments "Its a daily process" and "Yes, i am worried about the lapsus between the drop and rename statements"

How much money do you have (or more specifically, do you have the partitioning option) ? If so look at partition exchange

You have your permanent table consisting of a single partition. At the end of the day you swap that partition with the table (as a single atomic statement). By not dropping/renaming your main table, you shouldn't invalidate any packages etc (though that may depend on DB version).

Failing that use a view and do a CREATE OR REPLACE VIEW main AS SELECT * FROM table_a and each night you replace the view with a new one on the different table. That probably would invalidate packages though.

Answer 5

If you're worried about the time between the drop and the rename, here is another idea: Use a view that points to the "correct underlying table".

You'd start with

CREATE VIEW someName as Select * From OldTable;

Then you can set up your newTable. When you're ready, then just

CREATE OR REPLACE View someName as Select * From NewTable;

Then you can drop your OldTable. Next time you get some new data, build another NewTable_2 (or reuse OldTable .. then it's probably better to use Table1 and Table2) and redefine the view again.

The view is as simple as it gets, so it should be updatable without a problem. The only tricky thing is to always build a new table (or toggle between two tables), but this shouldn't be too difficult to set up and probably easier than totally avoiding any problems that might occur with your original suggestion.