ORA-16703报错怎么破？数据库启用状态下属性设置失败远程帮你解决

ORA-16703报错怎么破？数据库启用状态下属性设置失败远程帮你解决

ORA-16703错误是Oracle Data Guard环境中一个比较常见的报错，通常在你尝试修改主库或备库的某个属性（Property）时发生，尤其是当数据库处于启用（ENABLED）状态时，这个错误的完整描述通常是“ORA-16703: Could not apply the attribute to the database”，翻译过来就是“无法将属性应用到数据库”，简单理解，就是你下的命令没有被系统成功执行。

要解决这个问题,我们不能蛮干，得先搞清楚为什么在数据库开着的时候设置会失败，根据Oracle官方文档（来源：Oracle Database Data Guard Broker 文档）和一些常见的实践经验，原因主要有以下几个方面：

1. 状态不匹配： 这是最常见的原因，Data Guard对环境状态有严格的要求，你可能试图修改一个需要备库处于特定状态（如MOUNTED状态，而不是OPEN READ ONLY状态）才能生效的属性，如果你的备库正开着给应用程序读，这时候你去改一些底层参数，Broker（Data Guard的管理组件）就会阻止你，因为它怕引起数据不一致或操作冲突。

2. 网络或连接问题： 你是在主库上操作，但你要修改的属性可能需要Broker去和远端的备库进行通信才能完成设置，如果这个时候，主库和备库之间的网络连接不稳定，或者备库的监听器有问题导致Broker无法顺利连接到备库，这个操作就会失败，抛出ORA-16703。

3. 资源争用或进程繁忙： 数据库内部可能正有某些关键进程在运行，比如正在应用日志（Redo Apply）或者正在做备份恢复操作，这时候Broker为了安全起见，可能会暂时不允许你修改相关属性，以免干扰这些关键任务。

4. 属性本身有依赖或限制： 有些属性不是孤立的，它们可能依赖于其他属性的设置，或者，某些属性在特定的配置下（比如最大可用性模式和高性能模式）允许的操作是不一样的，你可能没有满足这些前提条件。

知道了原因,我们就可以像侦探一样，一步步排查并解决问题了，下面是一种远程协助时常用的排查思路，你可以跟着做：

第一步：别慌，先停一下

立刻停止你正在进行的重复操作,反复尝试一个失败的命令可能会让情况更复杂，仔细看你收到的ORA-16703错误消息，它有时候会附带更详细的错误代码，比如ORA-16703后面可能还跟着一个(具体编号)，这个编号能提供更精确的线索。

第二步：检查Data Guard的整体状态

打开你的SQL*Plus，以SYSDBA身份登录到出现问题的数据库（通常是主库），执行以下命令，看看整个Data Guard配置是不是健康的：

DGMGRL> SHOW CONFIGURATION;

重点关注这几列：

• Name: 你的配置叫什么名字。
• Enabled: 是不是已经启用（YES）。
• Protection Mode: 是什么保护模式。
• Databases: 列出了哪些数据库。
• Status: 这一行最关键！如果这里显示的是SUCCESS，说明大框架是好的，如果显示的是ERROR或者WARNING，那问题可能就出在这里，你需要先解决这个状态异常。

第三步：深入查看具体数据库的状态

光看整体配置还不够,得看看每个“家庭成员”的状态，执行：

DGMGRL> SHOW DATABASE VERBOSE ‘你的数据库名（比如PRIMARY）’;

把这个命令分别用于你的主库和备库,Verbose参数会显示非常详细的信息，你要像检查身体一样，仔细查看：

• Database Status: 是MOUNTED, OPEN READ ONLY, 还是OPEN？
• Transport Status: 日志传输是否正常？有没有延迟？
• Apply State: 备库的日志应用是ON还是OFF？
• 在输出的最下方,会有一个“Properties”部分，这里列出了所有可设置的属性及其当前值。

第四步：根据状态判断操作时机

对比你刚才查看到的状态和你想要执行的命令。

• 场景A： 如果你想修改一个与日志应用相关的属性，但发现备库的Apply State是ON（正在应用日志），那么很可能需要先暂停日志应用，你可以尝试：DGMGRL> EDIT DATABASE ‘备库名’ SET STATE=‘APPLY-OFF’; 等备库暂停后，再执行你原本想做的属性设置命令，设置成功后，别忘了再把它打开：DGMGRL> EDIT DATABASE ‘备库名’ SET STATE=‘APPLY-ON’;
• 场景B： 如果你发现Transport Status或Apply State显示为ERROR，那说明Data Guard的同步链路本身就有问题，这时候你应该优先解决这些错误（比如检查网络、日志传输服务等），让状态恢复正常（变成ON或健康状态），然后再尝试设置属性，链路都不通了，你改什么设置都很难成功。

第五步：检查网络和连接

如果状态看起来都正常,但还是失败，就要怀疑是瞬时网络问题，你可以尝试从主库服务器tnsping一下备库的TNS服务名，看看连通性如何，也可以尝试重启一下主备库的Broker进程（dmon进程），有时候重启能解决临时的通信故障，在操作系统层面，用oracle用户执行：dg_broker_startup.sql 或者直接杀掉dmon进程让它自动重启（此操作需谨慎，最好在非业务高峰进行）。

第六步：查看日志获取终极线索

如果以上步骤都解决不了,日志就是最后的“证人”，你需要去查看Data Guard Broker的跟踪日志（trace log）和备库的alert日志文件。

• Broker日志的位置由DIAGNOSTIC_DEST参数和DG_BROKER_CONFIG_FILE参数共同决定，通常在$ORACLE_BASE/diag/rdbms/.../drconfig名/trace/目录下。
• 备库的alert日志通常位于$ORACLE_BASE/diag/rdbms/.../alert/目录下。

在这些日志里,搜索你报错的时间点附近的记录，很可能会发现比ORA-16703更具体、更底层的错误信息，比如某个文件找不到、权限不足、空间不足等，根据这个终极线索，问题往往就能迎刃而解。

解决ORA-16703的核心思路就是“先诊断，后操作”，不要一上来就想着怎么把命令执行成功，而是要耐心地使用SHOW CONFIGURATION和SHOW DATABASE VERBOSE这两个强大的诊断工具，搞清楚当前Data Guard各个组件的精确状态，八成以上的问题，通过检查状态、在正确的时机（如暂停应用）执行操作就能解决，剩下的疑难杂症，则需要通过分析日志来找到根因，保持冷静，一步步来，这个错误并不难克服。