Sql 删除所有表时的Oracle性能

我有以下Oracle SQL：

Begin

-- tables
for c in (select table_name from user_tables) loop
execute immediate ('drop table '||c.table_name||' cascade constraints');
end loop;

-- sequences
for c in (select sequence_name from user_sequences) loop
execute immediate ('drop sequence '||c.sequence_name);
end loop;

End;

它是由另一个开发人员提供给我的，我不知道它是如何工作的，但它会删除数据库中的所有表

它是有效的，但它需要永远

我不认为扔掉我所有的桌子需要那么长时间。怎么回事？还有，这个脚本可以改进吗

---

注意：大约有100个表。

我会尝试将DROP TABLE语句更改为使用

Purge

关键字。由于要删除所有表，因此实际上不需要同时级联约束。这个动作可能是导致它变慢的原因。我没有Oracle的实例来测试这个，所以它可能会抛出一个错误

如果它确实抛出了一个错误，或者没有更快，我会删除序列drop命令，以找出哪个命令花费了这么多时间

Oracle关于DROP TABLE命令的文档如下所示

“这是可行的，但需要永远！”

在这种情况下，永远意味着一张桌子不到三秒钟：）

放下桌子不仅仅是放下桌子。还有要删除的依赖对象—约束、索引、触发器、lob或嵌套表存储等。还有要使视图、同义词和存储过程失效的存储过程。有需要撤销的授权。必须取消分配表的空间（及其索引的空间等）

所有这些活动都会生成递归SQL、从数据字典中选择或更新数据字典的查询，这些查询的性能可能很差。即使我们不使用触发器、视图和存储的过程，数据库仍然必须运行查询来确定它们的缺失

与普通SQL不同，我们不能调优递归SQL，但我们可以调整环境以使其运行更快

我假设这是一个开发数据库，在其中定期构建和拆卸对象，并且您使用的是10g或更高版本

清理回收站

SQL>purge-recyclebin

收集数据字典的统计信息（需要DBA权限）。这些可能已经被收集，因为这是10g和11g中的默认行为

一旦你有了字典统计数据，确保你使用的是基于成本的优化器。理想情况下，这应该在数据库级别设置，但我们可以在会话级别进行修复：

SQL>alter session set optimizer\u mode=choose

---

一种替代方法是删除用户而不是单个表等，并在需要时重新创建它们。它通常更健壮，因为它会删除所有的表、视图、过程、序列等，并且可能会更快。

100个表，但有多少数据？删除意味着写入事务（TRUNCATE TABLE不会），这可能会影响查询速度。@OMG，让我重新填充数据库……我不确定一次有多少数据。CASCADE CONSTRAINTS子句强制删除主键被外键引用的表。如果没有它，我们需要修正删除表的顺序，以便首先删除依赖表，或者让脚本使用ORA-02449失败感谢您的回答。我明天会在工作中查看它。虽然已经4年了，但与Oracle信息的最佳来源相比，“choose”显然已经过时了，也许不是Oracle信息的最佳来源，但这次我觉得这个主题很有趣。顺便说一句，使用v$参数中的SELECT值，其中NAME='optimizer_mode'；找出您当前的优化器模式。这是我的12c服务器的所有行。