centos 4.2 install oracle9i

Installing 9i Release 2 on Centos 4.2 (and hence on RHES4 generally)

Submitted by on August 1, 2006 - 23:02.

1.0 Introduction

Before you can get started learning how to administer Oracle, you'll need to install it. On Windows, this crucial step generally involves clicking [Next] half a dozen times, and making yourself a cup of tea (and I'm only half-kidding!). On Linux, and Unix generally, however, things are nowhere near as simple, and much depends on preparing things correctly if the Oracle installation is to go smoothly -and it's to document those preparation steps properly that I've written this article.

Of course, anyone that decides to install Oracle on Linux has to answer the question: what Linux distro should be used? My usual answer to that question has long been 'Red Hat Enterprise Server 3 or 4, or a free clone thereof', for the simple reason that you won't find Oracle installed on much else by way of Linux distros in the real world. It might be fun getting Oracle working on Mandriva 2006, Mepis, Fedora Core 4 or what have you (or even on something like FreeBSD), but you won't ever see those platforms in a production server room, so really: what's the point?

The proper Red Hat Enterprise Server software costs real money, though -quite a lot of it, in fact. So in this article I'm going to be using one of those free clones of it I just mentioned. Specifically, I'll be using a copy of Centos 4.2, the latest version of the Community Enterprise Operating System, which for no cash at all. Centos is compiled from Red Hat's own source code (which has to be made freely available to anyone that wants it, of course: the beauty of the GPL), so it's as identical to the real thing as you can reasonably get.

There are a lot of other Red Hat clones out there: , for example; or ; or ; or ... You can use any or all of these if you choose, and the instructions in this article will be equally as applicable to them as to Centos - or indeed to Red Hat Enterprise Server 4 itself. I happen to like Centos these days because a good support community has built up around it, and it therefore isn't quite the one-man-band affair that, say, White Box seems to be. But that's not to disparage those other distros, so if you're using those instead, keep on doing whatever suits you!

You will no doubt have noticed, too, that this article is about installing Oracle version 9i -and it's reasonable to ask why I'm documenting the installation of an "old" Oracle version, rather than the shiny new 10g! Well, the answer to that comes in three parts: first, 9i is still a supported Oracle version, so it's a perfectly legitimate and sensible thing to be installing it afresh these days; second, this document is actually a re-working and a refresh of an article I first wrote back in 2002; and third, explains how to install version 10g on Centos, so it's not like I've forgotten 10g exists! (That 10g article will soon itself be re-worked to bring it into the new site style... give it just a few days!)

I should probably also mention before I start that the machine on which Centos/Red Hat/Whatever and Oracle are to be installed should be a reasonably capable one: if it doesn't have at least 512MB of RAM and 6GB of free hard disk space , it should be considered inadequate, and things are likely to go wrong or not work at all.

2.0 Installing Centos

I won't be discussing every aspect of installing Centos, on the grounds that it's generally pretty straightforward! I would just remind you to make sure you're installing the 4.2 release of Centos, and not some earlier one. I'd also point out that you will want to select the Custom Installation Type when prompted, because you'll need to tailor the set of packages to be loaded onto your server. When it comes to disk partitioning, you can generally let Centos automate the partitioning scheme -but make sure that whatever it proposes includes at least 1GB of swap space:

 Install_Oracle9204_on_CentOS4.2.doc   

You'll notice here that I was happy to let Centos organise my disk space into a single logical volume group, internally split into 1GB for the swap partition, and 7 GB for everything else (plus a tiny boot partition that's outside of the logical volume). You should aim to do something broadly similar.

Another important part of the Centos installation that you need to get right is this one:

I do actually use a DHCP server at home, but you must never use DHCP for a machine that is to act as an Oracle Server. I wrote some time ago will explain why. So you see me here editing the network interface settings and deliberately de-selecting the Configure using DHCP option which is unfortunately switched on by default. I then specify a fixed IP address that suits my home network setup -but you would obviously enter whatever address made sense for your own unique circumstances.

Another part of the installation process might cause you to make decisions which will later trip you up:

The problem here is that the installer wants to enable the in-built firewall and the SELinux option. With the firewall on, you won't be able to connect to your Oracle database from remote clients, however, which rather renders the exercise of building it in the first place a little redundant! And SELinux might be just what America's National Security Agency wanted (as indeed it is), but it will completely wreck your chances of having a functioning Oracle system. So, switch both off -and you'll have to confirm your decision when asked because the installer will protest at what it deems to be your lax security ways. In a production setting, of course, Oracle databases definitely live behind firewalls, and it would be a foolish DBA who didn't make that happen -but those firewalls are Oracle-aware and carefully configured ones, not your freebie switch-it-on-and-hope-for-the-best ones you see here!

Finally, you will come to the package selection option:

You see me here making the only two changes to the default selection of packages that are strictly necessary for a successful Oracle installation. By all means add whatever other packages take your fancy, but you must make sure that the Development Tools and Legacy Software Development options are selected.

After those issues are dealt with, the installation simply chugs along, asking you to swap CDs when appropriate. Finally, the thing will reboot, and ask you to create a non-root user account. Please do not create a user called "oracle" at that point: just create an ordinary account for yourself. We'll be creating the special oracle user account later, and if you try doing it with the GUI tools provided during the installation process, you'll get it wrong!

Apart from that, you must make sure that you do not upgrade the installation once it is complete. That is, don't use up2date, yum, apt or any other method for patching or updating the operating system. If you do, you'll get yourself into dependency hell when it comes to installing some crucial packageswhich we have to do next. Install Oracle first, and only when it is all working should you think about updating your O/S (at which point, you can update it without nasty consequences as far as Oracle is concerned).

3.0 Adding Packages to the Server

Once you have a working un-updated Linux server, it will need to have several extra packages added before the Oracle 9i installer will even be able to start. Unfortunately, there are 22 different packages that have to be installed as part of this vital preparation step! All of them can be found on the original Centos installation CDs (and they should similarly be available on the installation CDs of whatever other RHES4 clone you might be using), but you'll have to hunt around for them. As a service to my readers, however, I have done the hunting of Centos 4.2 CDs for you, and this is a list of the files and where you can find them:

Centos 4.2 Disk 1:

xorg-x11-deprecated-libs-6.8.2-1.EL.13.20.i386.rpm
xorg-x11-libs-6.8.2-1.EL.13.20.i386.rpm
xorg-x11-xfs-6.8.2-1.EL.13.20.i386.rpm

Centos 4.2 Disk 2:

alsa-lib-devel-1.0.6-5.RHEL4.i386.rpm
fontconfig-devel-2.2.3-7.i386.rpm
freetype-devel-2.1.9-1.i386.rpm
libjpeg-devel-6b-33.i386.rpm
libtiff-devel-3.6.1-8.i386.rpm
libungif-devel-4.1.3-1.i386.rpm
xorg-x11-6.8.2-1.EL.13.20.i386.rpm
xorg-x11-deprecated-libs-devel-6.8.2-1.EL.13.20.i386.rpm
xorg-x11-devel-6.8.2-1.EL.13.20.i386.rpm

Centos 4.2 Disk 3:

audiofile-devel-0.2.6-1.i386.rpm
esound-devel-0.2.35-2.i386.rpm
libaio-0.3.103-3.i386.rpm
libaio-devel-0.3.103-3.i386.rpm
openmotif21-2.1.30-11.RHEL4.4.i386.rpm

Centos 4.2 Disk 4:

glib-devel-1.2.10-15.i386.rpm
gnome-libs-devel-1.4.1.2.90-44.1.i386.rpm
gtk+-devel-1.2.10-33.i386.rpm
imlib-devel-1.9.13-23.i386.rpm
ORBit-devel-0.5.17-14.i386.rpm

Bear in mind that if you're using any RHES4 clone other than Centos 4.2, there's no guarantees that the disk locations I've specified above will be right for you. But they're definitely right for Centos 4.2 (at least, for my downloaded copy of it!)

Locating these files is only half the battle, of course: you actually need to copy those files off their respective CDs into a single directory somewhere. I created a directory called /home/hjr/Desktop/patches for this purpose, but you can create it anywhere you like, and call it anything you like... so long as it ends up storing all 22 files. As the root user, you then can try installing them all in one go:

[root@otho patches]# rpm -ivh *.rpm
warning: alsa-lib-devel-1.0.6-5.RHEL4.i386.rpm: V3 DSA signature: NOKEY, key ID 443e1821
Preparing... ########################################### [100%]
package xorg-x11-libs-6.8.2-1.EL.13.20 is already installed
package xorg-x11-deprecated-libs-6.8.2-1.EL.13.20 is already installed
package xorg-x11-xfs-6.8.2-1.EL.13.20 is already installed
package xorg-x11-6.8.2-1.EL.13.20 is already installed

As you can see, the command to install the packages is simply rpm -ivh *.rpm. In my case, that produces a warning for the alsa-lib package stating that it lacks a valid DSA encryption key. This is not a major concern, given that we've just copied the file off the original installation CDs, which is about as valid and trustworthy a source of software as you can get! The rather more serious problem here is that four of the 22 packages are already installed, and therefore nothing at all can be installed until those four are removed from the 'installation set'. That's easily fixed, though:

rm -f xorg-x11-libs-6.8.2-1.EL.13.20.i386.rpm
rm -f xorg-x11-deprecated-libs-6.8.2-1.EL.13.20.i386.rpm
rm -f xorg-x11-xfs-6.8.2-1.EL.13.20.i386.rpm
rm -f xorg-x11-6.8.2-1.EL.13.20.i386.rpm

[root@otho patches]# rpm -ivh *.rpm
warning: alsa-lib-devel-1.0.6-5.RHEL4.i386.rpm: V3 DSA signature: NOKEY, key ID 443e1821
Preparing... ########################################### [100%]
1:glib-devel ########################################### [ 6%]
2:ORBit-devel ########################################### [ 11%]
3:libungif-devel ########################################### [ 17%]
4:libtiff-devel ########################################### [ 22%]
5:libjpeg-devel ########################################### [ 28%]
6:libaio ########################################### [ 33%]
7:freetype-devel ########################################### [ 39%]
8:fontconfig-devel ########################################### [ 44%]
9:xorg-x11-devel ########################################### [ 50%]
10:gtk+-devel ########################################### [ 56%]
11:imlib-devel ########################################### [ 61%]
12:audiofile-devel ########################################### [ 67%]
13:alsa-lib-devel ########################################### [ 72%]
14:esound-devel ########################################### [ 78%]
15:gnome-libs-devel ########################################### [ 83%]
16:libaio-devel ########################################### [ 89%]
17:openmotif21 ########################################### [ 94%]
18:xorg-x11-deprecated-lib########################################### [100%]

You see me here first deleting the four packages that have already been installed, and then the other 18 get installed with the same command as before -only this time, it all works perfectly.

The real point here is that I can't be sure what package groups you may or may not have selected during your specific installation, and you might therefore have most or indeed all of these packages already available to you. So I've given you the worst-case scenario (22 packages required), and shown you how to deal with that in general terms (obtain all 22, and get rid of ones that your specific environment declares already exist).

4.0 Adding Oracle-specific Compatibility Packages

Two further Oracle-specific packages now have to be installed. They are fortunately (often, you find these things are only available to Metalink's paying customers!). You need both the compat-libcwait-2.1-1.i386.rpm and the compat-oracle-rhel4-1.0-5.i386.rpm packages, so download both of those (they are both very small) into their own directory. They need to be the only RPMs in whatever directory you choose for this purpose (and again, you could create one especially for the purpose and delete it when you've done).

You then become root once more, and install them both together like so:

[root@otho Desktop]# ls
compat-libcwait-2.1-1.i386.rpm compat-oracle-rhel4-1.0-5.i386.rpm patches temp

[root@otho Desktop]# rpm -ivh *.rpm
Preparing... ########################################### [100%]
1:compat-oracle-rhel4 ########################################### [ 50%]
2:compat-libcwait ########################################### [100%]

Here you see me first checking that no other RPMs are stored where I downloaded the Oracle-related packages to (in this case, it happens to have been on my desktop), and then installing them with the usual rpm -ivh *.rpm command.

The installation of these two packages marks the end of the 'weird' installation phase -by which I simply mean, the specific tweaks you have to make to get 9i running on RHES4 or its clones. Everything after this point by contrast is standard Oracle-on-Linux stuff, which you'd end up doing no matter what version of Oracle you were installing, and no matter what distro you were using.

5.0 Standard Oracle Preparation

As root, you now need to create a new user that will perform and own the Oracle installation. This user is generically referred to as the oracle user, and is quite often created with the actual name oracle, though it might be a good idea from the security point of view to choose something rather less obvious! You also need to create a place on the hard disk where the Oracle software should actually get installed. And you finally need to adjust the kernel parameters for your server so that the Oracle software can run with sufficient server resources to make it reasonably fast and efficient. You do all three of those things as follows.

5.1 Creating the oracle user

Become root in a new terminal session and issue the following commands:

/usr/sbin/groupadd oinstall
/usr/sbin/groupadd dba
/usr/sbin/useradd -g oinstall -G dba oracle
passwd oracle

The first two commands here create new operating system groups. The first, oinstall, is intended to be the group to which the owner of the Oracle install will belong. As owner of the installation, members of this group will therefore have the right to upgrade and patch the Oracle software. This is very much the sort of function we might associate with the traditional SYSADMIN role. The second group, dba, is intended to the group whose members can administer Oracle databases -that is, shut them down, start them up, back them up and recover them in the event of a disaster. These are very much functions which are associated with the DBA role, of course, which might explain the operating system group's name!

The idea behind creating two groups in this way is that large organisations quite often have distinct teams of people. SYSADMINs don't create tables or do performance tuning, and DBAs don't install new RAM chips or re-partition hard disk. (Just as well on all counts, I'd say!) Creating the two groups like this therefore allows us to reflect a real division of labour. Of course, my third command above rather spoils the effect a little: I've just created a new user called oracle and made him a member of both groups simultaneously! But this reflects the real world too: a lot of organisations don't have the SYSADMIN/DBA split, but have one team of people responsible for both sorts of function.

The point here is that by creating both groups, even if I haven't chosen to keep their membership split, I've given myself 'growth capability' for the future: if I ever do need to separate different users by the different functions they perform, I'll already have the operating system group structure that will let me.

Anyway: the fourth command above lets you specify a new password for the new oracle user.

5.2 Creating a home for the Oracle installation

Still as the root user, you next create a set of directories into which the Oracle software will eventually be installed:

mkdir /oracle
mkdir /oracle/92
chown -R oracle:oinstall /oracle

The official way of doing this is to create multiple mount points, and deeply nested sub-directories, so that you end up with something looking like /u01/app/oracle/product/9.2.0.4/db and so on and on. By all means follow the official advice (which goes under the rather grand name of the Optimal Flexible Architecture or OFA for short) if you want to, and certainly do so in a production environment. But for the purposes of home learning, the OFA guidelines always strike me as completely over the top. Perhaps its the residual Windows user in me, but I hate that level of nested sub-directory!

As you can see, therefore, I'm proposing a definitely sub-optimal architecture that has the huge advantage of being quick to type: a straightforward /oracle/92 will do nicely! You can also see me letting the new oracle user own the new directories -a vital step if the installation is to have the rights to save anything in them.

Having created the installation destination directories in this way, I need to let the oracle user know that they exist and what they're intended to be used for. That's done by specifying a set of environment variables for the oracle user. Once again as root, issue this command:

gedit /home/oracle/.bashrc

This will launch a text editor (and if you prefer vi or emacs to gedit, please feel free to amend the command accordingly) and open up the .bashrc file which sets the environment variables for a user. You just paste these new variables and commands into that file:

ORACLE_SID=lx92
ORACLE_BASE=/oracle
ORACLE_HOME=/oracle/92
PATH=$ORACLE_HOME/bin:$PATH:.
LD_ASSUME_KERNEL=2.4.19

export ORACLE_SID ORACLE_BASE ORACLE_HOME PATH LD_ASSUME_KERNEL

ORACLE_BASE is the variable that announces where any and all Oracle software can be found. ORACLE_HOME then specifies specifically where a particular Oracle installation's files are located. If, therefore, I was to install 9i and 10g on the one server, they would both have the same ORACLE_BASE, but they'd have different ORACLE_HOMEs (for example, /oracle/9i and /oracle/10g).

Strictly speaking, I won't need the ORACLE_SID and the PATH variables set in this way until I come to create a database. The PATH statement here wll enable me to find the Oracle programs that create databases without me having to actually move to the directory they're stored in, and the ORACLE_SID statement sets the name for the instance which will manage the database. Even though we don't strictly need these variables set right now, though, we might as well get them ready ahead of time.

Finally,the LD_ASSUME_KERNEL variable is needed to persuade Oracle 9i's installer (which was written back when the 2.4 kernel was the latest game in town) that it's OK to run even though we are now using a 2.6 kernel.

5.3 Setting Kernel Parameters

Finally, you need to adjust the configuration settings which govern how much memory and other O/S resources a single running program can use on the server -because Oracle will want lots! You once again become the root user in a terminal session and issue this command:

gedit /etc/sysctl.conf

You then add these lines to the very end of text file that is then opened by the text editor:

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000

Make sure there's a blank line after the last of the lines shown above, and then save the modified file. You now get the new settings for these parameters picked up by issuing this command (still as root):

/sbin/sysctl -p

With that done, the last of the operating system preparation steps has just been completed.

6.0 Installing Oracle 9.2

6.1 Preparing the Installation Media

You now need to get your installation media ready. You might have official CDs from Oracle, of course, in which case you might be able to succeed with an installation directly off those. On the other hand, if you install any version of 9i Release 2 earlier than the 9.2.0.4 release, you will get serious errors during the installation which can only be fixed by a subsequent upgrade to 9.2.0.4 (or better) and a lot of tricky re-linking commands... so I'd advise you not to go that route!

Instead, , save that to your hard disk (I tend to store them in a directory called osource, created and owned by the oracle user), and install direct from there. This method also has the advantage that you won't be pestered throughout the installation to keep changing CDs!

The download comes as three separate files, called ship_9204_link_diskn.cpio (where n can be 1, 2 or 3). They will first need to be unzipped, and then unpacked, as the oracle user like so:

gunzip *.gz
cpio -idm < ship_9204_linux_disk1.cpio #(should report 1288238 blocks)
cpio -idm < ship_9204_linux_disk2.cpio #(should report 1263504 blocks)
cpio -idm < ship_9204_linux_disk3.cpio #(should report 585396 blocks)
rm -f *.cpio

Note the number of blocks reported by each unpacking operation. If you get different numbers from these, your download is corrupt, and you need to get a fresh download that is 'clean'. If everything unpacks successfully, however, you no longer need the source cpio files, and that's why my final command above deletes them. At the end of this process, you'll end up with three directories, called Disk1, Disk2 and Disk3.

6.2 Performing the Installation

Once you've got this far, all the hard work is behind you: the installation process itself is really quite painless. The secret to success is in doing good preparation work beforehand. I won't describe the installation process here, therefore: instead you can watch a Flash movie/slideshow which explains what's going on, and shows you what to type in at different points along the way.

If you don't want to watch the movie, you should just know that to launch the installer you invoke the runInstaller program, from wherever you ended up creating or storing the Disk1 directory. In my case, therefore, I'd type:

su - oracle
Password:
/home/oracle/osource/Disk1/runInstaller

Make sure that you do a software-only Enterprise Edition installation: creating a database is a separate exercise entirely, which I'll describe in detail in just a moment. The oinstall group should be specified as the group with permissions to update the software. And Enterprise Manager should be dismissed when it launches automatically at the end of the entire process.

7.0 Creating a Database

7.1 Creating a Listener

It's not a requirement to create a Listener before you create a database, but it makes sense to do so. A Listener is a process which listens on a well-known port for requests from remote users seeking to connect to the Oracle database. It is the Listener's job to then 'broker' these connection requests and help establish a user <-> database connection. Without one, therefore, you'd only ever be able to connect to the database whilst directly logged onto the server itself, which is obviously a bit of a show-stopper!

Usually, the simplest way of creating a Listener is to use the Network Configuration Assistant -a nice, GUI wizard that requires not much more than for you to click [Next] several times. There's a Flash movie you can watch showing this tool in action -and even though the movie was made with a Windows XP machine, the screens would be identical on Linux.

However, there are two reasons why running the Configuration Assistant won't suffice in the present situation. Firstly, Oracle 9i's Enterprise Manager (a GUI tool we use to administer databases) requires something called static declaration of instances rather than dynamic instance registration. That's just a long-winded way of saying that the Listener has to be configured with an explicit list of instances to listen out for... and the Network Configuration Assistant does not provide a way to create such a list. The second reason not to use the Configuration Assistant is simply that it doesn't work -at least, not for me on a regular basis, for Oracle version 9i running on Red Hat Enterprise Server 4 or one of its clones! Every time I ran the Net Configuration Assistant in such an environment, it would happily step me through all its screens until the point where it was actually asked to do something for real... and then it would just crash out with a lot of Java exception errors. You might have better luck (which is why the link to the Flash movie is shown above), but you'll still have to worry about getting the static list of databases in place.

Incidentally, subsequent investigation has revealed that Centos 4.2 (which has the crashing netca problem) uses later versions of key libraries than true, proper Red Hat Enterprise Server 4 (which has no trouble running netca at all). It would therefore appear that netca is very sensitive to the library versions in use, and you may or may not have success using it, depending entirely on whether you're using kosher RHES4 or the particular "clone" you've opted for instead (I haven't bothered testing Lineox or Tao to see if they suffer from the same problem, for example). I wouldn't lose too much sleep about this, though, because netca is not the only tool we have for configuring these things.

As a functionally-richer alternative, we have the Network Configuration Manager tool to do the job of Listener configuration (and this tool definitely doesn't bomb out with Java errors, even on Centos 4.2!) The Manager requires a little more work to get right than the Assistant, but not that much more! To invoke the Network Configuration Manager, therefore, you should become the oracle user in a new terminal session and issue this command:

netmgr

I have, of course, made a brand new Flash movie for you to watch showing you exactly how to go about using this tool to create a properly-configured Listener for an Oracle 9.2 installation.

7.2 Creating a Database

You are now ready to create your new Oracle Database. We do so as the Oracle user, invoking the graphical tool Oracle now recommends as the preferred method of creating any Oracle database: the Database Configuration Assistant, or DBCA.for short. Just issue this command at the command line whist logged in as the oracle user:

dbca

The wizard that then takes you through the business of creating a database is is not a difficult thing to use: mostly, in our case, it involves clicking [Next] to step through the various screens, accepting all defaults as you do so. Just be sure to specify the correct database name (it should match what is set as your ORACLE_SID, but with a proper domain extension -so in my case, lx92.dizwell.local is right).

For those of you who want to see a database actually being created, I've got yet another Flash movie you can watch that shows you the entire process.

8.0 Managing the Database with Enterprise Manager

Once your database is successfully created, you'll probably next want to ensure that the database can be managed using the Enterprise Manager Console. The EM Console is a Java-based application that can be run in one of two modes: direct, client-server connection to the database being managed (called standalone mode) or in what is called Management Server mode. This involves creating a second database and a set of tables within that new database (called the Enteprise Manager Repository), connecting to that second database, and getting the second database to connect to the database you really want to manage (and the one you've just created). If that all sounds rather complicated, it's because it is! It's technically known as an 3-tier connection, because you the client are connecting to a backend database via an intervening middle tier management database: it gives you lots of flexibility (the one middle tier database can manage many different backend databases) and lots of juicy capabilities -but discussing it further in this article really takes us way outside of scope! (Though I might just mention that you can generalise the architecture so that it is not just 3-tier, but n-tier).

So, instead, I'll show you how to connect Enterprise Manager directly to the database, which is much simpler but still gives you lots of powerful management capability (just don't try and schedule any jobs to run on the database in this mode, though!)

8.1 Starting Enterprise Manager

To launch Enteprise Manager in standalone mode, you simply start a new terminal session and as the oracle user issue the command:

oemapp console

You'll then see this login screen:

To connect to the database directly (client-server mode), you make sure the launch standalone option is selected, and then click [OK]. Enterprise Manager will then run, and if you navigate through the tree structure on the left-hand edge of the display and expand the 'Databases' item, you should see your new database listed there (courtesy of the static declaration of its existence when we configured a new Listener earlier):

If you now click on the '+' icon next to your database's name in that tree, you'll be asked to provide appropriate database logon credentials:

You could log on as SYSTEM, too, since that's another in-built account in all Oracle databases, and very powerful, but here I've opted to connect as SYS -which means having to select SYSDBA from the Connect as drop-down box. I've also elected to save this as my 'preferred credential' (not a very good thing to do in a production environment, I might add, where you really don't want to be routinely connecting to a database as SYS under any circumstances).

When you click [OK] at this point, Enterprise Manager will warn you that to set a preferred credential, it has to store those credentials locally, though it does so in an encrypted format. Once you acknowledge the element of risk in having database logons and passwords stored on a client machine (which is certainly a bit of a worry, no matter how good the encryption technology that might be in use), you'll get this sort of thing displayed:

From this point on, you're on your own: describing everything Enterprise Manager can be used for is a huge undertaking, and warrants an article or three on its own! To start with, it's really just a matter of clicking on things and exploring what sort of options are available. By way of a very brief outline, you'll find memory configuration and ways to startup and shutdown the database under the Configuration item you see me selecting in the screenshot. To create new tables, index and other data structures, or to see what data existing tables contain, click on the Schema item. To create new users, or to review and alter the details about existing users, click on the Security item. To add new datafiles to your database, and thus to make it grow in size, you'd use the Storage option.

All I can say at this point is: happy exploring!

Side Note: one of the reasons I didn't document how you'd go about using Enterprise Manager in full-blown Management Server mode is that on my Centos 4.2 box, the intelligent agent refuses to start. This actually happens on the "proper" Red Hat Enterprise Server 4 machine, too, and is therefore an indication of the generic problems that can arise from running a fairly old version of Oracle on a fairly recent distro. The answer is to patch the Oracle installation to a later patch release (9.2.0.6 or 9.2.0.7 would do, for example) and then relink (recompile) the agent executables. This is not a trivial task, especially since patch releases are only available to paying customers who have Metalink access. If you are desperate to experiment with full-blown Enterprise Manager and you don't have access to Metalink, you're really not going to be in luck. It's 10g for you, I'm afraid! (Either that, or find yourself an ancient copy of Red Hat Advanced Server 2.1, or an even older copy of Red Hat 9, because they both run 9i Release 2 without issues. I have on this very site to prove the point, after all).

Just bear in mind that you can do pretty much everything you need to know as a DBA with standalone mode Enterprise Manager, except for job scheduling and monitoring the database for event occurences that indicate trouble is brewing. These are not unimportant things, of course, but they also quite as fundamental as knowing how to startup, shutdown, backup, recover, export, import, create users, tables and indexes and so on, all of which you can do quite happily without an intelligen agent.

9.0 Automating Listener and Database startup

The last thing I wanted to describe in this article is how you go about ensuring that if you bounce your Redhat/Centos server, all the Oracle bits-and-pieces shutdown nicely and start back up automatically. This is quite easy to do, in part because Oracle supplies two scripts to help achieve it. Those scripts are called dbshut and dbstart, and both can be found in the ORACLE_HOME/bin directory. These two scripts both read the contents of another text file, called /etc/oratab, to determine which databases need to be started and stopped automatically. So the first thing you have to do is to edit that file to indicate that your new database should indeed be auto-started and -stopped.

9.1 Editing /etc/oratab

Since the oratab file lives in the /etc directory, of course, only the root user can edit it. So, become the root user and invoke your favourite text editor, like so:

[hjr@galba ~]$ su - root
Password:
[root@galba ~]# gedit /etc/oratab

If you ignore all the comment lines at the start of the file, you should find these two entries:

*:/oracle/92:N
lx92:/oracle/92:N

Each entry is made up of three parts: the database name, the ORACLE_HOME and whether to automate the specified database's startup and shutdown. You therefore need to edit the contents of the file so that it reads like this:

*:/oracle/92:N
lx92:/oracle/92:Y

There's no need to alter the first of the entries, you'll notice: just the one that specifically mentions your new database by name. Save the modified file, and we'll move on to the next stage.

9.2 Testing It!

As the oracle user, you might like to now test the dbshut or dbstart scripts and see whether they work when invoked manually. Which one you test, of course, depends on whether your database is already up and running or not. Mine is, so I'll test the shutdown script first:

[hjr@galba ~]$ su - oracle
Password:

[oracle@galba ~]$ $ORACLE_HOME/bin/dbshut

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Mar 22 12:24:17 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

SQL> Connected.
SQL> Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
Database "lx92" shut down.

The only commands I actually typed there were the ones I've highlighted in bold: so the shutdown process itself was entirely automated, and this script works just fine. Now, let's try to start the database with the dbstart script:

[oracle@galba ~]$ $ORACLE_HOME/bin/dbstart

Can't find init file for Database "lx92".
Database "lx92" NOT started.

Hmmm... much less success this time around, obviously! What we have here is an unfortunate side-effect of Oracle having invented the spfile in version 9i: DBCA and SQL*Plus certainly understand that this new style of initialisation file exists, but the startup script (supplied by Oracle themselves, of course!) doesn't. So we have to help out a little!

The actual initialisation file being searched for is the old-fashioned default one of initSID.ora, whereas the new spfile-style one that DBCA creates by default is called spfileSID.ora (in each case, the SID component in the names represents the value of the ORACLE_SID environment variable). We therefore need to create a new initSID.ora which points to the spfileSID.ora which actually exists, and you do that like this:

[hjr@galba ~]$ su - oracle
Password:
[oracle@galba ~]$ touch $ORACLE_HOME/dbs/initlx92.ora

You would obviously replace my "lx92" with whatever was the value of your own ORACLE_SID environment variable. Once the new file exists, we need to edit it in a text editor of your choice and add just one line to it as follows:

spfile= $ORACLE_HOME/dbs/spfilelx92.ora

The new init.ora therefore acts as a 'pointer' to where the actual initialisation file can be found. The dbstart script should now, therefore, be happy:

[oracle@galba ~]$ $ORACLE_HOME/bin/dbstart

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Mar 22 12:35:07 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

SQL> Connected to an idle instance.
SQL> ORACLE instance started.

Total System Global Area 236000356 bytes
Fixed Size 451684 bytes
Variable Size 201326592 bytes
Database Buffers 33554432 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.
SQL> Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Database "lx92" warm started.

...and it certainly seems that way! Once again, the only command I actually issued was the first one shown here in bold. Everything else happened automatically. So, at this point, we know that if we invoke our dbstart and dbshut scripts, databases will indeed be started and stopped automatically. All that remains to do is to write a script that can invoke the two Oracle-supplied scripts in this manner.

9.3 The dbora script

As the root user once more, you now need to create a new script, usually called dbora, and stored in the /etc/init.d directory. It is this script which will call the other two Oracle-supplied scripts depending on whether the server itself is starting up or shutting down, and its contents should look something like this:

#!/bin/bash
#
# /etc/init.d/dbora
#
# Startup script for Oracle databases

export ORACLE_HOME=/oracle/92
export ORACLE_SID=lx92
export PATH=$PATH:$ORACLE_HOME/bin

case "$1" in
start)
su oracle -c "$ORACLE_HOME/bin/lsnrctl start"
echo -n "Starting Oracle: "
su oracle -c $ORACLE_HOME/bin/dbstart
touch /var/lock/oracle
echo "OK"
;;
stop)
echo -n "Shutdown Oracle: "
su oracle -c $ORACLE_HOME/bin/dbshut
rm -f /var/lock/oracle
echo "OK"
;;
*)
echo "Usage: 'basename $0' start|stop"
exit 1
esac
exit 0

Essentially, the script creates two 'procedures', one called "start" and one called "stop". The start procedure calls the dbstart script as the oracle user, whilst the stop procedure calls the dbshut script as the oracle user. The start procedure also happens to start the Listener, though the stop procedure doesn't bother stopping it because a Listener that simply dies neither causes nor risks causing data loss.

With that file stored, you need to make it executable:

chmod 775 /etc/init.d/dbora

Finally, you link the new script into the Red Hat/Centos runlevel service startup mechanism by issuing the commands (still as root):

ln -s /etc/init.d/dbora /etc/rc.d/rc0.d/K10dbora
ln -s /etc/init.d/dbora /etc/rc.d/rc1.d/K10dbora
ln -s /etc/init.d/dbora /etc/rc.d/rc2.d/K10dbora
ln -s /etc/init.d/dbora /etc/rc.d/rc3.d/S90dbora
ln -s /etc/init.d/dbora /etc/rc.d/rc4.d/S90dbora
ln -s /etc/init.d/dbora /etc/rc.d/rc5.d/S90dbora
ln -s /etc/init.d/dbora /etc/rc.d/rc6.d/K10dbora

All that remains to do is to bounce your server, and see whether or not the Oracle database is already running when the server is back up and you attempt to connect to it. If the server bounce fails to automatically start the instance, you'd know about it because you'd get this result:

[oracle@galba ~]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Mar 22 12:54:43 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

Whereas, if the instance is up and running automatically, the first thing the oracle user would see when attempting to connect would be:

[oracle@galba ~]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Mar 22 12:55:54 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

So, provided you don't see a 'connected to an idle instance' message; and provided you do see a 'Connected to etc etc etc' message, you can be sure the automation stage has succeeded!

10.0 Conclusion

At the time that I'm writing this, Oracle 9i is looking pretty old: elsewhere we have 10g Release 2 to work with, and 11q (or whatever it's going to be called) can't be far away! But 9i is still a supported Oracle release, and third-party vendor support issues will certainly see it in production use for a long time to come. Not to mention, of course, that 9i remains a stable and solid RDBMS and thus a good foundation on which to deploy mission-critical applications applications.

So I don't feel in the slightest that it has been a waste of time documenting how to install 9i onto the leading Linux platform, because I am sure the information will come in handy to lots of people for many months to come.

I wish 9i on RHES4 didn't have issues with Intelligent Agents than can only be resolved by applying paid-for patches and a lot of old relinking shenanigans, but all the core functionality works as advertised, and I therefore hope that you have been successful in following along, and that you are now primed and ready to start learning the tricks of the DBA trade with your new database!