惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
爱范儿
爱范儿
H
Help Net Security
V
Visual Studio Blog
J
Java Code Geeks
Stack Overflow Blog
Stack Overflow Blog
Microsoft Security Blog
Microsoft Security Blog
Apple Machine Learning Research
Apple Machine Learning Research
MyScale Blog
MyScale Blog
The Cloudflare Blog
Martin Fowler
Martin Fowler
D
Docker
腾讯CDC
F
Fortinet All Blogs
雷峰网
雷峰网
GbyAI
GbyAI
G
Google Developers Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Recent Announcements
Recent Announcements
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Blog — PlanetScale
Blog — PlanetScale
Engineering at Meta
Engineering at Meta
博客园 - 聂微东
博客园 - 叶小钗

博客园 - 石云华

gpnptool手动修改GPnP-Profile信息,解决GI集群因心跳配置异常而无法启动的问题 hugePage配置不当,浪费太多物理内存,内存不足导致集群重启 terminating the instance due to error 472,故障原因分析 Exadata存储节点的RPM数据库损坏 duplicate方式搭建DataGuard时,报ORA-19563: header validation failed for file错误 Oracle 19.25 RAC 业务 IP 平滑变更实操 EM13c监控Exadata,提示Agent Unreachable Exadata环境中的CVE-2026-31431漏洞说明 /var/log/message日志中的“megaraid_sas 0000:65:00.0: Application firmware crash dump mode set success”信息 DBCA后,只能启动一个实例,都是rp_filter惹的祸 Exadata更换Infiniband交换机 数据库集群中的bond1接口出现网络丢包 EM13告警:Metric evaluation error start - oracle.sysman.emSDK.agent.fetchlet.exception.FetchletException: Permission denied(publickey,password) Exadata,更换完思科交换机后,与上联交换机无法通信 Exadata更换计算节点的硬盘 Exalogic虚拟机的网络无法启动,提示Device has different MAC address than expected 单个ASM磁盘free空间为0,导致rebalance时提示“ASM磁盘组空间耗尽(ORA-15041)” Exadata的思科交换机,重启后进入到了rommon模式 SYSAUX表空间中的SYS.EXP_HEAD$表,占用大量空间 PX并行进程产生大量的trace日志,导致文件系统撑爆 回收站存在大量对象,导致Insert into...select语句夯住 用dg broker执行switchover时,报0RA-01017 增量备份恢复的方式修改缺失归档的DataGuard 未设置min_free_kbytes参数,导致操作系统进行页缓存回收时,整个操作系统夯住 Exadata数据库性能异常,备份进程卡住 MySQL 5.7版本,搭建一个两主一从的多源主从复制环境 恢复某个数据文件不适当,导致DataGuard无法open数据库 Exadata计算节点的内存出现故障,导致CPU耗尽 Bug 34885986 - Flashback log file was not reused even if db_flashback_retention_target is passed
分析Exadata写入慢的性能故障
石云华 · 2026-04-13 · via 博客园 - 石云华

1、故障概述

某税务系统,Exadata上运行的ORACLE数据库,在每个月的征期时间段内,数据库性能低下,主要表现为业务数据写入慢,甚至出现业务写入超时的情况。

本文档针对整个故障进行分析,并给出相应的建议。

2、故障处理

1.1 分析故障时间段的AWR报告

image

 从数据库的TOP10等待事件可以看出,当前最为严重的等待事件为:free buffer waits和write complete waits.

free buffer waits等待事件,大概意思就是ORACLE要进行物理读时,在内存中没有找到合适的空闲内存块,此时就需要唤醒DBWN进程将内存中的脏数据刷回磁盘,然后释放内存,在等待脏数据刷回磁盘的这一过程中,请求空闲内存的进程就进入睡眠状态进行等待,等待事件就为free buffer waits.

write complete waits等待事件,当内存中的一个脏数据块正在被刷回磁盘的过程中,另外一个进程对这个数据块同时发起IO请求,这个IO请求就需要等待,等其被写入磁盘完成后,才能再次访问,这一过程就会产生write complete waits等待事件。

从等待事件大概可以看出,问题在于磁盘的写入性能太差,业务系统的数据变化比较大,导致内存中的脏数据刷回磁盘比较慢。

image

 分析后台进程的等待事件。可以看到,db file parallel write等待事件占用了近80%的数据库时间。平均延迟为11207ms,这也表明,磁盘的写入性能非常非常差。

1.2 分析存储软件日志。

检查存储软件日志,发现“自动磁盘擦洗和修复”特性已经开启。

 “自动磁盘擦洗和修复”特性,主要是为了尽早地发现和解决硬盘的坏道问题,默认每两个星期会自动运行。但是,这个特性带来的负面问题是:磁盘擦洗时,会消耗大量IO,在业务高峰期时,会造成IO耗尽,业务不可使用。

在其他省份的税务系统,相应的做法是:手动关闭该特性,在每月的征期结束后,手动启动该特性,等磁盘擦洗工作结束,再次关闭该特性。

1.3 检查存储配置。

检查当前的存储配置,如下所示。

image

 从存储软件的配置来看,当前FlashCache闪存的配置为WriteThough模式。WriteThough模式 对比 WriteBack模式的FlashCache,工作原理图如下所示。

image

 从WriteThough模式的工作原理图可以看出:刷内存中的脏数据,是直接刷入机械磁盘,才完成刷脏数据操作。

然而,WriteBack模式的FlashCache,刷内存中的脏数据,是先刷加到闪存卡中,就完成刷脏数据操作,后期再慢慢地将闪存中的数据刷回机械磁盘。

闪存的IOPS远远高于机械磁盘,所以需要开启存储的WriteBack模式,解决写入慢的问题。

3、故障解决

关闭存储节点的“自动磁盘擦洗和修复”特性,改成手动。调整所有存储节点,开启闪存的WriteBack模式。 最终,写入慢的性能故障得以解决。