月归档：2015 年六月

Leap Second(润秒）跟Oracle相关产品的提示

发表于 2015 年 6 月 30 日 由 Lunar

今天好多朋友都在讨论Leap Second(润秒）的问题（不少集成商和客户都收到Oracle的通告了）： Oracle官方的解释也很清晰： Oracle所有产品线关于润秒的说明： Information Center: Leap Second Information for All Products – Database – Exadata – Middleware – Exalogic – Linux – Sun – Fusion – EBS – JDE – Siebel – Peoplesoft (Doc ID 2019397.2) . MySQL也会有相应的影响，比如 NOW() … 继续阅读 →

发表在 Database | 标签为 , | 留下评论

使用DUL和ODU抽取Exadata上的oracle数据库（抽取磁盘上的数据文件）

发表于 2015 年 6 月 23 日 由 Lunar

之前研究过dul和odu，发现不能识别磁盘，当时犯了一个错误，因为普通环境（非exadata环境），都是在主机上运行扫描磁盘的工作，因此我之前也在exadata的主机上扫描磁盘，发现不行，具体参见： 在Exadata上，为什么 DUL 和 ODU不能读取ASM数据库的数据，但是Kfed却可以？ 今天在exadata的存储节点（cell节点）上配置了一下，发现dul和odu都可以直接扫描磁盘，以后有exadata上oracle数据库损坏时，请联系我，O(∩_∩)O哈哈 具体测试如下： 这里我使用control+C终止了，因为磁盘太大了，扫描时间太久，上面的信息已经可以证明，至少可以扫描 至于normal external等其他问题，以后再说。 扫描文件具体如下： 这里 IDX_DATA1.dat 就是dul扫描出来的一些信息，之后使用命令抽成文件就依据这些。 再看看ODU： 这里报错是因为cell上磁盘空间很小，稍微一折腾就满了（存放ODU抽取文件的是根，100%了）： 先别急删除，进去看看数据; 可以看到，odu也抽出了数据， 并且，可以看到，已经抽取了几个dbf的数据文件。

发表在 ASM, backup&recovery, DUL ODU, Exadata | 标签为 , , , | 留下评论

ASM NORMAL REDUNDANCY情况下，谁完成了数据的镜像IO？

发表于 2015 年 6 月 16 日 由 Lunar

前几天，一些朋友讨论ASM中，如果是NORMAL redundancy磁盘组，数据的镜像是由oracle rdbms进程完成，还是由ASM的进程完成镜像的工作。 我们知道，ASM NORMAL REDUNDANCY磁盘组类似于RAID 10的操作，也就是镜像+条带划。 . 在传统架构中，oracle只负责写入一份数据，数据保护（镜像）是由存储或者RAID卡来完成的，那么在ASM中是否也是DB完成一次写入，ASM进行同步呢？ 根据下面的测试，结论是： DB的进程完成数据库中所有应用数据的IO操作，包括镜像数据的IO。而ASM进程只负责元数据（metadata extent）的维护和IO。 . 具体测试如下： 首先，我们创建一个normal redundancy的磁盘组，用来放数据库的redo，比如 +REDODG： 这个两个磁盘的failure group的信息如下： 然后，我们使用REDODG创建了9组redo log group（这套10204的RAC的redo都放在上面了）: 这个数据库实例的LGWR进程号为 11159： 现在我们使用strace跟踪一下这个进程在数据库切换日志时的动作，如果lgwr进程只写了一个设备，比如/dev/mapper/redolun1或者/dev/mapper/redolun2，那么可以再跟踪一下ASMB进程。 . 如果LGWR进程写了两个设备，即/dev/mapper/redolun2和/dev/mapper/redolun1都写入了相应的IO，那么我们可以认为，数据库的LGWR自己完成了primary extent和mirror extent的全部操作。 这也是Oracle 文档中一直说明的一点“ASM负责ASM实例的metadata的IO，而DB完成应用实际数据的IO”。 具体跟踪文件如下： 上面的跟踪文件可以很清晰的看到，LGWR进程连续写了2分相同的数据到fd为16和17的设备上。 那么16和17是什么呢： 这里看到，16和17就是redodg所使用的两个磁盘。也就是说，LGWR自己完成了primary extent和mirror extent的IO操作。 至此已经很清楚了，那么可以我们可以推断，DBWR等数据库操作也是有DB自己的进程完成了，而ASM只负责元数据的IO操作和维护。 具体的测试，有兴趣的可以自己跟踪。 上面的跟踪信息还可以看到，实际上oracle使用AIO的方式（使用io_submit，io_getevents等），定期同步控制文件的信息，仍然是写16和17两个设备。 … 继续阅读 →

发表在 ASM | 标签为 , | 留下评论