您如何衡量在 Oracle 中删除模式的影响？

Question

我想删除一个陈旧且冗余的架构。运行DROP USER old_schema CASCADE 运行成功，它被丢弃了。

如何确定删除此架构是否会导致数据库中的其他组件（在不同的架构下）可能中断？

我编写了测试以确保与此架构的过程和类型（这是此架构中唯一的对象）交互的所有组件都可以正常工作（并且已在发行版中被取代和逐步淘汰），但我想知道是否有办法（本机或其他方式）知道是否有任何对象仍链接到此架构。

---

理想情况下，我希望有一些插件/实用程序/SQL-sn-p 可以检查所有与架构之间的链接，并列出依赖项/依赖项：

• 确认我认为正确的信息
• 手动操作，我可能错过的任何操作

---

编辑 01：

一个稍纵即逝的评论（被立即删除）提到了一些关于 INVALID OBJECTS - 任何人都可以推断这一点吗？

Answer 1

没有一个实用程序可以为您执行此操作，因为系统可以通过多种方式依赖您的数据库架构。例如，一个脚本可能每 12 个月登录一次以执行某些任务，一些动态 SQL 可能从另一个模式运行，或者另一个数据库可能通过数据库链接运行查询。

您可以通过检查架构是否允许直接连接来缩小可能性，然后查看对其对象的任何授权。

最终，您需要进行一些研究和测试，以评估放弃架构的相对风险。如果您的环境得到相对良好的控制和记录，您应该能够非常自信地确定哪些代码或系统依赖于您希望删除的架构。

如果删除架构很重要，并且您希望在删除它时将出现问题的风险降至最低，您可以考虑对以下一组步骤进行更改：

1. 创建数据库的非生产副本。

2. 查询 DBA_OBJECTS 以获取 status='INVALID' 的任何对象。应该没有。

3. 删除架构（注意：这是您的非产品数据库！）。

4. 查询 DBA_OBJECTS 以获得 status='INVALID' 的任何对象。构建脚本以相应地修复这些问题。

5. 尽您（和您公司）的能力测试所有应用程序和接口。构建脚本以实施发现的问题所需的任何其他修复。

6. 创建另一个数据库的非生产副本。删除架构。测试您的修复脚本。也许让另一个团队做一些额外的测试，以防遗漏。

7. 进行备份，然后在生产中删除架构。运行修复脚本。

8. 当一些未经测试的关键位开始失败时，请等待尖叫声。如果这种情况立即发生，请考虑从备份中恢复模式。注意：可能需要 24 小时或 12 个月，某些事情才会开始失败（例如，每天或每年计划的作业）。