分类目录归档：RAC

Oracle 12.1 RAC 系列 – 配置第二个网络和相应的SCAN2

发表于 2016 年 2 月 24 日 由 Lunar

在配置ADG或者使用oracle 的集群管理应用的HA时（比如OGG），我们可能希望使用不同的网络，以避免ADG传输日志等对主生产网络的造成影响。 从11.2开始，我们可以使用crs管理多个网络资源（缺省只有network1），但是SCAN只能在多个网络中的一个上活动（缺省是network1，后续可以指定到不同网络上）。 然后，我们通常会配置专门为ADG传输日志的network2网络，但是在配置连接串时，只能使用vip（因为SCAN通常给主生产上的network1使用）。 . 从12.1开始，我们可以配置多个网络上的多个SCAN，比如我们配置ADG时，在network2上配置SCAN2。 具体配置如下： –检查网卡接口对应的IP地址： –添加新的public网络 –检查网络定义，缺省只有一个网络定义：network1 –添加新的网络集群资源（a new network cluster resource） 这时集群的网络资源中已经配置了两个网络（包括新增加的网络），如果使用“crsctl status res -t”查看，可以看到： –添加vip –启动vip，查看vip资源 –检查新创建的vip是否运行了： –添加网络2上的监听： 在network2上配置SCAN: –启动network2上的监听 –在network2上启动SCAN –在network2上添加SCAN LISTENER –检查监听状态 配置ORACLE数据库实例支持多个网络： 配置客户端连接串 —检查数据库是否可以登录： 至此已经全部完成。 Oracle 12.1 RAC 系列： Oracle 12.1 RAC … 继续阅读 →

发表在 Installation and Deinstall, Linux, network, ORACLE 12C, RAC | 标签为 , , , , , | 留下评论

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

11.2 RAC 系列-安装新主机，识别老存储-1-识别ASM磁盘

发表于 2016 年 2 月 22 日 由 Lunar

在有些场景下，RAC环境中如果主机出现问题，比如硬件故障等，不能启动，我们需要尽快存储上的启动数据库，恢复业务，那么就需要迁移以前的RAC环境到新的主机环境下，我测试了11.2和12.1的RAC，恢复过程还是很快的，基本上就是安装软件的过程，如果真实场景恢复业务，有两种方法： 1，按照我这里的方法重新安装主机，恢复RAC和数据库 2，如果之前有可用的操作系统的备份（比如NBU备份了OS），那么直接使用NBU还原即可 . 我这里测试的是方法1，重新安装11204的GI（Grid Infrastructure）和ORACLE RDBMS软件，然后识别老存储。 测试环境：单节点RAC, 操作系统是OEL Linux 6.6, 数据库版本是11.2.0.4 11.2 RAC 系列-安装新主机，识别老存储-1-识别ASM磁盘 11.2 RAC 系列-安装新主机，识别老存储-2-准备识别数据库 11.2 RAC 系列-安装新主机，识别老存储-3-配置老存储的数据库 Oracle 12.1 RAC 系列-安装新主机，识别老存储和恢复数据库 . 首先，因为存储使用的是11204的ASM，测试过程只安装11204的GI（Grid Infrastructure）软件，不用OUI配置GI。 执行root.sh： 相应的checkpoint文件内容： 这里看到“DESC=”ROOTCRS_NODECONFIG” STATE=”SUCCESS””表示GI已经配置完成。 图形界面点击ok，继续执行其余配置,配置完成后，再次检查checkpoint文件： 这里看到，checkpoint文件的日期没有变化，说明checkpoint文件是执行root.sh的时候才有用的，也就是这个过程是11.2中为了方便客户，增加了root.sh的失败后继续配置二设计的，非常体贴的功能。在12.2中，该功能更加方便，他将会只管的告诉你当前配置的检查点情况，如果有些步骤失败后，oracle会自动清除老的配置，以便可以失败安装后不用重装，而是纠正错误后继续配置，类似“断点续传”那种意思。 . 比如，下面是12.2beta上安装RAC时执行root.sh的过程： 可以看到，这个过程比12.2以前的RAC执行root.sh的提示更加清晰了。 好吧，回到我们的环境中，继续检查老的asm磁盘组 将上述磁盘组添加到ASM启动磁盘组的列表中： 对新添加的磁盘组执行mount和dismount后，这些磁盘组就会自动添加到ocr中： … 继续阅读 →

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

单实例数据库转换为RAC数据库–使用rconfig转换

发表于 2016 年 1 月 28 日 由 Lunar

测试目的： 单实例数据库转换为RAC数据库 测试环境：Oracle 11.2.0.3 测试方法：使用rconfig的方式 . $su – oracle cp $ORACLE_HOME/assistants/rconfig/sampleXMLs/ConvertToRAC_AdminManaged.xml lunar.xml 转换过程超级简单，如果你观察操作过程的rconfig日志会发现，这个方法的本质是： 1，后台自动配置RAC的CRS配置信息（CRS的，spfile的，口令文件等等） 2，自动调用rman进行backup of copy类型的数据库备份和恢复 3，自动添加RAC中第二个节点的thread 2的redo logfile group . 具体操作如下： 执行期间可以观察日志，看看rconfig怎么完成转换的，我个人觉得这个很有意思。 日志位置：$ORACLE_BASE/cfgtoollogs/rconfig_时间戳。 . 检查转换后的CRS状态： 常见问题1： 报错信息：The cluster is not configured or is not running on node: RAC1 … 继续阅读 →

发表在 Database, Installation and Deinstall, RAC | 标签为 , | 留下评论

单实例数据库转换为RAC数据库–手工转换

发表于 2016 年 1 月 28 日 由 Lunar

测试目的： 单实例数据库转换为RAC数据库 测试环境：Oracle 11.2.0.4 测试方法：手工转换 . 首先，安装一套RAC环境，并把单实例数据库通过通过rman还原到这个环境（通常如果是生产环境，我们会搭建从RAC到单实例数据库的ADG，以减少停机时间）。 然后生成一个源库（单实例数据库）spfile： 注意检查tnsnames.ora中用于local_listener参数的两个配置条目是否正确： 修改刚才备份的pfile文件（/home/oracle/lunar/spfile.lunardb.tmp），添加RAC相关配置： 使用这个pfile启动数据库： 添加thread2： 添加实例2的undo表空间： 启用实例2（thread2）： [oracle@dm01db01 dbs]$ orapwd file=orapwlunardb1 entries=10 password=oracle [oracle@dm01db01 dbs]$ pwd /u01/app/oracle/product/11.2.0.4/dbhome_1/dbs [oracle@dm01db01 dbs]$ scp orapwlunardb1 dm01db02:/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/orapwlunardb2 orapwlunardb1 100% 2560 2.5KB/s 00:00 [oracle@dm01db01 dbs]$ [/shell] 创建spfile： 使用grid用户查看： 修改initlunardb1.ora … 继续阅读 →

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

11.2和12c RAC的ohasd守护进程在不同Linux版本的演变

发表于 2016 年 1 月 26 日 由 Lunar

前面我们已经讲解过11.2 RAC的启动过程，可以注意到，RAC的根守护进程是/etc/init.d/init.ohasd，那么不同版本的Linux中/etc/init.d/init.ohasd是如何启动的呢？ 注意：12.1的非Flex Cluster启动过程跟11.2 RAC一致。但是从12.2beta版 RAC的测试结果来看，从12.2开始OUI安装很可能只有Flex Cluster了，没有了11.2的那种普通RAC了。 . Linux4和Linux5中，在完成核内引导(内核被载入内存并运行,初始化所有的设备驱动程序和数据结构等)之后,就通过启动一个用户级程序/sbin/init的方式来启动其他用户级的进程或服务。 所以,init始终是第一个进程,其PID始终为1(ps -aux | less),它是系统所有进程的父进程. 我们看一下这三个文件哪里不同： 可以看出，/etc/inittab.no_crs的内容就是在没安装GI以前的/etc/inittab备份文件，而/etc/inittab.crs的内容就是安装GI以后/etc/inittab 备份文件 也就是说，在Linux 5中，安装完RAC(10.2或者11.2)后，该脚本就会增加上面一行启动ohasd守护进程的脚本，如果要在系统启动时启动crs，那么就需要让/etc/inittab中包含下面的一行启动命令： h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 /dev/null 2>&1

发表在 Database, Linux, RAC | 标签为 , , | 留下评论

etc目录下的init.ohasd和ohasd文件丢失后如何启动GI

发表于 2016 年 1 月 26 日 由 Lunar

上一遍我们已经知道11.2和12c RAC中的/etc/init.d/init.ohasd是启动RAC所有其他进程的守护进程。 那么如果有人误删除了这个文件或者错误修改了，怎么办呢？ 这个解决不难，因为在Standalone环境中，/etc/init.d/init.ohasd来自于$GRID_HOME/crs/init/init.ohasd，而/etc/init.d/ohasd来自于$GRID_HOME/crs/init/ohasd。 我们对比一下$GRID_HOME/crs/init/和/etc/init.d/下的ohasd和init.ohasd，看看文件内容是否一致： [/shell] 可以看到，$GRID_HOME/crs/init/和/etc/init.d/目录下的文件内容是一致的，只是权限不同。/etc/init.d/目录下的文件权限是750，$GRID_HOME/crs/init下的权限是644。 好了，解决方法有了，如果/etc/init.d/init.ohasd或者/etc/init.d/ohasd丢失了，手工创建/etc/init.d/init.ohasd 就可以了： 如果再细心一点，我们会发现$GRID_HOME/crs/init目录下除了这两个文件外，还有一个名称为ohasd.sles的文件。 熟悉SLES Linux的朋友可能猜到了，是的，这个是在SLES Linux上使用的ohasd版本。 检查当前版本是否为SLES: 现在，我们删除/etc/init.d/init.ohasd文件来模拟init.ohasd文件丢失或者损坏： 然后我们使用$GRID_HOME/crs/init/下面的文件复制过来，手工启动试试看： 下面的显示删除/etc/init.d/init.ohasd后reboot系统的结果（也可以使用kill进程的方式，不重启主机）： 可以看到，当前没有任何RAC的进程被启动。 我们尝试恢复这个丢失的ohasd守护进程配置文件： 然后reboot系统后，该进程已经启动了：

发表在 Database, Linux, RAC | 标签为 , , | 留下评论

11.2中，如何手工kill所有的CRS进程而不导致主机重启？

发表于 2016 年 1 月 25 日 由 Lunar

我们都知道，在RAC环境中，如果kill ocssd.bin进程，会引起主机重启。 但是有时候系统已经异常了了，且CRS不能正常关闭，而主机可能是几年没重启的老系统，没人敢重启，现在怎么办？ 我们只能尝试手工kill进程的方式，然后手工修复CRS（注意，在10.2 RAC中，只有3个d.bin进程）。 测试环境：操作系统是OEL 6.6 这套RAC的CRS版本是11.2.0.4： 注意，由于12.1普通RAC（非Flex Cluster）的情况根本文一样，处理思路和过程也一样。 查看当前CRS的状态： 查看当前所有的CRS进程： 这么多进程，他们的关系参见：11.2 RAC 的启动过程 好吧，我们开始模拟kill进程。首先kill 掉/u01/app/11.2.0.4/grid/bin/ohasd.bin（会自动重启，参见11.2 RAC 的启动过程） 然后，我们kill cssdmonitor： 这里没有这个集成，表示cssdmonitor进程被重启过了： （参见11.2 RAC 的启动过程） 上面进程启动时间在20:04~20:07之间的，都是被/u01/app/11.2.0.4/grid/bin/ohasd.bin进程重启后，自动后台重启的。 现在，我们kill mdnsd gpnpd gipcd osysmond。 这4个进程中，前面3个是CRS启动除了ohasd以外，最早启动的几个进程。 如果kill这些进程，ohasd都会重启的： 这里我们看到，刚才kill 的4 进程都没起来，怎么回事？ 别急，还没到时间，ohasd需要check后才启动，O(∩_∩)O哈哈~ 然后，我们kill 监听： 好吧，看看，刚才kill的进程都被重启了，11.2的RAC真强悍啊。 … 继续阅读 →

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