This mini-HOWTO will cover the installation of oracle on SLES9 (SUSE LINUX Enterprise Server 9) for x86 and AMD64 architectures.
If you find any error imprecision or simply you have suggestions (or you need help) feel free to contact me at fabrizio.magni _at_ europe.com

Some notes before starting:
 

• 9i is only available (at this moment) as 9.2.0.4 for AMD64 (x86-64) so you don't have many installation choices;
• on this website you can find the 10g installation for 32 bit only on AMD64 because oracle haven't yet released a version for AMD64.
• the x86-64 architecture allow 64 and 32 bit applications to live together even if you have to follow some more step for installing and using the 32 bit part.
• SLES9 for AMD64 can be downloaded both from novell and SuSE portals.
• Oracle 9.2.0.4 for x86-64 is available from OTN.

As always I'd like to thank the people in the suse-oracle mailing list and people on comp.databases.oracle.server newsgroup.
I wish to thank Simon Grabinar and Joel Backer for their support on the asyncronous I/O.

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.
For the filesystem I won't open a religious war for the type and number of partitions. The test were made on reiserfs only for a wrong installation. Personally I prefer ext3 for this kind of systems (even because reading http://lse.sourceforge.net/io/aio.html reiserfs is not supported for aio on direct I/O).
I preferred to recompile my own kernel due to problems with hugetlb, opteron architecture and numa support. You can skip this part.

After installing the basic system make sure you have the libX, libaio, compat, libaio-devel (even the 32 bit version).
compat-2004.7.1-1.2
compat-32bit-9-200407011229
XFree86-libs-4.3.99.902-43.22
XFree86-libs-32bit-9-200407011229
libaio-devel-0.3.98-18.4
libaio-32bit-9-200407011229
libaio-0.3.98-18.4
libaio-devel-32bit-9-200407011229

Installing orarun make your installation easier so I reccomand 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) for installing 9.2.0.4. 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.
In any case you should modify the /etc/profile.d/oracle.sh deleting or commenting the lines which refer to gcc295.

Create the directory tree for the oracle installation (look at the standard OFA): the default is /opt/oracle/product/9ir2.
I prefer /u01/app/oracle/product/9ir2
 

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:
 

• /etc/passwd: change the shell for the oracle user created by orarun (default is /bin/false);
• /etc/group: oracle user should belong to dba and oinstall;
• /ets/sysconfig/oracle for ORACLE_BASE, ORACLE_HOME, ORACLE_SID and several kernel parameters plus the starting parameter for the oracle script in /etc/init.d (useful during machin boot).
• /etc/profile.d/oracle.sh (or oracle.csh depending on the shell you chose above). Make sure to set LD_ASSUME_KERNEL='2.4.20' (other value could be used: read Ulrich Drepper paper at http://people.redhat.com/drepper/assumekernel.html) then comment the lines about gcc 295 (see notes on old_gcc, below).
• comment the following line in /etc/init.d/oracle:
  #test -d /lib/i686 && export LD_ASSUME_KERNEL=2.2.5
  or change it in
  test -f /lib64/libc.so.6 && export LD_ASSUME_KERNEL=2.4.20

Reconnect to the machine with the oracle user and check if everything is ok.

Now you can insert the CD, mount it and run the installer:
 

• mount /dev/cdrom (if you didn't insert oracle in the cdrom group then the command ahs to be issued by root).
• if you are in a remote machine make sure your X server is running and export the DISPLAY: export DISPLAY=<your local IP>:0.0;
• /media/cdrom/runInstaller -ignoresysprereqs

Known issues:

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

--------------------------------------------------------

Asynch I/O on SLES9 (9.2.0.4)

Let's say that SLES9 at this stage seems to break async I/O compatibility with oracle.
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:
 

Then relink the binaries with the command:
 

and set

filesystemio_options=setall in you spfile
which enable direct I/O plus async I/O.

A good reference for the problem is Simon Grabinar's webpage:

http://www.grabinar.com/simon/aio.html

Reported Issues:
 

Rainer Kaluscha (rainer.kaluscha _at_ uni-ulm.de) reported and solved three issue met on this same architecture.
With his consent I'm pasting the piece of mail covering them. Thank you Rainer!

I encountered 3 problems not mentioned there. The solutions 
may be interesting for others so you might want to include them in 
your howto:

1. The database assistant refused to create a database with charset 
WE8ISO8859P15 - only WE8ISO8859P1 works ...

2. ulimit: the user oracle had a limit on file size - so I ran into 
trouble when a datafile grew beyond 4GB ...
ulimit -f unlimited cured this (alternatively, one could probably 
also use osh)

3. The third one was trickier: I'm using the Intermedia text option. 
The INSO filtering utility ctxhx couldn't be linked because only a 
32bit version of ctxhx.o is present, the libraries are in 
$(OH)/ctx/lib32 and the makefile ins_ctx.mk is ignorant on that.

As ctxhx only works as a filter for temporary files I tried an 
executable from a 32bit machine. However, that one also had a (known) 
bug (undefined symbol: stat). By creating a dummy stat.c (cmp. 
http://www.lyranthe.org/diary/archives/2002/02/ctxhx_with_linu.html) 
like this:

/*
     workaround for bug: undefined symbol: stat
     provides a function stat instead of inlined code
*/

#include <sys/stat.h>

/* extern __inline__ */ int stat (__const char *__path,
                 struct stat *__statbuf) __THROW
{
   return __xstat (_STAT_VER, __path, __statbuf);
}

and including it into ins_ctx.mk *before* the INSO libs:

ctxhx: $(CTXHXOBJ) $(ORACLE_HOME)/ctx/lib/stat.o
     $(LINK) $(CTXHXOBJ) $(ORACLE_HOME)/ctx/lib/stat.o $(INSO_LINK)

I was able to link and run ctxhx on the 32bit machine.

Copying the executable to the 64bit machine and including the 32bit 
libraries in LD_LIBRARY_PATH did the trick. You might have to set an 
s-bit on ctxhx as it runs with the current user id while Oracle 
create the temporary files with owner/group oracle:dba ...

Contact information:
fabrizio.magni _at_ gmail.com