Red Pill Analytics recently performed the installation of OBIEE 12c on an Exalytics machine for one of our customers. There is no option to use the Domain Management Utility for installing OBIEE 12c… that’s still only capable of installing OBIEE 11g. Therefore OBIEE 12c is a manual install on Exalytics, but it’s very similar to installing OBIEE 12c on OEL 6.6 instead.
The customer wanted to host both the DEV and TEST environments on one machine. We could have used one Middleware Home and multiple Domains — which is very easy in 12c — but the client wanted complete isolation between DEV and TEST, which is best delivered by persisting dual Middleware Homes. There are of course pros and cons to each approach, but due to the customer requirements, we took this route.
![Installing OBIEE 12c on Exalytics](http://redpillanalytics.com/wp-content/uploads/2017/03/Phil1.png)
Finally, we also wanted to split the BI Domains from the Middleware Homes as well, which is the recommended install technique for 12c. This was not an option in OBIEE 11g, as the Domain was really useless, and it was the Instance that was key, so patching meant upgrading the installation and the configuration at the same time. Now, everything that was done by the Instance in 11g is managed by the Domain, which like most of Oracle Middleware, is where it belongs.
So what does this actually mean? In simple terms, an upgrade of OBIEE 12c means creating a new Fusion Middleware Home, and then upgrading the Domain to use that new Fusion Middleware Home. With an architecture like this, we can avoid some confusion. For example if we place the Domain inside of the Fusion Middleware Home (old school), when we upgrade, the Domain will be within an older version of FMW, but pointed at a newer version. Seems strange and confusing to me. Don’t feel bad if you didn’t know this OBIEE 12c fun fact; we were in contact with Oracle ACS during this process, and surprisingly even they were unaware of it!
This post will walk through the steps of accomplishing these tasks. These steps could be adapted for installing on any Linux environment that is pursuing an architecture set up like this.
A few additional notes before we get started, then. I have set up the directory structure so that each OBI instance will be on it’s own mount point (/u01 and /u02). I also created two separate oracle users — one for each instance. Usernames like Oracle01 and Oracle02 (or something similar) work well in this case; these easily correspond to the mount points our environments are deployed on. Why bother with separate users at all? This allows us to avoid any complications of having one user be the software owner for multiple instances. You may need to edit the memory limits set for these users in the /etc/security/limits.conf file. Our default limits were lower than what we needed to run the services, which could make you look a bit like Han Solo when you see the config failing upon the start up phase.
![](https://cdn-images-1.medium.com/max/1600/1*ZoAixM33Muh_u8ObAb9Y8Q.gif)
I installed using /u02, so the instructions will reflect those paths. Be sure to change your scripts to match your directories where applicable. Also note that I will be installing via response file, not with the GUI. Here are the response files for the FMW Infrastructure Install, the OBIEE Install, and the OBIEE Configuration.
- Obtain the software files and move them to your Linux environment. You can download them and SCP them to the machine; or, you can use WGET to have the files land directly on to your machine. For this installation you will need JDK1.8.0 version 101 or higher, the FMW Infrastructure installer, and the OBIEE 12c files.
- Install the JDK (be sure to have 64 bit) into the appropriate directory by unzipping the package and moving the directory. We’ll be using partitioned JDKs in this environment, meaning that we will have a JDK that supports each OBI environment. I placed mine in /u02/oracle/java.
- Then set the JAVA_HOME variable to your new jdk directory by running an export command. Additionally, export this to the PATH variable. Make sure that they have exported correctly by echoing these variables. Finally, check the java version with the java version command. The commands are listed below.
export JAVA_HOME=/u02/oracle/product/java/jdk1.8.0_111
export PATH=$JAVA_HOME/bin:$PATH
echo $JAVA_HOME $PATH
java -version
To work around any potential X forwarding or tunneling issues you may have on your machine, I’ll be describing how to do the silent install. This install type will run the install without a GUI window, meaning that all of the parameters for the install must be set within the response file. This also means that we will have to create all of the directories that we want our files to land in, as we won’t be able to create them on the fly within the GUI. Let’s begin.
Run the following commands to create the directory structure:
mkdir /u02/oracle/product
mkdir /u02/oracle/product/12.2.1.2
mkdir /u02/oracle/product/12.2.1.2/obi_1
mkdir /u02/oracle/config
mkdir /u02/oracle/config/domains
mkdir /u02/oracle/config/domains/bi
mkdir /u02/oracle/oraInventory
echo 'inventory_loc=/u02/oracle/oraInventory' >> /u02/oracle/oraInventory/oraInst.loc
echo 'inst_group=oracle' >> /u02/oracle/oraInventory/oraInst.loc
Once you have created the directory and the install files, it’s time to edit the response files. In the location where you have unzipped the software, open the .rsp file and edit the ORACLE_HOME value to match the directory above. Mine was /u02/oracle/product/12.2.1.2/obi_1. Also edit any other parameters in the response file that need to be changed for your environment. Then execute the following command to install the infrastructure. Your command may be different depending on your directory set up.
java -jar fmw_12.2.1.2.0_infrastructure.jar -silent -responseFile ./fmw_12.2.1.2.0_infrastructure.rsp -invPtrLoc /u02/oracle/oraInventory/oraInst.loc
Once the infrastructure has finished installing, we’ll need to export several variables for the OBIEE software install. Run the following commands to export the DOMAIN_HOME, FMW_HOME, and PATH variables. As before, I recommend setting these in the user’s bash profile as well. Once you have set the variables, be sure to check them with the echo command.
export DOMAIN_HOME=/u02/oracle/config/domains/bi
export FMW_HOME=/u02/oracle/product/12.2.1.2/obi_1
export PATH=$PATH:$DOMAIN_HOME/bitools/bin:$FMW_HOME/oracle_common/common/bin
echo $DOMAIN_HOME $FMW_HOME $PATH
Now unzip the OBIEE software packages and edit the response file to reflect the environment you’d like to create. Specifically, you will have to edit the DECLINE_AUTO_UPDATES, ORACLE_HOME, and INSTALL_TYPE parameters to conduct the install. Once the file is ready, execute the installer by running the following command (again, be sure to tailor it to your environment).
./biplatform-12.2.1.2.0_linux64.bin -silent -responseFile /u02/oracle/bi_platform-12.2.1.2.0_linux64.rsp -invPtrLoc /u02/oracle/oraInventory/oraInst.loc
Once this install has completed, make edits to your config response file, and navigate to the following path: $FMW_HOME/bi/bin. Here you will find the config scripts for running the configuration of your environment. Run the below command to kick off the configuration (with edits made for your environment, of course).
./config.sh -silent -responseFile /u01/oracle/config.rsp
Once the configuration has completed, the services should start right up, and you’ll be able to start using your environment!