Using HUGETABLE in oracle and “ORA-27125: unable to create shared memory segment”
On SLES9 hugetlb is enable by default and it could cause you problems.
A good resource to resolve this kind of issue can be found here:
http://linux.inet.hr/oracle10g_on_debian.html
However on oracle9i if you wish to use this feature (without the DISABLE_HUGETLBFS=1 trick) you will need patch #3386122 from metalink which is available for x86 only. I asked a backport for x86-64 but I’m still waiting.
On 10g you don’t need any patch.
The common way to avoid ORA-27125 on 10g is to disable hugetlb with:
linux: # cd $ORACLE_HOME/bin
linux: # mv oracle oracle.bin
cat >oracle <<“EOF”
#!/bin/bash
export DISABLE_HUGETLBFS=1
exec $ORACLE_HOME/bin/oracle.bin $@
EOF
linux: # chmod +x oracle
This is necessary because the env variables aren’t passed to the oracle command by java applications such as dbca (otherwise to define DISABLE_HUGETLBFS=1 in your environment should be enough).
If you are experiencing:
ORA-12547: TNS:lost contact
this is likely due to a wrong wrapper generation. Make sure you didn’t create the file above with “vi”. Use “cat” instead.
(Another cause could be a wrong re-linking phase. Check if “relink all” works correctly).
But why not to use this new kernel feature?
To allocate huge pages do:
echo 2048 > /proc/sys/vm/nr_hugepages
A page, by default, is 2MB so with 2048 you are allocating 4GB of your RAM for hugepages.
Check it in /proc/meminfo.
There is even the chance to mount a hugetlb file system.
Create a mount point:
mkdir /dev/hugetlbfs
and mount it:
mount -t hugetlbfs -o uid=55,gid=59,mode=0777 hugetlbfs /dev/hugetlbfs
This last bit is not mandatory but can be useful for debugging and advanced management.
Now you don’t need anymore DISABLE_HUGETLBFS=1 or a wrapper for the “oracle” command.
To make the changes permanent insert these lines into /etc/sysctl.conf
vm/nr_hugepages=2048
vm/disable_cap_mlock=1
And this into /etc/fstab (only if you wish to mount a hugetlbfs).
hugetlbfs /dev/hugetlbfs hugetlbfs mode=0777,uid=59,gid=55 0 0
This will allow your oracle user to access the memory in a way similar to the shm mechanism.
If you don’t want to reboot your machine you can issue these commands:
sysctl -p
mount -a
which set all the variables in sysctl.conf in your proc and mount all the file systems listed in fstab.
To check if your instance is using hugetlbfs use
cat /proc/meminfo |grep Huge
HugePages_Total: 1024
HugePages_Free: 940
Hugepagesize: 2048 kB
The value of Total and Free should be different.
If you are using a kernel without the patch for disable_cap_mlock then there is another solution (maybe next SLES9 kernels will include it).
From kernel 2.6.7 place in you sysctl.conf the following lines:
vm/nr_hugepages=2048
vm/hugetlb_shm_group=55
Where hugetlb_shm_group contains the gid of the oracle group (usually dba).
It is a more secure way to access hugetlb than with disable_cap_mlock.
If you encounter:
ORA-00385: cannot enable Very Large Memory with new buffer cache parameters
Then you have use_indirect_data_buffers=true in your spfile. Set it to false (I still haven’t found a way to use HUGETLB and use_indirect_data_buffers=true).