分类目录归档：ASM

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

发表于 2016 年 2 月 23 日 由 Lunar

在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-配置老存储的数据库

发表于 2016 年 2 月 22 日 由 Lunar

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-准备识别数据库

发表于 2016 年 2 月 22 日 由 Lunar

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/的临时文件，有什么后果，以及如何处理

发表于 2016 年 1 月 25 日 由 Lunar

测试目的： 模拟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数据库（抽取磁盘上的数据文件）

发表于 2015 年 6 月 23 日 由 Lunar

之前研究过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？

发表于 2015 年 6 月 16 日 由 Lunar

前几天，一些朋友讨论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信息的脚本

发表于 2015 年 5 月 17 日 由 Lunar

当ASM中某些磁盘状态异常，比如应该是“MEMBER”的，却是“CANDIDATE”或者其他等各种盘头异常，或者ASM实例异常，可以使用下面脚本收集ASM信息（来源于MOS）

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

使用dd备份和恢复ASM中的数据文件头

发表于 2015 年 5 月 17 日 由 Lunar

今天看了飞总微博上的备份ASM中数据文件头（http://www.xifenfei.com/5888.html），觉得有意思 佩服飞总专业的钻研精神，那么多X$的internal视图……O(∩_∩)O哈哈~ 这里用大家随处可见的（除了extent分布的x$kffxp需要百度和google外），其余都是文档中有详细记载的常用ASM视图来实现同样功能：

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

oracle数据块如何定位到ASM中？在exadata定位block的思路是什么？

发表于 2014 年 11 月 28 日 由 Lunar

前几天有个朋友提出一个“老问题”，数据库上的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小时

发表于 2014 年 9 月 26 日 由 Lunar

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

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