When you install an Oracle code tree on a non-windows platform, Oracle includes a utility that allows you to change the OS environment and access different databases running on the machine. Let’s investigate using Oracle’s oraenv utility.

What is oraenv?

I will start off by clarifying, there are actually two scripts oraenv and coraenv. If you use the C shell, you will use coraenv. If you use bash, Bourne or Korn shells, you will use oraenv. They both perform the same function: using the information stored in the oratab, it gets the path to the Oracle home, updates the OS path with the Oracle home directory and sets the variables ORACLE_HOME, ORACLE_SID and ORACLE_BASE. I will continue to reference oraenv, but everything here applies to coraenv as well.

Interacting with oraenv

Oraenv is located in /usr/local/bin, which is normally included in a user’s default path on the machine. That means that you won’t have to include the full path to the script when you want to use it. Let’s look at an example of changing the environment from one database to another.

If we look at the OS variables, we can see that we are configured to access the 12c database DH12102A:

/home/oracle> echo $ORACLE_SID

DH12102A

/home/oracle> echo $ORACLE_HOME

/orasw/app/oracle/product/12.1.0/db_12102a

/home/oracle> echo $PATH

/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:.:/orasw/app/oracle/product/12.1.0/db_12102a/bin

And if you check the version of sqlplus, we see that it is the 12.1.0.2 version:

/home/oracle> sqlplus -v



SQL*Plus: Release 12.1.0.2.0 Production

If you look at the oratab, you can see the databases on the server (only the last two lines are shown):

/home/oracle> cat /etc/oratab

DH11204A:/orasw/app/oracle/product/11.2.0/db_112044:N

DH12102A:/orasw/app/oracle/product/12.1.0/db_12102a:N

I have two databases, DH11204A and DH12102A. As you can see, they are versions 11204 and 12102 respectively.

Let’s change the environment to the 11.2.0.4 database. Since oraenv is a shell script and you want the changes made by the script to alter the environment variables in your current shell, you will include a period before you run the script. Read this for more information on Unix/Linux shell sourcing.

/home/oracle> . oraenv

ORACLE_SID = [DH12102A] ? DH11204A

The Oracle base remains unchanged with value /orasw/app/oracle

Now when we look at the same variables, we can see that oraenv has updated the variables. We are accessing the database DH11204A and the 11.2.0.4 Oracle binaries:

/home/oracle> echo $ORACLE_SID

DH11204A

/home/oracle> echo $ORACLE_HOME

/orasw/app/oracle/product/11.2.0/db_112044

/home/oracle> echo $PATH

/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:.:/orasw/app/oracle/product/11.2.0/db_112044/bin

/home/oracle> sqlplus -v



SQL*Plus: Release 11.2.0.4.0 Production

 

Non-interactive usage of oraenv

What if you are running a script that will change the database environment, but there is no human interaction? For example, a script that will run a sql script against every database on the server. To do this, oraenv looks for an OS variable, ORAENV_ASK, to determine if it will prompt you for the new database SID. If ORAENV_ASK is set to YES or if the variable is not defined, oraenv will prompt you for the SID that you want to use. If ORAENV_ASK is set to NO, oraenv will change the environment to the SID specified in the OS variable ORACLE_SID.

As you can see, we are still using the 11.2.0.4 database from the previous example:

/home/oracle> echo $ORACLE_SID

DH11204A

Let’s change the back to the 12.1.0.2 database, using oraenv non-interactively:

/home/oracle> export ORAENV_ASK=NO

/home/oracle> export ORACLE_SID=DH12102A

/home/oracle> . oraenv

The Oracle base remains unchanged with value /orasw/app/oracle

Looking at the environment, we are using the 12.1.0.2 database again:

/home/oracle> echo $ORACLE_SID

DH12102A

/home/oracle> echo $ORACLE_HOME

/orasw/app/oracle/product/12.1.0/db_12102a

/home/oracle> echo $PATH

/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:.:/orasw/app/oracle/product/12.1.0/db_12102a/bin

 

Customizing oraenv

Surprisingly, Oracle promotes the idea of adding your own customization to oraenv. Looking at the tail end of the file, you can see where Oracle denotes where you can add these customizations:

#

# Install any "custom" code here

Your customizations are simply shell commands. You can use them to make whatever modifications to the shell environment that are needed when the database environment changes.

One of the changes that we make is to set an environment variable that points to the database trace directory. This saves us typing when we are diagnosing an issue that involves reviewing trace files or the text version of the alert log:

/home/oracle > tail /usr/local/bin/oraenv

export ORACLE_BASE ;

fi

#

# Install any "custom" code here

#



# ========================================================================================

# Set the db_trace environment variable that points to the trace and alert logs

# ========================================================================================

export DB_TRACE=${ORACLE_BASE}/diag/rdbms/`echo $ORACLE_SID|tr '[:upper:]' '[:lower:]'`/$ORACLE_SID/trace

You can see how this variable changes as we change the Oracle home:

/home/oracle> export ORAENV_ASK=YES

/home/oracle> . oraenv

ORACLE_SID = [DH12102A] ? DH11204A

The Oracle base remains unchanged with value /orasw/app/oracle

/home/oracle> echo $DB_TRACE

/orasw/app/oracle/diag/rdbms/dh11204a/DH11204A/trace

/home/oracle>

/home/oracle> . oraenv

ORACLE_SID = [DH11204A] ? DH12102A

The Oracle base remains unchanged with value /orasw/app/oracle

/home/oracle> echo $DB_TRACE

/orasw/app/oracle/diag/rdbms/dh12102a/DH12102A/trace

 

Oracle changes to oraenv

You will have to keep in mind that the oraenv is not always a static file, it can change. The file is created / recreated when you run the root.sh script for ANY Oracle home on the server. This usually happens when you patch or if you add a new Oracle home to the server. When root.sh is run, it will overwrite the existing oraenv and all of your changes are erased.

To overcome this, I created a shell script in a different directory that contains all of the oraenv customizations. Then I add a line to the end of oraenv that sources that file:

/home/oracle> tail /usr/local/bin/oraenv

fi

#

# Install any "custom" code here

# ========================================================================================

# Title       : oraenv_Custom_Code

# Author      : Darryl Hickson

# Date        : 26-JUL-2016

# Description : Create a call for the custom code for oraenv.

# ========================================================================================

. /orasw/app/oracle/admin/install/oraenv_custom_code.txt

It is a part of our procedures that when root.sh is run, we run a script that adds this command to oraenv.

 

Conclusion

If you are new to Oracle or new to Oracle on a non-Windows platform, oraenv will become a utility that you use a lot. Using Oracle’s oraenv gives the DBA an easy and consistent way to change between database environments and manage multiple databases on a server.