月归档：2014 年十月

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

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

发表于 2014 年 10 月 8 日 由 Lunar

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