一、 问题描述
2025 年xx月xx日左右数据库存在卡顿，后续持续卡顿出现。
一、 问题分析
(一) 现网环境
1. 数据库部署环境
Oracle 数据库一体机RAC环境。
2. 数据库状态检查
1)
cpu
使用峰值接近80%
2）
IO
峰值平稳，未有明显瓶颈
(一) 问题分析
1. 数据库AWR/ASH
1)
AWR
分析报告
2)
ASH
分析报告
3) 数据库信息收集
//RAMN
备份持续过长,12月29日备份级7TB
//
数据库TOP等待
//
卡顿点涉及阻塞链
//SYS
用户数据字典及后台进程阻塞
//
全局LMD（ges）阻塞源
//
部分sqlversion_count较高
//cusor mismatch
//redo
及切换
//
参数配置
2. 分析结论：
Ø 慢SQL,SQL扫描(TOP CPU TIME)
Ø bitmap 索引引发行锁争用等待问题(INDEX)
Ø 等待事件library cache lock/library cache pin/log file sync
Ø 解析命中率较低
Ø REDO 日志生成过快，日志切换频繁
Ø cursor 游标命中率低，open_cusor过载参数配置
Ø RAMN 备份时间过长，持续到业务峰值(14:00)
Ø 业务峰值期间，触发高负载pdb级全库级统计信息收集
Ø 参数配置问题
三、 优化建议
以下参数全局集群节点调整:
1) 日志组2GB调整为 4GB，后续持续关注
2) bitmap 索引引发的tx锁，建议删除bitmap索引或者重建为btree索引
3) 核心参数调优： session_cached_cursors =200 open_cursors = 5000 # 初始值300 // 关闭gc相关参数特性（ACS自适应游标/动态DRM） _optimizer_cartesian_enabled= FALSE # 初始TURE _gc_policy_time = 0 # 初始值20 _gc_undo_affinity = FALSE #true _cursor_obsolete_threshold = 1024 # 原8192 _optimizer_extended_cursor_sharing = NONE _optimizer_extended_cursor_sharing_rel = NONE _optimizer_adaptive_cursor_sharing =FALSE _undo_autotune = FALSE _use_single_log_writer = TRUE // 如果仍然存在问题，考虑更改参数 cursor_sharing = similar/force _undo_autotune = FALSE
4) TOP 慢sql进行sql调优或者查询改写(略)
5) 优化RMAN备份，缩短RAM备份时长
6) 严格控制全局级统计信息任务或者自动维护窗口，业务低峰期执行统计信息
