标签归档：kfed

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

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

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

发表于 2014 年 3 月 3 日 由 Lunar

我们都知道，从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损坏的修复过程

发表于 2013 年 6 月 16 日 由 Lunar

一大早起来折腾昨天的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 | 标签为 , | 一条评论