The installation of Oracle 10g on SLES9 x86 is a lot easier than the one on AMD64 so this document is going to be a sort of cut and paste of the x86-64 version without the parts not needed due to thenative 32 bit architecture.
As always any feedback (even negative) can be sent to fabrizio.magni _at_ europe.com
Usual notes before starting:
As always I'd like to thank the people in the suse-oracle mailing list and people on comp.databases.oracle.server newsgroup.
My apolagize if the above steps are a cut-and-paste of the AMD64 documentation (I know it is boring but for me it is fastr than writing everything from scratch).
I don't wish to cover the operating system installation in this paper even because the installation is pretty easy.
I suggest you to chose the basic installation and then to add some packages later using yast.
Oracle, starting with 10g, suggest you don't use neither a filesystem nor rawdevices for your DB but ASM (I'll try to cover it later) but it is not mandatory so you can decide to switch back to the old cooked device or raw devices. The type of filesystem is up to you, your experience and tastes. There are several papers which covers performance for every fs flavour. Scalzo's one are the most popular. Have a look before deciding.
Personally I prefer ext3 for datafiles.
I preferred to recompile my own kernel due to problems with hugetlb, opteron architecture and numa support. You can skip this part.
Hugetlb are not an issue for 9i but they procure a headache on 10g. I haven't solved my issues on this topic yet but later I provide a good link with several solutions.
After installing the basic system make sure you have the libX, libaio, compat, libaio-devel and openmotif (even the 32 bit version).
compat-2004.7.1-1.2
XFree86-libs-4.3.99.902-43.22
libaio-devel-0.3.98-18.4
libaio-0.3.98-18.4
openmotif-libs-2.2.2-519.1
openmotif-2.2.2-519.1
Installing orarun make your installation easier so I recommend it. However read the notes below before installing.
Last version is orarun-1.8-31 and can be downloaded from suse website (actually their ftp).
Note on gcc:
gcc_old-2.95.3-11 is not necessary (as describe on some website). On the contrary the linking phase needs gcc 3.x!!!
So be warned: if you are going to install older gcc for anmy puprpose make sure oracle looks for the 3.x version during the relink.
Note on orarun:
Orarun is a useful package which can simplify the preinstallation part. However this rpm depends on gcc_old (read above) so if you want to use it you have two possibilities: install the old gcc and change your PATH variable for the oracle users or install it with --nodeps options.
Then modify the /etc/profile.d/oracle.sh deleting or commenting the lines referring to gcc295.
Create the directory tree for the oracle installation (look at the standard OFA): the default is /opt/oracle/product/10g/db_1.
I prefer /u01/app/oracle/product/10g/db_1
Make sure to chenge the ownership of the tree with chown (the owner should be the oracle user while the group oinstall).
Now you can modify some files in /etc:
vm/disable_cap_mlock=1 vm/nr_hugepages=2048
Reconnect to the machine with the oracle user and check if everything is ok.
If issuing a relink all you you get:
/app/oracle/product/10g/db_01/bin/relink: line 59: [: too many arguments
Then comment the line from 59 to 63 in /app/oracle/product/10g/db_01/bin/relink.
You are now ready to install the oracle engine. Insert the CD, mount it and run the installer:
Known issues:
If you can't access metalink then you can create your own patch as suggested by Jakub Jelinek (I found the trick on suse-oracle mailing list):
------- From Jakub Jelinek on 2003-11-21 16:49 -------
Try using some less buggy JVM.
Latest Sun JDK should work just fine for example.
Or, as a workaround for the buggy JVM, you can try:
gcc -O2 -shared -o ~/libcwait.so -fpic -xc - <<\EOF #include <errno.h> #include <sys/syscall.h> #include <sys/types.h> #include <sys/wait.h> pid_t __libc_wait (int *status) { int res; asm volatile ("pushl %%ebx\n\t" "movl %2, %%ebx\n\t" "movl %1, %%eax\n\t" "int $0x80\n\t" "popl %%ebx" : "=a" (res) : "i" (__NR_wait4), "0" (WAIT_ANY), "c" (status), "d" (0), "S" (0)); return res; } EOF --------------------------------------------------------
export LD_PRELOAD=~/libcwait.so
now you can install.
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:
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 relinking 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 dafeult, is 2MB so with 2048 you are allocating 4GB of your RAM for hugepages.
Check it in /proc/meminfo.
To allow every user to access the hugepages SuSE introduced a flag:
echo "1" > /proc/sys/vm/disable_cap_mlock
Otherwise your oracle user won't be able to allocate huge pages and you'll get errors when creating or starting an instance.
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).
Asynch I/O on SLES9:
Even on some documentation it is stated that aync I/O is enable by default: you should need only to relink the binaries with the command:
and set
filesystemio_options=setall in you spfile
which enable direct I/O plus async I/O.
Let's say that SLES9 at this stage seems to break async I/O compatibility with oracle (at least on 9i) so I'm pasting here the same advices I have written for the 9i mini-HOWTO.
A common error you could meet is:
ORA-27083: skgfrliopo: waiting for async I/Os failed
My guess is that the libc syscall(2) mechanism introduced by libaio 0.3.97 and above is not supported by oracle.
So my solution is quite simple. Download the sources of libaio 0.3.96-3 here, compile them with 'make' and then copy
libaio.a
libaio.so.0.1
in $ORACLE_HOME/rdbms/lib.
in this way you still have the libaio-0.99 shipped with SLES9 on your system but oracle uses the 0.96 you provided.
If you don't want to insert anything into your oracle installation tree you can create a directory wherever you wish and modify you LD_LIBRARY_PATH.
example:
A good reference for the problem is Simon Grabinar's webpage:
http://www.grabinar.com/simon/aio.html
Contact information:
fabrizio.magni _at_ gmail.com