<stephen@zx81.org.uk>
Linux is well known for being difficult and, generally, user hostile. Being a bit of a Unix fan I'm not sure whether I agree with that or not.
Oracle is similar I guess. Initially it's difficult to get to grips with, but it's difficult to work with any other RDBMS when you're used to it.
Combine the two, remember that 8i is only the second production release, and you realise that this isn't going to be straight-forward, even if you're familiar with both.
I am, but I had problems. Many problems were my own stupidity or hubris, but I document them for completeness.
First, this document is for people who want to install Oracle 8i version 8.1.5 on Linux. It does not cover any earlier versions. If you want to install 8.0, I recommend you try Linux Journals guide, and if you want to install any of the previous versions you're going to have to use the SCO version and follow Paul Haigh's Oracle Database HOWTO.
If you're trying to install the 'right' version, here is a little of my back-ground. Clearly if yours is similar we're going to be on the same wave-length.
I'm assuming that you have a certain amount of knowledge in this area. Even installing Oracle isn't a trivial exercise, so I don't intend writing a 'press this key now' type of guide. If you want this kind of 'dummies guide,' neither this HOWTO nor Oracle are probably the right thing for you.
Things move quickly in the world of Linux and Oracle, meaning that this document can quickly get out of date. If this document is more than a month or two old, I suggest you take a look at my web site for an update.
You get what you pay for. I offer no warranty of any kind, implied or otherwise. I'll help you where I can but legally you're on your own.
This HOWTO has been written by Stephen Darlington. It couldn't have been created without the constant stream of questions and answers on Oracle Technet and the Usenet news-groups. So thanks to the people that keep posting and sorry that I can't credit you all individually!
Thanks to the following people, in no particular order, for their contributions to this document: Ton Haver, Guy Cole, Iain Frerichs, Albert Braun, Steve Morando and Krill Kokoshka.
I welcome any constructive feedback on this HOWTO and any general Linux or Oracle issues. Email me at stephen@zx81.org.uk.
This document is copyright 2000 Stephen Darlington. You may use, disseminate and reproduce it freely, provided you:
These restrictions are intended to protect potential readers from stale or mangled versions. If you think you have a good case for an exception, ask me.
(This copyright notice has been lifted from Eric Raymond's Distribution HOWTO.)
In this section, we'll set up Linux so that you're in a position to get Oracle 8i from the CD that they sent you into your hard-disk.
The Oracle installation process begins when you've built your PC, installed Linux, configured it and connected it to your network.
I think that the most important part of the prerequisites is not to underestimate them and, as far as the software is concerned, not to differ unless you have to.
My sad tale is as follows:
Oracle seem to have done most of their development on RedHat Linux. For a fuss-free installation, do the same. I've heard horror stories about trying to get it installed on other distributions.
I used a fairly vanilla RH6 setup and had very few problems. I downloaded and installed the JRE version 1.1.6v5, added all the patches up to August 1999 and upgraded the kernel to 2.2.13, but that was in order to support my network card. I have no reason to suspect that Oracle won't work with the RedHat supplied 2.2.5 kernel.
Note, the Oracle installer seems to be hard-coded to expect the JRE
executable to be at /usr/local/jre/bin/jre
. While this
doesn't mean that you have to install it there (see below), it does
mean that you can't get away with using the JDK. This is an important
point so I'll repeat it: you must use the JRE, the Oracle installer
won't work with the JDK!
I performed the following steps to get a working copy of the JRE:
cd /usr/local
bzip2 -d -c jre-1.1.6-v5-glibc-x86.tar.bz2 | tar xvf -
ln -s jre116_v5 jre
As for the hardware, once you get above a certain 'base' level Oracle should work on almost any hardware you get get Linux running on. My system, for reference, is an Intel Celeron 466Mhz with 128Mb memory, an 8Gb hard-disk and a DM9102 network card. This is not a machine for heavy database applications, but is perfectly sufficient for a small test or development system.
As mentioned in the previous section, Oracle do their development using RedHat 6.0, so for a hassle-free installation this is what you should probably use.
But what options do you make and which of the vast number of packages need to be installed to make Oracle work?
Firstly you need two to three times the amount of memory you have for your swap space. (You'll need around 200Mb of memory, real or virtual, just to run the installer!) Note that contrary to popular opinion, Linux swap partitions can be larger than 128Mb.
The arrangements of your other partitions can also be important. Make sure that the Oracle software is on a different partition to your operating system, and make sure that the Oracle data-files are on yet another partition. The idea here is to make sure that your data-files do not get fragmented. (In a live environment, you're likely to have a number of disk with Oracle spread across them. There are a number of good books that you consult for more information on this.)
As for the software, I took the easy option and installed just about everything. You certainly need all the 'base' packages, X Windows (the installation routine is a Java GUI) and the development tools regardless of whether you intend doing any coding or not. Compared to the size of Oracle and your databases a Linux distribution is tiny, probably less than a gigabyte. It's worth installing it all for an easy life!
The documentation suggests that you make changes to the Linux kernel so you can get more shared memory. Since this is so difficult in Linux (unlike most commercial Unix's you have to recompile the kernel), the approach I took was to go ahead with the installation anyway. The default RedHat Linux settings worked, although you may have to change them for a larger development or production system.
Note that some people have had to recompile the kernel to get Oracle to work at all. I guess it must depend on the other software that you're running on the same machine.
Follow the instructions in the Oracle documentation (on the installation CD in HTML format) and the Linux Kernel HOWTO to build your new kernel.
Using LinuxConf (or whatever other method you feel comfortable with), you need to add a new group called "dba" and a new user called "oracle", which should belong to your newly created "dba" group.
You can make any other user a DBA by putting them in the DBA group. If you have several DBA's this is probably a good idea for auditing purposes.
I would recommend that you do use 128Mb of RAM or more. I think it would be difficult to get any serious work done with less.
However, if you disable the Java option and set all the shared memory settings to be relatively small, there's no reason why it shouldn't work. I've heard success stories with 64Mb. You're probably not going to get away with 32Mb, though.
There is a caveat. You may only need half of what Oracle recommends to run the thing, but to install it their number starts to make sense. I've heard reports of the installer using 150Mb of memory and I've seen it well over 120Mb myself. If you have 64Mb or less of memory, make sure you have lots of swap space and patience.
An alternative that should work is as follows (although I've not
had chance to test it): install Oracle on another, bigger machine and
copy across the $ORACLE_HOME
directory. If you have all the same
users and groups I can't see why if wouldn't work.
I'm still running 6.0 myself, so all I can say is that a number of people have claimed success with this configuration.
At the time of writing, Oracle 8i has been certified with RedHat 6.0 and "Certification for other distributions is currently in progress" (Oracle 8i Patch FAQ).
Oracle specify the Linux kernel version 2.2 or above and GLIBC version 2.1 with any window manager. In theory, any distribution that meets these requirements should work.
In practice, Oracle may not support it and you may have more problems trying to complete the installation. Unless you have a very good reason to do otherwise I suggest you stick to RedHat 6.0 with all the patches you can get hold of.
There's no obvious reason why it shouldn't work -- I used 2.3.19 for a while because it supported my network card and the stable kernel at the time didn't -- but unless there's a pressing need it's certainly safest to stay well clear. I switched back to the stable series as soon as the driver was included.
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.
Hopefully you followed the advice from the previous section and didn't create a database.
For most people, I can probably outline the process in a couple of words: "Run 'dbassist'." Unless this is the first time you've ever run Oracle, none of the questions should really phase you.
For completeness, I'll document what I did but I'd best say what I was aiming for first. Bottom line: this is neither a production system nor a 'serious' (i.e., several people, full time) development box. I installed 8i to play around and see what was new or different from 8 and older versions.
This means that when 'dbassist' offered an easy option I took it. And
when it suggested using a different disk, or at least a different
partition, I declined. My $ORACLE_HOME
is
/home/oracle
. All the data files and software are in there,
all on one partition.
dbassist
cd $ORACLE_HOME/dbsYou now need to edit a file called "init<SID>.ora" ("initdev1.ora" in my case). About half-way down the file is a commented out line looking something like this:
# rollback_segments = (r01, r02, r03, r04)Uncomment this line (remove the hash), save the file and you're done.
MANAGER
'. (It seems to be
conventional to put Oracle passwords in uppercase. In fact passwords
are not case sensitive.) I recommend you change it straight away by
typing password
at the SQL*Plus prompt. (For people expecting an
ALTER USER
command, this is new to the version of SQL*Plus
supplied with 8i.)
The other password that you need to know is the one for SYS. It
defaults to 'CHANGE_ON_INSTALL
' and you should do exactly what it
says!
sqlplus
system/<password>
). Then type:
@?/sqlplus/admin/pupbld.sqlThe question-mark is an alias for the
$ORACLE_HOME
directory.
And that's it. You should now have an operational database that you can log into using SQL*Plus.
Yes and no. If you're just playing around, building a database for yourself to learn the new features of 8i, then 'yes.' The database the above instructions will build is complete and will work fine.
However, if you know anything about Oracle, you will quickly realise that the default configuration is appallingly bad. If you're making a serious, production system I recommend you use the "Custom" option.
Even for my toy system I did some tweaking. I increased the sizes of most of the table-spaces and changed them so that they didn't grow automatically (I hate software when it tries to be too clever).
No and it will work fine if you don't, but I don't recommend putting all your files on the same disk nevertheless.
Spreading the files over a number of disks, even it's just the data files on one and the rollback segments on another, will have a significant performance advantage. Read an Oracle DBA book if you need further information.
Caused by several zero-length files in the initial installation. Following the patch procedure will fix this problem.
To cut a long story short, your $ORACLE_SID
is probably set
incorrectly or not at all. Make sure it's set to the same value you
gave 'dbassist' and that it's value is exported (i.e., export
ORACLE_SID
in any Bourne compatible shell).
This is a very common error, and there are a number of different things that cause it.
Firstly you'll want to make sure that you're not creating a Shared Server configuration (sometimes known as MTS). Create a database using Dedicated Server and convert it later.
If that's not it, check your NLS_LANG
environment variable. The
easiest option is to unset it. If you really want to use it, make sure
that you have it exactly right. Make sure you don't transpose any '1's
(one's) for 'l's (the twelfth letter of the alphabet)!
Congratulations, you have Oracle running on your Linux box. You have created a database and can connect to it using SQL*Plus.
Of course, this is not the end of it. Ideally, you'd be able to connect to it as another Unix user or from a completely different machine. That is what this section is for.
Some of the details in this section are a little sketchy as this is not a configuration that I personally use. However, performing one of the following steps should work:
. oraenvif you run a Bourne-like shell (like Bash or pdksh)
source coraenvif you prefer the C-Shell
When running "oraenv" I get an error if I use 'bash', the default Linux shell. It seems not to cause any problems so don't worry. You can always use 'pdksh' if it does worry you.
I remember this being very complex with earlier versions of Oracle, but just seemed to work here. I'm sure that must mean that I did something wrong, forgot something I did or that there's a massive security hole.
This is what I remember doing:
$ORACLE_HOME
is set correctly)lsnrctl start
On your client machine all you need to do now is point it at the right machine and database instance.
If you want more control over the process, the "Net8 Configuration Assistant" ('netec') should be able to help.
This used to be very difficult in many earlier version of Oracle, involving editing many text files, most of which had an fantastically complex syntax.
But in 8i, if you've got your JVM working, then all you need is the "Net8 Easy Config" program. Follow these steps to allow your machine to connect to a database on another machine:
netec
at the command
prompt while logged in as 'oracle.'
If you want more control over the process, you may need to use the
"Net8 Assistant" -- a big window with many confusing options -- which
can be started with the netasst
command.
The problem is with a couple of zero-length files. Installing the patch should fix this problem.
Now that you've managed to get Oracle installed, you'll want to try and use it. Although it's possible to do everything from your server PC, it's generally best to user the client-server facilities and use another machine to access your database.
Naturally Oracle have a large collection of, largely, pretty good client software, however there's not much for Linux at this time. Of the Oracle software, I recommend getting hold of the following:
But most of the best software comes from other places...
I seem to get most of my Oracle information from colleagues and books. I'm not able to give away my colleagues, but the books I recommend are as follows:
You'll note a bit of an O'Reilly theme there. I've not found a bad O'Reilly book yet. Similarly, I've never found a good Oracle Press book.
There's a lot of useful stuff on the web.