Oracle数据库管理每周一例（12.2,18c,19c） 2020-08-06

第九期 最近遇到的一些故障及其处理方案

由于上周突然生病住院，所以停更了一周，这周依然很忙零散写点东西

前两节主要是针对锁、等待、hung相关故障的说明，应对这类问题除了从业务侧逻辑进行分析调整，有时候还需要查找数据库侧的问题，因为很多情况下语句在数据库中的执行情况和业务逻辑是存在不一样的现象。

1.可手工重现的hung分析

本节其实这是我之前遇到的一个小问题，在做完RAC to RAC ADG灾备切换演练后发现通过EM无法生成AWR报表，到服务器上执行也无法生成AWR报表。由于操作可以复现，所以用了开启10046 trace的方法获取操作的相关数据库信息并提交MOS进行分析。

SQL*PLUS>
alter session set events '10046 trace name context forever, level 12'; 
select 1 from dual; 
@?/rdbms/admin/awrrpt.sql （因为执行很慢，执行10分钟后ctrl+c停止）
select 2 from dual;
alter session set events '10046 trace name context off';
select value from v$diag_info where name='Default Trace File'; （获取对应trace文件并上传）

本次故障MOS分析为一bug，提供了一个小补丁，但是后面没有打补丁也逐步恢复正常了。以上操作可以用作可以手工复现的hung情况分析数据库为什么hung住了。

2.无法手工重现的hung分析

之前用xtts迁移到Exadata的那套数据库，最近一直有偶发的hung、等待和锁，由于无法通过执行对应语句百分百重现故障场景，因此在发现出现问题时使用一下方法进行信息收集：

1.对于非RAC环境
conn / as sysdba 
oradebug setmypid 
oradebug unlimit 
oradebug hanganalyze 3 （这里会输出rc文件位置）
oradebug dump systemstate 258 （等待10s，ctrl+c终止） 
oradebug hanganalyze 3 
oradebug dump systemstate 258 （等待10s，ctrl+c终止）
oradebug tracefile_name 
oradebug close_trace 

2.对于RAC环境，任意节点执行
conn / as sysdba 
oradebug setmypid 
oradebug unlimit 
oradebug -g all hanganalyze 3 （这里会输出当前实例的trc文件位置，其他实例可以从对应alert日志获取，如果能确定那个实例出现问题，可以只上传对应实例文件）
oradebug -g all dump systemstate 258 （等待10s，ctrl+c终止）
oradebug -g all hanganalyze 3 
oradebug -g all dump systemstate 258 （等待10s，ctrl+c终止）
oradebug close_trace 

上传相关trc文件到MOS分析即可。

3.PDB与CDB的undo

同样是用xtts迁移到Exadata的那套数据库，最近有偶发慢SQL的现象，使用EM巡检发现对应实例CDB的undo表空间已用可用空间只有50%，但是已用的分配空间超过了100%，在扩容undo表空间后语句执行恢复正常。
这里先要引入一些概念：
1.在EM中已用可用空间概念指的是表空间所有数据文件能达到最大容量之和，其实就是数据文件自动增长的话，数据文件数量乘以32G。
2.在EM中已用的分配空间的概念指的是当前数据文件还未进行下次自动增长时总容量使用的百分比。
3.从12.2开始，Oracle引入了local undo的概念，即PDB使用自己的undo。但是在local undo表空间不足的情况下，会使用对应实例CDB的undo表空间。

不知道为啥在这个19.6的环境中，undo表空间数据文件开启自动增长，数据库在用完已用的分配空间的情况下会判定undo表空间容量不足，回去使用CDB的undo。后来resize了所有数据文件之后，这一现象得到了缓解，但是仍然会出现使用CDB undo的现象，因此扩展的CDB的undo表空间。
关于undo表空间已用可用空间只有50%，但是已用的分配空间超过了100%的现象，由于业务每天都会执行非常大量的批处理，一些批处理需要在undo中使用连续的段，当undo中存在零碎段的情况下，可能会造成undo的实际占用超过实际使用的百分比，在加上上一段中undo自动增长异常的问题，导致undo异常。
目前关于这套数据库hung、锁、等待和undo的问题已提交MOS，暂时不确定是业务场景造成的这一连贯问题还是bug造成。当前通过监控CDB与PDB的表空间，在出现超限是及时扩容。

4.SMON

由于一些大SQL长时间运行，造成了卡顿、表锁等现象，或者就是业务方认为超时异常了，业务方索性就直接kill相关session，甚至是kill相关进程，触发SMON清理进程使用undo进行回滚，在这种情况下，SQL执行了多久，回滚会耗费更多时间同时会大量占用undo表空间，同时SMON会阻塞相关表相关行的操作直到SMON结束。这种现象在Exadata库上多次出现，也造成了其他相关问题，比如undo表空间。业务方的解决等待的操作方式十分粗暴也是造成这一问题的原因之一。目前也提交MOS进行分析。

下期预告：

最近遇到的一些故障及其处理方案(2)