Generally, following the documentation is a good idea. It's not that bad and you'll get much better support from Oracle if you have. (I ended up breaking things -- and knowing it would -- by following the documentation for Oracle Applications. It was the only way to get decent support.)
This document is going to give an overview, but you should still have their documentation available.
As part of the installation Oracle will ask a number of questions. Generally they're not too difficult but let's see what I entered and why.
runInstaller
) as user
'oracle'.
/u01
, but I ignored that and put it in
/home/oracle
. Oracles advice, in this respect, is usually
worth following. Click 'Next' when you've entered the details.
/tmp/OraInstall/orainstRoot.sh
. Do as it says. (You may have
to run pdksh
or bash
in the 'Bourne compatibility mode' to
get it to complete successfully.) When you're done click 'Retry.'
Unfortunately, the CD that Oracle sent you was probably version 8.1.5.0.0. As with almost all first releases there are problems with that version (problems include empty files, so they're quite serious) and a patch, to version 8.1.5.0.2 is essential. You'll certainly need it to progress to the "Configuration" section of this HOWTO. The patch described here is a cumulative patch, i.e., it includes all the files required to move from version 8.1.5.0.0 to 8.1.5.0.2.
The file you need is on the Oracle web site and is relatively easy to install.
$ORACLE_HOME
).
mkdir /tmp/orapatch cd /tmp/orapatch
tar zvxf $ORACLE_HOME/patches/linux815patches.gz
./linux_815patches.sh
Note that it's important not to uncompress the file in the current directory. The patch installer checks that the correct number of files are present and fails if there are not the right number. Of course, if it finds the patch archive it finds too many files!
Add the following lines to your ".profile" (or whatever the equivalent is for your shell):
. oraenv export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
Quite why the Oracle installer doesn't do this I have no idea.
If you see "[: integer expression expected before -lt
" the next
time you log in, it's because 'oraenv' is expecting your ULIMIT to be
an integer rather than the default 'unlimited.' I've seen no ill
effects by ignoring the error, but you can fix it by setting the
ULIMIT to something finite.
Firstly, make sure that you're running the right version of the JVM. I don't know what Oracle do with their software, but it's very dependent on the version you use.
Secondly, it might help if, instead of running runInstaller
from
the root of the CD, you move into install/linux
and run the
runInst.sh
shell script instead.
This problem seems more common on RedHat 6.1 than 6.0 and could be something to do with a newer C library.
I've also heard reports that if you have the wrong version of Gnome's usual window manager, Enlightenment, you might get this problem. Upgrade or switch to another environment such as KDE or Fvwm2.
This is not an uncommon occurrence. Usually it means that you're running an old version of Enlightenment. Upgrading or switching to another environment should fix the problem.
A similar problem is the installation program vanishing at some later point in the process, often around 80% of the way through. The consensus seems to be that Oracle ran out of memory. You should increase the amount of swap space your machine has, anything over 200Mb should be sufficient.
Which version of the Java Virtual Machine are you using? People have claimed success with other versions, but most of the problems that I had disappeared when I downgraded to JRE 1.1.6v5, the one that Oracle recommends in their documentation.
Two other things that are worth mentioning: make sure you use the JRE and not the JDK and, secondly, you should be using "green" threads. Unless you've set THREADS_FLAG to 'native' you almost certainly have the correct setting.
You do have GLIBC 2.1 don't you?
The error message that I'm talking about looks a bit like this:
error in loading shared libraries: libclntsh.so.8.0: cannot open shared object file: No such file or directory
This is the same as NT complaining that it can't find a DLL. It's very easy to fix. Simply add the following line to the end of your ".profile" if you're using a Bourne-like shell (ask a local guru if you don't know):
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
Or use the following line if you're using a CSH-like shell:
setenv LD_LIBRARY_PATH "$LD_LIBRARY_PATH $ORACLE_HOME/lib"
I don't use the C-Shell, so independent verification of this command would be appreciated.
The answer to this took quite a bit of tracking down, although the answer is on the Oracle web site if you look hard enough.
The default configuration of Pro*C doesn't know where to find all its
libraries, so you need to tell it. After installation
$ORACLE_HOME/precomp/admin/pcscfg.cfg
is empty, but it needs
to contain the following:
sys_include=(/home/oracle/precomp/public, /usr/include, /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include/, /usr/include, /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include, /usr/include) include=(/home/oracle/precomp/public) include=(/home/oracle/rdbms/demo) include=(/home/oracle/network/public) include=(/home/oracle/plsql/public) ltype=short
(The first four lines above, from sys_include
to include)
should all be on the same line in the file.)
The Oracle documentation doesn't mention this, but you also need to
edit $ORACLE_HOME/precomp/lib/env_precomp.mk
. On the line
that defines CCPSYSINCLUDE
, put the following:
CCPSYSINCLUDE=sys_include='($(ORACLE_HOME)/precomp/public, /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include, /usr/include/g++-2, /usr/include)'
This works for RedHat 6.0, but may need tweaking for other distributions or later versions of RH.
This is tricky, barely documented by Oracle and common across all their products and installation programs. It's about time they did something about it!
Often what happens is as follows: you install Oracle Enterprise Edition and, as Oracle tells you, you dash off and install all the available patches. Then you decide you need the pre-compilers and install Oracle Programmer from the same CD.
Before you installed Pro*C your database worked, and now it doesn't.
The problem is that the versions of the pre-compilers that you installed were not patched and some of the Oracle server code relies on the fixes; Oracle's installer is so stupid that it will overwrite newer version of the same code.
The solution is not pretty. Since you can't extract an individual file from the CD you need to install the whole thing again, this time adding Oracle Programmer before the patch.