Database Reference
In-Depth Information
The srvctl command is an option-rich tool, and if you are not sure about the syntax, type srvctl -h to
understand the options in the srvctl tool.
Miscellaneous Topics
There are some important topics that require special attention in RAC. For example, in a single-instance database,
memory starvation can lead to performance issues, but in RAC, memory starvation can lead to a node reboot.
Process Priority
In RAC, a few background processes must have higher CPU scheduling priority. For example, an LMS background
process should run with higher CPU priority, as the LMS process is the workhorse of global cache transfer, and
CPU starvation of an LMS process can increase global cache latency. Further, if an LMS process suffers from CPU
starvation, network packets can be dropped, leading to gc blocks lost waits in other nodes. Underscore initialization
parameter _high_priority_processes controls the processes that will execute at an elevated priority. By default, this
parameter is set to elevate the priority of VKTM (Virtual Keeper of Time) and LMS background processes. Generally,
you do not need to modify this parameter.
_high_priority_processes= 'LMS*|VKTM'
For example, in the Solaris platform, the LMS process will execute with RT priority. Of course, elevating a process
priority requires higher-level permissions, and this is achieved using oradism binary in Unix platforms and oradism
service in Windows platform. Notice in the following that oradism executable is owned by root userid with setuid flag
enabled. OS group prod has execute permission on this oradism binary. Essentially, with setuid permission of the root
user, the oradism executable is utilized to elevate the priority of background processes.
$ ls -lt oradism
-rwsr-x--- 1 root prod 1320256 Sep 11 2010 oradism
Setuid permissions on oradism executable are needed to alter the priority of background processes. When
you execute root.sh during GI software installation, this setuid permission is set on oradism executable, but during
software cloning, DBAs typically do not run root.sh, and so the oradism executable does not have correct permissions.
Hence, the priority of LMS process is not elevated, leading to global cache latency issues during CPU starvation.
Executing root.sh script and verifying that the oradism executable has correct permission after the completion of
software cloning is recommended.
Also, GRID processes, such as cssd.bin, cssdagent, and cssdmonitor, etc., should run with elevated priority.
Again, oradism binary in Grid Infrastructure software must have proper permissions. Permissions on an ordism file in
GI were not a big problem until version 11.2, as cloning of GI was not widely used. However, in version 12c, cloning of
GI software is allowed and binary permissions require careful attention if GI software is cloned.
While elevated priority for background processes protects the background processes from CPU starvation, it does
not mean that CPU starvation will not cause node stability issues. For example, the LMS process must wait for the
LGWR background process to do a log flush sync before sending the blocks (for certain types of global cache transfer).
If there is CPU starvation in the server, then LGWR might not get enough CPU; LGWR will suffer from CPU starvation,
and that can lead to longer waits by the LMS process. Remote instances will suffer from prolonged global cache
transfers. So, CPU starvation in one node can increase the global cache latency in other nodes, inducing slowness in
the application; in a few scenarios, this CPU starvation can also lead to node reboots. It is a recommended practice to
keep CPU usage below 75% to avoid CPU starvation and reduce node stability issues.
 
Search WWH ::




Custom Search