Consider the issues and setup discussed in database ownership and we have one final operating system setting to make. The value for shmmax must be set by root to a value in decimal two times the available RAM. There are three ways this can be set. The most practical way for a DBA is to edit the /etc/sysctl.conf file to include the following:
# Oracle7i-10g requirement - double the amount of installed RAM
kernel.shmmax = 2147483647 # for 2GB
# kernel.shmmax = 4294967294 # for 4GB
# kernel.shmmax = 8589934588 # for 8GB
#
# trust these calculations - do not be tempted to round up by one
# starting with zero = max. max -1 for you and me counting from one
After restarting Linux, continue with the installation, as follows:
Create the required groups:
groupadd oracle
groupadd
dba
The following entries will be made in /etc/group:
oracle:x:500:
dba:x:501:oracle
Create
the required users and add to group(s):
useradd -g oracle -G
dba oracle
useradd -g
dba <local admin> {i.e., oradm}
useradd -g
dba <local user> {i.e., davidr}
The
following entries will be made in /etc/passwd:
oracle:x:500:500:RDBMS Software Owner:/home/oracle:/bin/bash
oradmin:x:501:501:DBA:/home/oradm:/bin/bash
drussell:x:502:501:CEO:/home/davidr:/bin/bash
Test
each account to confirm new files are created properly.
Set
passwords for each user:
passwd <userid>
Check
that home directories exist with proper ownership and populate the .bashrc for each Oracle user (“oracle”, “oradm”, and “davidr”),
as follows:
export ORACLE_BASE=/usr/app/oracle
export
ORACLE_HOME=$ORACLE_BASE/product/10.1.0/db_1
export PATH=$PATH:/$ORACLE_HOME/bin:$HOME/bin
Just for the installation, unset ORACLE_HOME if ORACLE_BASE is used, and let Oracle use the default
for ORACLE_HOME calculated off ORACLE_BASE.
unset ORACLE_HOME
Allowing
this to default to an Oracle value you will find that there is a whole new
level, and a certain amount of additional complexity involved. We normally hard-code
ORACLE_HOME to “$ORACLE_BASE/product/10.1.0” (i.e., by adding the
product directory and the version directory). There is no provision for multiple
copies of the same version of code.
Multiple databases can still exist but they are all executed from the
same libraries. There is one set of
code to patch and maintain this way and there is no theoretical limit on the
number of databases.
This
makes sense. A complaint from past
versions had been the placement of “oradata”
below “product” in the tree structure. Datafiles from
different databases were separated below that within “oradata”
using the SID. This new structure
places “oradata” in a more appropriate
location where the data files are not related to the database libraries.
If
this redundancy is used and multiple products are loaded then multiple products
will have to be patched. The
immediate advantage is that more than one Oracle product or version can reside
in “ORACLE_HOME” and be independent of the other product or
version.
If
you unset ORACLE_HOME for the installation be sure to go back and reset it in
your .bashrc file.
After
the installation, during testing, it will become obvious that the ORACLE_SID
variable must be set. You would
think that, somehow, the Oracle “database creative assistant” would
set that; but it does not. Set
it now, as follows:
export ORACLE_SID=’eliany’
<< or some value in LOWERCASE!
Getting
“tricky” with upper or mixed case SIDs
gets confusing quickly. Avoid them.
There
are several new features in 10g.
One of them is “Oracle Managed Files” (OMF). Part of the new tree-structure when
using OMF requires the SID to be displayed in uppercase. If you have started with uppercase for
your SID, you have created a problem that may very well defeat this new
feature.
Note:
This information necessary for using Oracle from an existing account should be
provided to users in an email when the system is ready. You should not customarily distribute
passwords in email. That should be
done verbally.
As
oracle user create OFA directory structure (provides defaults for Oracle
Installer)
mkdir /usr/app/oracle/product
mkdir /usr/app/oracle/product/10.1.0
Depending on where your product was obtained the installation program may be run from different locations. Always remember if running from CDROM to indirectly reference the file or you will not be able to switch disks if prompted.
My
choice is to run the Oracle installation program from a Staging area:
./runInstaller
&
select “custom” and pick the
products
Unix group to modify oracle software is
oracle
Unix group for OSDBA and OSOPER is
dba
Follow remaining onscreen instructions for the installation and database creation if selected. This is where knowledge of you hard disks will come in handy. The online help will be sufficient for anyone who has made it this far.
The
sqlnet.ora and tnsnames.ora
files created with a “default” in this area should be operational
to test. The tnsnames.ora
file will need modifying based on your user’s requirements.
It
should almost always be a custom file with some thought going into it as to which
systems the user, or class of user, will be accessing. IP addresses, host names, database
names, etc. should be discussed in the correct forum and not publicized beyond
some form of “need to know”.
Do not leave hosts not required in a tnsnames.ora
file.
DO
NOT encourage problems. Consider
any system breakable… even Oracle.
Don’t Forget! It’s not finished until it stops and starts with the OS without intervention. See automatic Oracle shutdown/starting procedures. There are other tasks that should be done at this time. Cleanup. Remove trace files, review logs and remove. Secure creation scripts. If it is anticipated that they will be used to create other identical systems, you might want to make sure they work – and relative to what location. Modifications are almost assuredly in order if these are important to you.
This
is a single CDROM server installation. The OEM product and any other monitoring
tools are next.
Last Revised: April 2007