日归档:2014 年 10 月 8 日

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

因此,下面我尝试比这个方法稍微科学一点点的方法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修复

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

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

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

正如在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

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

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

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

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

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

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

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

升级到11.2.0.4的一些发现-2-其他发现

升级到11.2.0.4的一些发现-1-catupgrd.sql大致解读 升级到11.2.0.4的一些发现-3-catalog.sql的主要内容 1,如果当前连接的用户不是SYS,那么会报ORA-01722: invalid number错误: 那么判断是否当前连接用户为LUNAR,就可以使用下面的语句: 同样道理,判断当前数据库版本是否为11.2.0.4: 然后,通过下面的命令查看sqlplus的错误日志: 这里我们看到,并没有记录下来sqlplus的操作错误,仔细看一下,原来set errorlogging on table命令必须在当前用户下执行,例如: 看,错误信息,一目了然 3, auto-bulkification by setting event 10933 4,catupgrd.sql会调用catupstr.sql, 这个脚本执行过程中中,还需要依次调用: catupses.sql i0902000.sql——重整 props$,dependency$,mon_mods$。之后,该脚本还调用i1001000.sql。i1001000调用i1002000.sql。 在i1002000.sql有有一个有意思的操作: Rem clear 0×00200000 (read-only table flag) in trigflag during upgrade update tab$ set trigflag = … 继续阅读

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