在solaris环境，在11.2.0.4之后（或者Patch 16387058 on top of 11.2.0.3.5），Oracle自动把LGWR进程放到_high_priority_processes中，（不管是单实例还是RAC）。在这之前，需要手工运行priocntl -s FX -m 60 -p 60 -i pid
设置到_high_priority_processes后，Oracle的LGWR进程将会工作在高CPU优先级下，你通过ps -eclf|grep ora_lgw看，他会工作在FX 60，即实时的CPU优先级中。
但是在一个数据库中，看到LGWR没有工作在FX60，且同样配置的一个数据库，LGWR却可以正常工作在FX60。
经检查，这是由于这个数据库的oradism的属主和权限不对。
|
1 2 3 4 5 |
正常： -rwsr-x--- 1 root dba 1888176 Jul 8 2014 /ppkk/mydbp1/rdbms/oracle/12c/product/12.1.0/bin/oradism 错误： -rwxr-x--- 1 myousr dba 1888176 Jul 8 2014 /ppkk/mydbp1/rdbms/oracle/12c/product/12.1.0/bin/oradism |
再进一步查，发现造成设置权限错误的原因，是安装完数据库之后，没有正常执行root.sh脚本。
|
1 2 |
more root_ddbb3940_0_2016-04-06_18-29-10.log Oracle root script execution aborted! |
因为root.sh脚本会调用rootadd_rdbms.sh，在rootadd_rdbms.sh中：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
…… RUID=`/usr/bin/id|$AWK -F\( '{print $1}'|$AWK -F= '{print $2}'` if [ $RUID -ne 0 ];then $ECHO "You must be logged in as user with UID as zero (e.g. root user) to run root.sh." $ECHO "Log in as user with UID as zero (e.g. root user) and restart root.sh execution." exit 1 fi if [ -f $ORACLE_HOME/bin/oradism ]; then $CHOWN root $ORACLE_HOME/bin/oradism $CHMOD 4750 $ORACLE_HOME/bin/oradism fi # remove backup copy if [ -f $ORACLE_HOME/bin/oradism.old ]; then $RM -f $ORACLE_HOME/bin/oradism.old …… |
除了由于oradism的属主和权限问题，另外还有一些情况会造成_high_priority_processes中的进程不工作在实施模式：
如，在某些环境中如supercluster也会造成即使设置_high_priority_processes，也不工作在FX60的情况下。
如，在AIX环境下，启动进程的用户缺少CAP_BYPASS_RAC_VMM、CAP_PROPAGATE，如果启用了NUMA的话没有赋予NUMA_ATTACH的权限，也会不工作在实时下。
最后，顺便在说一下，除了本文谈到的oradism文件，另外的一个文件权限也要注意：
ASM用户能看到磁盘，但是Oracle用户却看不到asm diskgroup和disk
物理硬盘的权限设置都没问题,多路径也正常，这时需要去看ASM下的oracle文件的属性：
|
1 |
-rwsr-s--x 1 grid oinstall 152400480 Feb 3 2010 $GI_HOME/bin/oracle |
如果这个文件的权限被改了，就会造成DB无法使用ASM正常mount起来的磁盘。
参考：
LMS not running in RT (real time) mode in 10.2.0.3 RAC database (Doc ID 602419.1)
RAC and Oracle Clusterware Best Practices and Starter Kit (Linux) (Doc ID 811306.1)
ASM Diskgroup Can Not Be Shown When Creating Database With DBCA (Doc ID 1269734.1)
SuperCluster – ssctuner is not adjusting the scheduling class of all of lms , lgwr and vktm processes to FX-60 (Doc ID 1628298.1 INTERNAL)