标签归档：11.2 RAC

11.2中修改私有网络的private ip对应的主机名

发表于 2015 年 4 月 13 日 由 Lunar

Oracle Clusterware使用oifcfg来管理网络信息（网卡，子网，网络接口的角色等等），但是他不管理每个网卡实际的IP地址。 因此，不能使用oifcfg来修改IP地址(只能修改子网)。 可以使用oifcfg getif来显示当前OCR里面的网卡信息，例如： 在UNIX和linux系统中，网络接口的名称通常由OS来分配。 Windows系统中有所不同（不熟悉Windows上的RAC，职业生涯中，安装不超过10次Windows平台的RAC……） 数据库对外提供服务的网络，我们通常称为PUBLIC网络，VIP也是存储在OCR里面跟PUBLIC同一网段上的IP地址 注意：VIP是绑定在public ip上的虚拟IP，只有CRS启动后，才有VIP。 用于RAC中节点间通信或者RDBMS跟ASM实例通信的网络，我们称之为Private网络（私有网络），用于内部互联。 从11.2开始，cluster_interconnect也被用来做clusterware hearbeats 在11.2之前（11.1和10g），RACA使用私有IP对应的主机名（例如 lunar-priv）来作为集群的心跳（在安装RAC时有界面让指定的） . 当修改了私有网络的IP或者主机名，就需要修改CRS（10g和11.1）或者GI(11.2以后)。 8i和9i没这个问题，因为那时候，Oracle没有自己的集群软件，只有“集群数据库”，所有的集群功能都是第三方集群软件完成的。 例如 : HP的MC SERVERS GUARD/OPS OPTION AIX的HACMP Solaris的SUN Cluster Tru64 UNIX的TruCluster ……………… . 在11.2之前，私有IP对应的主机名保存在OCR中，我们不能修改私有网络的主机名。 但是正因为如此，修改了私有IP，而私有IP对应的主机名其实并没有发生改变。 如果要修改主机名就简单的执行rootdelete.sh和rootdeinstall.sh重新配置CRS就可以了。 具体的例子请参考《在10.2 RAC中重建CRS的过程》 . 从11.2开始，CRS（Cluster Ready Service）升级为GI（Grid … 继续阅读 →

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

11.2中修复CRS不能启动的例子-1-使用正常节点的gpnp profile修复损坏节点

发表于 2015 年 4 月 13 日 由 Lunar

SSD上的一个11.2 RAC的其中一个节点OS不能起来了，鼓捣半天还是不行 想想这个是2013年买的，才两年啊……，不知道是不是这个原因，反正很无语…… 另一个10多年前的活动硬盘上那个RedHat 2上的Oracle 8.0.6都还可以使用 . 就这个环境，从其他活动硬盘上复制了节点1的老的备份到SSD上，尝试修复整个RAC。 由于只修改了节点1的IP跟我现在VBOX中的配置一致即可，且节点2是正常的，因此，无需大招。 只要两件事情; 1,在OS层面修改节点1的网络配置: 2,把节点2的gpnp profile传给节点1 . 具体如下： 1，将2个节点的crsd都关闭，把节点2的profile.xml复制到节点1： 确认节点2的crs是关闭的： 2，确认当前的节点2的gpnp profile信息是正确的： 我这里主要是私有网络的IP地址应该为192.168.20.0网段： 即 可见这里是正确的。 注意这里，当所有CRS进程都不启动时，gpnp的信息来自于他自己的一个cache（猜测这个是从文件上保存的profile中读取到他自己的所谓cache的） . 3，查看节点1当前的gpnp profile，注意，其中的net2的信息，是错误的： 4，确认节点1的crs全部都是关闭的： 5，备份节点1当前的gpnp profile： 6，将节点2的gpnp profile复制到节点1： 7，启动节点1和节点2的crs（正常启动即可）： 8，可以看到，节点1已经可以正常启动了： 这里看到节点1的网络信息也正常了 再启动节点2： 除了network2（用于ADG的网络，还没有修改相应的配置），其他都正常了。

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

11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法-2-使用root.sh重构crs

发表于 2014 年 10 月 8 日 由 Lunar

因此，下面我尝试比这个方法稍微科学一点点的方法2：重新执行节点1的root.sh，来尝试修复节点1的权限问题。 使用rootcrs.pl -deconfig删除crs配置信息： 使用root.sh重新配置crs： 配置结束后，可以看到，节点1的数据库是不能正常启动的： 这个原因是很明显的，跟手工修改u01目录权限一文中的类似： 修改oracle二进制文件的权限： 再次尝试启动数据库： 再回过头看看root.sh修改了哪些主要目录的权限： 这些目录是11.2 RAC的基本服务资源。从11.2开始，GI中不再显示类似上面的基础服务资源，需要使用init参数来看： 从修改过程可以看出，感觉上，root.sh比第一种手工修改的方法科学一点，但是居然oracle二进制文件的权限还是没有修改好，那么其他的是否有细节问题，不好说。 总之，Oracle建议的方法，还是加减节点，让Oracle完全的重构这个节点的所有文件，以防止日后任何的CRS异常终止或者异常宕机等行为。

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

11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法–使用rootcrs.pl -init修复

发表于 2014 年 10 月 8 日 由 Lunar

还原节点损坏的场景： 可以看到，此时crs起不来了，后台报错： 可以看到，卡在ora.mdnsd服务不能启动： 使用rootcrs.pl的init选项尝试修复，结果是不行的： 后台日志的报错信息，跟上面的是雷同的。 可见，使用rootcrs.pl -init修复目录权限，在chown -R /u01面前，作用不大。

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

11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法–手工修复权限之总结

发表于 2014 年 10 月 8 日 由 Lunar

正如在11.2 RAC 上所有grid环境需要的文件的权限配置文件：crsconfig_fileperms 和 11.2 RAC 上所有grid环境需要的目录的权限配置文件：crsconfig_dirs中描述的，理论上，根据这两个文件，自己写一个shell脚本修改全部grid环境所需的权限，看上去是可以的。 也正如11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法-1-手工修复错误的权限中所证明的，其实真要是手工修改，只为了让crs可以起来，完全不必要那么麻烦，只要简单的几条命令即可，但是上面的3种手工修改权限的方法，都是oracle官方所不支持的，以前也有人log SR专门问过这类问题，官方给的推荐方法就是remove nodes and add nodes： 这种解释是很好理解的，11.2 RAC相对10.2来说可以说是重新设计的，相对复杂很多的庞然大物，其附带的功能也非常多，因此，手工修改后，到底会有什么风险，稳定性如何保证都是问题…… 因此，明天我用加减节点的方法来重现故障后，再减节点和加节点的方法修复试试看，O(∩_∩)O哈哈~

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

11.2 RAC 上所有grid环境需要的文件的权限配置文件：crsconfig_fileperms

发表于 2014 年 10 月 8 日 由 Lunar

在11.2的$GRID_HOME/crs/utl目录下有一个文件crsconfig_fileperms，记录了所有grid目录下各个文件的权限定义，例如：

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

11.2 RAC 上所有grid环境需要的目录的权限配置文件：crsconfig_dirs

发表于 2014 年 10 月 8 日 由 Lunar

在11.2的$GRID_HOME/crs/utl目录下有一个文件crsconfig_dirs，记录了所有grid目录下各个目录的权限定义，例如：

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

11.2 RAC 修改了目录权限(u01)后crs不能启动的解决方法-1-手工修复错误的权限

发表于 2014 年 10 月 8 日 由 Lunar

在11.2RAC中，如果修改了gird的安装目录(类似chown -R xxx /u01)，比如通常我们会使用/u01，则crs会出现不能启动的状态，启动时，mdnsd进程会首先卡主，crs日志会有如下信息： 下面我们尝试使用3种方法来修复该问题。 方法1————直接修改/u01和其他相关文件或者目录的权限： 注意： 此方法，仅仅用于紧急启动数据库或者ASM的不得已的做法，在生产环境下，官方建议的做法是删除节点和添加节点（后面会在方法3中详细描述）。 首先修改/u01目录为grid:oinstall，并修改/u01/app/oracle为oracle:oinstall 如果进行上述目录权限的修改，那么crs表面可以启动，但是可以看到后台重要的agent进程都是错误的状态： 还有一些对ohasd和crsd比较关键的文件的权限，也一并修改了： 此时启动可以crs可以启动了。 但是，可以看到目录权限有问题的节点，数据库没有正常启动： 手工启动数据库，报错信息如下： 这个错误通常意味着oracle二进制文件权限不对，尝试修改： 正常情况下，$GRID_HOME/bin/oracle和$ORACLE_HOME/bin/oracle的权限都应该是6751，即“-rwsr-s–x” 对比下节点2（正常节点）： 再看看节点1（问题节点）： 手工修改$GRID_HOME/bin/oracle文件权限： 顺便检查一下$ORACLE_HOME/bin/oracle文件权限： 现在，再重新启动数据库： 目前该数据库貌似可以启动了，如果在很多异常情况下，目前的情况，已经可以尝试导出数据库或者备份数据库等等了。 但是这种状态的crs和数据库是存在很大隐患的，比如很可能会异常宕机或者出现其他莫名其妙的损坏等情况。 因此，一旦权限出现问题，要么使用rootcrs.pl -init修复（通常这种情况下，这种修复是徒劳的，后面的测试会证明这一点） 否则官方不支持任何手工手工修改权限的做法。就这一点，官方有明确的:

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