标签归档:kfed

在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 … 继续阅读

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

Exadata上验证ASM磁盘头备份的位置

我们都知道,从Oracle 10.2.0.5开始,ASM磁盘会自动备份磁盘头块,备份块的位置在第2个AU的倒数第2个块上。 通常,缺省情况下,AU SIZE是1M,每个AU可以有256个block(每个block 4k),256*4k()=1M 因此,第2个AU同样存放了256个block(0~255),其备份块的位置为 au=1 blkn=254(au和block都是从0开始计数的) 具体的恢复案例,可以参考: ASM磁盘头被fdisk损坏的修复过程 那么在exadata上,缺省的AU是4M,也就是每个AU可以存储 1024个block,即 block 0 ~ block 1023 那么第二个AU的倒数第二个block就是 au=1 blkn=1022 ( au和block都是从0开始计数的 ) 我们来检测一下是不是这样: 注意: 这里kfed命令中,需要指定ausz=4m,否则kfed缺省按照1M来计算,那么结果就是错误的了: 在kfed中指定ausz=4m,检测结果: 经过检查,我们发现,这个规律在exadata上依然有效,ASM除了缺省4M的AU,其余没什么变化,O(∩_∩)O哈哈~ 顺便介绍一个小方法,快速计算备份块的位置:(该方法根据ASM Support Guy修改而来)

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

ASM磁盘头被fdisk损坏的修复过程

一大早起来折腾昨天的12c(我装的是standalone),发现使用文件虚拟成设备的方法,磁盘IO效率很低(我猜是这个原因),于是铲掉打算重新安装 铲掉12c RAC跟铲掉11.2 RAC没啥区别,参考前面的文章 5分钟内搞定。 安装完grid,感觉磁盘不够用,于是把vm停了,加一块新的盘,然后启动后,fdisk /dev/sde 悲剧了,刚弄完就想起来,这个是ASM的DATADG…………于是,你懂的…… 查看日志,ora.DATA.dg 资源状态异常: 使用kfed可以清晰的看到,盘头损坏了: 在ASM中也可以看到,/dev/sdb原本是DATA DG的设备(HEADER_STATU应为 MEMBER),现在确变成“CANDIDATE”: 我们知道,每个ASM磁盘的UNIT 1,块254(Allocation unit# 1, Block# 254)是盘头的备份,因此查看下,这个块是否是好的: 手工把ASM磁盘组DATA挂载上: 好了,可以安装db软件,然后建库了…………

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