Oracle 11g 重命名。保证是原子的?

发布于 2024-08-14 07:21:55 字数 209 浏览 6 评论 0原文

我在 plsql 脚本

drop table new;
rename old to new;

“旧”表中有一些 (5) 重命名语句,其中包含非常有价值的信息。

在我看来,如果重命名命令保证是原子的,那么我就解决了一个问题。

它是原子的吗?如果没有,有没有办法进行“安全”重命名?

提前致谢

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

镜花水月 2024-08-21 07:21:56

RENAME 是一个 DDL 命令。所以它是一个单独的离散事务,如果这就是您在这种情况下所说的原子性的意思。因此,它是尽可能安全的。我无法想象重命名会如何导致您丢失数据。但如果您感到偏执,请记住这就是大自然为我们提供备份和恢复的原因。

编辑

确保在 DROP 成功且 RENAME 失败时不会丢失数据的方法是部署 RENAME 两次:

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

这样您就可以在线获取数据。这也最大限度地减少了停机时间。

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.

如何视而不见 2024-08-21 07:21:56

鉴于您的评论“这是一个日常流程”和“是的,我担心删除和重命名语句之间的失误”,

您有多少钱(或更具体地说,您有分区选项)?如果是这样,请查看分区交换

您的永久表由单个分区组成。最终,您将该分区与表交换(作为单个原子语句)。通过不删除/重命名主表,您不应该使任何包等失效(尽管这可能取决于数据库版本)。

如果无法使用视图并执行 CREATE OR REPLACE VIEW main AS SELECT * FROM table_a ,那么每天晚上您都会在不同的表上用新视图替换该视图。但这可能会使软件包失效。

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.

少跟Wǒ拽 2024-08-21 07:21:56

Rename 将是原子的,所以你应该没问题。正如 APC 所指出的,

我无法想象重命名会如何导致您丢失数据。

我在你的脚本中唯一能看到的就是删除之后和重命名之前的时间,没有new表,因此某些SQL可能会失败。然而,这个时间会很短,任何更复杂的事情(比如Insert From Select)都会带来更多问题。

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.

柒夜笙歌凉 2024-08-21 07:21:56

我猜您担心旧表上的并发 DML(插入/更新/删除)可能会在重命名期间丢失?在这种情况下,不用担心 - RENAME 是 DDL,它会在持续时间内锁定表。

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.

就是爱搞怪 2024-08-21 07:21:56

如果您担心删除和重命名之间的时间,这里有另一个想法:使用指向“正确的基础表”的视图。

您可以从

CREATE VIEW someName as Select * From OldTable;

然后您可以设置您的新表。当你准备好后,然后

CREATE OR REPLACE View someName as Select * From NewTable;

你就可以删除你的 OldTable。下次您获得一些新数据时,构建另一个 NewTable_2 (或重用 OldTable .. 那么最好使用 Table1 和 Table2)并再次重新定义视图。

该视图非常简单,因此它应该可以毫无问题地更新。唯一棘手的事情是始终构建一个新表(或在两个表之间切换),但这应该不会太难设置,并且可能比完全避免您最初的建议可能出现的任何问题更容易。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文