Recently, we experienced an issue on our oracle database. The database is hung and the following error keeps occurring in alert file.
WARNING: oradism did not start up correctly.
Dynamic ISM can not be locked.----------------------------------------
oradism creation failed for unknown reasons 0 8 500
My research hits the oracle document ID 1074905.1 “WARNING: Oradism did not start up correctly – Reported in the Alert.log”. This document recommends to correct the mount points. After checking the system error log, we didn’t find typical error, for example,
[ID 809163 kern.info] NOTICE: oradism, uid 303: setuid execution not allowed, dev=13b00001770
Another document “When Will DISM Start On Oracle Database? (Doc ID 778777.1)” talks about “Oracle will use DISM instead of ISM if SGA_MAX_SIZE is set larger than the total of the database buffers (in particular, db_cache_size dynamic SGA resizing is not supported with the older db_block_buffers parameter), the shared pool, the redo buffers, the large pool, the Java pool, the fixed size.” Just simply followed this suggestion, the error message “WARNING: oradism did not start up correctly” is gone.
When Will DISM Start On Oracle Database? (Doc ID 778777.1)
Dynamic intimate shared memory (DISM) is a unique feature of Solaris. It achieves dynamic memory management. On other OSs, When you specify SGA_MAX_SIZE, then the complete size of SGA_MAX_SIZE is reserved from your memory (reserved from Swap not from physical RAM) at instance startup. Then you can dynamically increase SGA_TARGET size until you reach SGA_MAX_SIZE. On Solaris, however, and due to DISM feature, SGA_MAX_SIZE is not reserved from the memory at instance startup but it is allocated when needed. This presents a great value since you do not reserve memory you are not using.
The use of DISM requires that the ora_dism process starts. The process will not start unless SGA_MAX_SIZE is greater than sum total of all SGA components. This means that in case you use SGA_TARGET. you specify size of SGA_MAX_SIZE greater than SGA_TARGET.
**For 11g only**
Oracle Database also uses DISM
if it is available on the system and MEMORY_TARGET
is set by the user.
By default, SGA_MAX_SIZE is not set during database installation and hence it takes the same value as SGA_TARGET. The use of SGA_TARGET is not a necessity to use DISM. Oracle will use DISM instead of ISM if SGA_MAX_SIZE is set larger than the total of the database buffers (in particular, db_cache_size dynamic SGA resizing is not supported with the older db_block_buffers parameter), the shared pool, the redo buffers, the large pool, the Java pool, the fixed size. In this case you will need to check the total of following parameters:
The difference between the total and the SGA_MAX_SIZE is so small that it can be approximated in calculations related to Granule size, so DISM should not be started, otherwise the ora_dism process will be started. .
Please note that to use DISM, you must have ISM enabled (which is the default case on Oracle 10g/11g). You will need always to check parameter:
Also done following suggestion.
“11g: ORA-609 TNS-12537 and TNS-12547 or TNS-12170 in 11g Alert.log (Doc ID 1116960.1)”
For that reason, we often recommend increasing the values for INBOUND_CONNECT_TIMEOUT at both listener and server side sqlnet.ora file as a preventive measure. If the problem is due to connection timeouts, an increase in the following parameters should eliminate or reduce the occurrence of the ORA-609s.
These settings are in seconds. Again, the default is 60. A setting of 120 seconds should resolve most if not all ORA-609 errors.
As explained in the Cause section, The ORA-609 error is thrown when a client connection of any kind failed to complete or aborted the connection process, so ORA-609 and TNS- errors are expected while shutting down the database – as client connection will fail to complete or aborted the connection process before the connection/authentication process was complete. So please ignore the ORA-609 and TNS- errors, if these are appear while database instance is shutting down.