Oracle 10.1.0.3 x86-86 on SUSE LINUX Enterprise Server 9 x86-64


Since my last document lot of things changed: a new release of oracle was released, a new SuSE service pack for SLES9 and a new orarun.
For this reason I decided to write a new documentation which is going to explain how much easier is to install 10g on the SLES9 (and, of course, on SuSE Professional 9.2).

NOTE: The old (obsolete) document is kept online because it contains the solution of several common errors. It could be of help.

First of all make a clean SuSE installation and make sure to add this packages:

  • gcc,
  • glibc-devel,
  • make,
  • compat,
  • XFree86-libs,
  • libaio-devel,
  • libaio,
  • openmotif-libs,
  • openmotif.

And the 32bit counterparts. Example:
 

  • glibc-32bit,
  • glibc-devel-32bit,
  • XFree86-libs-32bit.

I prefer to add even these for the operating system administration (they are not mandatory!):

  • sysstat  (a must have!!!!),
  • namp,
  • bing,
  • iptraf,
  • traffic-vis,
  • smartmontools (keep your internal disks checked),
  • ntp,
  • strace,
  • nmap,
  • findutils-locate,
  • gdb,
  • ddrescue  (it saved my life a couple of times),
  • multipath-tools   (only if you are connected to a SAN),
  • lvm2.

It is now time to add orarun to simplify the subsequent oracle installation.
 

linux: # rpm -Uvh orarun-1.8-109.i586.rpm

This new version can be found here. It add a user “oracle” member of three groups: dba, oinstall and disk. The last group will be useful when dealing with raw devices (and ASM).
As always, in 10g, you don’t need the old gcc (gcc_old package) to relink the engine. Use the default one (gcc 3.3.3).

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
 

linux: # mkdir -p /u01/app/oracle/product/10g/db_1

Make sure to change the ownership of the tree with chown (the owner should be the oracle user while the group oinstall).
 

linux: # chown -r oracle:oinstall /u01/app/oracle

Now you can modify some files in /etc:
page
 

vm/disable_cap_mlock=1
vm/nr_hugepages=2048

  • /etc/passwd: change the shell for the oracle user created by orarun (default is /bin/false);
  • /etc/group: oracle user should already belong to dba, oinstall and disk;
  • /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 LD_ASSUME_KERNEL=’2.4.21′ (other value could be used: read Ulrich Drepper paper at http://people.redhat.com/drepper/assumekernel.html) and change LD_PRELOAD in LD_PRELOAD_32.
  • Important note: I prefer to unset LD_ASSUME_KERNEL and LD_PRELOAD after the installation. I’m still writing an article on the subject. The programs works better without those parameter (not necessary anymore from 10g on);
  • This part is not mandatory anymore! If you wish to use the hugetlb feature then follow these steps or refer to the relate document.

the nr_hugepages represents the memory you wish to allocate for oracle with the hugetblfs mechanism. Pagesize default is 2MB so you have to decide the right number for you.
The disable_cap_mlock is a workaround which permits to every user to use hugetlb.
Enable manually your changes with
linux: # sysctl -p
Remember to add boot.sysctl amongst your booting scripts (if not done yet):
linux: # chkconfig boot.sysctl on
(or doing it via yast: runlevel editor in expert mode).

Give a password to the oracle user:
 

linux: # passwd oracle

And connect with a new shell to this user.

Now launch this command:
 

oracle@brealmdbls02:~> /etc/init.d/oracle start

it will set the linux kernel parameters. It is done because the oracle universal installer is going to check them.

If you are installing from a remote location export the display:
 

oracle@brealmdbls02:~> export DISPLAY=<your local IP>:0.0

or better: connect via ssh with -X or -Y parameter:
 

oracle@localpc:~> ssh -Y oracle@brealmdbls02.ras

You X sessions will be securely tunneled via ssh and no export of the display will be needed.

You are now ready to install the oracle engine. 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 has to be issued by root).
  • /media/cdrom/runInstaller
  • 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.

Some images are easier to follow than pages of explanations:

I prefer and “advanced installation”.


Chose a location for the oracle inventory. The group oinstall should be the one in charge for installation and patching.

As root launch orainstRoot.sh (it modify the installation group).


Set here where you wish the engine to be installed (aka your ORACLE_HOME)

Which type of installation do you prefer? I’m for a custom one.

This is the screenshot of the prerequisite check.

If custom: what do you wish to install?

Group dba is in charge for “super user db administration”. Every user in this group can connect to your db without authentication.

Let’s create a DB later.

Installation started.

Another script launched by root.

Wait until the CRS is up and running then go on.

Setting the network. I prefer to skip waiting to have a database on the machine.

The error you get if you skip the network configuration.

You have finished the oracle engine installation.

Link the existing oratab to the one needed by oracle (from root):
 

linux: # ln -s /etc/oratab /var/opt/oracle/oratab


Now you are ready to create a database.

Good luck.

PS: Have a look at the documentation regarding Async I/O and hugetlb!!

Notes on cssd and ASM

By default the CRS is installed and started (see above).
Do you really need it?
If you are using RAC or the ASM then it is necessary otherwise you can comment this line:
#h1:35:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 </dev/null
in /eth/inittab.
Stop the daemon with /etc/init.d/init.cssd stop.

If you are using ASM, instead, the default configuration is wrong and after a reboot you could get a: ORA-29702 or ORA-29701.

What to do?

In /etc/oratab set at Y the DB you wish to be started automatically:

*:/u01/app/oracle/product/10.1/db_1:N
+ASM:/u01/app/oracle/product/10.1/db_1:Y
PITIA:/u01/app/oracle/product/10.1/db_1:Y

Then in /etc/inittab move the cssd line before the init 3 servicing:

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
# Starting Cluster Deamon for ASM
h1:35:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 </dev/null
l3:3:wait:/etc/init.d/rc 3
#l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

(make sure you don’t have two init.cssd lines).

Now you can test the reboot (in /etc/sysconfig/oracle you need to decide which components to start on reboot).

, , ,