标签归档:asm

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

在巡检时,发现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进程

先看一下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磁盘头备份的位置

我们都知道,从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的信息

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

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

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

关于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

以下过程主要涉及如下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后恢复

我们都知道误删除文件后,如果没有其他操作,且数据库没有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中

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

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

mkdir在asm中做了什么?

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

asmcmd中cp文件的测试

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