大规模升级来临，谈谈Oracle 12cR2使用经验

命中Bug 26405036 Large Allocation Of "ges enqueues" and "ges resource dynamic" In The Shared Pool 会把共享池从20g不断自动resize到200g以上，直到sga_max_size中无法有空余空间了，应用报ora-04031。

解决方法是打补丁，目前Oracle 18.5的补丁也出来了：

临时解决方案如下：

SQL> oradebug setmypid

SQL> oradebug lkdebug -m reconfig lkdebug

问题2：在home目录产生大量trace文件或者是单个超大文件，空间满导致系统hang。

这个问题现象相似，但不止是一个bug：

原因1：

Trace files generation with message “AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1”.

这是Bug 25415713，安装one-off patch可以解决。

原因 2：

Trace files generated from RMAN module with KRB messages.

可能是：

Bug 28174827 ：RMAN Unconditional KRB Trace File After Installing Fix Of Bug 22700845

Bug 28390273 ：RMAN UNCONDITIONAL KRB TRACE FILE AFTER PATCH 27674384

通过alter system set events 'trace[krb.*] disk disable, memory disable';解决。

原因3：

KZAN: ORA-55917 during CLI write.

KZAN: SYS user audit records will written to files now.

需要禁用KTLI tracing：

alter system set event='55901 trace name context off';

alter system set event='TRACE[RecordCompose] off';

alter system set event='TRACE[FileWrite] off';

alter system set event='TRACE[QueueWrite] off';

问题3：在RAC集群环境下，对大表进行truncate会导致另一个节点hang住。dbaplus社群有过专门诊断文章：你敢在Oracle 12c R2上做大表truncate吗?

该bug在最新版的PSU中已经修复：

问题4：升级到Oracle 12c/18c后，低版本数据库客户端连接会报错：

ORA-28040: No matching authentication protocol/ORA-01017: invalid username/password; logon denied

需要先在sqlnet.ora中加入SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8/SQLNET.ALLOWED_LOGON_VERSION_SERVER=8，然后再重置密码解决。(参考MOS文档 ID 2296947.1)

五、几个重要参数

还有其他一些建议设置的参数，大多数是为了避免bug，还有一部分是为了关闭某些Oracle特性。

ASM初始化参数，memory_target设为2G，process设置为200或以上。

数据库参数：

• _serial_direct_read= AUTO; 避免high direct path read
• _lm_tickets=5000;默认1000，增加GES messaging tickets
• _px_use_large_pool=TRUE;并行会话使用large pool而不是共享池，降低ora4031
• _b_tree_bitmap_plans=FALSE;
• SEC_CASE_SENSITIVE_LOGON=FALSE;禁用密码大小写敏感
• _gc_defer_time=0;减少进程对热块争用
• _datafile_write_errors_crash_instance=FALSE;数据文件(sysytem以外表空间)I/O读写错误被发现时，发生错误的数据文件进行offline而不关闭实例。
• event='10949 trace name context forever:28401 trace name context forever, level 1:10849 trace name context forever, level 1' ;关闭数据库当中用户持续输入错误密码导致大量library cache lock;关闭自动serial direct path read特性，避免出现过多的直接路径读，消耗过多的IO资源
• _undo_autotune=FALSE;关闭undo自动调整
• _use_adaptive_log_file_sync=FALSE;写日志缓冲区到文件方式默认是采用Post/wait方式，在11.2.0.3版本开始增加了Polling的方式。关闭该参数不允许切换。
• "_fix_control"='14142884:ON','8560951:ON','8893626:OFF','9344709:OFF','9195582:OFF','9380298:ON','13704562:OFF','16053273:OFF','8611462:OFF','17760375:OFF','17938754:OFF','8560951:ON'
• 当然，同时要说明的是，这些仅仅是认为必要注意的参数，真实环境还有其他参数也同样要注意。如果你在阅读过程中，认为还有某些参数是应该必须调整的，欢迎在文章后面留言，给其他同行做一个参考。

六、升级参考文章

核心数据库升级是一件复杂的系统工程，必须经过严谨的方案制定、升级测试、性能测试及最后的割接迁移流程，虽然我们已经经历过上千套系统的12c升级，但是每次升级前的测试仍然能发现新的缺陷。

有些是应用代码的，有些是SQL性能的，有些是数据库软件的甚至有些是存储链路的，充分的测试才是确保成功升级的唯一保证。

对于大数据量的升级迁移，Oracle副总裁swonger有一个演讲：migrate + 200TB database in less than 1 day，讲的是欧洲电网的案例，使用了TTS+expdp+perl等多种手段，值得一看。

链接：

https://www.neooug.org/gloc/Presentations/2018/Swonger_Migrate_200TB.pdf

对于升级来说，不仅要关心升级本身能否按时间完成，关于升级之后的性能如何、稳定性如何、可用性、数据一致性和完整性如何也同样重要，而且都应在正式升级割接前进行充分的模拟验证。

作者介绍

杨志洪，dbaplus社群联合发起人，新炬网络首席布道师，对数据库、数据管理有深入研究，合译《Oracle核心技术》《Oracle Exadata专家手册》。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!