1.操作系统版本：Linux node2 2.6.32-642.4.2.el6.x86_64 CentOS release 6.7 数据库环境版本：oracle 11g r2 11.2.0.4 rac+asm+dg，以下为节点1 节点2的报错部分信息
1.1节点1报错信息如下：
注：
1.TNS适配协议期错误、连接失败应该是常规报错中经常出现的，产生报错情况多种多样，由于22号下午三点更换的防火墙代理程序，故Client在default 60秒内没有完成认证，连接失败是
相对比较正常的事情。
2.第二个原因是当时oracle负载非常高，所以连接超时失败，暂时不考虑在sqlnet.ora设置SQLNET.INBOUND_CONNECT_TIMEOUT方式处理，这里主要探讨TNS-12535另外一种情况的，结合本案例
的深入分析。
TNS-12535最早报错时间是2017-11-22 20:44:50.816000 +08:00在节点1，结合oracle mos文档，描述TNS-12535报错情况，给出如下解释：在共享服务器连接模式当中，如果SHARED_SERVER
参数设置过小或不足，如果没有空闲的shared server进程可用，那么通过共享服务器模式连接到数据库的连接请求就会失败， TNS-12535错误就会出现dispatcher trace文件中，表明disp
atcher队列中的请求超时，实际生产环境，我们只看到一笔trace文件，对应官网需求，关注一下shared parameter参数设置情况
确实是设置过小，做如下操作改变共享池连接大小：
摘抄官方mos文档的一段描述：
在共享服务器模式中，当并发工作的ACTIVE SESSION数大于max_shared_servers参数时，就不能在增加新的shared server processes，新的session请求就会得不到空闲的shared server processes的响应，dispatcher进程无法为会话分配一个服务器端进程（shared server perocesss）也就会出现数据库连接不上的现象。最后出现超时现象
-----------------------------------------
3.分析节点1ORA-600[kjbrasr:pkey]报错信息：
3.1此报错主要是由于LMS进程因为DRM操作而引发bug，解决办法比较简单，通过禁用DRM方式，但是目前我无法评估禁用DRM 对于整体性能的影响DRM 特性可以一定程度上优化数据库性能，
但是对于没有分区或分schema 的应用程序而言 DRM并不会带来好处。 Oracle 官方推荐在BRM应用程序 上 要禁用DRM特性对应Docuemnt id 1319678.有详细说明。
3.2具体停用方式可以通过设置“_gc_policy_time=0，设置 _gc_read_mostly_locking= False，这里需要注意设置 _gc_read_mostly_locking= False可以避免replayed lock 大量传输，
官方给出的解释口径为，设置此参数可以减少LMS触发bug的可能性。
3.3分析trace日志情况：
3.3续：通过systemstate的wait chains可以看到，等待lms进程动态重设和重新配置ges过程，等待客户端和服务端交互过程，同时等待gcs资源目录切换，没有阻塞的blocking process
3.4关注Bug 17215647 - ORA-600 [kjbrasr:pkey] in LMS during instance recovery of DROP/TRUNCATE operations (文档 ID 17215647.8)文档，ora - 600[kjbrasr:pkey]可以在RAC的
LMS中出现，trace里绘描述pkey/objd的错配错误，在实例恢复期间执行删除/截断操作。下面.对oracle rac DRM做一个简短的概念说明：在Oracle 10g版本中开始提出了DRM特性默认情况下，当某个对象的被访问频率超过某阈值，并且在某一节点的访问远高出其他节点，而同时该对象的master又是其他节点时，
那么Oracle则会触发DRM操作来修改master节点。DRM的好处是通过动态修改资源的主节点，大幅度降低某些场景下的gc rac类型的等待事件带来的性能瓶颈。但通过Mos查询，发现DRP的bug
简直就是比比皆是，各种奇怪的数据库故障。下面我们来看一下rac数据库在昨天20:30到23:30之间的gc current request等待事件情况：
案例分析：从LMD进程的trace文件中看到的确出现了DRM事件，trace文件中看到有日志：Rcvd DRM(36333) READMOSTLYTransfer pkey 519282.0 to 1 oscan 0.1。随后就出现了”gc currentrequest”、
”log file switch(checkpoint incomplete)”这样的等待事件。总结来说，看到的等待现象都是表象，问题的根源是数据库进行了DRM资源的动态调整，DRM会造成各种bug问题，现在的问题是
如果是DRM造成的gc current request等待，那么前面出现的等待log file switch(checkpoint incomplete)就容易解释了。因为drm造成的问题会导致整个数据库freeze。
根据Bug12998795 - RAC hang with signature 'gc current request'<='gc buffer busyacquire' (Doc ID 12998795.8)文档描述，提供的soloution中让我们尝试设置不受支持的隐含参数："_gc_read_mostly_locking"=FALSE
"_gc_bypass_readers"=false，具体解决办法如下：
1.关闭数据库DRM功能 彻底关闭需要修改_gc_policy_time=0参数，但是需要重启数据库，暂时不考虑
2.线上调整，在线调整参数_gc_policy_minimum=1000000 ，_gc_affinity_ratio=1000000，使其达不到设置的值，做到在线关闭DRM
3.验证DRM是否关闭，可以v$policy_history，关注affinity统计信息
---------------------------------------------
4.节点2报错分析：
4.1ORA-00600[kcbnew_3] [a] [b] [c] 是Oracle 9i 9.2之后引入的新的块检测机制。一个存有数据块的cache buffer在被重用的过程中，buffer的状态为state且数据为temp或undo。 oracle一致性
检查比较了buffer header的block class和传递给调用者的block class并发现不一致
4.2结合mos文档，ORA-00600[kcbnew_3]的三个参数随着版本的不同有几种解释：
oracle 11.1和之后：
ORA-00600: internal error code, arguments: [ktspffbmb:objdchk_kcbnew_3], [0], [148155], [4], [], [], [], [], [], [], [], []
[a] 内存循环计数器，实际是新初始的块的数目
[b]代码层面访问该cache的object id
[c] flag定义该buffer使用的特点
根据MOS文档给出的解释，该ORA-600 [kcbnew_3] 属于内核内存buffer管理使用，其影响可能导致进程失败、SQL执行失败，但不会造成2次数据损坏
4.3解决ORA-00600:[kcbgcur_3]遵循官方NOS文档 ，kcbgcur_3这个函数出现ORA-00600错误一般是告诉我们，当一个状态为”CURRENT”的cache buffer中存放的是程序所预期的数据地址，即TABLESPACE号和相关DBA(RDBA)，但Oracle却发现这个block并不属于一个预期的OBJECT(实际是发现了不同的Data_object_id)。
4.4严格意义来讲不应该属于一个物理或者逻辑的坏块，就好像ORA-08012一样，这一般说明是数据出现了逻辑上的误差，造成这样报错的可能原因有：
严重的写丢失Lost Write造成逻辑上的不一致
Oracle自身bug造成的逻辑上的不一致
------------------------------------------------------
5.最后我们来看一下trace文件中数据库对象的状态情况：
Xid：事务id，在回滚段事务表中有一条记录和这个事务对应
Uba：回滚段地址，该事务对应的回滚段地址
第一段地址：回滚数据块的地址，包括回滚段文件号和数据块号
第二段地址：回滚序列号
第三段地址：回滚记录号
以上dump信息我们可以看到对应事务id持有对象地址正在被scn占用，锁定级别为2，表示row-S (SS)锁定模式
再看该trace的buffer header内容
1.0x68be20a538是BH的哈希值，对应15号数据文件，rdba: 0x03ea301b (15/2764827)表示rowid中的相对文件号，可以通过如下命令获取十进制数：
SELECT dbms_utility.make_data_block_address(15,2764827) from dual;--65679387
2.class:表示buffer header对应block的类型，1表示data block ba: 0x68b071c000表示BUFFER中block address，是块在内存中的物理地址
3.pool: 3 bsz: 8192 表示块大小
4.obj: 148155块上数据对应在哪个对象里
5.tch: 1 buffer 的访问次数
6.flags: block_written_once redo_since_read
flag中，每位代表如下含义：
0 buffer_dirty 14 stale
1 notify_after_change 15 deferred_ping
2 mod_started 16 direct_access
3 block_has_been_logged 17 hash_chain_dump
4 temp_data 18 ignore_redo
5 being_written 19 only_sequential_access
6 waiting_for_write 20 prefetched_block
7 multiple_waiters 21 block_written_once
8 recovery_reading 22 logically_flushed
9 unlink_from_lock 23 resilvered_already
10 down_grade_lock 25 redo_since_read
11 clone_being_written 29plugged_from_foreign_db
12 reading_as_CR 30 flush_after_writing
13 gotten_in_current_mode
7.全局缓存dump信息内容依托于以上单节点buffer header内容，以独占模式持有该buffer的rdba,并在与此全局缓存元素相关的缓冲区列表中继续追加，追加方式基于BH的哈希值
GCS SHADOW 0x5fdf777fd0,4 resp[0x7f2a7c380,0x2a301b.f] pkey 148155.0
这里可以看到pkey指向了这个148155数据库对象
----------------------------------------------
6.orcl2_ora_35820_i593923.trc文件分析
这部分内容可以参考关于library cache 分析情况，我的另一篇文章，20170921_ORA-600_ktspgfb-1_如人饮水冷暖自知
20170729_ORA00600kghsskins1_如人饮水冷暖自知
20170729_ORA00600kghsskins1_如人饮水冷暖自知
20170727_ORA00600_12333_如人饮水冷暖自知
20170625_ORA00600报错解决_如人饮水冷暖自知
--------------------------------------------------
