Sql 您如何衡量在Oracle中删除架构的影响？

我有一个陈旧且冗余的模式，我想放弃它。运行

DROP USER old_schema CASCADE

成功运行并删除

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

我已经编写了测试，以确保与此模式的过程和类型（这是此模式中唯一的对象）接口的所有组件都是功能性的（并且在发行版中已被取代和淘汰），但我想知道是否有办法（本机或其他方式）以了解是否有任何对象仍链接到此架构

---

理想情况下，我希望有一个插件/实用程序/SQL代码段可以检查所有指向/来自您的模式的链接，并列出依赖项/从属项：

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

---

编辑01:

---

一条转瞬即逝的评论（被迅速删除）提到了一些关于无效对象的内容-有人可以据此推断吗？

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

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

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

如果删除模式是很重要的，当你放弃它时，你希望最小化出错的风险，你可以考虑以下步骤的变化：

创建数据库的非生产副本

查询DBA_对象以查找

状态='INVALID'

中的任何对象。应该没有

删除模式（注意：这是非prod数据库！）

查询DBA_对象以查找

状态='INVALID'

中的任何对象。构建相应的脚本来修复这些问题

尽你（和你的公司）所能测试所有应用程序和接口。生成脚本以实现发现问题所需的任何其他修复

创建数据库的另一个非生产副本。删除模式。测试修复脚本。也许可以让另一个团队做一些额外的测试，以防遗漏什么

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

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

---

AUDIT

命令浮现在脑海中。但是，如果您不知道如何使用

审计

，这远远超出了我在本场景中所能解释的范围。可能需要研究步骤2、3、4似乎解决了问题的关键-谢谢。我已经测试过了，之后没有无效的DBA_对象，所以这很好。关于如何从模式跟踪数据库链接，有什么想法吗？我唯一的成功就是通过版本控制进行文本搜索（使用代理搜索）。我将研究您是否可以在您所在位置的每个数据库上运行查询，以清点所有数据库链接。