DBAIOps的博客

实际上智能化诊断的实现有很多种渠道，不过大部分做智能化诊断的厂家都会选择从数据入手，通过数据的异常来发现系统可能存在的问题，这种做法只要有算法工程师和略懂运维的人参与就可以开展，不需要大量的运维专家参与，比较容易开展工作。因为如果简单的通过有向图扫描所有诊断路径，最终的结果肯定是把所有的工具都执行一遍，然后所有的诊断路径中发现的问题再做汇聚。如果不通过知识梳理的方式，而采用深度学习的方法对数据进行分析，从而形成这样的诊断路径，那么所需要的数据和案例是海量的，其数据归集和数据标注工作也是一项巨大的工程。

不过使用这个结构的最主要的是dbwr，这个数据结构里和DBWR相关的数据项特别多。LRU链是我们传统所说的replacement list,用于BUFFER的LRU替代，LRU-W是需要DBWR写入数据文件的链，LRU-P是当前正在写入的链表，当时所有的BUFFER都被PIN住，等写入完成后会降低锁定级别，并被重新链入LRU。当时他们的研发负责人也十分理解我们的需求，不过从他们目前的情况来看，如果要统计每个等待事件的时间，则会严重的影响数据库的执行效率，对SQL执行性能有很大的负面影响。

第三个是扩大经常动态扩展的列表对象的初始大小，减少其动态扩展的次数，最好能够让它们不再动态扩展，这个做法会浪费一定的共享池空间，但是是可以解决这个问题的最好的方法。正因为这样，如果系统并发量很大的时候，很多共享池的内存是被PIN住，无法释放的，这样，共享池的空闲空间就被分给为无数个很小的碎片，对于一些较大的分配，可能就无法满足，出现ORA-4031也就不可避免了。根据HEAP的内存管理方法可以看出，共享池碎片化是不可避免的，随着数据库实例的启动时间的增长，这种碎片化趋势会越来越明显。

根据对数据库的理解，如果单实例能够打开，说明这个数据库的数据字典是基本一致的，有可能存在的问题是第二个实例的REDO丢失部分数据，导致某些数据出现不一致，另外一个实例的UNDO出现不一致。5、不过这时候数据库是存在一些数据不一致的地方的，会有一些坏块，对这种情况，一般有两种后续处理方法，第一种是继续找存在问题的对象，进行修复，还有一种是导出数据，重建数据库，再倒入数据，使数据库重新恢复正常，一般情况下，对于一个十分重要的数据库，第二种可能是最佳方法，当然需要一定的停机时间才可以进行类似的操作。

60号进程以S模式申请enq: RO - fast object reuse锁，但锁Enqueue RO-0002003C-00000001被15号进程以X模式占有，同时16号进程以X模式申请Enqueue RO-00020010-00000001锁，但Enqueue RO-00020010-00000001被15号进程以SS模式占有同时Enqueue RO-00020010-00000001被16号进程自己以SSX模式占有。229、231和3点42分的ssd trace等待的对象仍然是一样的。

他回答是这些都没错，然后我问他网卡的顺序是否正确，在HP-UX下有时候私网和公网的网卡在两台服务器上的设备名不对应，也可能会出一些莫名其妙的错误。这下子就很明确了，估计是HP-UX的补丁没有打全，经过检查，发现GOLDQPK11i 没有打，打了补丁后，测试一下/usr/sbin/pingnode1 -n 1 -m 3 ,一切都OK了，于是再安装CRS，一切正常。那么下面该怎么处理呢？在常规方法无法找到问题的时候，使用操作系统跟踪工具对某个出问题的配置过程进行跟踪是十分有效的方法，命令去检查节点的健康性。

因为在不设置这个事件的时候，如果RMAN恢复数据文件的时候发现备份集有坏块，就会在坏块的位置写入一个空块。而设置了这个事件，不管怎样，都会将这个块写入数据文件，这可能导致不一致的产生。不过设置了这个事件也不一定能够跳过坏块恢复文件，因为一个备份集往往有多个文件，如果标志哪个块属于哪个文件的数据块坏了，那么恢复数据将变得不可能。：如果在恢复的时候还没有恢复到所需要的所有数据块，就碰到文件结束了，这个时候会报 ORA-19612,如果设置了这个事件就会忽略这个错误。为了解决这个问题，Oracle提供了两个。

到目前位置，用kfed使用常规方法修复磁盘头还是一件十分困难的事情。直到Oracle 10.2.0.5开始，Oracle也意识到了asm的这个问题，在asm metadata中保留了一个备份块，这样使用 kfed的一个隐含功能就可以实现asm磁盘头的一键修复了。ASM磁盘头故障的原因十分复杂,一般和安装与运维有关，其根本原因就是Oracle.比如在AIX平台上,如果没有清掉PVID，下次服务器重启时就可能会出现设备名混乱的问题，如果你用chdev去修改设备，那么ASM磁盘头可能会丢失。

是不是很简单，不过有些细心的人会有疑问了，一个4096字节的块，只能包含60个AU项，如果有冗余，只能包含30M的AU的指针，超过30M的文件如何处理呢。在这个数据库中，SYSAUX的ASM文件号是257，因此这个文件的FILEDIR是AU 60的BLOCK 1。这个别名文件的ASM文件号是6。首先我们要了解的是DISK HEADER，每个DG的DISK都有一个HEAD，其位置是文件头部（如果以0为第一个块的话，那就是0号块），DISKHEADER其实就是每个DISK的AU 0的BLOCK 0。

昨天不知道什么原因写了一篇关于故障自愈的文章，很巧的是，下午和一个客户做智能化运维交流的时候，有人也提出了Oracle数据库如何做故障自愈这个问题，晚上就想到了3年前的这个方案，于是今天早上就把它写出来和大家分享一下。当自动化处置工作完成后，部分自动化处置的影响可能会在后续陆续出现（比如表分析，索引重建等），因此本次自动化处置执行完成后，还需要创建一个事后监督任务，在事后的一段时间内，或者事后的某些特定日期、时间段进行事后监控（比如优化一个与月结相关的参数与索引，其效果需要下次月结时才能体现出来）。

大多数做数据库优化的DBA在阅读AWR报告的时候，都是从TOP EVENT开始阅读的，或者把TOP EVENTS当成重点来阅读，所有的分析都是围绕着TOP EVENTS的，我刚刚开始学习阅读STATSPACK报告的时候，也是如此。因为大多数数据库的性能问题与故障都是与数据库负载相关的，经常有朋友说，为什么这套系统会出问题，另外一套不出问题，或者说为什么RAC的一个节点出问题，另外一个节点为什么不出问题。或者说你使用ASM的时候，存在多个ASM磁盘组，而这些磁盘组的磁盘来源于不同的存储，或者不同类型的存储。

我们可以看到ksmsp实际上指向了一个kghds的链表，而这个链表实际上是指向真实的SO头而，对x$ksmsp的统计实际上会遍历heap链表，对于共享池很大，并且共享池并发访问很重，特别是共享池存在性能问题的场景，这种访问无疑会加重共享池的负担，甚至成为压垮骆驼的最后一根稻草。x$kghlu经常被某些数据库监控软件用来监控共享池问题，不过频繁的访问这个数据结构还是会对数据库产生影响的，特别是数据库并发比较大，共享池存在性能问题的时候，如果过于频繁的监控这个数据结构，可能会产生一些相当严重的问题。

以我这些年做数据库服务的经验来看，nmon虽然能够生成漂亮的图表，但是如果是做问题的根因定位，其数据采集的粒度和丰富程度，都远不如OSW。目前也有很多监控OS的开源工具，利用开源协议比较友好的开源工具，学习OSW采的数据内容，搞一套OS采集工具，集成到数据库产品中，应该会对售后服务有很大的帮助。目前国产数据库的售后服务面临更大的挑战，第三方服务能力的缺失导致客户现场问题不经缓冲直接会压到数据库原厂的售后服务人员头上，而国产数据库厂商的售后服务体系远没有Oracle那么完善和强大，因此将会面临更大的压力。

实际上用户是把SQL PROFILE当成绑定执行计划了，其实从原理上讲，SQL PROFILE并不是强行绑定执行计划，而是通过SPM分析发现统计信息与实际运行情况不符，因此通过SQL PROFILE设置了一些TABLE_STATS hint，从而让优化器可以使用更为精准的生成执行计划。上面这张图也来自于Oracle的官方文档，这张图十分清晰，从上面我们可以看出，SQL PROFILE是用于纠正过去错误的执行计划的，但是并不限定今后不会再次使用这个错误的执行计划。不过它的缺陷是缺乏灵活性。

只不过加入跟踪后的数据库运行可能会变得不稳定或者触发一些非预期的行为和BUG，因此目前为止，除了Oracle体系化的发布了EVENT接口，让运维人员可以自行通过EVENT设置来改变数据库运行行为，或者监视数据库的内部运行，其他数据库还必须依赖一些外部的跟踪工具，使用起来并不方便。在缺乏必要的资料，甚至连一个METALINK账号都没有的时期，学习Oracle数据字典的基本原理，以及数据库启动时的主要动作等，都是通过10046 trace文件完成的。只要误差都是差不多的，对于实际分析来说并没有太大的问题。

我这个环境的CPU_COUNT是16，而每个实例的Redo Strand最小值是2，因此启动实例的时候也启动了2个LGWR worker，这说明数据库实例有两个LGWR worker group，当系统空闲，没有什么需要写入的REDO数据的时候，LGnn都在等待空闲等待事件LGWR worker group idle，而lgwr进程在等待rdbms ipc message。搞了二十多年Oracle，从5.1用到11.2，Oracle 10G出来的时候，我就说这应该是我学习的最后一个版本的Oracle了。

谈到Oracle数据库等待事件的知识库问题。Oracle的锁实际上也是十分重要的等待事件，遇到锁的时候如何解读锁的含义，从而定位问题的原因也是DBA需要掌握的一种技巧。今天我把我们团队这些年梳理的一些知识开放出来，和大家分享。D-SMART的知识库也是这样一点点的建设起来的。这300多个锁分析的知识库是Oracle近2000个等待事件的知识库中的一个十分重要的组成部分，希望我分享的这个内容能够对大家在今后的运维工作中有索帮助。 锁名称 风险 说明

通过ALERT LOG检查发现，18:53分ZZZOSS3出现了故障，并且进行了自动重启，自动重启后，就出现了集群3个节点全部HANG住的现象。于是检查ZZZOSS3的nmon日志，发现从18:45分左右开始，物理内存空闲比例大幅度下降，并且在18:51分开始出现了大量的系统换页。晚上19点左右接到报障后，老白立即远程登录进行处理，由于当时是客户的业务高峰期，因此首要是恢复系统运行，然后再开展问题调查，消除故障隐患。DBA发现三节点的集群突然变慢，其中1号和2号节点的数据库均无法正常使用。

因为在不设置这个事件的时候，如果RMAN恢复数据文件的时候发现备份集有坏块，就会在坏块的位置写入一个空块。而设置了这个事件，不管怎样，都会将这个块写入数据文件，这可能导致不一致的产生。不过设置了这个事件也不一定能够跳过坏块恢复文件，因为一个备份集往往有多个文件，如果标志哪个块属于哪个文件的数据块坏了，那么恢复数据将变得不可能。：如果在恢复的时候还没有恢复到所需要的所有数据块，就碰到文件结束了，这个时候会报 ORA-19612,如果设置了这个事件就会忽略这个错误。为了解决这个问题，Oracle提供了两个。

准确的判断是基于对系统整体清晰的认识的基础的，没有深入的调研，没有对系统进行深入的剖析，是无法完成真正的优化的。而第二次优化不仅仅依赖于AWR提供的数据，更多的和开发团队进行了沟通，充分理解了应用软件的特点，结合AWR和应用特点，终于发现临时表和PUBLIC别名这个问题的根源，从而找到了解决问题的正确方向，很好的完成了本次优化工作。在和开发人员的沟通中，发现了一个十分重要的一点，就是应用系统在创建了一张临时使用的表后，又在上面创建了一个别名，供后续的操作使用，当临时表的数据超时时，定时。

在切换过程中出现问题，在没有分析清楚问题的情况下采用强制打开数据库的方式，导致备库中的12个数据文件在备库打开后处于OFFLINE DROP状态，和这12个文件相关的部分表无法访问。经过和相关操作人员确认，是因为主库创建新文件时，备库的裸设备不存在，从而导致在备库中生成了一个UNNAMEDxxxxxx的文件，为了将这个文件重新迁移到裸设备上，做了上述操作。由于DATAGUARD中的这些文件本身存在问题，导致这类文件处于非正常状态，在DATAGURAD切换后，无法实现这些文件的切换。有些文件甚至是空文件。

他回答是这些都没错，然后我问他网卡的顺序是否正确，在HP-UX下有时候私网和公网的网卡在两台服务器上的设备名不对应，也可能会出一些莫名其妙的错误。这下子就很明确了，估计是HP-UX的补丁没有打全，经过检查，发现GOLDQPK11i 没有打，打了补丁后，测试一下/usr/sbin/pingnode1 -n 1 -m 3 ,一切都OK了，于是再安装CRS，一切正常。那么下面该怎么处理呢？在常规方法无法找到问题的时候，使用操作系统跟踪工具对某个出问题的配置过程进行跟踪是十分有效的方法，命令去检查节点的健康性。

因为在不设置这个事件的时候，如果RMAN恢复数据文件的时候发现备份集有坏块，就会在坏块的位置写入一个空块。而设置了这个事件，不管怎样，都会将这个块写入数据文件，这可能导致不一致的产生。不过设置了这个事件也不一定能够跳过坏块恢复文件，因为一个备份集往往有多个文件，如果标志哪个块属于哪个文件的数据块坏了，那么恢复数据将变得不可能。：如果在恢复的时候还没有恢复到所需要的所有数据块，就碰到文件结束了，这个时候会报 ORA-19612,如果设置了这个事件就会忽略这个错误。为了解决这个问题，Oracle提供了两个。

到目前位置，用kfed使用常规方法修复磁盘头还是一件十分困难的事情。直到Oracle 10.2.0.5开始，Oracle也意识到了asm的这个问题，在asm metadata中保留了一个备份块，这样使用 kfed的一个隐含功能就可以实现asm磁盘头的一键修复了。ASM磁盘头故障的原因十分复杂,一般和安装与运维有关，其根本原因就是Oracle.比如在AIX平台上,如果没有清掉PVID，下次服务器重启时就可能会出现设备名混乱的问题，如果你用chdev去修改设备，那么ASM磁盘头可能会丢失。