首页 > 数据库 > Oracle > Oracle 11g 割接 19c 典型问题处理
1、故障描述
某次某用户某业务系统,ogg割接迁移完成后,某月24晚业务层面出现大量表不存在报错以及27日业务层面出现大量慢sql导致业务主机夯死。以下为本次故障排查之明细。
2、根因分析
(1)、业务层面出现大量表不存在报错
业务后台日志输出
业务层面在源库(11g)使用大量全局同义词,公有同义词本身不控制权限,同义词只是别名,在数据库割接与同步的过程中均使用的是针对schema级别同步,不会同步全局数据,并且在数据校验、对象校验也是针对schema级别,而迁移的用户同义词均在public(全局)下。
1)、原表重命名、drop table、move 表、重建表;公有同义词不会自动更新 / 删除,DDL 变更一张核心业务表,会导致全库大量业务直接报错。
2)、慢sql解析阶段,数据库解析表名:先找本地对象 → 再找 PUBLIC 同义词。大量公有同义词,会增加硬解析开销,从而影响到业务慢sql
3)、统计信息收集、分区表维护,不能通过SQL文本直接判断对象。
4)、无法确定SQL真实访问的schema对象,在各项数据库报告中 (AWR报告、慢SQL)难定位真实对象
5)、多业务schema共存的风险如一个实例部署多套业务系统,大量public同义词互相污染命名空间。
例:业务A、业务B都建同名公有同义词,互相覆盖,出现跨业务串访问,严重数据错乱。
(2)、业务日志统计分析出现大量出现慢sql问题
后台日志分析19C统计信息自动收集功能已正常开启(图1)但是执行时间异常
通过数据库后台 dba_tab_col_statistics表中last_analyzed列字段分析有存在较久的表(图1),并且stale_stats列字段中有出现统计信息已更新至最新但出现(yes)统计信息已失效字样说明两张交易流水表,收集完统计后短时间内 DML 变更超过 10%。而stale_stats出现(NO)字样没过期,stale_stats 只是基于DML(内核表)修改量的标记。
图 1
图 2
这个问题的本质是,Auto Optimizer Stats Collection 19c自动维护任务执行未全量收集schema级别的所有统计信息(疑似与同义词、别名有关联)只正确收集了一部分表的统计信息,以及19C的优化器与11G不同,从而影响至业务sql执行效率偏低等问题。
以及Oracle环境新升级,新接管的buffer cache为空,业务高频访问的数据块、索引块为加载之内存缓冲区,业务上线后产生大量物理读,导致业务上线出去卡顿,tps抖动、响应延迟飙升、慢sql变多。
(3)、关于11g升级19c后函数 WMSYS(Workspace Manager 工作空间组件)不存在、失效问题
后台日志报错
因12cR2 / 19c:彻底移除该函数,升级后视图、存储过程、业务 SQL 调用时直接报错,并且WM_CONCAT非官方函数,Oracle 不提供 BUG 修复与兼容性保障。需业务侧提前完成函数调整或重建。
3、解决方案
(1)、上线前、期间
割接测试阶段,业务需要在19C测试环境上进行完整的性能测试,提前发现同义词或者慢SQL,并且在迁移割接期间需充分压测业务能力以及回访top高频sql,预热buffer cache(数据),并将执行计划载入shared pool,避免大量硬解析。提前解决隐患,避免业务正式上线后出现问题。
(2)、手动维护19c统计信息任务:
手动收集系统数据字段的统计信息
exec dbms_stats.gather_dictionary_stats(no_invalidate=>false)
此存过包收集系统数据字典统计信息,no_invalidate:指定是否在收集统计信息时使相关的依赖游标失效,默认为FALSE,表示该过程立刻使依赖游标无效。建议再查寻相关基表很慢等情况下定期收集系统数据字典相关信息。
手动收集业务用户关联表的统计信息
exec dbms_stats.gather_schema_stats(ownname=>'用户名',estimate_percent=>10,degree=>8,cascade=>true,granularity=>'ALL');
(3)、定期维护用户统计信息:
配置crontab脚本定期收集核心表的统计信息
现网环境影响:
1)、因需收集全库系统数据字典信息,数据库可能会出现卡顿显现。
2)、意味着相关业务sql执行计划会受到影响,导致cbo优化器会自发性重新收集计算处理。
风险:可控
(4)、调整业务层面同义词管理逻辑:
1)、业务禁止新增PUBLIC同义词;存量逐步把PUBLIC同义词迁移为私有同义词并赋权,最终优先做到SQL直接写schema.表名
2)、规范开发代码:SQL语句强制带上schema,禁止裸表名
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/30310891/viewspace-3181471/ ,如需转载,请注明出处,否则将追究法律责任。