关于utlrp.sql的坑

最近被utlrp.sql坑惨了

因为公司的脚本是要交付出去的东西，需要经常执行，反复验证，供多个局点使用，而之前看中了utlrp.sql多线程编译无效对象的机制，图省事，就在脚本中使用了它，非常信任Oracle官方提供的脚本。

殊不知它有很多坑！

比如，如果你的SGA设置太小了，它就会执行失败，并报错。

而由于安装实例时，SGA是可以配置的，而又没有标准，所以测试运维他们在安装环境的时候，这个值都没有统一，有的配的大，有的配的小，而公司里环境又多，所以不可能保证每个实例的SGA都设置的足够大。

最近遇到几个环境的，执行utlrp.sql卡死了，查看trace日志，发现了报分配shared_pool失败等类似的错误。之后把SGA改到4G才能顺利执行。

再比如，如果你对sys用户的SESSIONS_PER_USER做了限制，则它可能会卡死，查看oracle进程的CPU使用率为100%。

由于安全是公司的红线，对安全要求非常严格。所以对数据库中的用户账户的profile相关参数做了严格的限制，就比如管理员相关账号的profile的SESSION_PER_USER参数，被设置成了10，结果导致执行的utlrp.sql时卡死，查看trace日志，发现一直在报exceeded SESSIONS_PER_USER limit的错误。

最后果断不能在这种要交付出去的脚本中执行utlrp.sql，改成使用spool生成普通的alter语句来重新编译无效对象的方式，以提高脚本的稳定性。