Oracle10g on Debian Linux howto

Is running Oracle10g on Debian Linux possible? Oh yes, definitely! And it runs great, really. It's even easier to install than older versions of Oracle as there are no problems with incompatible libc library & other bugs. You need to make just two simple preparations before you can enjoy your new development database.

Important note: I tested this only on the Debian unstable distribution and only with the 2.6 kernel, as that's what I'm running. I believe that most of you that are running Debian unstable are also running the newest stable kernel, so that shouldn't be a problem, right? Let's go step by step...

---

1) As Oracle10g is certified only on Redhat Enterprise Linux and United Linux you will get this error when you run Oracle's runInstaller, and installation will stop:

Checking operating system version: must be redhat-2.1, UnitedLinux-1.0 or redhat-3

Failed <<<<

Solution: You should be able to just do

runinstaller -ignoreSysPrereqs

and then installer won't check for the operating system. Tip by Wim Coekaerts.

2) Oracle10g is able to utilize so called hugetlbpages, a feature that was added in the 2.6 Linux kernel, but is also available as a backport in RHEL 3 (which uses 2.4 kernel). Feature is enabled by default. Effectively, instead of using standard 4KB pages (on standard 32bit x86 architecture), with hugetlbpages functionality enabled pagesize will rocket to 4MB and thus save you a lot of CPU cycles which would otherwise be spent managing many smaller pages. Second good thing is that it will save some of your precious physical memory because there will be less pagetables for kernel to worry about. That is more true as you have more memory dedicated to the database and/or more clients connected to it. Trying to run Oracle installation on a standard Linus kernel you will get you the following error during creation of the initial database:

ORA-27125: unable to create shared memory segment

Solution A: To enable hugetlbpages, first you need 2.6 kernel, and then you need to recompile it with the following config options enabled:

CONFIG_HUGETLB_PAGE=y
CONFIG_HUGETLBFS=y

The second one is not strictly needed, but it won't hurt.

You will also need this small patch:
It enables ordinary users (beside superuser) to create and allocate hugetlbpages. It might be a security risk, so be careful! After you reboot your newly compiled kernel, there's one more thing you need to do. Now that you have enabled hugetlbpages support, you need to tell kernel how many pages you will need. You can do that manually like this:

echo "64" > /proc/sys/vm/nr_hugepages

Better yet, you can put the line like this in the /etc/sysctl.conf file:

vm/nr_hugepages = 64

and then you will get your hugetlbpages after every reboot. It is quite important to request hugetlbpages shortly after boot, before system memory gets fragmented. To check that you have succeeded, run:

grep Huge /proc/meminfo

You should get output similar to this:

HugePages_Total:    64
HugePages_Free:      0
Hugepagesize:     4096 kB

As you can see, my Oracle is happily running (there are 64 pages in total, but none of them is free because Oracle has allocated all of them).

In my example I have configured Oracle to use slightly less than 256MB of memory for its SGA (Total System Global Area 264241152 bytes). That is deliberate as I have dedicated 256MB of memory to hugetlbpages (64 pages * 4MB page = 256MB). You'll need to figure out for yourself how much memory you're willing to let Oracle database use. Keep in mind that the memory allocated to hugetlbpages is unavailable to the rest of the system!

Solution B: You can also disable hugetlbpages and thus save you some hassle. Theoretically, you'll loose some performance too, but don't loose sleep over that fact. Just do

export DISABLE_HUGETLBFS=1

before starting installer or dbca or whatever. Then Oracle won't use SHM_HUGETLBFS in shmget(). Another fine tip by Wim Coekaerts.

3) David Mansfield reports that when creating initial database using dbca, he gets the ORA-27125 error. He figured out why: "dbca (a java program) needs to startup the oracle binary to create the instance. When it starts it (and fails) you can verify using /proc that the environment DOES NOT contain the DISABLE_HUGETLBFS=1 environment variable. For some reason, java drops this environment variable, and hence the startup fails."

He also offers a solution for this problem:

cd $ORACLE_HOME/bin
mv oracle oracle.bin
cat >oracle <<"EOF"
#!/bin/bash

export DISABLE_HUGETLBFS=1
exec $ORACLE_HOME/bin/oracle.bin $@
EOF

chmod +x oracle

He adds: "In fact, this only needs to be done when creating the database (under dbca). After the creation is done, and further startups occur from the shell, there is no problem."

4) Starting with the 2.6.7 kernel, kernel developers have added /proc/sys/vm/hugetlb_shm_group control over who can allocate hugetlbpages. I presume this means that my patch above is not needed anymore, and that you need just to

echo "" > /proc/sys/vm/hugetlb_shm_group

to get Oracle working with hugetlbpages enabled. But I haven't tried it myself, please report if it works for you.

5) This last tip is not for Debian users, but I'll put it anyway because it might help some Suse 9.1 user. People on the various forums report that the following works for Suse 9.1:

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

I haven't personally tested this tip either and can't help if it doesn't work for you because I don't have any experience with Suse Linux. Thanks for this tip goes to Ulrich Dunnebeil.