Re: A comp.databases.oracle.server FAQ

From: FM <fabrizio.magni_at_mycontinent.com>
Date: Tue, 24 Aug 2004 08:24:46 +0200
Message-ID: <412adf66$2@x-privat.org>

Howard J. Rogers wrote:

>>
>>Have you tried echo "1" > /proc/sys/vm/disable_cap_mlock?
>>
>>It didn't worked for me but I was on SLES9 and on a x86-64 architecture.

>
>
> No, I haven't tried that. I have no experience with SLES9 at all, so I don't
> doubt you. The thing I was talking about is rather different, I think,
> since it has to do with a new feature of the 2.6 kernel which is enabled by
> default called HUGETLBFS. You have to set an environment variable,
> DISABLE_HUGETLBFS=1, before invoking tools such as dbca... but you can't
> (apparently) just stick it in as part of your usual environment variable
> set. It needs to be in a wrapper script called 'oracle'. Details in the
> Google archive for this group (search for the thread "Help: 10g on Fedora
> Core 2, ORA-27125")
>
> Regards
> HJR
Testing now on SuSE Linux Enterprise Server 9:

echo 2048 > /proc/sys/vm/nr_hugepages

(Test if all is ok with /cat/proc/meminfo).

mount a hugetlb file system:

I have this in my fstab
hugetlbfs /dev/hugetlbfs hugetlbfs mode=0777,uid=59,gid=55 0 0

where uid is my oracle10g user and gid my dba group.

(have a look at hugetlbpage.txt in your kernel sources).

echo "1" > /proc/sys/vm/disable_cap_mlock

This last command should allow every user to use the hugetlbfs (from kernel 2.6.7 there is a /proc/sys/vm/hugetlb_shm_group).

Then open the instance. The DISABLE_HUGETLBFS=1 (and the wrapper) shouldn't be necessary anymore.

Look in /proc/meminfo to check in oracle is using the hugetlb.

-- 
Fabrizio Magni

fabrizio.magni_at_mycontinent.com

replace mycontinent with europe

Received on Tue Aug 24 2004 - 01:24:46 CDT