INSTALLING AND CONFIGURING ORACLE ON THE LINUX PLATFORM

This document will walk you through the steps of installing Oracle 8i
Enterprise Edition release 3 (Oracle version 8.1.7) or release 2 (8.1.6)
in a Linux environment. Everything you read in this document is hands on, roll-up-your-
sleeves-and-get-busy material for Oracle users who want to get an Oracle database up and running quickly, but want
the database to be scalable and to perform well.

These steps are meant to get you up and running as quickly as possible, while leveraging best practices in order to
set up a scalable, robust database environment that offers high performance.
I ran my Oracle installations on a server running Red Hat 6.2 Linux with a
2.2.16 kernel. However, Oracle?s publications indicate that other
distributions and versions of Linux are also supported.

Oracle 8i releases 2 and 3 both install very smoothly on Linux. If you also
have a copy of Oracle version 8.0.5 or Oracle 8i release 1 (version 8.1.5)
lying around and you are wondering which version of Oracle to go with, the
answer is simple. Do not waste your time with Oracle version 8.0.5 or
Oracle 8i release 1 for Linux. I?d recommend you install release 3 because
it has several new features, but release 2 is also very solid.

Please note: Oracle 8i release 3 on Linux now supports the Oracle Parallel
Server option for high availability and scalability. OPS implementation is
quite complex and will not be covered here.

There are four phases to getting Oracle up and running on your server:

Prepare the server

Install the Oracle software and create a simple database

Create a scalable Oracle database (optional)

Complete the server configuration

We will walk through these phases one at a time, detailing all the steps involved. The end result will be a very
usable database that can be scaled up quite large. Of course, every implementation is unique, and you will need to
evaluate each step carefully against your particular requirements. However, this document will get you off to a very
solid start.

Prepare the Server

These steps configure your machine so that it will be ready to accept the Oracle software and database. In this
section, we will make sure the operating system meets Oracle?s minimum requirements, create a Unix user and
group to ?own? the software, and create some directories that will be used by the Oracle software and database. All
of the steps in this section are run as the root user.

Make sure that your Linux system is supported. You must have a 2.2 kernel,
GLIBC 2.1, and a supported Linux distribution. According to Oracle Support as
of March 2001, the supported Linux distributions are as follows:

Supported Linux DistributionsFor Oracle 8i release 2 (8.1.6)

Red H

Launch the Oracle Database Configuration Assistant with the following commands:

Choose a database type of Custom and click Next. This will give you the opportunity to configure your
database optimally.

Choose a primary application type of Multipurpose and click Next.

Enter the approximate number of concurrent database users you anticipate and click Next. How you set
your semaphore kernel parameters earlier will impact how many concurrent users your
database can support. Note that this setting is very easy to change later so you should not feel locked in
by what you choose now.

Choose the dedicated server mode and click Next. Only consider using
shared server mode if you will be using Oracle?s JVM and IIOP, or if you
will have many (as in hundreds) of concurrent users whose database sessions will be idle much of the
time. Shared server mode (also known as multi-threaded server or MTS) is historically less stable
and is best avoided when possible.

Select the options you would like to have configured in your database, such as JServer or Advanced
Replication. The schema objects required to support these features will automatically be built during
database creation. Note that some of these options require extra licensing. You should not choose
options you are not licensed to use. Click Next.

Enter a global database name and SID for your database. These do not seem to pick up from the
ORACLE_SID environment variable, unfortunately. Your global database name should be the same as
the SID, with your domain name added on to the end. As you enter the global database name, the SID
and initialization filename will enter automatically. Do not change the initialization filename.

Set the compatibility to 8.1.0 in order to be able to use newer Oracle features to the fullest.

You may click Change Character Set and select character set names from lists if desired. However,
these fields should default correctly from your environment variable settings. Note that with few
exceptions, you cannot change the character set of a database after creation. The character set you
choose now is the character set you will be stuck with unless you rebuild your database. So put some
thought into choosing your character set. If you want to use Unicode, select the
UTF8 character set.

Click Next.

You now have the opportunity to choose filenames for the control files. The default base names should
not be changed, but you should change the directories where these files will be located. Put the control
files in the oradata/$ORACLE_SID directory under three different mount points. Click Next.

You now have the opportunity to choose filenames and sizes for the six tablespaces that will initially
make up your database. Make any desired changes and click Next. I recommend the following
changes:

The default base names for each file should not be changed, but you should change the
directories where these files will be located. Put the files in the oradata/$ORACLE_SID
directory under one or more mount points.

I prefer to turn off the autoextend feature, but you may use it if you wish.

It will be easy for you to change file sizes later, but I recommend that you start with the
following:

Tablespace

Size (Mb)

System

300

Tools

100

Users

100

Rollback

500

Index

100

Temp

500

Note that the minimum required size for the system tablespace depends on which
options you have elected to configure. Do not assume that the default system
tablespace size suggested by the Database Configuration Assistant will be
sufficent, because it might not. For example, if you choose to configure
all database options for an Oracle 8.1.6 installation, the database creation
will fail if your system tablespace is smaller than 250 Mb and autoextend is
turned off. Meanwhile, the Database Configuration Assistant suggests a system
tablespace size of only 54 Mb.

You now have the opportunity to choose filenames and sizes for the online redo logs. The default base
names should not be changed, but you should change the directories where these files will be located.
Put the files in the oradata/$ORACLE_SID directory under one or two mount points. The default file
size of 500 Kb is too small for almost all situations. I recommend a size of 10240 Kb. Make all files
the same size. Click Next.

You can accept the default checkpoint interval and timeout for now. You can also leave archive
logging disabled for now. (Deal with this one when you establish your backup and recovery plan.)
Click Next.

You now have the opportunity to set the SGA sizing parameters. The defaults are not bad.
Make sure your server has enough physical memory to
keep the entire SGA in memory at all times. I recommend the following changes:

Set the database block size based on the figure you decided upon earlier, typically 8 Kb or 16
Kb. The database block size cannot be changed after the database has been created, so choose
carefully. All other settings on this page can be changed very easily.

Set the shared pool size to 41943040 or more. This is where Oracle will cache data dictionary
elements, SQL statements, and parsed SQL.

Set the data block buffers to at least 1000, but probably much more. This determines how
large Oracle?s buffer cache will be for holding frequently accessed data. The size of the buffer
cache will be equal to the number of buffers times the database block size.

The trace file directory defaults are all good and should not be changed. Click Next.

Choose to create the database now and click Finish. Alternatively you can save the information to a set
of shell scripts.

An alert window will tell you that the database creation will take some
time and will ask if you wish to proceed. Choose Yes. A progress window will
show you how the database creation is going. How long the database creation
will actually take depends on which options you have elected to configure, how
many disk devices your database will be spread across, and the processor and
memory capabilities of your database server. It took 70 minutes to create a
database with all available options configured on my little server with a
400 Mhz processor, 256 Mb RAM, and one IDE disk. It took 20 minutes to create
a database with no options configured on the same server.

When the database has been created, an alert window opens to show you the SYS and SYSTEM
passwords. Write these down (if you don?t already know them by heart!) and click OK. The Oracle
Database Creation Assistant exits.

Adjust the configuration of the Net8 listener if necessary. You can edit the listener.ora file in
$ORACLE_HOME/network/admin to suit your needs, although you may find the default file to be totally
acceptable. If you removed the starter database, then you should remove its entry from listener.ora now.
Depending on your network topology, you might want to change the hostname or IP. (In my case my server is
multi-homed, but I only want the database to accept connections from the internal network.) You should leave
the extproc settings as they are; extproc is part of the mechanism that allows PL/SQL to call out to procedures
outside the database. My listener.ora file looks like this:

Prepare a tnsnames.ora file in $ORACLE_HOME/network/admin on the database server and distribute it to all
clients. Edit the default file to suit your needs. Change the hostname or IP if needed. Remove the entry for the
starter database if you got rid of the starter database. My tnsnames.ora file looks like this:

The default parameter file that the installer created for the database instance is deficient in a few ways. You will
find the parameter file in $ORACLE_BASE/admin/$ORACLE_SID/pfile. Save a backup copy of this file
before you start editing it. Some of the things you should correct or improve upon are:

Note that much of the advice in the comments of the parameter file is laughable and should be taken
with a grain of salt. Some of these comments were written ten years ago for Oracle 7.0 and have not
been updated since then.

Update the sort_area_size parameter to a reasonable value based on how much physical memory your
database server has.

You might want to reorganize the entries in your parameter file to divide them into logical groups. This
might make it more readable, but this is a personal taste sort of thing.

Adjust tablespace configurations in the database as required to improve performance and scalability. Here are
some of the things you?ll probably want to do:

Alter the temporary tablespace to give it appropriate default storage parameters. This will allow Oracle
to manage temp space effectively when performing sorts. You can use a statement in SQL*Plus such
as:

ALTER TABLESPACE temp DEFAULT STORAGE (INITIAL 4m NEXT 4m);

All users including SYS and SYSTEM should have the TEMP tablespace designated as their
temporary tablespace. You can use the following query and statement in SQL*Plus to check each
user?s temporary tablespace designation and change as necessary:

Depending on the anticipated size of your database and the expected number and type of concurrent
transactions, you may want to adjust the number of rollback segments and their storage parameters.
However, the rollback segment configuration established by the Database Configuration Assistant
should be able to get you started.

Change passwords for all users, particularly SYS and SYSTEM. You can do this with statements in
SQL*Plus such as:

ALTER USER <username> IDENTIFIED BY <new password>;

At this point the database has two tablespaces available to hold your application tables and indexes: USERS and
INDX. However, I recommend that you instead create new tablespaces for holding application segments. Create
separate tablespaces with data files on separate physical devices for tables and indexes. You may want to split
your application segments into several tablespaces, based on object size, permanence, volatility, I/O volume, or
any of a number of other criteria. I recommend that you choose default storage parameters for each application
tablespace as follows:

Set INITIAL to either 128k, 4m, or 128m, depending on the planned sizes of the objects to be placed in
the tablespace.

Create application roles if desired. Alternatively, you can use the default roles CONNECT, RESOURCE, and
DBA.

Create your application users that will own the application schemas. Set the default tablespace to one of your
application tablespaces designated to hold tables, and set the temporary tablespace to TEMP. Assign quotas on
all of the application tablespaces where the user will need to be able to create schema objects. (You can use the
keyword UNLIMITED.) You should not set any quota on the temporary tablespace. Do not plan to create any
application objects in the SYS or SYSTEM schemas, or store any application objects in the SYSTEM or TEMP
tablespaces. Here is a sample application user creation statement:

Grant roles and/or system privileges to the application users. Note that if you grant the RESOURCE role to a
user, that user will also receive the UNLIMITED TABLESPACE system privilege. This will let the user create
objects in any tablespace they wish, regardless of quotas. I recommend you revoke UNLIMITED
TABLESPACE from all application users you create. Sample statements to grant and revoke privileges are as
follows:

GRANT connect, resource TO bob;
REVOKE unlimited tablespace FROM bob;

Complete the Server Configuration

These steps complete the configuration of your server for smooth Oracle operation. These steps could have been
performed earlier, but are more straightforward if performed after a database has been created. In this section we
will configure the server to start the database and Net8 listener automatically whenever the server is rebooted,
change the oracle user?s login script to eliminate hardcoding, and create individual operating system accounts for
each database user.

Edit the /etc/oratab file to verify that the entry for your database is correct. Lines starting with a
pound sign are considered comments and are ignored. Each non-comment line contains the name of one Oracle
instance, its ORACLE_HOME, and a Y or N. A Y indicates that the database should be started automatically on
server reboot, and an N indicates that it should not. The three fields should be separated by colons. A sample
/etc/oratab file looks like this:

#
# /etc/oratab
# ===========
#
DEMO:/u01/app/oracle/product/8.1.7:Y

Edit the login file (.profile or .bash_profile) for the oracle user to eliminate hardcodings and call the oraenv script to
set the environment instead. The following will work with Bourne shell, Korn shell, or Bash:

Note that this script assumes that the local bin directory (/usr/local/bin) is on your path. Also, if you use C
shell then you should edit .cshrc and have it source coraenv.

Create separate Unix accounts for DBAs and database users who will log onto the database server directly. You
should only log in as oracle when installing or patching software. The Unix accounts for DBAs should be
members of the dba group, and other users should not be members of the dba group. Give each of these
accounts a login file like oracle?s so that their environment initializes correctly when they log in.

To make the database and Net8 listener start up automatically when the
server reboots and shut down automatically when the server shuts down, you?ll
need to create a dbora file in /etc/rc.d/init.d and link it to /etc/rc.d/rc3.d
and /etc/rc.d/rc0.d. You?ll need to do this as the root user. First create a
file called dbora in /etc/rc.d/init.d as follows:

Note that this script starts the Apache HTTP server as the oracle user, which
is not a good idea from the standpoint of security. Oracle recommends that you
run the Apache HTTP server from a very restricted Unix user, such as the
orapache user we created earlier. Unfortunately, this leads to file permission
problems that I have not yet had the time to resolve.

Conclusion

This document walks you through all of the intricate details of getting Oracle up and running on a database server
running Linux. It may look complicated, but that?s only because this document goes down to a nitty gritty
level of detail.

Please keep in mind, though, that the requirements are different for every
Oracle implementation. I am extremely confident that if you follow these steps
to install Oracle 8.1.7.0.1 or 8.1.6.1.0 Enterprise Edition on a server running
Red Hat 6.2 Linux, then the process will go very smoothly for you. However, no single document can address every
specific hardware configuration and every set of business needs. Please use this document as a starting point to get
Oracle up and running in your shop. To get the best performance and scalability, each system needs to be considered
individually.

About the Author

Roger Schrag has been an Oracle DBA and application architect for over eleven years, starting out at Oracle
Corporation on the Oracle Financials development team. He is the founder of Database Specialists, Inc., a consulting
group specializing in business solutions based on Oracle technology. You can visit Database Specialists on the web
at http://www.dbspecialists.com,
and you can reach Roger by calling +1.415.344.0500 or via email at
rschrag@dbspecialists.com.