数据库学习日常案例20231225-oracle AWR报告分析sequence cache连接缓慢卡死 故障

• 1.故障现象

某日业务反馈数据库连接超时，连接上会隔40s断开连接，过后间隔3s又会重新连接上，但是执行sql语句进行操作会出现卡慢，导致应用系统出现连接失败。

• 2.故障分析

1、排查数据库机器过程：
出现连接不上问题的是两个节点上的数据库，根据之前处理数据库问题的经验可得知，
此数据库所搭载的服务器为AIX操作系统的IBM小型机，
现场一线工程师通过CRT连接进入这两台机器的操作环境中，执行如下命令：
# topas
此命令用于查看主机CPU使用率，以便于查看是否主机存在故障，
经检测后发现主机及操作系统均为正常。
                                                                         
2、排查网络问题
确认主机及操作系统正常后，驻场一线工程师继续测试网络，
排查是否由网络故障引起的问题：
#ifconfig
得到ip地址
#ping IP
在反复测试后得出结论：网络传输正常，
无丢包现象，故得出结论网络没有问题

3.查看数据库状态
检查数据库能否连上
1).通过服务器连接
在CRT连接上两个节点时通过以下命令
# su - oracle
$ sqlplus / as sysdba
SQL>
2).检查数据库
通过服务器连接数据库成功，经过查看未有断连现象，
并且通过指令检查数据库连接状态：
SQL>select * from dual;
                                                                         
每经过一分钟再次输入指令查询连接状态：
得出结论为数据库连接稳定，没有断连或连接超时问题

SQL>select status from v$instance;
检查后发现数据库运行状态稳定，无故障
查看数据库进程数：
SQL>select count(*) from v$process;
当前进程数为896；
SQL>show parameter processes;
最大进程数为：1200；
进程数也在正常范围类。

• 3.AWR分析

• 
• 通过对top应用程序进行过滤分析，查到跟序列相关的应用程序消耗巨大
• 
• 进一步查看开发人员对序列的cache值设置，发现应用程序所对应的此段代码所涉及的序列号的cache值设置均不合理，通常cache分配最少为1000以上，此段代码的cache值仅为100，从而导致一旦涉及到此应用操作就会导致严重卡慢，从而导致连接超时及断连现象。
• 

• 4.解决方案

• 结果分析后得出结论为应用程序代码所对应的cache值设计不合理为出现此次故障的原因，
  与客户现场进一步确认及分析后给出解决方案：
  应用查询所涉及到序列号为118个，应用方常用为75个，
  将此75个序列号所对应的cache值改为建议大小1000，
  开发人员根据建议将常用的75个序列号所对应的cache值均改为1000，
  从而问题得以解决。
• cache的作用：当大量语句发生请求，申请序列时，为了避免序列在运用层实现序列而引起的性能瓶颈。Oracle序列允许将序列提前生成 cache x个先存入内存，在发生大量申请序列语句时，可直接到运行最快的内存中去得到序列。但cache个数也不能设置太大，因为在数据库重启时，会清空内存信息，预存在内存中的序列会丢失，当数据库再次启动后，序列从上次内存中最大的序列号+1 开始存入cache x个。序列的cache要求设置不低于2000，Oracle数据库，序列缓存值（cache）属性默认为20。当并发量大时，一旦缓存值较小，就会出现瓶颈，RAC环境下尤其严重。

• 5.等待事件说明

• select name,wait_class from v$event_name;
  1. 理类：Administrative
  此类等待事件是由于DBA的管理命令引起的，这些命令要求用户处于等待状态，比如，重建索引。
  【Waits resulting from DBA commands that cause users to wait (for example, an index rebuild)】
  2. 应用程序类：Application
  此类等待事件是由于用户应用程序的代码引起的（比如：锁等待）
  【Waits resulting from user application code (for example, lock waits caused by row level locking or explicit lock commands)】
  3. 群集类：Cluster
  此类等待事件和真正应用群集RAC的资源有关。（比如：gc cr block busy等待事件）
  【Waits related to Real Application Cluster resources (for example, global cache resources such as 'gc cr block busy'】
  4. 提交确认类：Commit
  此类等待事件只包含一种等待事件－－在执行了一个commit命令后，等待一个重做日志写确认（也就是log file sync）
  【This wait class only comprises one wait event - wait for redo log write confirmation after a commit (that is, 'log file sync')】
  5. 并发类：Concurrency
  此类等待事件是由内部数据库资源引起的，比如闩锁。
  【Waits for internal database resources (for example, latches)】
  Row Cache Objects  --Oracle用于控制内存并发的串行锁机制
  6. 配置类：Configuration
  此类等待事件是由数据库或实例的不当配置造成的，比如，重做日志文件尺寸太小，共享池的大小等。
  【Waits caused by inadequate configuration of database or instance resources (for example, undersized log file sizes, shared pool size)】
  7. 空闲类：Idle
  此类等待事件意味着会话不活跃，等待工作。比如,sql * net messages from client。
  【Waits that signify the session is inactive, waiting for work (for example, 'SQL*Net message from client')】
  8. 网络类：Network
  和网络环境相关的一些等待事件，比如sql* net more data to dblink。
  【Waits related to network messaging (for example, 'SQL*Net more data to dblink')】
  9. 其它类：Other
  此类等待事件通常比较少见。
  【Waits which should not typically occur on a system (for example, 'wait for EMON to spawn')】
  10. 调度类：Scheduler
  Resource Manager related waits (for example, 'resmgr: become active')
  11. 系统I/O类：System I/O
  此类等待事件通过是由后台进程的I/O操作引起的，比如DBWR等待，db file paralle write。
  【Waits for background process IO (for example, DBWR wait for 'db file parallel write')】
  12. 用户I/O类：User I/O
  此类等待事件通常是由用户I/O操作引起的,比如db file sequential read。
  【Waits for user IO (for example 'db file sequential read')】

• 6.总结

• AWR 报告是 Oracle 数据库重要的性能诊断工具，AWR 对一段时间内数据库的核心状态指标进行详细的分类展示，蕴含了十分丰富的信息。如果某个指标异常，可以通过解读 AWR 报告对其追根溯源，寻找解决方案