标签归档：asm

使用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 | 标签为 , | 留下评论

收集ASM信息的脚本

发表于 2015 年 5 月 17 日 由 Lunar

当ASM中某些磁盘状态异常，比如应该是“MEMBER”的，却是“CANDIDATE”或者其他等各种盘头异常，或者ASM实例异常，可以使用下面脚本收集ASM信息（来源于MOS）

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

使用dd备份和恢复ASM中的数据文件头

发表于 2015 年 5 月 17 日 由 Lunar

今天看了飞总微博上的备份ASM中数据文件头（http://www.xifenfei.com/5888.html），觉得有意思 佩服飞总专业的钻研精神，那么多X$的internal视图……O(∩_∩)O哈哈~ 这里用大家随处可见的（除了extent分布的x$kffxp需要百度和google外），其余都是文档中有详细记载的常用ASM视图来实现同样功能：

发表在 ASM | 标签为 , | 一条评论

oracle数据块如何定位到ASM中？在exadata定位block的思路是什么？

发表于 2014 年 11 月 28 日 由 Lunar

前几天有个朋友提出一个“老问题”，数据库上的block能否对应到EXADATA的block上，我答应做个demo，一直没时间，今天闲了，玩了一下： 对于EXADATA来说，这个需求设计两个问题： 1，数据库的block如何对应到asm中 2，exadata上的block如何对应到cell上的物理盘（griddisk，celldisk都是逻辑概念） 首先创建测试表： create table lunartest as select * from dba_users; –查找里面用户名为LUNAR的ROWID: 记录一下这个表的username=’LUNAR’的数据的rowid，便于验证数据。 然后找到该表的第一个block，也就是segment header，方法至少有3种 1，通过dbms_rowid 2，通过dba_extents 3，通过dba_segments 这里我们随便选一种，找到了该block的位置： 查看当前ASM的AU尺寸和BLOCK尺寸（通常是缺省的，不排除特殊客户自己设定的或者exadata的情况，因此还是找一下）： exadata上使用KEFED的例子可以参考《Exadata上验证ASM磁盘头备份的位置》 我的数据库为8k的数据块（db_block_size），那么计算一下对应到ASM是哪一个extent: lunartest表在DATA DG的asm file 1755上： 如果是exadata，那么输出类似下面的，这里并没有本质区别（区别在通信方式上，后面会讲……）： 根据上面的计算，查找这个表的第一个数据块在哪一个ASM的diskgroup,disk和AU的信息： 如果是exadata环境，那么查询到的信息，对应到这里的/dev/lunarlun02可能就是类似下面的：o/192.168.10.3/DATA_DM01_CD_00_dm01cel01： 这里也就对应到cell01（IP为：192.168.10.3） 具体例子可以参考：Exadata更换硬盘的操作过程和解释 使用dd 我们用dd验证一下数据，： 验证数据：这个LUNARTEST是根据DBA_USERS做的CTAS，因此上面我们有一行测试数据，这里可以找到： 因为是别人的生产库，不能使用bbed等工具瞎折腾，因此，我这里使用UltraEdit查看这个块来验证数据： 可以看到数据是吻合的。至此，上面将oracle的block对应到ASM是没问题的。 另外，如果要想观察asm的具体操作，还可以使用strace，比如 read64(15, … 继续阅读 →

发表在 ASM, 内部机制 | 标签为 , , | 留下评论

使用ASM的数据库和使用文件系统的数据库在AIO上哪里不同？

发表于 2014 年 9 月 26 日 由 Lunar

昨天客户的一个重要应用切换到新的系统环境上，今天观察，发现部分异常等待： 从OS的CPU负载来看，定期会出现一个峰值，从ASH中可以看出，这个峰值对应的等待事件跟AWR的完全吻合。 因此，主要怀疑两个东西： 1，应用的SQL和对象的属性（比如table或者index的统计信息，并行度等等……） 2，系统的AIO设置 上面的第一条，已经提交给开发相应的SQL和其他信息 第二条，因为系统以前是11.2 RAC，使用了ASM，而现在是单机文件系统. 因此对比了这两种环境下AIO的异同，结论如下： 1，Linux下，ASM数据库和文件系统数据库的AIO设置差别： (1). ASM的AIO属性是不受 FILESYSTEMIO_OPTIONS 参数的影响（因为ASM会绕过文件系统buffer），只跟DISK_ASYNCH_IO有关系 (2). 文件系统的AIO属性跟 FILESYSTEMIO_OPTIONS 和 DISK_ASYNCH_IO 都有关系 2，FILESYSTEMIO_OPTIONS=NONE ： Bug 6733627 – Unaccounted Wait Time on “Direct Path” operations with FILESYSTEM_IO_OPTIONS=NONE (Doc ID 6733627.8) 3， db file … 继续阅读 →

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

ASM disk和diskgroup等使用的限制

发表于 2014 年 5 月 9 日 由 Lunar

11.2 ASM磁盘和磁盘组的限制如下： Oracle ASM has the following limits on the number of disk groups, disks, and files: 63 disk groups in a storage system 10,000 Oracle ASM disks in a storage system 1 million files for each disk group Without … 继续阅读 →

发表在 ASM | 标签为 , , | 一条评论

Exadata的数据保护机制（冗余机制）-4-ASM PST

发表于 2014 年 3 月 17 日 由 Lunar

Exadata的数据保护机制（冗余机制）- 1 Exadata的数据保护机制（冗余机制）- 2 Exadata的数据保护机制（冗余机制）- 3- Failure Group 为了补充前面两篇的一些概念，这里，我们简单介绍下ASM的PST。 我们知道，asmfile extent是分布在多个磁盘之间，称为partner，Partner disk会存放在一个或者多个分离的failure group上。ASM自动选择Disk partner并限制其数量，这是受隐含参数”_asm_partner_target_disk_part”控制的。在10g中，每盘都会存在最多10个Disk partner，而在11gR2中每盘都会存在最多8个Disk partner。ASM会自动创建和维护Partner关系，如果磁盘损坏（failure），那么ASM会更新其extent map使今后的读取操作指向剩余的健康的partner。 对于external redundancy 的磁盘组，每个磁盘组只有一个PST table，对于normal redundancy 的磁盘组，每个磁盘组有3个PST table，对于high redundancy 的磁盘组，每个磁盘组有5个PST table。 . PST的信息是由GMON进程维护的。PST 包含了一个磁盘组中ASM disk的状态信息：disk number，status（online or offline），partner disk number，heartbeat的信息，11g的ASM中，PST 还引包含了failure group的信息。因此，ASM根据PST(Partner Status Table)的信息就知道哪个盘的partner是offline状态的。 … 继续阅读 →

发表在 ASM, 体系架构, 内部机制 | 标签为 , , | 留下评论

Exadata的数据保护机制（冗余机制）- 3-Failure Group

发表于 2014 年 3 月 17 日 由 Lunar

Exadata的数据保护机制（冗余机制）- 1 Exadata的数据保护机制（冗余机制）- 2 为了补充前面两篇的一些概念，这里，我们简单介绍下ASM的Failgroup。 ASM提供了3种冗余方法。 EXTERNAL，即ASM本身不做镜像，而依赖于底层存储阵列资深实现镜像；在External下任何的写错误都会导致Disk Group被强制dismount。在此模式下所有的ASM DISK必须都完好，否则Disk Group将无法MOUNT。 . NORMAL， 即ASM将为每一个asmfile extent创建一个额外的拷贝以便实现冗余；默认情况下所有的asmfile都会被镜像，这样每一个asmfile extent都有2份拷贝。若写错误发生在2个Disk上且这2个Disk是partners时将导致disk Disk Group被强制dismount。若发生失败的磁盘不是partners则不会引起数据丢失和不可用。 . HIGH， 即ASM为每一个asmfile extent创建两个额外的拷贝以便实现更高的冗余。2个互为partners的Disk的失败不会引起数据丢失，当然，不能有更多的partners Disk失败了。 数据镜像依赖于failure group和extent partnering实现。 . ASM在NORMAL 或 HIGH 冗余度下可以容许丢失一个failure group中所有的磁盘。 . 下面我来详细说下，Oracle如何通过failure group来提供数据的高可用性。 首先，ASM使用的镜像算法并不是镜像整个disk，而是作extent级的镜像。ASM会自动优化文件分布以降低设备故障造成数据丢失的可能性。 在normal redundancy模式下，ASM的按照extent进行striping时是在一个DiskGroup中完成的（即，在一个DG的2个Fail group之间完成的，而不是一个单独的FG中完成），ASM环境中每分配一个extent都会有一个primary copy和一个secondary copy，ASM的算法保证了secondary … 继续阅读 →

发表在 ASM, 体系架构, 内部机制 | 标签为 , , | 留下评论

在Exadata上，为什么 DUL 和 ODU不能读取ASM数据库的数据，但是Kfed却可以？

发表于 2014 年 3 月 15 日 由 Lunar

普通的dul在exadata上是不能读取 cell 节点的数据的： 这里很清晰看到DUL报错了“OS error 2: No such file or dire”和“DUL: Error: “, 12″，由于篇幅关系，这里我就不贴前台DUL的报错界面了，这个trace已经很清晰了。 那么，我猜ODU也是同样的采用传统的read和write的方式读取数据的，跟踪一下，主要内容如下： 我们看到，ODU读取了配置文件：“write(1, “load asm disk file ‘asmdisk.txt’”…, 44) = 44” 然后根据配置文件中的信息直接读取磁盘内容。 很明显，这种情况下ODU还是直接根据文件路径读取信息，那么在Exadata上，自然是搜索不到的。 因为，Exadata上，数据是放在cell上的，db节点调用 libcell11.a 并通过 socket 的方式通信。 但是kfed可以读取cell的数据，具体方法参见 Exadata上验证ASM磁盘头备份的位置 我跟踪了一下kfed读取cell上数据块的过程，大致如下： kfed打开socket，并读取/etc/nsswitch.conf来进行域名解析： kfed 读取自己的fd（/proc/self/fd/），fd是linux系统上进程的文件描述符： kfed 读取 ADR … 继续阅读 →

发表在 内部机制 | 标签为 , , , , | 一条评论