To accommodate a change of strategy I needed to add an additional 20 disks to the current ASM instance I had running..This needed to be done in the shortest time possible, and when the Storage and Linux Admin where done, I could start and create the ASM Disks and diskgroups. Labeling the disks with
# oracleasm createdisk DATA099 /dev/lun99
went fine for all the LUNs, however when I wanted to created the disk groups in ASM, I was suddenly greeted by an
ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool", .... )
message..and there was no more possibility to add another disk group. This made sense, when checking the SGA of the running instance:
$ sqlplus / as sysasm sql> show parameters sga < output here>
Fortunately: the current disks/disk groups kept running despite the out of memory of the ASM. I’m not sure if this was by design, but I at least was happy it kept humming along, especially since this ASM instance hosts all the DEV/TST environments and they needed to keep running until we had a convenient time to shut all the databases neatly down.
There are at least two solutions to this issue:
A) Allocate more memory to the ASM instance with a shutdown.
B) Prevent this issue from happening in the first place by enlarging the memory before adding disks.
In my case I’m using AMM in conjunction with /dev/shm and not ASMM with HugePages. Make sure the /dev/shm can accommodate the new setting you plan to use, otherwise the instance won’t start at the next boot/restart of the instance!