Oracle SuperCluster M6-32 Hardware
 
SPARC SuperCluster T4-4
 
Oracle SuperCluster T5-8 Half Rack
 
Oracle SuperCluster T5-8 Full Rack
 

PLA-Support>Eng Systems>Exadata/ODA/SSC>SPARC SuperCluster>DB: SuperCluster_EST
 

In this Document

Purpose

Scope

Details

References

Applies to:

Purpose

 This document is to explain the presence of an ora_dism<sidname> process in  Solaris environments even when Dynamic Intimate Shared Memory (DISM) is not in use.  This document will assist in understanding false positives from legacy health check tools that rely on ps outputs, as well as assist in troubleshooting various issues by ensuring that the presence of such processes do not prevent the appropriate checks for Dynamic Intimate Shared memory (DISM) from taking place.

Scope

 Intended for anyone running or supporting an Oracle database on Solaris.

Details

 Based on documents such as <Document 1468297.1> Dynamic Intimate Shared Memory (DISM) is not supported for use on SPARC SuperCluster Solaris environments. Many other Solaris generic support articles, legacy monitoring tools and older perceptions generate warnings or concerns if a ora_dism<instancename> process is found in the environment. The history behind this is that the oradism executable was originally built to enable Dynamic Intimate Shared Memory (DISM). This is one of the reasons for it having the setuid bit.  Over various releases, the oradism executable has been used to enable several other database operations, most occurring at database startup, after which the processes exit.  However certain operation must maintain the running process such as Oracle Shared Memorry in 12c and dnfs in 11G and above.

In Solaris, oradism program is used for:

 Know if NUMA is enabled on Solaris.
 Mount dNFS volumes
 Dispatch ACFS (ASM Clustered File System) request -non SuperCluster systems at this time.
 Perform SCSI commands across scsi disks
 Attach to DISM memory, lock and unlock it
 Change process priority
 Dump OS information
 Integration with DTrace
 Implementation of Optimized Shared Memory in 12c

If there is a case where Dynamic Intimate Shared Memory  is the suspected culprit, verify whether it is indeed enabled by using pmap:

 The output from pmap –xs shows three address ranges associated with shmid=0xb (that is, id=11, since “b” is 11 in hexadecimal): one with 256 Mbyte pages, one with 4 Mbyte pages, and one with 8
 byte pages. Each of them is clearly labeled “ism”. If on 12c and Optimized Shared Memory it would show "osm". If DISM had been in use, the output would have shown “dism” instead. E.g:

Plese note both MAA best practices for RMAN on SuperCluster use dNFS, therefore having these ora_dism<instancename> processes present in a SuperCluster environment is expected. However, the feature of Dynamic Intimate Shared Memory is not supported, therefore the pmap technique  should be used when debugging to make sure this feature is not enabled. For continuous real time checks to ensure that the feature is not in use, all SuperCluster environments should be running ssctuner which uses the memory approach to validate this. The ssctuner tools will log an error to the messages file of the operating system if Dynamic Intimate Shared Memory is in use. Here is an example of such an error as seen in /var/adm/messages:

References

This solution has no attachment