ORA-28062报错咋整啊，策略表达太长导致的远程修复方法分享

ORA-28062这个错误，说白了就是Oracle数据库的口令策略太复杂，而且这个复杂度的规则（我们叫它口令验证函数）写得太长了，长到数据库自己都有点处理不过来，超出了它内部规定的长度限制，这个问题特别容易出现在一种情况：你有一个很大的数据库系统，中心数据库（主库）下面连着很多个分支或下属的小数据库（远程库、备库），你在主库上修改了口令策略，这个改动想自动同步到各个远程库上去，结果在同步的过程中，策略的脚本因为太长，在远程库上执行时就爆出了ORA-28062错误，下面我就专门针对这种“远程修复”的场景，分享一下怎么一步步把它整好。

你得明白问题出在哪儿,核心原因是那个叫UTLPWDMG.SQL的脚本文件（或者是你自己写的自定义口令验证函数脚本），里面定义策略的SQL语句文本长度超过了Oracle允许的某个内部阈值，当主库通过数据泵（Data Pump）、GoldenGate之类的同步工具，或者简单的数据库链接（DBLINK）来在远程库上执行这个长脚本时，远程库的SQL解析器就“噎住了”，报出这个错，思路不是去简化你的密码策略（因为安全要求可能不允许），而是要想办法“骗过”这个同步机制，或者换个方式把策略部署到远程库上。

第一步：别慌，先确认问题

你得先在报错的远程数据库上,检查一下当前的口令策略设置，用数据库管理员账号（比如SYS或SYSTEM）登录到那个出问题的远程库，执行这个查询：

SELECT LIMIT FROM DBA_PROFILES WHERE PROFILE='DEFAULT' AND RESOURCE_NAME='PASSWORD_VERIFY_FUNCTION';

看看返回的是什么,如果显示的是NULL，说明远程库还没应用上策略；如果显示的是一个函数名（比如VERIFY_FUNCTION_11G或你自定义的名字），但同步还是报错，那很可能就是这个函数定义的代码太长了，你需要去主库上，找到这个函数的完整定义脚本，看看它到底有多长。

第二步：主库上找到“罪魁祸首”脚本

登录你的主数据库,找到那个定义口令验证函数的脚本，如果是Oracle自带的，它通常在$ORACLE_HOME/rdbms/admin/utlpwdmg.sql这个路径下，如果是你们公司自己开发的，那就去找源代码，用文本编辑器打开这个文件，你会看到里面有很多SQL语句，核心是创建或替换一个名为VERIFY_FUNCTION（或类似名字）的PL/SQL函数，这个函数的内容可能非常长，特别是如果包含了复杂的密码规则检查，比如检查密码历史、字典词、字符种类、重复字符等等。

第三步：核心解决方法——分拆脚本，逐个击破

既然一次性执行整个长脚本会报错,那我们就不让它一次性执行，我们把一个大脚本，切成几个小块的SQL文件，然后手动或者通过可控的方式，在远程库上按顺序逐个执行，这叫“化整为零”。

1. 解剖脚本：仔细阅读utlpwdmg.sql（或你的自定义脚本），你会发现它不只是创建一个函数，可能还包含一些其他的设置，比如修改DEFAULT profile的密码参数（PASSWORD_LIFE_TIME, FAILED_LOGIN_ATTEMPTS等），以及创建那个核心的验证函数。

2. 动手切割：把原脚本切成几个逻辑部分，通常可以这样分：

   

   • 文件1：set_profile_params.sql - 包含所有ALTER PROFILE DEFAULT LIMIT ...的语句，只修改密码的生命周期、最大错误尝试次数等参数，这些语句通常不长。
   • 文件2：create_verify_function.sql - 只包含CREATE OR REPLACE FUNCTION your_verify_function ... 这一大段代码，这就是最可能超长的部分。
   • 文件3：assign_profile.sql - 包含将验证函数分配给profile的语句，比如ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION your_verify_function。

3. 远程执行：

   • 通过FTP、SCP或者其他文件传输方式，把这三个小文件上传到远程数据库服务器上。
   • 用SQL*Plus或者其他数据库连接工具，登录到远程库。
   • 按顺序执行这三个文件,先执行文件1设置基本参数，这通常很快成功。
   • 关键的一步,执行文件2来创建函数，因为现在你只执行这一个创建函数的语句，数据库的SQL引擎可以集中处理它，虽然它长，但避免了在长事务或复杂解析环境中被截断，成功率会大大提升。
   • 最后执行文件3，把创建好的函数绑定到profile上。

第四步：验证和收尾

执行完所有分拆的脚本后,再次在远程库上执行第一步的那个查询，确认PASSWORD_VERIFY_FUNCTION已经正确指向了你创建的函数名，可以尝试修改一个测试用户的密码，触发一下这个验证函数，看复杂的密码规则是否生效（比如你设了密码要大小写数字特殊字符，你试一个简单的密码"123"，它应该会报错提示你不符合要求）。

第五步：长远考虑和预防

• 优化函数代码：如果可能，检查一下那个自定义验证函数的代码，看看有没有冗余的逻辑或者可以简化的地方，虽然不一定能大幅缩短，但优化一下总是好的。
• 规范部署流程：以后在主库修改口令策略时，如果涉及到远程库的同步，就不要依赖自动化的、可能直接执行长脚本的工具了，把这种策略变更纳入标准的手工部署流程，使用上面这种“分拆脚本”的方法，确保部署的可靠性。
• 文档记录：把这个问题的现象、分析过程和解决方案记录下来，特别是分拆后的脚本要保管好，下次再遇到同样的问题，或者有新同事遇到，就能直接上手处理，避免重复踩坑。

ORA-28062在远程同步场景下的解决，精髓就在于“拆分”二字，绕过数据库对单条语句长度的限制，通过手工分批执行，虽然多花了点手动操作的功夫，但能实实在在地解决问题，保证你的重要安全策略能够顺利部署到所有需要的数据库节点上。