一、 问题描述

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)        严格控制全局级统计信息任务或者自动维护窗口，业务低峰期执行统计信息