标签归档:asm

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

之前研究过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?

前几天,一些朋友讨论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信息的脚本

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

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

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

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

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

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

前几天有个朋友提出一个“老问题”,数据库上的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上哪里不同?

昨天客户的一个重要应用切换到新的系统环境上,今天观察,发现部分异常等待: 从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等使用的限制

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

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

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却可以?

普通的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 … 继续阅读

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