我有一个老化和冗余的架构，我想放弃。正在运行DROP USER old_schema CASCADE会成功运行并且已被删除。
如何确定是否删除此架构会导致数据库中的其他组件（在不同架构下）可能中断？
我已经编写了测试，以确保与此模式的过程和类型（这个模式中唯一的对象）接口的所有组件都是可用的（并且已在发布中被取代并逐步淘汰），但我想知道是否有一种方式（本机或其他方式）知道是否有任何对象仍然链接到此架构。
理想情况下，我希望有一些插件/实用程序/ SQL-snippet可以检查与模式之间的所有链接，并将依赖项/依赖项列出到：
编辑01：
稍纵即逝的评论（已被删除）提到了无效对象的内容 - 有人可以对此进行推断吗？
答案 0 :(得分：2)
没有一个实用程序会为您执行此操作，因为系统可以通过多种方式依赖于您的数据库架构。例如，脚本可能每12个月登录一次以执行某项任务，某些动态SQL可能从另一个模式运行，或者另一个数据库可能通过数据库链接运行查询。
您可以通过检查架构是否允许直接连接来缩小可能性，然后查看其对象上的任何授权。
最终，您需要进行一些研究和测试，以评估丢弃架构的相对风险。如果您的环境受到相对良好的控制和记录，您应该能够非常自信地确定哪些代码或系统依赖于您希望删除的模式。
如果删除架构非常重要，并且您希望在丢弃架构时将出现问题的风险降至最低，则可以考虑对以下一组步骤进行修改：
创建数据库的非生产副本。
查询status='INVALID'的任何对象的DBA_OBJECTS。应该没有。
删除架构（注意：这是你的非prod数据库！）。
查询status='INVALID'的任何对象的DBA_OBJECTS。根据需要构建脚本以相应地修复这些内容。
根据您（以及您公司的）最佳能力测试所有应用程序和界面。构建脚本以实现发现问题所需的任何其他修补程序。
创建另一个数据库的非生产副本。删除架构。测试修复脚本。也许让另一个团队做一些额外的测试，以防错过任何东西。
进行备份，然后将架构放入生产中。运行修复脚本。
当一些未经测试的关键位开始失败时，请等待尖叫声。如果立即发生这种情况，请考虑从备份恢复架构。注意：在某些事情开始失败之前可能需要24小时或12个月（例如每日或每年的预定工作）。