Part1问题环境
Oracle 11GR2 Rac
Linux服务器
Part2问题定位
群友发了一个AWR报告，说是数据库负载特比高，需要帮忙看看什么情况
2.1、查看数据库负载
DB Time / Elapsed = 207.26 倍
负载很大
2.2、判断数据库使用类型
要初步判断数据库的适用类型，究竟是逻辑型数据库还是IO型数据库，这个有助于接下来的分析思路
每秒 Redo的产生量是 45kb/s，低的吓人
每秒逻辑读的产生量是 445MB/s
每秒物理读的产生量是 189M/s
每秒物理写的产生量是 0.1M/s
每秒硬解析的产生量是 6.7个/s
每秒事务的产生量是 9.8个/s
基本判断数据库属于逻辑型数据库，数据量产生的很小，物理读的也不小，但是在这里我基本判断还是一个由于查询事务导致的数据库高负载，只不过逻辑查询更严重一些。
2.3、数据库命中率判断
Redo NoWait %这个数值低于95%就需要严重关注，它的含义是redo提交不需要等待的百分比，这个已经到了负值，说明数据库提交方面遇到了很严重的问题。
2.4、等待时间排序的等待事件
问题太多，一下子不知道该看哪个了，
总的来说由commit和system I/O更显眼一点，这里注意到的是控制文件读和log file sync排第一和第二，这个情况在DBA攻坚指南看到过。属于是引起log file sync的种类之一，因为控制文件太大或者归档操作太过频繁引起的。
cluster等待事件的热点块也许是原因也许是结果，需要第二层关注
2.5、判断等待类型的时间排序
%DBTIME加起来没到100%，大约只有50%，说明这台服务器要么是CPU太老旧，要么是这台服务器有其他的服务在使用，划分走了机器的CPU
%WIO说是CPU因为等待IO计算的百分比，在CPU拉跨的情况下，IO等待百分比还是这么高，实在是太夸张了
尤其是log file sync等待事件的情况下，应该现在优先判断一下磁盘的情况
看看io
of=/soft/testdisk/io_test.bin
指的是redo日志磁盘路径生成的压测文件
dd if=/dev/zero of=/soft/testdisk/io_test.bin bs=8192 count=1000 oflag=direct
注意：严重危险，不熟悉的情况下，建议云平台或者存储人员操作
2.6、零零碎碎的验证
SELECT MAX(SEQUENCE#) SEQUENCE, THREAD# THREAD FROM GV$ARCHIVED_LOG WHERE RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE# FROM V$DATABASE) AND STATUS='A' AND STANDBY_DEST='NO' GROUP BY THREAD#
按理来说，查询归档的sql成本不会这么大
日志切换频率，验证了和数据量没有什么关系
控制文件这么大的逻辑读是不正常的。
Part3问题解决
3.1、磁盘IO验证
看看io
of=/soft/testdisk/io_test.bin
指的是redo日志磁盘路径生成的压测文件
dd if=/dev/zero of=/soft/testdisk/io_test.bin bs=8192 count=1000 oflag=direct
3.2、控制文件定位
判断步骤是
1、查询控制文件大小
2、查询归档大小和归档数量
3、查看这个时间段是否有归档的操作（尤其是删除）
解决方案
设置归档保留时间（不要再业务高峰清理）
控制 控制文件大小，看是否能缩一下
监控归档sql是否需要这么频繁，设置执行间隔
查看控制文件真实大小
select v.*,round(BLOCK_SIZE*FILE_SIZE_BLKS/1024/1024,2) from v$controlfile v;
查看控制文件构成及其每部分大小
record_size的单位是字节（bytes），
select type,record_size from v$controlfile_record_section order by record_size desc;
SELECT
type AS "区域类型",
records_total AS "预分配记录数",
record_size AS "单条记录大小(字节)",
-- 核心计算：区域总大小 = 记录数 × 每条大小
ROUND((records_total * record_size) / 1024 /1024, 2) AS "总大小(MB)"
FROM v$controlfile_record_section
ORDER BY (records_total * record_size) DESC;
BACKUP_REDOLOG 40M
ARCHIVED_LOG 127.75M
DELETED_OBJECT 1M
LOG_HISTORY 2M
查询现存的数据库归档，deleted表示归档是否删除，name一定要指定对，因为可能会有ADG，所以只需要看本地实际存在的就行。
SELECT
COUNT(1) AS "现存归档条数",
ROUND(SUM(BLOCKS * BLOCK_SIZE) / 1024 / 1024,2) AS "总大小(MB)",
MIN(FIRST_TIME) AS "最早归档时间",
MAX(COMPLETION_TIME) AS "最新归档时间"
FROM v$archived_log
WHERE
name IS NOT NULL -- 确保是有效归档
AND deleted = 'NO' -- 未被删除
AND standby_dest = 'NO' -- 排除备用库归档;
后续发个截图发现是备库归档满了，导致数据库同步失败。
crosscheck backup;
crosscheck archivelog all;
delete noprompt archivelog all completed before 'sysdate-1';
Part4问题回溯
1、看到log file sync的时候，又看到控制文件，当时想的就是控制文件出现了问题，攻坚指南里但是写着enq: CF - contention是形影不离的关系，可是在top 10没看到，在后续的后台等待日志看到了，可惜是事后梳理发现的，说明等待事件之间的绑定关系还是记得不清
2、虽然直觉性直接去判断控制文件的大小，再去查归档的大小，而且在top 10的sql语句里发现了归档的查询，消耗占比排第二，当时是笃定就是他的问题，但是事后反思还是应该看看磁盘的IO，进行一下压测，可以更好地判断，到底是磁盘性能异常还是控制文件过大引起的。
3、后续群友更发了一个关于数据库归档无法传输，导致数据库归档积攒的报错，但是当时好多查询sql写的并不是那么准确，也给我的判断带来了误判，比如说现存归档的数量和大小，他给我的是所有的，而不是现存的。
4、最重要的是，还没进行归档删除，数据库负载自己降下来了，很奇怪，到底做了什么操作也没说。到底是业务下来了（因为已经是快下午六点了）还是磁盘异常恢复还是数据库监控归档sql停止，都没说，所以很难判断真正的原因。
Part5问题原理
控制文件的原理、作用、判断方式建议看看 《Oracle DBA实战攻略：运维管理、诊断优化、高可用与最佳实践》.(周亮)
到时候跟写一篇具体的吧
