月归档:2014 年十月

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