场景3： dd现有设备损坏，ASM Instance Crash
一、故障现象模拟：
（1）添加一块现有磁盘，命名为DATA05，加入ASM-DISKGROUP后报错重复设备：
（2）因怀疑DATA05别名对应设备与系统现有设备重复，并且没有设别到DATA04已有数据，对DATA04进行dd操作：
dd if=/dev/zero of=/dev/HUA_LUN5500f_DATA05 bs=4k count=1
（以上命令生产系统中请慎重操作）
![ASM3-1-1](http://albertdba.com/"wp-content/uploads"/2019/06/ASM3-1-1.png)
场景实验（2）一块设备对应两个别名：
本次实验模拟同一个块设备对应两个不同别名，如果新添加的磁盘误操作为此种情况不会造成恶劣的影响，如果生产系统中将已有设备覆盖（新添加磁盘与已有磁盘名称重名），会造成操作系统设备识别不到已有设备，非Normal以上冗余造成数据丢失。
一.故障现象重现：
（1）编辑配置文件，将同一设备设置成不同别名。
![ASM2-1](http://albertdba.com/"wp-content/uploads"/2019/06/ASM2-1.png)
因负责运维的数据库多为ORACLE RAC+ASM（UDEV）架构，随着业务规模不断扩容，数据库存储已经成为数据库服务资源交付主要瓶颈环节。对于数据库运维团队来讲，除去依照业务行为提前规划数据库存储用量之外，数据库ASM添加存储磁盘工作也是DBA工作中的家常便饭，因此工作风险较大，也较为常见，所以计划分享下UDEV配置错误导致的ASM磁盘组故障及恢复案例，供大家参考。
测试三种情况：
场景（1）模拟不同设备对应一个别名
场景（2）一块设备对应两个别名
场景（3）dd现有设备损坏，ASM Instance Crash
RAC 3节点 external冗余,（测试环境,Nomral以上冗余有点奢侈）测试环境：
测试磁盘：
![ASM-测试磁盘](http://albertdba.com/"wp-content/uploads"/2019/06/ASM-测试磁盘.png)
测试环境磁盘初始状态：
![ASM-初始状态](http://albertdba.com/"wp-content/uploads"/2019/06/ASM-初始状态.png)
前几日刚到公司一大早，接到值班人员的微信，应用反馈前一晚22:00左右应用报大量无法请求到数据库连接的错误，让咱们帮忙看看，应用邮件中描述非常“捉急”，看来是报错影响不小，我立马打起精神，准备好好分析一波。
（1） 登陆系统，生成AWR报告
![一个应用无法获取新连接案例](http://albertdba.com/"wp-content/uploads"/2019/06/一个应用无法获取新连接案例.png)
故障时间段，此数据库经历了大量Library Cache Lock与Cursor pin s wait on x等待事件，数据库因Library Cache Lock与Cursor Mutex资源瓶颈，阻塞大量活动会话，导致应用无法获得新的数据库连接
周四接到值班同事的电话求助：”应用反馈一套数据库写入严重缓慢“ ，放下电话立即登录系统查看数据库状态，发现该数据库正在经历严重的IO类等待事件，enq:HW-contion,log file sync,log file parallel write,buffer busy wait(非IO类等待事件，但为受害者)，gc相关等待事件（非IO类等待事件，但为受害者）。
![direct path read](http://albertdba.com/"wp-content/uploads"/2019/06/direct-path-read-e1561183577274.png)
崔华老师DBSNAKE博客摘取官方解释（http://www.dbsnake.com/）：
a. This event manages library cache concurrency. Pinning an object causes the heaps to be loaded into memory. If a client wants to modify or examine the object, the client must acquire a pin after the lock.When a process pins an object data heap that is not in memory, the process can determine whether the data heap is to be loaded in the PGA or SGA. An object must be pinned in Exclusive mode if it is to be modified.However, the process first will always pin the object in Share mode, examine it for errors and security checks, and then, if necessary,(such as needing modification) pin it in Exclusive mode. An object is never pinned in Exclusive mode if only read access is required. This is because all dependent transient objects (cursors) are invalidated (null locks broken) when an object is unpinned from Exclusive mode. The effect would be unnecessary recompilation and reparsing of all dependent packages, procedures, and functions. If the process wants to actually examine or modify the object, then it must acquire a library cache pin on the object data heap itself (after acquiring a library cache lock on the library cache object handle). Pinning the object causes information about the object and its data heaps to be loaded into memory if they were not already there. This information is guaranteed to remain in memory at least until the pin is released. Locks and pins are externalized in X$KGLLK and X$KGLPN, respectively.
Library Cache结构为一组HASH_TABLE，当SQL进行解析时将SQL_TEXT（SQL文本）进行HASH运算后生成HASH_VALUE，将运算出的HASH_VALUE与HASH_BUCKET值进行匹配（找到相同HASH_VALUE的BUCKET），然后每个HASH_TABLE一个条目中链接了一个双向链表，链表上的存放的便是Library Cache Object Handles(recr类型的Chunk), Handle下挂载的便是Library Cache Object(Heap 0，Heap 6等) 。
SQL解析时，利用HASH_VALUE遍历HASH_TABLE中匹配的的句柄对象，包括扫描父游标句柄并通过父游标句柄找寻子游标句柄与子游标heap 0,heap 6(sql执行计划) ，这样一来便可以判断用有何种解析方式解析目标SQL，是父游标无法匹配的硬解析或子游标无法共享的硬解析、能够共享SQL Cursor的软解析，软软解析。
然而，在生产OLTP系统中，SQL解析与执行阶段会申请各种Latch与Mutex来保护高并发的请求与内存中Library Cache Object的一致性，也就意味着串行操作一定会申请、持有，等待各种Library Cache中的资源。