时间戳

首页 > 解决方案 > 您如何衡量在 Oracle 中删除模式的影响？

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

问题描述

我有一个要删除的陈旧且冗余的架构。运行DROP USER old_schema CASCADE成功并被丢弃。

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

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

理想情况下，我希望有一些插件/实用程序/SQL-snippet 可以检查所有指向/来自您的架构的链接，并将依赖项/依赖项列出到：

编辑 01：

一个稍纵即逝的评论（被立即删除）提到了一些关于无效对象的东西——任何人都可以推断出这个吗？

标签： sqloracledatabase-schemasql-drop

解决方案

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

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

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

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

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

  2. 查询 DBA_OBJECTS 的任何对象，其中status='INVALID'. 应该没有。

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

  4. 查询 DBA_OBJECTS 的任何对象，其中status='INVALID'. 构建脚本以根据需要相应地修复这些问题。

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

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

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

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

推荐阅读