标签归档：asm

Exadata更换硬盘的操作过程和解释

发表于 2014 年 3 月 13 日 由 Lunar

在巡检时，发现cell的alert有如下告警： 我们注意到有这样的信息，就表示磁盘有损坏的情况，结合sundiag信息，可以发现磁盘确实损坏，需要更换。 另外，此时也可以通过直接看机柜，该磁盘为闪蓝色灯，表示进行拔出的操作了。 关键信息： SEAGATE Model Number : ST360057SSUN600G Serial Number : E0P387 Slot Number : 9 Cell Disk : CD_09_dm01cel02 换盘前，我们一般作比较细致的检查： 1.在db节点上grid用户登录，这是要确认一下asm disk是不是被drop掉。drop掉就可以直接更换，如果没有，就需要手动去drop了。 这里表示磁盘celldisk：CD_09_dm01cel02已经被ASM自动删除了，且当前没有正在运行的rebalance操作。 2. 在相应的存储节点（dm01cel02）上进行确认检查： 确认物理盘状态： 这里发现磁盘的报错信息跟alert是一致的： 磁盘的物理位置和编号如下： 我们这里是HDD9损坏。 此时从机柜边上观察，如果磁盘闪蓝灯则可以直接拔出，如果是闪橘色灯，那么需要手工关闭这个磁盘设备，然后再拔出： alter physicaldisk 20:9 serviceled off 更换完成后需要检查： 1，磁盘的LED指示灯变为绿色 2，确认新换盘的celldisk，griddisk状态是normal … 继续阅读 →

发表在 日常运维 | 标签为 , , , , , , | 留下评论

看图说话——ASM实例和ASMB进程

发表于 2014 年 3 月 9 日 由 Lunar

先看一下ASM实例的大体部署： 我们都知道，ASM实例管理着元数据，普通数据库实例通过查询元数据的信息来访问相应的ASM文件。 ASM实例和数据库实例都可以访问一组普通的磁盘，这套磁盘被称为磁盘组。 然后，数据库实例直接访问ASM文件的内容，并在与ASM实例通信时获取有关这些文件的分布信息。 Group Services用于注册数据库实例查找ASM实例时所需要的连接信息： Group Services用于注册数据库实例查找ASM实例所需要的连接信息。 当ASM实例mount一个磁盘组时，它就将磁盘组的信息和连接串注册到Group Services。 数据库实例知道了磁盘组的名称，就可以找到应该连接到哪个ASM实例。 ASM实例有哪些独特地方： 1，INSTANCE_TYPE = ASM 2，startup = startup mount(11.2以后，可以直接对ASM实例 startup，但是本质还是startup mount)，对于ASM实例，mount选项不会去mount数据文件，而是mount在参数文件中ASM_DISKGROUPS指定的磁盘组 3，connect / as sysdba(10g) 和 connect / as sysasm(11.2) ASM的后台进程有很多，具体可以参考reference中的描述，这里只想研究一下数据库和ASM之间负责心跳机制的ASMB进程。 我们知道ASMB进程实际上是提供了一个数据库实例和ASM实例之间通信的桥梁，比如在数据库中创建、删除文件，或者修改文件等等的跟存储物理变化相关的操作。首先，我们观察下，他们在CRS,ASM和数据库启动过程中的启动顺序和先后关系： ASM的alert： DB的alert： ASM和数据库实例的ASMB进程都分别将信息注册到css中，参看ocssd.log: 这里，数据库启动时，ASMB的活动过程： 1，ASM实例的ASMB进程启动(spid: 3637，asm_asmb_+ASM1) 2，ASM实例的ASMB进程启动了一个连接到ASM实例的进程（spid：3641，oracle+ASM1_asmb_+asm1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))） … 继续阅读 →

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

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的信息

发表于 2013 年 11 月 1 日 由 Lunar

当ASM出现故障时，需要收集的主要信息如下（来自于MOS，log SR时，通常让你提供alert，trace和这些信息），

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

结合event 10046跟踪ASM的所有操作

发表于 2013 年 11 月 1 日 由 Lunar

关于ASM的限制，请参见 ASM – Scalability and Limits (Doc ID 370921.1) 有朋友说12.1上已经可以创建2T的文件，事实上，在很多时候，我们还是不建议这样使用，bug依然存在，维护还是问题。。。。。 例如： Bug 14181123 ROOT.SH HANGS ON OHASD.BIN REBOOT Bug 16565325 ASM FILE CREATION PERFORMANCE REGRESSION 当你碰到ASM的一些报错或者bug，怎么去检查问题呢？ 前面已经说过使用DBI_TRACE去trace asm的过程，这里再说下，结合event 10046去诊断问题。 比如一个场景，客户反映在ASM上创建表空间很慢，或者cp很慢，或者其他。。。。。很慢的问题，那么首先我们先设置 DBI_TRACE=1 来跟踪ASM的内部操作： 这里你可以看到ASM的每一个操作的详细的执行情况 然后，我们设置event 10046来跟踪该进程的执行情况 例如，我们将 +ASMDATA/RACDB/datafile/USERS.259.814462681 复制到/home/grid/asmfile 现在我们使用tkprof进行格式化： 可以看到，trace中显示了每一步我所执行的操作映射成ASM内部操作的过程和执行计划，时间等等详细信息，根据这个，不难找出瓶颈或者问题了吧，O(∩_∩)O哈哈~

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

基于scn恢复ADG和ASM在rman备份恢复过程中的tuning

发表于 2013 年 10 月 18 日 由 Lunar

以下过程主要涉及如下3个问题： 1，根据SCN号“重做”ADG 2，主库是ASM数据库，使用了一半自动命名文件名的文件，和一部分手工指定文件名（别名）的文件： ——————————————————————————– 针对OMF的数据文件使用下面命令： catalog start with ‘+DATA1/MUM/DATAFILE/’; 针对非OFM的数据文件使用下面命令： catalog datafilecopy ‘<File-Specification>’; ——————————————————————————– 3，优化ASM的IO效率 源库： 备库： 查看主库force logging： 查看有哪些文件含有force logging操作，以及他们的scn（下次执行，应该带上orderby，这样更清晰）： 备库： 生成批量的backup命令，进行基于scn的恢复（含有force logging的都需要） 主库，备份可以有两个方法： 1，根据上述备份命令写备份脚本 2，从最早的一个scn开始备份也可以 restore 数据文件： 总共新增加了3个文件，重新备份这3个文件即可： 现有ASM的文件信息如下： 有两个错误，这个是因为上面操作时没有注意到数据库中有2个offline的数据文件，下次操作记得备份时把offline的文件不要备份就好了。。。。。。 <bold>开始recover database，这个过程非常慢长，主要原因： 1，存储着实太差了。。。。。。 2，网络速度太差了（这个是NFS的空间） 3，ASM在recover 时需要tuning </bold> 监控rman恢复进度： … 继续阅读 →

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

Linux误删除文件并且数据库crash后恢复

发表于 2013 年 8 月 21 日 由 Lunar

我们都知道误删除文件后，如果没有其他操作，且数据库没有crash（句柄还在），那么是可以通过fd找到文件进行数据库恢复的，具体可以参考以前的文章：linux 误删除文件恢复 那么，如果句柄已经释放（比如数据库crash了），且客户重启了数据库，并执行了一些“恢复”尝试，然后怎么办？ 我们测试下，这里我们要借助一个小工具：ext3grep 该工具可以在下面的网址下载最新版： http://code.google.com/p/ext3grep/downloads/list 系统必须要有e2fsprogs-libs，否则安装ext3grep的时可能会有问题。 如果你下载了rpm包，那么安装so easy: 如果你下载了src的源码，那么可以如下方式安装： 我们看下他的帮助，还是很强大的： 模拟数据库文件被误删除，且数据库crash： 数据库启动报错，丢失了文件 ‘/oradata/orcl/users01.dbf’。 现在使用ext3grep进行扫描和恢复： ext3grep是针对ext3文件系统的（ext2单有自己的扫描恢复工具），确认丢失的文件是ext3文件体系: 这里，我的数据文件都在/oradata，是设备 /dev/sdc1 ： 注意这里，我的数据库目录的inode是 4358145 ，下面我们开始从这个inode继续查找： 文件的inode已经被覆盖了 这里根据两个两个信息进行恢复文件的操作： （1）数据库报错告诉我们需要恢复的文件名称：/oradata/orcl/users01.dbf （2）ext3grep的提示信息告诉我们了从哪里开始写文件： Inode 4358145 is directory “orcl”. 恢复过程如下： 从上面提示我们看到了文件已经恢复出来了，放在 orcl/RESTORED_FILES 下面： 完了不行了，被覆盖了。。。否则这一步就会在当前执行ext3grep的目录下找到一个RESTORED_FILES目录，里面就是我们的user01.dbf文件，再之后，你懂的。。 把他copy到/oradata/orcl/users01.dbf，然后执行recover datafile ‘/oradata/orcl/users01.dbf’，在open，就ok了。。。 我们再测试另一个工具extundelete（感觉原理跟ext3grep一样），看看他是不是强大一些，o(∩_∩)o … 继续阅读 →

发表在 backup&recovery | 标签为 , , , , , | 留下评论

expdp导出数据到asm中

发表于 2013 年 8 月 10 日 由 Lunar

asm中创建目录 数据库创建目录 expdp导出数据到asm 检查expdp导出文件 补充说明 如果有rac，可以使用cluster=y，parallel=10…………这样就在整个集群parallel，在xd就用dbfs，本质就是这个原理的

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

mkdir在asm中做了什么？

发表于 2013 年 8 月 10 日 由 Lunar
发表在 ASM | 标签为 | 留下评论

asmcmd中cp文件的测试

发表于 2013 年 8 月 10 日 由 Lunar

[grid@lunar ~]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.1.0 Production on Fri Aug 9 15:59:23 2013 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 – 64bit Production With the Automatic Storage … 继续阅读 →

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