查看从数据库中删除了哪些下拉表级联约束

Question

有没有任何方法（我可以在脚本文件的顶部添加一个命令）可以知道在执行时从数据库中删除了什么：

DROP TABLE MyTable CASCADE CONSTRAINTS

我现在的做法是在删除myTable:之前选择所有引用完整性约束

SELECT constraint_name 
FROM user_constraints 
WHERE TABLE_NAME = 'mytable' 
AND constraint_type in ('R')

和：

SELECT constraint_name 
FROM user_constraints 
WHERE constraint_type in ('R') 
and r_constraint_name in (select constraint_name 
                           from user_constraints
                           where constraint_type in ('P','U') 
                           and table_name='mytable')

Answer 1

我同意这似乎是一个遗漏，但仔细想想，很难看出它会带来什么好处。

CASCADE CONSTRAINTS选项的主要用例是在重新构建模式时（通常是在开发中），将DROP TABLE语句按正确顺序放置的开销太大。因为我们正在重新构建模式，所以所有外键约束都应该恢复，所以我们不需要知道它们是什么。

这确实假设我们已经正确地维护了构建脚本，并将其置于源代码控制之下。如果我们没有处于那种幸福的境地，那么放弃一张桌子并级联外键约束是鲁莽的。

同样，如果意图是删除表并保持删除状态，那么我们应该进行影响分析，在删除表之前确定外键。可能是通过运行问题中的查询：）但您对脚本的引用表明，这不是您想要的场景。

我们可以用类似于RETURNING。。。DML语句支持INTO语法。然而，有一个问题，您的查询中的一个空白突出了这个问题其他模式可以构建引用我们表的外键（如果我们已授予REFERENCE特权），因此查询应该在ALL_CONSTRAINTS上，并返回OWNER和CONSTRAINT_NAME。这意味着假定的返回。。。INTO功能需要填充两个嵌套的表，或者一个复杂类型的表，这可能需要大量的低级抖动（用技术术语来说），但没有带来太多好处，因为用例太窄了。

Answer 2

我可以想到两种可能性：

1. 如果你启用了回收站，那么我认为所有掉落的物体都会被移到那里。您可以查询recyclebin视图，查看最近丢弃的内容。（这可能包括碰巧在同一时间掉落的不相关物体。）

2. 激活SQL跟踪：ALTER SESSION SET SQL_TRACE = TRUE。这将导致生成一个跟踪文件，其中包含会话执行的所有SQL语句，包括递归SQL。您需要访问数据库服务器才能查看跟踪文件。