接手新环境，如何从头分析数据库性能

接手新环境，如何从头分析数据库性能，聊聊我的思路。

技术人人都可以磨炼，但处理问题的思路和角度各有不同，希望这篇文章可以抛砖引玉

以一个例子为切入点

一、问题背景

某客户希望协助他们对数据库进行全面分析优化，emmm...这活我接了。

• 主机类型：Huawei9008 V5

• 操作系统：Red Hat Enterprise Linux Server release 7.7

• 存储：1918.0GB（RAID,磁盘类型未知）

• 内存：512 G

• CPU型号：Intel(R) Xeon(R) Platinum 8168 CPU @ 2.70GHz ( 8 U * 24 core) 

• CPU核数：192CORE( 8 U * 24 core)

• 数据库环境：Oracle 19c （单实例）

二、初步分析及建议

• OS及数据库环境基础参数配置可依据官方文档配置（略）

• 压测过程中发现lgwr进程异常，按oracle的处理机制，一但lgwr写无法完成，前端所有sql，几乎都会阻塞；Lgwr写入缓慢，是io问题，还是cpu问题导致，这个需要更细粒度的数据去排除和验证。

其他建议：

• 1、部署os级别的采集脚本，5秒采样一次，监控cpu及io使用情况，用来进一步分析问题时段的io及cpu情况 （客户评估实施）

• 2、调整_use_adaptive_log_file_sync参数为false，禁止lgwr自适应提交 (客户评估实施)

• 3、降低程序中的非绑定变量SQL。

• 4、应用层面继续排查和优化

三、疑问点排查及分析思路

1、定位问题准确时间点

10月20号9点31到9点35分活动会话很高，前端应用出现阻塞

10月19号9点25到9点36分活动会话很高，前端应用出现阻塞

2、AWR情况分析

从awr中，top 的等待是log file sync

3、Lgwr trace文件分析

Log file sync会话等待的是log file parallel write，lgwr进程对超过500ms的提交会记录到trc文件，

9月19号 09:26，09:28，09:30，09:35 出现了4次30到200秒的写超时。

9月19号 09:34 出现了1次190秒的写超时。

4、数据库io指标分析

从oracle的数据字典中排查IO的的吞吐量和io request次数，如下，问题时段没有明显的波动，大致可以排除由于sql io消耗导致的阻塞。

5、硬解析指标分析

客户提出硬解析指标高，怀疑硬解析问题。

查看最近7天的sql的硬解析次数，问题时段硬解析测试也非最高值，最近7天的趋势上看，也没有明显数量级的增加，硬解析如果出现问题，相应会有library cache的等待，awr中也并没有看到，排除此问题。

6、连接风暴因素排查

检查客户监听日志，有波动，但没有短时间大量连接创建，排除此因素。

7、监控数据分析和优化

结合几天的观察，db这边基本判断io负载增高，导致lgwr超时，lgwr超时导致连接阻塞，io负载增高的原因和解决办法大致有二个方面：

• 1、优化物理io请求高的sql，尽可能降低数据库的iops请求

• 2、评估db主机的io的能力，主要是iops的能力，目前看到wait和svctm，util都比较高，之前压测故障时间，都是iops高位运行时（sar -b 的tps 在1200到1300），lgwr的trace文件中显示的超时次数突增；

可以横向对比一下挂载了同样存储的其它主机，它的io表现，排除db主机和os潜在问题，评估io潜力到底有多大？

8、SQL优化部分

针对top SQL进行优化（优化过程略）

四、初步优化完，后续补充压测更新

1、客户io监控数据分析

10.22

查看iostat命令监控输出，从9点06分，9点09分，9点12分，9点22分开始，出现多次io写入为0的情况，长短不一，最长出现190秒无法写入。

2、Lgwr trace文件分析

根据当时的数据库监控，无论iops，还是io吞吐量都很低，但IO表现非常不理想，结合上面的SQL多客户维度分析，建议客户对数据库环境的IO整个链路(FC SAN,HBA,OS，MULTIPATH,存储等) 做进一步排查或调换。

更多干货关注：“数据与人”