Oracle10g on Debian Linux howto

gust

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...
[color="#dd0000"]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:
[color="#0000a0"]Checking operating system version: must be redhat-2.1, UnitedLinux-1.0 or redhat-3
Failed
Solution: You should be able to just do
[color="#0000a0"]runinstaller -ignoreSysPrereqs
and then installer won't check for the operating system. Tip by Wim Coekaerts.
[color="#dd0000"]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:
[color="#0000a0"]ORA-27125: unable to create shared memory segment
Solution [color="#dd0000"]A: To enable hugetlbpages, first you need 2.6 kernel, and then you need to recompile it with the following config options enabled:
[color="#0000a0"]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:
hugetlbs-permitall.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:
[color="#0000a0"]echo "64" > /proc/sys/vm/nr_hugepages
Better yet, you can put the line like this in the /etc/sysctl.conf file:
[color="#0000a0"]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:
[color="#0000a0"]grep Huge /proc/meminfo
You should get output similar to this:
[color="#0000a0"]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 [color="#dd0000"]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
[color="#0000a0"]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.
[color="#dd0000"]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:
[color="#0000a0"]cd $ORACLE_HOME/bin
mv oracle oracle.bin
cat >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."
[color="#dd0000"]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
[color="#0000a0"]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.
[color="#dd0000"]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:
[color="#0000a0"]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.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/340/showart_62352.html