某客户数据库系统节点1 CPU使用率过高问题分析处理

原创 已于 2026-03-12 00:23:04 修改 · 385 阅读 · 11 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#oracle #数据库
于 2026-03-12 00:16:03 首次发布

一、故障描述

某日早上9:00发现CRM节点一CPU使用率比平时高，到达90%左右。通过巡检日志，发现有分区索引失效。

二、故障分析

2.1 查看数据库的等待事件

从上面看以看出gc buffer busy等待比较严重，会话数达200之多。

从上可以看出引起gc buffer busy 的主要sql_id 为3gstz9qcvj064。

查看该问题sql的执行计划，发现表TL_B_NOTIFYTRADELOG执行了全分区表扫描。这样的执行计划很定很消耗资源的。通常来说，sql执行计划很糟糕，首先查看该表的统计信息是否准确。

由上面统计信息可以看出，该表的收集的统计信息已经过期。且部分分区未能有统计信息显示。

查看索引状态

SQL> select t2.owner,t1.index_name,t2.table_name,t1.partition_name,t1.status

  2  from dba_ind_partitions t1,dba_indexes t2

  3  where t1.index_name=t2.index_name

  4  and t2.owner='UCR_UIF1'

  5  and t1.index_name in('IDX_TL_B_NOTIFYTRADELOG_1','IDX_TL_B_NOTIFYTRADELOG_2');

OWNER      INDEX_NAME                     TABLE_NAME           PARTITION_NAME                 STATUS

---------- ------------------------------ -------------------- ------------------------------ --------

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_1      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_2      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_3      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_4      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_5      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_6      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_7      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_8      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_9      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_10     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_11     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_12     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_13     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_14     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_15     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_16     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_17     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_18     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_19     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_20     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_21     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_22     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_24     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_25     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_26     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_27     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_28     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_29     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_30     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_31     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_1      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_2      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_3      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_4      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_5      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_6      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_7      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_8      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_9      UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_10     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_11     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_12     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_13     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_14     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_15     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_16     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_17     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_18     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_19     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_20     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_21     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_22     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_23     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_24     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_25     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_26     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_27     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_28     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_29     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_30     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_2      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_31     UNUSABLE

UCR_UIF1   IDX_TL_B_NOTIFYTRADELOG_1      TL_B_NOTIFYTRADELOG  P_I_TL_B_NOTIFYTRADELOG_23     UNUSABLE

从上可以看出分区索引失效。由于分区索引失效，sql 执行计划糟糕，进行了全分区表扫描，从而消耗了更多的cpu资源。

三、故障处理

索引出现失效时，应当重建失效索引，并及时收集表的统计信息系。

四、总结建议

由于本次索引失效是由于数据清理造成分区索引失效。导致sql执行效率极差。建议在有数据移动的操作后，及时维护索引。

听雪楼主.
关注
数据库系统的体系结构
bluespeedinfo的博客
04-03 4350
数据库系统的体系结构受所运行的计算机系统的影响很大，尤其受计算机体系结构中的联网、并行和分布等因素的影响。计算机联网可以使某些任务在服务器系统上执行，而另一些任务在客户机系统上执行。这种工作任务的划分导致了客户/服务器结构数据库系统的产生。在一个组织机构的多个节点或部门间对数据进行分布，可以使数据存放在最需要它们的地方，同时仍能够被其他节点或其他部门访问。分布式数据库系统用于处理地理上或管理上分布...
数据库系统的体系结构知识笔记
IT技术分享社区
11-07 1349
1、集中式数据库系统分时系统环境下的集中式数据库系统结构诞生于20世纪60年代中期。当时的硬件和操作系统决定了分时系统环境下的集中式数据库系统构成早期的数据库技术的首选结构。数据和数据管...
分布式的客户端-服务器结构_数据库系统的体系结构知识笔记
weixin_39739404的博客
11-16 1235
1、集中式数据库系统分时系统环境下的集中式数据库系统结构诞生于20世纪60年代中期。当时的硬件和操作系统决定了分时系统环境下的集中式数据库系统构成早期的数据库技术的首选结构。数据和数据管理都是集中的，数据库系统的所有系统，从形式的用户到DBMS核心都集中在DBMS所在的计算机上。2、客户端/服务器体系结构网络技术的高速发展，使现在的软件大多数采用客户端/服务器体系结构。特点：客户端负责数据表示服务...
故障树分析法（FTA）——根本原因分析的重要武器！
热门推荐
voiue的博客
12-22 1万+
（Fault Tree Analysis，FTA）是在对系统的可靠性进行分析时最常用的方法之一。FTA方法是指在系统设计或改进过程中，通过对可能造成系统故障的各种因素（包括硬件、软件、环境、人为因素等）进行分析，画出逻辑框图（即故障树），从而确定系统故障原因的各种可能组合方式及其发生概率，并以此计算系统的故障概率，采取相应的措施，以提高系统可靠性的一种设计分析方法和评估方法。故障树分析图经常被用在Six Sigma进程中，特别用在Six Sigma业务改进进程的分析阶段。
Oracle INITCAP函数详解
u013391334的博客
06-13 408
能将字符串中每个单词的首字母转为大写，其余字母转为小写。数据库中一个常用的字符串格式化函数。数据类型的字段，但可以通过隐式数据类型转换间接实现。来确定字母的大小写，不支持根据语言环境进行智能处理。的首字母转换为大写，其余字母转换为小写。需要符合特定语言书写规范的国际化应用。英文或其他单字节字符集为主的转换。支持多字母组合规则（如荷兰语的。可能略慢，需加载语言排序规则。是一个历史悠久的基础函数，在。：返回一个字符串类型（及更高版本中均可使用。（如德语、荷兰语等）。：该函数不能直接处理。
快速入门MySQL数据库基础(2)
最新发布
2401_88541147的博客
06-17 209
MySQL数据库操作指南：摘要 本文系统介绍了MySQL数据库的核心操作，包括：1.数据库创建（CREATEDATABASE）及字符集/校验规则设置（utf8/gbk等）；2.字符集查看（showcharset）与校验规则管理（showcollation）；3.数据库修改（ALTERDATABASE）、删除（DROPDATABASE）及完整信息查看（showcreatedatabase）；4.关键数据备份（mysqldump命令）与恢复（source命令）操作；5.连接状态监控（showprocesslis
Oracle Skills实战：提升AI的SQL能力
renkejia1988的博客
06-16 314
Oracle Skills 用四个文件、不到 100KB，把 AI 的 SQL 能力从「初级工程师」拉到「高级 DBA」。
数据库写轮眼：看透 MVCC 版本链、快照、隔离级别。
初入后端的大二在校生
06-15 978
在数据库高并发场景下，海量事务同时读写同一份数据，单纯依赖锁机制相互制衡，只会造成无休止的阻塞等待；脏读、不可重复读与幻读，更如同忍界无解的幻术，牢牢桎梏着系统性能。 正如这幅图中，宇智波鼬借 Undo Log 铺展绵延不绝的数据历史分身版本链，佐助则凭借 ReadView 写轮眼，筛选出仅对当前事务可见的数据快照。 MVCC 正是数据库世界里独一份的宇智波瞳术，它摒弃锁竞争的对抗思路，依托多版本数据与视图可见性规则，为每一笔事务划分独立读写时空，从根源化解并发读写矛盾。
Oracle 19c 多租户体系架构介绍
xfhuangfu的专栏
06-16 244
Oracle 19c 多租户体系架构介绍
SQL优化-从慢查询到执行计划
weixin_51864284的博客
06-17 997
先看执行计划，再动索引，再改 SQL，顺序别反了。
【基础】PostgreSQL 数据导出
shen12138的博客
06-17 490
PostgreSQL 的导出其实可以很精细：先用查询摸清各表大小，再用pg_dump配合精准排除不需要的数据。这套「先查后导」的流程既能节省导出时间，又能控制备份文件的大小，值得在实际工作中推广使用。
PostgreSQL 聊一下索引和排序规则
u011962508的博客
06-16 328
可以把数据库表想象成一本很厚的书。如果没有目录，你要找某个章节，只能从第一页开始一页一页翻。如果有目录，你可以先看目录，直接跳到对应页码。数据库里的索引就类似书的目录。age INT如果phone没有索引，数据库可能要从第一行扫到最后一行。如果给phone数据库就可以先去索引里查手机号，再定位到对应的数据行。排序规则通常叫Collation。它决定字符串之间如何比较和排序。'a''A''á''b''a'和'A'相等'a'和'A'不相等'á'和'a'接近'á'
知识库系统的内容资产闭环怎么设计
Keep calm and create shit
06-14 359
这周在做知识库文档的开发链路, 一开始很容易把功能想简单：用户上传一个文件，后端保存起来，数据库记一条记录，然后返回成功。这个思路在网盘、附件系统里没问题，但放到知识库系统里就不够了。所以这周我主要围绕一个问题做设计：一个文件从上传开始，到变成可检索、可编辑、可重建索引的知识资产，中间到底应该拆成哪些状态和边界？
SeaTunnel 实时同步 Kafka JSON 数据到 Oracle 完整配置 + 踩坑实战总结
weixin_53083884的博客
06-17 393
摘要：本文介绍使用SeaTunnel 2.x实现Kafka到Oracle的实时数据同步方案。通过JsonPath解析嵌套JSON字段，SQL转换处理日期格式、生成主键，最终批量写入Oracle。配置要点包括：1) Kafka消息需指定src_field解析嵌套结构；2) 采用JsonPath+SQL双层转换提高可维护性；3) Oracle连接需严格匹配字段顺序。文章重点总结了5个常见问题：字段顺序不匹配导致静默丢弃、嵌套JSON解析失败、日期格式转换异常、offset过早提交导致数据丢失，以及UUID主键格
Oracle 数据库巡检检查清单
Nightwish5的博客
06-14 222
本文档整理了Oracle数据库日常巡检的核心检查项，涵盖数据库状态、性能、空间、安全等多个维度。
蛋白序列数据API接口资源，含谱系、疾病与变异、翻译后修饰、表达、相互作用等信息
Yiyaoshujuku的博客
06-17 210
本文旨在系统梳理当前主流的蛋白质数据API资源，从接口选择、请求构建、数据解析到批量获取策略，提供一套完整、可操作的实战指南。
Oracle CHR函数详解
u013391334的博客
06-12 211
中一个基础的字符串函数，它的作用是将数字代码转换为对应的字符，可以理解为。函数功能相反，常用于字符编码的转换操作。避免被 SQL*Plus 视为替换变量。此语句将地址信息分行输出，提升可读性。语句中直接构建包含特殊字符的字符串。)，实现 Windows 风格的换行。：若指定此子句，函数将使用数据库的。：如果参数为负数，函数将报错。之间，返回其直接对应的字符。函数，巧妙地生成了字母表序列。：用于检索字符的数字代码。若不指定，则默认使用。场景示例：动态生成字母序列。用于包裹动态生成的标识符。
Oracle INSTR函数详解
u013391334的博客
06-14 311
，从源字符串的哪个位置（字符数）开始搜索。可以为负数，表示从末尾开始反向搜索。函数拥有灵活的语法，可以精确地定义搜索的起始点和要查找的第几次出现。它返回指定子串在源字符串中的位置，若未找到则返回。类型，代表查找到的子串第一个字符在源字符串中的位置，，要查找的字符串，可以为单个或多个字符。），指定查找子串的第几次出现。：查找子串首次出现的位置。个字符开始查找，结果为。
MySQL和Oracle关于读未提交的区别
njq774327136的博客
06-12 332
MySQL和Oracle关于读未提交的区别
日常巡检 Oracle 时，ChatDBA 怎么把会话、SQL 和等待事件一起看
云原生智能数据管理平台
06-15 292
Oracle 实例巡检，本质上是在业务变慢前提前发现信号。NineData ChatDBA 可以把分散在会话、SQL、等待和事务里的线索汇总成清晰结论，帮助团队更早发现风险、更快进入治理动作。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值