排查医疗系统卡慢的一次经历 二--ASH报告

ASH是什么？ （Active SessionHistory）
ASH以V$SESSION为基础，每秒采样一次，记录活动会话等待的事件。不活动的会话不会采样，采样工作由新引入的后台进程MMNL来完成。

v$active_session_history视图提供了在实例级别抽取会话活动信息。活动会话每分钟会被抽样一次且被存储在sga中的循环缓冲区中.任何被连接到数据库且正等待一个不属于空闲等待事件的会话会被考虑是一个活动的会话。每个会话抽样都是一组行数据且通过v$active_session_history视图来返回每个被抽样活动会话的行数据，返回最新被抽样会话的第一行数据。因为活动会话抽样是存储在sga中的循环缓冲区中，系统活动越大的，活动时间越少会话的可以被存储在循环缓冲区中。这意味着在这期间被抽样的每个会话会出现在v$视图中或者会话活动的时间会在v$视图中被显示，这完全依赖于数据库活动情况。

ASH buffers 的最小值为1MB，最大值不超过30MB.内存中记录数据。期望值是记录一小时的内容，所以说ASH 内存记录数据始终是有限的

一般在线上实时诊断数据库性能问题，特别是负载高w出来上了100后，cpu 100%，这个时候用ash实时出日志报告，就能很大程度上准确定位问题所在。

2、ASH生成过程关键，在系统中运行CMD ，切换到某个路径下，用来保存报告的目录
例如，我讲报告打算保存到D:\ASHReport目录

C:\Users\Administrator>D:    //切换到D盘
D:\>cd d:\ASHReport          //切换到这个目录下，否则生成的报告不好找。
D:\ASHReport>sqlplus / as sysdba  //启动sqlplus 这样方式启动的SQLPlus生成的报告就在D:\ASHReport目录下 

下面进入SQL数据库的SQLPLUS生成报告的过程，会依次提示你输入相应的三个参数

SQL>@?/rdbms/admin/ashrpt.sql    //主要命令是这个，命令后，会让有如下参数需要手动填写：

第一个参数。选择报告类型，我一般喜欢看html

Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
输入 report_type 的值:  html  

第二个参数 日志报告起始时间
Enter value for begin_time: 08/31/1620:00:00
– 输入ASH 开始的时间，时间格式上面的示例有说明，比如我这里是09月08日 00:00开始。

Specify the timeframe to generate the ASH report
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter begin time for report:

--    Valid input formats:
--      To specify absolute begin time:
--        [MM/DD[/YY]] HH24:MI[:SS]
--        Examples: 02/23/03 14:30:15
--                  02/23 14:30:15
--                  14:30:15
--                  14:30
--      To specify relative begin time: (start with '-' sign)
--        -[HH24:]MI
--        Examples: -1:15  (SYSDATE - 1 Hr 15 Mins)
--                  -25    (SYSDATE - 25 Mins)

Defaults to -15 mins
输入 begin_time 的值:  09/08 00:00

//第三个参数。我记得这个单位是分钟。这里输入20代码从开始到结束取20分钟的日志产生报告。一般也就是故障卡顿的结束时间，如果是直到现在还在卡顿，那么直接回车就可以了

Report begin time specified: 09/08 00:00

Enter duration in minutes starting from begin time:
Defaults to SYSDATE - begin_time
Press Enter to analyze till current time
输入 duration 的值:
Report duration specified: 20  //我这里单位是分钟

生成的过程中可能会出现如下错误。主要是时间格式造成的时候

第 1 行出现错误:
ORA-01843: 无效的月份
ORA-06512: 在 "SYS.DBMS_SWRF_REPORT_INTERNAL", line 10999
ORA-06512: 在 "SYS.DBMS_SWRF_REPORT_INTERNAL", line 10421
ORA-06512: 在 "SYS.DBMS_WORKLOAD_REPOSITORY", line 1554
ORA-06512: 在 line 1

很简单使用语句查看当前的变量。然后把当前会话的变量修改一致就可以了

select name,value$ from props$ where name like '%NLS%';  --查看当前数据库的变量设置

然后跟进具体情况，自己修改成一致即可。不建议修改环境变量，因为会导致其它问题。我们只需要修改当前会话的环境设置即可。

ALTER SESSION SET NLS_DATE_LANGUAGE='AMERICAN'; --设置日期格式，应该要跟数据库的一致
--ALTER SESSION SET NLS_DATE_LANGUAGE='AMERICAN';
--ALTER SESSION SET NLS_DATE_LANGUAGE='AMERICAN';
--ALTER SESSION SET NLS_DATE_LANGUAGE='AMERICAN';

然后就可以在D:\ASHReport\找到刚生成的报告了。

ASH报告里面主要着重看的是
1.Top User Events
2.Top SQL
3.Top SQL with Top Events
4.Top SQL with Top Row Sources
5.Top Blocking Sessions

如果出现下列情况一般的处理方式
TABLE ACCESS - FULL

类型	说明	处理方法
TABLE ACCESS - FULL	这种代表全表搜索，性能很低，数据越大越慢。	加索引或者修改sql增加某个可以索引的字段
CPU + Wait for CPU	该事件只能说明cpu很忙，至于是否cpu过载要看情况	一般来说逻辑读写不是特别多的话而且cpu整体不忙的话，很大程度上可以认为sql语句应该使用并行执行来加快速度。
log file sync	什么是log file sync等待事件呢？在一个提交（commit）十分频繁的数据库中，一般会出现log file sync等待事件，当这个等待事件出现在top5中，这个时侯我们需要针对log file sync等待事件进行优化，一定要尽快分析并解决问题，否则当log file sync等待时间从几毫秒直接到20几毫秒可能导致系统性能急剧下降，甚至会导致短暂的挂起。	https://www.cnblogs.com/iyoume2008/p/7691025.html
db file sequential read	可能表示在多表连接中，表的连接顺序存在问题，可能没有正确的使用驱动表;或者可能说明不加选择地进行索引	从读取开始，增加SGA中buffer cache的大小，避免每次都从硬盘中去读数；优化sql语句，减少不必要的块读取； https://blog.csdn.net/qq_34556414/article/details/80526243

经过排查发现，系统卡顿的两个主要元凶，
一。很多表都没有多少索引， 基本上都是TABLE ACCESS - FULL 全表搜索。一次故障中发现，系统正在执行一条统计语句，执行次数比较多，800多次，而且是全表扫描的统计。 后增加了索引，优化了SQL，问题当场就解决了。类似的事情还有很个，也都是没有索引引起的。 可以说没有索引导致的问题占了系统卡顿90%的概率。 其它问题导致的概率则相对较低。
另外我在加索引的时候也发现，有些查询语句确实是无法建立合适的索引的，也不太可能让所有的程序员都能排查到所有的SQL语句， 针对这个问题我认为，对于业务表一定要增加时间字段例如CreateTime 这样在每个查询中固定都必须加上这个时间条件取最近90天或者最近30天的数据，并对时间增加索引， 可以大幅缩小查询范围。这样可以保证系统在一定程度上经久不衰。不会越用越慢。
另外在建表的时候一定要给每个字段一个默认值 防止因为条件中有where name is null，而导致数据放弃使用索引。

二。 通过ASH报告发现某个表有着惊人的磁盘读写量， 一个下午读取了320GB的数据。 后仔细排查才知道有些表里面使用了Long类型的数据， 里面存储了大量的二进制数据。后来知道这个是系统版本升级用的表。每次升级都会去插入一些新的记录，并且直接把可执行文件存入到了数据库中。 时间久了就卡的不像样了。
针对此问题， 我觉得是完全可以避免的。 数据库里面存Long类型是不适合的。 如果这个数据文件有可能超过1MB了。那么一定要考虑单独存储到文件系统中，通过HTTP访问。数据库中只存文件路径。可大幅减少数据库吞吐量。