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.
1.Introduction
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 11.2.0.1 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.
OR
WARNING: -------------------------------
WARNING: oradism not set up correctly.
Dynamic ISM cannot be locked. Please
setup oradism, or unset sga_max_size.
[Diagnostic 0, 8, 268]
----------------------------------------
Recommendation
Solution
File Path: oracle/<SID>/11202/bin/oradism
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.
Recommendations:
Solution
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
36 | |
7 | |
5 | |
5 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |