分类目录归档:ASM

Oracle 12.1 RAC 系列-安装新主机,识别老存储和恢复数据库

在11.2中模拟主机损坏,使用重新安装新主机识别老存储并恢复数据库。 11.2 RAC 系列-安装新主机,识别老存储-1-识别ASM磁盘 11.2 RAC 系列-安装新主机,识别老存储-2-准备识别数据库 11.2 RAC 系列-安装新主机,识别老存储-3-配置老存储的数据库 这里的测试也同样是模拟主机损坏,安装新主机识别老存储来恢复数据库,不同之处在于,这里假设老存储的ocr和vf是保存在单独的crsdg的,客户没有新的磁盘来创建新的crsdg,因此,我们需要将最前面的3块盘(除去sda后,是sdb~sdd)使用dd清除其前面50M的数据,然后用这3块盘组成后续安装GI时的CRSDG。 别的过程几乎都一样,添加数据库资源的时候,注意一下12.1跟11.2的命令不同,尽管12.1中如果使用11.2的添加数据库的命令也可以执行,并且没有报错信息(貌似兼容),但后续使用时可能会有问题,比如在ocr中识别的dbunique的信息是不正确的。 . 具体步骤如下(因为先在12.1中测试,然后才在112.测试,因此这里的测试记录了发现的一些问题和处理方法,而11.2中模拟主机损坏,直接使用了这里的经验,因此没有任何报错信息): 1,安装12.1.0.2的GI软件,如果需要也apply最新的PSU,然后查看磁盘和磁盘组: 创建ASM的spfile 查找spfile: 这里看到有两个spfile,哪一个是我们需要的呢? 或者如果这个存储上有多个数据库时,怎么确定哪个数据库使用哪个spfle? 我们知道ASM内部是使用OMF管理数据文件的,因此,它的命名规则是: 因此,根据dbuniquename我们就可以确定哪个数据库使用哪个spfile。 +group/DB_UNIQUE_NAME/file_type/file_type_tag.file#.incarnation# 文件类型是datafile, controlfile, onlinelog等等 我们将spifle从ASM中复制到文件系统,然后查看其中信息是否正确: 查看spfile 这时,启动是数据库会报错: alert中报错如下: 根据报错信息,我们知道,是因为oracle没有访问asm磁盘组的权限造成的,因此需要修改oracle权限: 再次mount数据库,依然报错: 报错信息如下: 具体的trace文件如下: 这里看到,应该是数据库还是不能访问磁盘组,将磁盘组注册到ocr中的过程如下: 再次查看,ocr中已经包含了这些磁盘组 将数据库注册到ocr中: 在12.1中如果沿用11.2的配置数据库命令,那么数据库可以启动,但是可以发现配置信息是有问题的: 例如,“Database name: lunarrac”这里显示lunarrac是我的主机名,而数据库名是lunar,因此使用112.的命令注册数据库到ocr会有其他未知问题 … 继续阅读

发表在 ASM, ORACLE 12C, RAC | 标签为 , , , | 留下评论

11.2 RAC 系列-安装新主机,识别老存储-3-配置老存储的数据库

11.2 RAC 系列-安装新主机,识别老存储-1-识别ASM磁盘 11.2 RAC 系列-安装新主机,识别老存储-2-准备识别数据库 11.2 RAC 系列-安装新主机,识别老存储-3-配置老存储的数据库 Oracle 12.1 RAC 系列-安装新主机,识别老存储和恢复数据库 安装Oracle 11.2.0.4数据库软件,然后执行root.sh,这个没有特别的东西,略。 之后,我们需要修改ORACLE RDBMS的oracle二进制文件的权限,让oracle 数据库进程可以获取ASM磁盘组。 注意,这里的/u01/app/oracle/product/11.2.0.4/dbhome_1/bin/oracle就是安装ORACLE RDBMS的ORACLE_HOME。 然后,将数据库添加到CRS中,启动数据库: 检查数据库在ocr中的配置: 启动数据库: 检查crs的状态: 至此,整个使用新主机识别老存储的RAC(主要是识别ASM)就完成了。如果是文件系统的环境,比这个简单很多,ASM的全部可以省略了。 . Oracle 12.1 RAC 系列: Oracle 12.1 RAC 系列-安装新主机,识别老存储和恢复数据库 Oracle 12.1 RAC 系列 – 配置第二个网络和相应的SCAN2

发表在 ASM, Installation and Deinstall, Linux, Oracle 11.1 & Oracle11.2, RAC | 标签为 , , | 留下评论

11.2 RAC 系列-安装新主机,识别老存储-2-准备识别数据库

11.2 RAC 系列-安装新主机,识别老存储-1-识别ASM磁盘 11.2 RAC 系列-安装新主机,识别老存储-2-准备识别数据库 11.2 RAC 系列-安装新主机,识别老存储-3-配置老存储的数据库 Oracle 12.1 RAC 系列-安装新主机,识别老存储和恢复数据库 假设原来的主机已经完全不能启动了(比如硬件故障等),只能在存储上的ASM中查找数据库使用的参数文件: 这里看到,数据库使用的参数文件是spfilelunar.ora,它是spfile.272.892409049的别名文件。 我们在ASM中查看一下: 检查数据库的spfile的内容: 这里确定的,该文件+datadg2/lunar/spfilelunar.ora(也就是+DATADG2/LUNAR/PARAMETERFILE/spfile.272.892409049)就是我们需要使用的数据库参数文件。

发表在 ASM, Installation and Deinstall, Oracle 11.1 & Oracle11.2, RAC | 标签为 , , | 留下评论

RAC环境下删除了/var/tmp/.oracle/的临时文件,有什么后果,以及如何处理

测试目的: 模拟RAC环境下有人误操作,删除了/var/tmp/.oracle/*下的oracle临时文件(删除Network Socket File) 测试过程:观察会有什么后果,以及如何处理。 . 测试环境:OEL 6.6 ,Oracle 11.2.0.4 Standalone(单实例使用ASM的环境) 如果是RAC,测试结论应该大体一致(机制类似)。 在Linux平台上,RAC或者HAS(单实例使用ASM的环境,比如standalone或者我们说的Oracle Restart)使用的Network Socket File在/var/tmp/.oracle/*文件: (在其他平台(比如, AIX HPUX等等)Network Socket File可能在:ls -lrt /tmp/.oracle/* /tmp/.oracle 或者 /usr/tmp/.oracle) 使用crsctl stop has -f停止has,然后就可以直接删除/var/tmp/.oracle/* 下面的Network Socket File: 如果/var/tmp/.oracle目录不存在,可以手工重建: 如果在has正常运行的状态下删除上述oracle临时文件,那么数据库可以使用,但是不能正常关闭: 可以看到,这时,crs通信异常了。 我们看下数据库: 这里看到数据库可以正常使用,但是不能关闭,关闭是报错:不能跟CSS进程通信。 数据库的alert显示为: 检查一下oarcle的进程: … 继续阅读

发表在 ASM, Oracle 11.1 & Oracle11.2, RAC | 标签为 , | 留下评论

使用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, 内部机制 | 标签为 , , | 留下评论

往使用了17T的DG中添加2个1.5T的LUN,共耗时3小时

当前使用了28块800G的SAS SSD。 昨晚,往使用了17T的DG中添加2个1.5T的LUN,从开始到ASM rebalance完成,总共耗时3小时(以前测试的Exadata 1/4配置,加载纯LOB对象,也是1小时1T,当时也感觉很震撼……),速度很快啊,记录一下,O(∩_∩)O哈哈~:

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