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

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

11.2 RAC 的启动过程

发表于 2016 年 1 月 25 日 由 Lunar

从11.2 GI(Grid Infrastructure)开始，RAC的结构跟10.2有翻天覆地的变化，在MOS的经典文档“11gR2 Clusterware and Grid Home – What You Need to Know (Doc ID 1053147.1)”中有详细的解释。 其中有一副经典大图可以一目了然的告诉我们这些d.bin进程之间的依赖关系（也就是启动和关闭，谁启动重启谁等等）： 从CRS的启动过程，我们也可以清晰的看到进程的启动顺序。 下面是一个11.2.0.3环境的CRS启动过程： 最先启动的是/u01/app/11.2.0.3/grid/bin/ohasd.bin ，他后面呆着reboot，表示它被kill后会被自动reboot。 /etc/init.d/init.ohasd进程就是重启/u01/app/11.2.0.3/grid/bin/ohasd.bin进程的守护进程。 他们的内容都来源于$GRID_HOME/crs/init/init.ohasd，后续blog会模拟丢失这个文件到处理，这里不赘述了。 会自动启动这个进程，并在/var/log/message中记录下这个启动过程。 /u01/app/11.2.0.3/grid/bin/ohasd.bin被kill 后，，系统会有几分钟的重启服务的时间，/var/log/message中记录下这个启动过程： 这个重启的过程在空闲系统大概需要不到2分钟，$GRID_HOME/`hostname -s`/alert`hostname -s`.log中会ohasd.bin被kill和重启后执行检查(check)和恢复(recovery)各种资源的日志如下： 好了，继续回到我们刚才的启动过程的讨论。接下来，我们看到orarootagent.bin cssdagent cssdmonitor不见了，增加 mdnsd.bin 然后是增加了 ocssd.bin gpnpd.bin orarootagent.bin gipcd.bin osysmond.bin cssdmonitor … 继续阅读 →

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

Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列-9-Linux 7.2上的virbr0设备

发表于 2016 年 1 月 23 日 由 Lunar

当我们安装了Linux 7.2（CentOS 7.2和 OEL 7.2都有下面的现象），缺省会安装一个虚拟网卡virbr0。 查看当前的IP信息： 这里我们看到Linux7开始使用enp0s3作为第一个缺省的网络接口名，类似于以前的eth0，当然，你后面可以修改这个缺省的网络接口名。 enp0s8是第二个网络接口名，而enp0s9就是我们新添加的第三个网络接口名。 enp0s3和enp0s8我们在安装时已经配置了网络连接和IP地址，设置了启动自动连接，因此没有问题。 enp0s9需要我们手工配置。 . 可以看出来，Linux7中缺省还有一个virbr0网络接口。 . 从网上摘录了virbr0的部分相关解释： virbr0 是一种虚拟网络接口，这是由于安装和启用了 libvirt 服务后生成的 libvirt 在服务器（host）上生成一个 virtual network switch (virbr0)，host 上所有的虚拟机（guests）通过这个 virbr0 连起来。 默认情况下 virbr0 使用的是 NAT 模式（采用 IP Masquerade），所以这种情况下 guest 通过 host 才能访问外部。 . 可以看出来，virbr0是一个虚拟网卡，并且由于在Linux7.2中（CentOS … 继续阅读 →

发表在 Installation and Deinstall, Linux, ORACLE 12C, RAC | 标签为 , , , , , , | Comments Off on Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列-9-Linux 7.2上的virbr0设备

Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列-8-在Linux7上安装11.2 RAC和12.1 RAC需要禁用哪些服务

发表于 2016 年 1 月 23 日 由 Lunar

安装Oracle RAC的时候，通常我们会禁用一些服务，比如：防火墙，avahi-daemon等等。 avahi-daemon是一种Linux操作系统上运行在客户机上实施查找基于网络的Zeroconf service的服务守护进程。 该服务可以为Zeroconf网络实现DNS服务发现及DNS组播规范,它可以在没有 DNS 服务的局域网里发现基于 zeroconf 协议的设备和服务。 用户程序通过Linux D-Bus信息传递接收发现到网络服务和资源的通知。 一般安装Oracle RAC，建议禁用该服务。 . 我们看一下，在Linux7（Linux5和Linux6中）以前我们一般禁用的服务列很多 例如： 等等 然后，在linux7下，已经不适用chkconfig命令了，而且很多以前的服务名称和启动配置都变化了（参考blog中Linux7管理开机启动服务的相关文章） 那么我们现在怎么禁用服务，禁用哪些呢？ 首先，看看系统中当前运行了哪些服务： 在前面的blog中已经有了禁用防火墙的描述，这里不赘述。 安装Oracle，除了防火墙和SELINUX以外，通常还需要禁用以下服务 Linux7以前的命令： 在Linux7中使用systemctl stop和systemctl disable: 在Linux6以前，我们使用chkconfig –list查看当前的服务，但是在Linux7中，大部分情况我们使用systemctl 如果使用chkconfig –list，则输出类似如下： 执行chkconfig的命令提示很清晰，他告诉我们，使用chkconfig将只显示SysV的服务，不包含原生 systemd服务。 我们查询一下在Linux5和6时，咱们经常禁用的服务，在Linux7中的状态： 根据上面输出，可以总结出来，还需要禁用下面这些开机自动启动的服务： （systemctl disable的作用类似于以前的chkconfig –level 2345 avahi-daemon off） … 继续阅读 →

发表在 Installation and Deinstall, Linux, ORACLE 12C, RAC | 标签为 , , , , , | Comments Off on Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列-8-在Linux7上安装11.2 RAC和12.1 RAC需要禁用哪些服务

Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列-7-网络管理之修改网络接口名

发表于 2016 年 1 月 22 日 由 Lunar

由于Linux7中采用了固定的网络接口名的方式，目的是如果网卡损坏可以方便的使用类似新增网卡的方法进行替换，非常简便 但是如果由于某种原因，需要修改网络接口名就很麻烦，例如想修改为以前的eth0的名称。 Linux7中，使用nmtui修改网络连接和IP地址后，可以使用重建加载配置文件的方式使新的配置生效。 需要注意的是，网络接口名称不能通过nmtui来修改（可以修改，但是修改是无效的，会被自动还原为缺省的网络接口名）。 . 下面是通过修改网络配置文件的方法来修改网络设备接口名称的过程（注意，结论是不能用此方法修改）： 修改/etc/sysconfig/network-scripts/ifcfg-eth1中的两个地方： DEVICE=eth1 ———-设备名称（device） NAME=eth1 ———-连接名称（connect） 修改后： 修改后重新加载配置文件： 这样只能修改连接的名称，但是不能修改设备名称： 错误：没有找到设备 ‘eth1’。 在Linux7中修改设备名称只能禁用一致和可预测的网络设备命名规则，即，修改grub，还原到Linux6的设备命名方法： 至此，我们看到，不能通过修改配置文件的方法来改变网络接口设备名称。 那么如果一定要在Linux7中将网络设备接口名修改回以前很土的eth0有方法么？ 答案是：yes。 . 我们可以通过禁用可命名规则，编辑/etc/default/grub文件来实现。 在该文件的GRUB_CMDLINE_linux=”rhgb quiet”改为GRUB_CMDLINE_LINUX=”net.ifnames=0 biosdevname=0 rhgb quiet” 运行命令grub2-mkconfig -o /boot/grub2/grub.cfg来重新生成grub配置并更新内核参数: 这里我们看到了熟悉的类似Linux6中的UDEV绑定网络设备的方式。 然后，我们reboot后，可以看到，网络接口名已经还原到了以前的样子： 现在，我们再还原回到可预测的网络设备命名网络接口的方法： Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列–1-简介 Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列-2-修改主机名和hostnamectl工具的使用 Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列–3-systemd（d.bin和ohasd守护进程） Linux7（CentOS,RHEL,OEL）和Oracle … 继续阅读 →

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