Chapter 16

Ten Oracle Installation Do’s

In this chapter, we describe ten things you shouldn’t overlook when installing Oracle. Getting off to a good start with a solid, proper installation is key to success. By recognizing the common pitfalls up front, you experience less heartache and pain later on. As the saying goes, a house must be built on a solid foundation.

Know the Documentation

Every OS that runs Oracle has a corresponding documentation set. This documentation covers installation prerequisites such as operating system packages, kernel parameters, network configuration, and more.

Every operating system is different. Even if you think they’re the same, you’re wrong. UNIX is UNIX, right? Wrong. HP-UX, AIX, and Solaris each have very distinct prerequisites. Go to the Oracle documentation on the Internet and download the latest and greatest installation guide for your OS. Read it thoroughly before you begin. We even recommend listing all the little things that you have to check before you begin. For example:

What is the default operating shell of the OS (Korn, BASH, or CSH)?

What tools are used to view OS performance data?

What commands are used to list the storage on the server?

If you make this a practice, you will find far fewer problems during and after installation.

Here’s the quickest way to get to the Oracle documentation:

1. Go to http://docs.oracle.com.

2. Select the version you’re interested in.

You see all the product offerings here, including the database. At this point, we’re focused on the database, so find the appropriate section. Hint: It’s usually at the top!

3. When you enter the 12c documentation set, click the Installing and Upgrading link to go to a subset of the documentation that focuses on installation and upgrade topics.

You can also click the + on the left side of the screen to get a list of more links for installing and upgrading.

4. Click the OS of your choice to enter the OS-specific installation guide.

Observe the Optimal Flexible Architecture

The Optimal Flexible Architecture (OFA) is an Oracle guideline that lays out how software and databases should be installed on a system. The OFA has these main purposes:

Find Oracle files in explicit locations, even when on multiple devices.

Set up a software tree that allows easy patching and upgrades.

Mirror Oracle installations across all environments so they’re the same or similar.

Keep separate Oracle files and installation types.

Facilitate routine management tasks.

Facilitate backup and recovery.

Manage and administer growth.

Facilitate layout for best performance.

We recommend you fully read and understand the Oracle documentation to best implement the OFA.

There are many rules and guidelines for using Oracle — too many to cover here. The Oracle documentation gives explicit examples and suggestions for a variety of operating systems and storage. Furthermore, OFA has evolved over the years. The main ideas remain, but some have been tweaked. For each release of Oracle, don’t hesitate to refresh yourself. The Oracle installation guide (which we mention earlier) has a section for each OS and its recommended OFA guidelines.

Configure Your Profile

The profile applies more to UNIX-type environments. However, by learning the key elements needed inside the profile, you can also see that they may apply to Windows.

The profile is the program (for lack of a better word) that runs every time you log in to your operating system. It is typically found in your home directory. Depending on the shell you use, it might be named any of the following ways:

.profile

.kshrc

.bash_profile

By configuring this script, you can take better advantage of the operating environment and your Oracle software. Different types of users also may have different profiles. Furthermore, you may have multiple profiles depending on what you will do when you log in.

The profile sets up variables, execution paths, permissions, and sometimes limits in your session. The Oracle documentation recommends specific settings for your environment. Some are OS specific; others apply to almost all Oracle installations.

Definitely include these elements in your profile:

Oracle base variable

Oracle home variable

Path variable

Default file-permission settings

Aliases

Library variables

Without a properly configured profile, you have to change these every time you log in to the system. We want to say having a profile is a requirement, but technically it’s not. However, you should make it part of your standard practice.

Write Your Own Documentation

Although plenty of documentation is available for you on the Internet and from Oracle itself, none of it is going to apply specifically to your installation. Every system has its little ins and outs and configuration customizations that differ slightly from what’s out there. Even if you follow the Oracle documentation to the letter, wading through it to install the software a second time (say, on another machine) is sometimes tedious.

Call your documentation what you want:

Playbook

Cookbook

Cheatsheet

Creating a document with all the concise steps needed for your installation (and patching, database creations, and backup strategies) and keeping it in a shared, accessible location will help all future activities be more consistent, efficient, and mistake free.

You may not always be at your company. You also may leave on good terms. Making sure your replacements have everything they need to understand what you did and why in the Oracle environment helps the transition go more smoothly. Plus, you can take your documentation with you to help on the next job!

Set umask

If you read and follow the Oracle documentation, setting the umask parameter should not be a problem. Linux/UNIX environments have an umask setting.

Forgetting to properly set the umask parameter means a difficult, if not impossible, Oracle installation. The result doesn’t typically affect the Oracle software owner; instead, it affects the users who log in to the OS and try to use the system.

umask sets the default permission modes on files and directories that are added to the system. These permission modes can affect files copied to the system during installation, as well as things like log files, which are created as part of normal operation.

The Oracle-recommended umask is 022. This setting results in files being read+write for the owner and read for all others. If you put the umask setting in the profile, it sets each time you log in.

Become Oracle

On a production system, the Oracle database software should be installed by a user specifically created for the task. This user is typically named oracle. Imagine that. Now, this isn’t a hard and fast rule, but we recommend that you seriously consider this — especially if you’re a beginner. This is the setup that you find in most systems as well as training materials and documentation.

Naming the user oracle avoids this scenario: The Oracle software is installed as another named user or by a user associated with a different software package. You don’t want John Smith installing the Oracle software stack under his own ID. He may leave the company someday, leaving you with a problem.

It’s not best practice to let login IDs exist for people who no longer work at the company, which is a security concern, not to mention confusing.

Set up a dedicated ID (we recommend oracle) to install software with. This dedicated ID makes maintenance and training easier, and it eases personnel transitions. This recommendation also comes from Oracle.

Some people have multiple versions of the database installed on the same machine. This is okay. You can keep the versions separate by having separate oracle owners. For example, you might have ora11g, ora12c, and so on.

Stage It

If you download the software from the Oracle website, you don’t need it on DVD for installation. We recommend keeping a hard copy somewhere for recovery reasons, but that’s about it.

Even if you bought the installation DVDs, copy the material to the hard drive before the installation.

The install is faster if the Oracle Universal Installer is reading from hard disk as opposed to DVD.

You don’t have to worry about someone else in the server room ejecting the disk and it disappearing forever.

Having a copy of the software helps if you want to add a feature that you hadn’t installed at first. It’s easier to find the copy in a staging area than hunting down the disk.

If the Oracle binary files are corrupt or lost due to some sort of disk failure and you need to reinstall a portion of the code tree, it’s right there. Sometimes downloading it can take some time. Having it readily available is the best thing to do.

You can get software from Oracle two ways:

Order it from the Oracle store.

Download it from the Oracle website.

Both copies are identical. The downloadable software isn’t a trial version. Anyone can download and use it, provided you contact an Oracle sales rep and pay for it.

Patch It

You just downloaded and installed your brand-new Oracle database. Now we’re telling you it needs to be patched. What?! Whether you order the DVDs or download the software, you’re probably not getting the most recent version. If you’re licensed for Oracle — and you should be — log in to the Oracle Support website and search for the most recent patchsets to apply to your database.

1. Go to the Oracle Support website at http://support.oracle.com.

2. Enter your login ID.

If you don’t have one, click the Register button and follow those instructions.

3. Enter your customer support identifier (CSI).

You get this when you purchase support from an Oracle sales representative.

When you log in, you see tabs across the top of the page.

4. Click the Patches and Updates tab.

5. Click Product or Family.

6. Enter the following information:

• Your product (RDBMS Server)

• Your release

• Your OS

• On the left, options to customize your search

We recommend being on the latest, greatest maintenance release of the Oracle software — but make sure the software is compatible with or supported by your application.

Many times we’ve discovered a client with an older version of Oracle. When we recommend a patch, the client announces it has some third-party software vendor who certifies only on a certain patch level.

Despite the problems with third-party software, there are benefits to being on the latest Oracle patchset:

Oracle keeps creating patches to fix bugs in the release as long as your patch level is supported. Otherwise, you’re out of luck.

Quarterly Oracle security patches are usually available for the most recent patchsets only.

The patchsets are maintenance releases in essence. This means that bugs found in previous releases are fixed.

Despite all the good things about being on the latest Oracle patchset, read the patchset documentation before you apply the patch; specifically, check the known issues section. Unfortunately, sometimes bugs are introduced with a patchset. Make sure that any new issues don’t affect the functionality your application works with.

Mind the User and Group IDs

This bit of advice pertains more to Linux/UNIX operating systems. When a group or user is created on Linux/UNIX, that group or user is assigned a user ID number. All file ownership and permissions are based on this number. By default, the OS chooses the first available number. This isn’t where problems occur.

Problems occur when you install Oracle on multiple servers — especially systems using Oracle RAC or DataGuard. Due to file sharing, if the user and group IDs don’t match across the systems, they’re not going to function properly. Furthermore, if you’re shipping Oracle files across the network (transportable tablespaces or cloning, for instance), you’ll have problems reading these files when they arrive.

The best practice is to specifically assign a number to your Oracle user and its associated groups when they’re created. Document this number in your company’s Oracle operating procedures manual. If you have multiple DBAs or Oracle installers, use the same ID numbers across all systems.

Back It Up

You finally configured your OS, set up all the Oracle users and groups, configured your profile, staged the software (and its patches), installed Oracle, patched Oracle, and created your first database. Unlike the guide-lines in Chapter 11, here we are specifically referring to the software binary directories . . . not your database.

Now back up your work! Also, test your backup to make sure it’s usable. We have seen people lose jobs because they never tested a backup and were unable to recover something.

Besides just creating a backup at the end, you could do multiple backups as you go: after the OS prerequisites are done, after Oracle is installed, after the patch, and so on. That way, you can easily go back without completely starting over.