标签：这个 案例 数据库 问题 排查 Oracle 日志 redo delete
Oracle性能排查小案例
原创jeanron1002021-07-23 15:03:10©著作权
昨天一个老同学找我说碰到了数据库的问题，因为各种杂事一直给耽误了下，今天做了一个初步的分析。
首先这是一个做统计业务的数据库，类型可以归为OLAP方向。根据反馈，在周末的时候相关的ETL任务会卡住，问题已经过去了一段时间，确切的说是发生了10月份的时候了，经过一段时间的排查发现问题是有规律的。所以想让我看看数据库层面有哪些潜在的问题，可以把这个问题解决掉。
首先我要到了一份AWR报告。整体看配置还是很不错的，小机下的11g RAC环境，硬件配置也是蛮不错的。
这里的DB time还是很高的，这也就能够间接说明是在ETL出现问题很可能和这个DB time异常是有关的。
看到这里我需要去明确既然是RAC环境，另外一个节点是否也有类似的问题，结果很快排除了，只在这个节点2上存在性能抖动，节点1上的负载可以忽略不计。
这是节点2一个概览信息。
里面有几个指标是很明显的，比如redo日志量实在是太高了，整体来看IO方面，压力还是蛮大的。
这个等待事件也是比较典型的，可以更加明确问题的方向了。
按照目前的信息，可以基本得到一个数据，每秒产生28M的redo日志量，那么1分钟会产生28*60近1.4G的日志，如果是一个小时，产生的redo就有80G左右。
可以看到等待事件，很多也是和redo方向相关的，排在首要的是日志切换频率的问题。
这是时间模型的一个概览。
基于以上的信息，我们可以更加关注于IO层面相关的SQL,结果一看一个准。
通过这个可以很明显的看到问题的瓶颈了，原来是有几个delete语句，经过确认这些delete语句是没有where条件的，也就意味着这是一个权标数据的清理，显然使用truncate是正确的解法。
经过了解，这属于ETL的一个流程，会先清理掉之前的数据，然后通过绑定变量批量写入数据的方式，调用的频率都是百万级别。
报告里面有一小栏不太起眼，通过这个指标能够明确的定位到问题。
在1个小时的时间里，日志切换了500多次，按照日志写入的情况，一个小时80G左右的日志，切换500次，那么redo文件的大小在150-200M之间，对于目前的这个配置和当前的问题来说，是很不合理的，按照问题发生时的情况，每隔7秒钟左右就完成一次日志切换。这个频率和我们预期的相差太大。
其实问题到了这里基本能够定位明确了。
不过老同学反馈了几个疑惑的问题，这个任务在每天都会执行，但是不是每天出问题，出问题的时间段经过观察发现比较规律，基本都是周末的时候出现问题。所以我需要继续明确下这个问题的潜在原因。
经过排查，这个数据库里面没有发现业务层面的scheduler任务，而且对比相邻天数同样时间的awr报告，没有发现等待的delete语句。
这有几种情况，一种是确实执行了delete，因为数据量不大，所以delete的结果完全可控，另外一类是这个任务的执行是有窗口时间的，是不是可能在周日的时候启动了业务层面的任务导致了这个问题。 这一点需要在ETL的相关配置中确认。
当然一种潜在的影响是数据库中默认会在晚上10:00开始一些定时任务，比如统计信息收集，日志清理等。这个影响是潜在的，如果存在不规范的delete方式，对于后端自动任务的执行性能是有潜在的隐患的。
所以最后的一个结论是：
-
把delete操作改造为truncate操作，这应该是这个问题出现的关键解决拌饭
-
调整redo的大小，如果按照1G的redo来计算，则将近1分钟切换一次，相比原来的方式要好很多了，况且有了第1个方案的保证，这个的压力会减少40%左右
-
查看周日的定时任务，需要统一检查，然后禁用掉这列后端任务。
相信这样一波改进之后，这个问题能够得到根本性的解决。
标签：这个,案例,数据库,问题,排查,Oracle,日志,redo,delete 来源： https://www.cnblogs.com/yaoyangding/p/15918421.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。