Oracle on Linux

Versions and Distributions

The version 7 release of Oracle has never been distributed for Linux, nor is there any consideration of this for the future. Interestingly, some enterprising individuals have been able to port version 7 distributions of Oracle for SCO to Linux. If you are interested in a back-port, the Linux and Oracle forum archives noted below should prove helpful.

Oracle Corporation has expressed a strong interest in maintaining a commitment to the Linux platform. Recent bulletins have noted that Oracle for Linux will be supported for both the 64-bit Alpha and Merced chips.

Oracle for Linux can be obtained through Oracle's standard retail channels in a CD-ROM distribution and via download from Oracle's Web site. The 8.0.5 version of Oracle can be downloaded from the Oracle Technology Network (OTN), http://technet.oracle.com/tech/linux/downld.htm. Several different download methods are available in an effort to reduce redundant transmissions due to network failure. As a single distribution, the standard version is 145MB in size. There are also several patches, some of which are required.

Oracle version 8.0.5 requires Linux version 2.0.34 or above. In addition, the system GNU C Library (GLIBC) version 2.0.6 is also required. The Oracle8 Installation Guide for Linux specifies GNU C Library version 2.0.7, but OTN has confirmed that version 2.0.6 is sufficient. The important thing to note, however, is that a vendor's distribution of Linux 2.0.34 might not include the required GNU C Library. Furthermore, the standard C Library, regardless of its version, is not acceptable. The GNU C Library is required.

This has been a troubling aspect for many installations. The Linux distribution standards appear to allow some flexibility in this area, so you need to note explicitly which libraries are contained within your distribution. Those Linux vendors who do not include the GLIBC with their distributions generally make it available for free from their Web sites. The GLIBC can also be obtained from various Linux distribution hosts on the Web, including http://prep.ai.mit.edu. and ftp://ftp.gnu.org/pub/gnu/glibc.

---

Sidebar: As one recent Linux email poster expressed it, "Linux is Linux is Linux!" Therefore, any Linux distribution that meets Oracle's requirements will satisfy core functionality. This fact is reassuring and comforting from a marketing and growth perspective. However, I'm personally more inclined to follow conservative, stability-oriented issues. I use Oracle for its functional capacity. My objectives are not met until the application works effectively and the conceptual requirements are fulfilled; not just when transactions are committed. I can appreciate those who venture out and work with new resources. It is these efforts that expand the marketplace, foster competition, reduce costs, and nurture new technologies. It is implicitly these people we have to thank for Linux.

When it comes to a new bridge, however, that will span my project from requirements to production, I would prefer to see a few people cross over before me.

So, I like to use what other people are using if it will satisfy my requirements. Generally, these products will prove less troublesome to implement. They are not particularly technically superior to other products or better programmed, but more of their flaws have been found and corrected. With regard to Linux distributions, Red Hat appears to fit this bill.

---

Installation

1. Obtain any applicable patches.
2. Satisfy Operating System requirements.
3. Satisfy Oracle Database requirements.
4. Execute installer.
5. Apply patches.

---

Caution: When researching for patches on Oracle's Web site, be careful not too confuse the Standard or Enterprise Edition of version 8.0.5 with the Early Adopter's release. The latter requires not only different patches, but more of them.

---

In addition to the 8.0.5.1 patchset, there is also a Linux-specific patch also required by Oracle (file: lnxpatch.tgz). The readme files included with these or any other patches should be reviewed prior to continuing on to the next step. The patches can dictate changes to the Operating System, Database requirements, or different steps to be followed in the install process.

Patches for Linux can be obtained from Oracle's Web site at ftp://oracle-ftp.oracle.com/server/patch_sets/LINUX/80patchsets/80510/

Operating System Requirements

• Ensure that the minimum memory requirements are met. Oracle requires at least 32MB of RAM. However, you are strongly encouraged to use at least 48MB. The BETA or "Early Adapter's" release of 8.0.5 required 48MB.
• Verify swap space requirements.
• Ensure that enough free disk space exists for the Oracle code, not the database data files. The Oracle for Linux complete distribution consumes approximately 400MB.
• Double-check to be sure that the operating system and any ancillary software meets Oracle's requirements[md]Linux 2.0.34 and GNU C Library version 2.0.6.
• Create the oratab file. One very frustrating aspect of the Oracle installation on Linux is the fact that many of the Oracle shell scripts reference the Bourne shell location as, /usr/bin/sh. This is true with the oratab_create.sh script. Unfortunately, unlike many UNIX installations, Linux does not by default maintain a copy of, or a link to, the Bourne shell executable in this directory. Your workaround is one of three choices: edit the file to correct sh location, copy the sh executable to the /usr/bin directory (or use a link), or finally, "dot" execute the offending script. See a Linux text for more information on performing these operations.
• Create a local bin directory.
• Create the Oracle account.
• Create a DBA group and, if necessary, a group for operators.
• Identify and allocate to the Oracle account disk space for the software distribution and ultimately the database files.
• Configure Linux Kernel for Oracle. This item not only sounds difficult, it can be complex in some situations. In contrast to the others tasks, this one can appear quite intimidating and is why it will be discussed in greater detail in the following section.

Controlling access by the various processes to the shared memory and other logical structures within Oracle requires the use of system semaphores (locks). The semaphores and shared memory functionality are usually grouped together as the Interprocess Communication (IPC) module or driver. Many UNIX platforms implement this functionality by default in their standard distributions. Adjustments might still be needed to support the desired Oracle configuration, for example, a large SGA or a significant number of Oracle processes or users.

It is important to distinguish the availability or implementation of this functionality from parameters that adjust the degree of functionality. In other words, on any UNIX platform, prior to starting Oracle, you need to determine if shared memory and semaphores are implemented. As I noted previously, this functionality generally exists. Next, you need to decide if enough shared memory and/or semaphores are available to support your Oracle environment.

One easy method to determine whether the IPC extension is implemented is to query the IPC status as illustrated in Figure x.1.

Figure x.1

If the IPC driver or module is not installed, this command should not be available. Another method is to examine the current kernel configuration as illustrated in Figure x.2.

Figure x.2

This X-Window screen is produced by moving (cd) to the /usr/src/linux directory and entering the command make xconfig and then accessing the General setup parameters. As you can see, the System V IPC drivers have been activated in this system.

After you have confirmed that the IPC drivers are initiated, the next consideration is to determine if their settings are sufficient for your database. This information can be found in many Linux systems by searching the files referenced by the following table.

Table x.1 - IPC Parameter File Locations

IPC Parameter	File Location
Shared Memory	/usr/src/linux/include/asm/shmparam.h
Semaphores	/usr/src/linux/include/linux/sem.h

Within these files you will find the parameters addressed in the installation manual. Unfortunately, in contrast to many UNIX systems, if these parameters do not satisfy your database needs, you do need to rebuild your kernel with the new versions of these files. Most UNIX systems simply require you to change these files and then reboot the system. In this case, these values are truly "parameters" to the operating system, rather than hard-coded.

Although rebuilding your kernel is certainly a nontrivial task, doing so with simple parameter changes is not as complex as modifying kernel drivers or modules. In the latter case, you need to use one of the make configuration tools:

• make config
• make xconfig
• make menuconfig

In addition, if you do find it necessary to modify these values, use new dimensions that are significantly higher than your anticipated needs. Shared memory is only allocated when it is requested by the Oracle instance. Although there is some overhead associated with defining larger values for both shared memory and semaphores, it is acceptable in comparison to the burden and risk of having to rebuild the kernel. It is a customary practice to set the single maximum shared memory segment size (SHMMAX) to the current RAM size or larger. Caution is needed, however, when the values approach the gigabyte or multiple gigabyte range. Many operating systems behave erratically at or above this level.

If you are using the Red Hat distribution and have examined the above kernel configurations, you have, hopefully, come to the conclusion that IPC is installed by default on your system. Furthermore, a relatively significant number of semaphores and a single maximum shared memory size of 32MB are already defined. Consequently, the daunting series of kernel configuration requirements outlined at the beginning of the Oracle installation manual are already in place for many Red Hat users.

---

Tip: If you are using the Red Hat distribution of Linux for Oracle, the Linux configuration requirements outlined at the beginning of the installation manual have already been completed for you[md]providing for an SGA as large as 32MB.

---

• Set your Oracle's umask parameter to a protective value, for example, 022.

---

Sidebar: I am a strong advocate of following the umask convention prescribed in the installation manual. If you set this value and then follow the practice of only using the Oracle account for software administrative purposes, that is, installations and upgrades only, you will significantly reduce the probability of corrupting a file due to operator error.

---

• Set the necessary environment variables and apply them to your current session. No parameter here differs from a standard UNIX installation.
• Double-check to make sure you are not using the Bash shell (/bin/bash), which is the default on Linux. You need to be using either the Korn (/bin/ksh) or Bourne (/bin/sh) shell at least for the duration of the installation.
• Perform any pre-installation tasks for optional Oracle tools or adapters. For many, if not all, of the Oracle tools and adapters, it is important not to select any functionality that is not presently supported by your system. For example, you can not install the Oracle Pro*COBOL precompiler prior to having COBOL installed. This dependency is also true for many of the Net8 adapters.
• The Oracle installation CD-ROM is in the RockRidge format, so it is important that it be mounted as described in the installation manual.

---

Tip: The default shell for Linux accounts is Bash. Oracle will not install correctly with this shell, you must choose either the Bourne (/bin/sh) or Korn (/bin/ksh) shell for the Oracle software owner account. Oracle uses Bourne shell examples throughout the installation manual.

---

• As I've noted above, it is generally a good practice to only install what is absolutely necessary. This distribution from Oracle further supports this approach. Do not attempt to install the documentation, or select any option that will install it, without first pre-creating the directory $ORACLE_BASE/doc or /u01/app/oracle/doc. The installer assumes this directory exists.
• You will most likely receive a message noting that the ULIMIT parameter is not set. This is merely a declarative message and can be accepted by selecting "OK."
• Again, stressing the points mentioned above, do not install the JDBC drivers if you have not defined the CLASSPATH environment variable or do not have classes available. Also, do not install the Pro*C precompiler if you do not have a C compiler executable. Violating either one of these points will halt the installer session.

---

Troubleshooting: Following, I address several common errors during the installation process, that is, while running orainst.

./orainst.cm: No such file or directory

You are possibly encountering a problem with your default shell; it is most likely something other than the Bourne shell (/bin/sh). Possibly, you are encountering the GLIBC problem discussed above. Either your distribution of Linux does not include this library, or you are not accessing it correctly.

bash: ./oratab_create.sh: No such file or directory

This error is caused due to the fact that the script is referencing the Bourne shell in the directory /usr/bin, and your version of Linux does not maintain a copy of the sh executable in this directory. In this case, the offending script will begin with the line #!/usr/bin/sh. The error message produced is very misleading and seems to imply that your PATH variable or current working directory is incorrect. In actuality, it is trying to say that within the oratab_create.sh script, there is a file or directory that can not be found. For this problem, you have three possible work-arounds:

• Replicate the sh executable to the /usr/bin directory either by copying it or creating a symbolic link to its original location (/bin/sh).
• "Dot" or "source" execute the file[md]run it in your current process[md]with, . orainst (there is a space after the period).
• Edit the file and modify the first line to #!/bin/sh

OIERR-SYSTEM /u01/app/oracle/product/8.0.5/bin/uilibmerge oracore

If you receive the preceding error during installation or a variation of it on the same missing target library, you need to apply the 8.0.5.1 patchset.

---

Figure x.3

When uncompressed, you follow the standard practice of untaring and then executing the patch driver script; in the case of the lnxpatch patch. The 80510 patchset should be activated second. You also untar this patch, but you then use orainst to apply it.

Database Creation

Database Administration

Many, if not all, of your UNIX tools should port readily to the Linux system. I have personally migrated various C, C++, Korn, and Bourne shell scripts to Linux and have thus far not experienced any problems.

Client Tools

Oracle Technology Network (OTN) requires that you register, but there is no admission fee.