Skip to Content

Dynamic Intimate shared memory (DISM)

Dynamic Intimate shared memory (DISM)

About the Document

     This document describes the purpose of DISM, its function, the steps necessary to ensure its effective behavior, and things to avoid.



     Recent Releases of Oracle Database can automatically assign more memory to System Global Area (SGA), up to a prescribed limit, to both the buffer cache and the shared pool if additional memory will improve performance. The Oracle Solaris Operating System supports such operations with the Dynamic Intimate Shared Memory (DISM) feature.

     It is important to note that significant performance degradation can occur if DISM is not configured correctly, and for that reason Oracle recommends that DISM be turned off by default on SPARC-based servers. Oracle recommends that DISM should always be turned off on x86-based systems running Oracle Solaris 10. DISM is turned on by default for Oracle Database on Oracle Solaris, which makes it important for Database Administrators (DBAs) to understand its capabilities and behavior.

2.Introduction to ISM and DISM

     Since shared memory is very heavily used in Oracle Database environments, it is important to optimize access to it and to minimize the amount of CPU consumed while referring to it. With this in mind, a specially-tuned variant of System V Shared Memory was introduced in Oracle Solaris many years ago, called Intimate Shared Memory (ISM). ISM has been widely used for database shared memory since.

     Oracle Solaris Dynamic Intimate Shared Memory (DISM) provides shared memory with the same essential characteristics as ISM except that it is dynamically re-sizable. That means that DISM, if configured correctly, offers the performance benefits of ISM while allowing the shared memory segment to be dynamically re-sized, both for the sake of performance and to allow dynamic reconfiguration (for example, adding or removing memory from a system or a domain). When Oracle Database decides to use DISM, it invokes it automatically on your behalf by adding an optional flag – the SHM_PAGEABLE flag – when attaching to Oracle Database’s SGA shared memory segment (via the shmat(2) system call).

3.Potential DISM issues and Solutions

3.1 Oradism permissions are not setup correctly

     The correct way to install Oracle Database is to use the installer. If an existing installation is copied to another system using tar, cpio or similar utility. If the file transfer is not carried out with superuser privileges, the Oracle Database oradism process (ora_dism_<ORACLE_SID>) will not run with the correct permissions.

     While diagnosing if you see the below lines in the alert log then the entry indicates that Oracle was unable to start the oradism process with superuser privileges

WARNING: ——————————-
WARNING: oradism did not start up correctly.
Dynamic ISM cannot be locked. —————————————-
Exec of oradism failed. Error is 13: Permission denied
WARNING: Detected too many memory locking problems.
WARNING: Performance degradation may occur.


WARNING: ——————————-
WARNING: oradism not set up correctly.
  Dynamic ISM cannot be locked. Please
  setup oradism, or unset sga_max_size.
  [Diagnostic 0, 8, 268]


  • Always use the Oracle Database installer to create new installations
  • If instance migration is carried out; ensure that it is done with superuser privileges
  • If using NFS to mount Oracle Database binaries ensure that NFS mounts allow root access.


  • The simplest way is to set the correct group and permission for oradism.

File Path: oracle/<SID>/11202/bin/oradism


  • Unset sga_max_size from your parameter file and bounce the database. This should also fix the issue.

3.2 The oradism process terminates

     If the Oracle Database oradism process dies for some reason (which is unlikely unless a system administrator with superuser privileges kills it), all locked memory will be automatically unlocked. Performance will suffer accordingly. From the Oracle Database 10g release, oradism will be restarted if it dies. Unfortunately, though, the SGA locks will not be reestablished. In this case it is necessary to restart the database instance to ensure that SGA memory is correctly locked.


  • Avoid any situation that might lead to the oradism process being accidentally killed
  • If performance is very poor, yet oradism is running, and running with root privileges, check to see if SGA memory is not locked. If SGA memory is not locked, it will be necessary to restart the database.


  • If the oradism process dies in Oracle Database 10g and later releases, Oracle Database is able restart it. As with Oracle Database 9i, though, it will be necessary to shut down and restart the instance to achieve optimal performance.
1 Comment
You must be Logged on to comment or reply to a post.