Application Server 10.1.3 on SUSE LINUX Enterprise Server 9
This document is based on a previous one
on how to install as10gR2 on SLES9.
You should start from that document since the preinstallation
process is identical.
The differences are few and involves only the installation GUI so
the only porpuse of this document is to show the snapshots of the
installation process.
Note: The installed product is the preview release 4 (a beta
version).
Best if at "Selectyion installation type" you go for the third
option.










This session is, in my opinion, the most
interesting.
If you have followed the installation
procedure you have seen that it is required that no env variable should
be set so even LD_ASSUME_KERNEL which is usually an important part of
other product installation.
What does it mean?
LD_ASSUME_KERNEL specify which
implementation of the libc.so.6 (glibc) to use.
Normally three different version are installed on your system:
/lib/i686/libc.so.6
/lib/libc.so.6
/lib/tls/libc.so.6
this is made for compatibility with
older system.
so if you set LD_ASSUME_KERNEL to 2.4.21 (the usual set for SUSE) you
are going to use /lib/i686/libc.so.6
Let's go to a system where I installed a
database and issue the command:
oracle@brealmdbls01:~> lsof|grep
oracle|grep libc.so.6|head -n 5
tnslsnr 2612 oracle mem
REG 104,2
1321972 275270 /lib/i686/libc.so.6
tnslsnr 2627 oracle mem
REG 104,2
1321972 275270 /lib/i686/libc.so.6
tnslsnr 2628 oracle mem
REG 104,2
1321972 275270 /lib/i686/libc.so.6
tnslsnr 2629 oracle mem
REG 104,2
1321972 275270 /lib/i686/libc.so.6
oracle 2784 oracle
mem REG
104,2 1321972 275270
/lib/i686/libc.so.6
As you can see all the processes of the
orcle user are employing /lib/i686/libc.so.6
Doing the same test on the machine where
you have just installed the application server you'll get:
oracle@breoraasls02:~> lsof|grep
oracle|grep libc.so.6|head -n 5
sshd 3356 oracle
mem REG 8,2
1345545 950307 /lib/tls/libc.so.6
bash 3357 oracle
mem REG 8,2
1345545 950307 /lib/tls/libc.so.6
opmn 6980 oracle
mem REG 8,2
1345545 950307 /lib/tls/libc.so.6
java 7004 oracle
mem REG 8,2
1345545 950307 /lib/tls/libc.so.6
opmn 8509 oracle
mem REG 8,2
1345545 950307 /lib/tls/libc.so.6
The result is, as expected, not the same.
Then what are the differences between
the two libc.so.6?
If you use them as a command you'll
discover:
oracle@breoraasls02:~>
/lib/i686/libc.so.6
GNU C Library stable release version 2.3.3 (20040412), by Roland
McGrath et al.
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 3.3.3 (SuSE Linux).
Compiled on a Linux 2.6.5 system on 2004-06-30.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by
Michael Glad and others
linuxthreads-0.10 by Xavier
Leroy
GNU Libidn by Simon Josefsson
NoVersion patch for broken
glibc 2.0 binaries
BIND-8.2.3-T5B
libthread_db work sponsored
by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules
0.19 by Thorsten Kukuk
Thread-local storage support included.
pthread library is compiled with floating stack support enabled.
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
oracle@breoraasls02:~>
/lib/tls/libc.so.6
GNU C Library stable release version 2.3.3 (20040412), by Roland
McGrath et al.
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 3.3.3 (SuSE Linux).
Compiled on a Linux 2.6.5 system on 2004-06-30.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by
Michael Glad and others
NPTL 0.61 by Ulrich Drepper
GNU Libidn by Simon Josefsson
NoVersion patch for broken
glibc 2.0 binaries
RT using linux kernel aio
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules
0.19 by Thorsten Kukuk
Thread-local storage support included.
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
Mainly NPTL 0.61 by Ulrich Drepper are
used instead of the older linuxthreads-0.10 by Xavier Leroy.
In 10g we can see how heavily the
development as been shifted from processes to threads. Even the
listener changed:
oracle@brealmdbls01:~> ps -fe|grep
tnsl
oracle 2612 1 0 Mar20
? 00:01:59
/u01/app/oracle/product/10.1.0.3/db_1/bin/tnslsnr LISTENER -inherit
oracle 2627 2612 0 Mar20
? 00:00:00
/u01/app/oracle/product/10.1.0.3/db_1/bin/tnslsnr LISTENER -inherit
oracle 2628 2627 0 Mar20
? 00:00:00
/u01/app/oracle/product/10.1.0.3/db_1/bin/tnslsnr LISTENER -inherit
oracle 2629 2627 0 Mar20
? 00:00:00
/u01/app/oracle/product/10.1.0.3/db_1/bin/tnslsnr LISTENER -inherit
Four threads (I have 4 CPU) instead of a
process.
Since I had serious problems with SLES7
threads (linuxthreads-0.09) and RAC I'm wondering if the newer native
posix thread libraries should be used instead of the older. I can't
answer now since I need to test the behaviour of the systems using
different libc.so.6 but I feel I contributed somehow to a possible
misconfiguration of several DBs in the SUSE community.
Another worry concerns async I/O (RT
using linux kernel aio) but even here I need to investigate further.
Contact
information:
fabrizio.magni _at_ gmail.com