As mentioned in the first part focusing on installing Oracle Analytics Server, the first step is about preparing the environment where you are going to install the product.

Everything starts with an operating system. OAS doesn’t care much about the “kind of hardware” on which it does run (physical hardware, virtual machine, containers), but it does care about the OS it does run on.
It is an enterprise server-side application! It is true that in the past (many years ago) it was possible to install the predecessor of OAS (OBIEE) on a desktop Windows environment. Starting with OBIEE 12c first, and OAS now, this is not supported anymore.
Many keep trying and keep failing. OAS requires Windows Server or Linux (Oracle Linux, Red Hat Enterprise Linux, SUSE Linux Enterprise Server).

As I said, my preference is Linux. Even if you aren’t a Linux expert, the OS knowledge to install OAS is not much: how to install packages, how to create directories, and some understanding of users, groups, and permissions.

In the end, to make your choice of an OS, you first need to pick one that is supported by OAS. There is a table with the full list that you can refer to: https://docs.oracle.com/en/middleware/bi/analytics-server/administer-oas/certification-systems.html.
At this time my personal choice is Oracle Linux 8.

If you decide to go with an OS that isn’t on the list it doesn’t mean it won’t work, but if it doesn’t or you have issues, you are by yourself because you decided to use an unsupported OS. Could still be done for a sandbox or just to have a look at the product, but not suggested with anything meant for production use.

Just a reminder: despite the FMW 12.2.1.4 documentation covering the details for an installation on Solaris or AIX, OAS only works in Windows or Linux. You must pick the “least common denominator” OS between the supported options of FMW and OAS, therefore no Solaris or AIX.

Prepare the OS for the installation

Having a supported OS is a first step, but not enough: some system requirements should be met.
These OS’s prerequisites are where things start being challenging in the official documentation. OAS requires first to install Fusion Middleware 12.2.1.4, and the documentation for this one has a detailed list of OS requirements.

Here as well it isn’t always the easiest to decide what applies to you or not, because FMW has multiple usages, therefore you have to go through the documentation and decide for every step if it’s something applying to FMW in general or only when FMW is used for a specific product.

Oracle Linux quick win

If you are installing on Oracle Linux or Red Hat Enterprise Linux there is a quick win to avoid having to go into details: by installing the oracle-database-preinstall-19c package most of the OAS requirements will be covered. The downside of this approach is that a lot more than what is needed by OAS will be installed.
It will be cleaner if you do take 5 minutes to look at the FMW 12.2.1.4 system requirements and install the required packages only.

No need to overthink the resource requirements, the FMW documentation is a bit generous with what they suggest. In practice, the amount of resources you need depends on the usage of the system. Just keep in mind it is an enterprise application: if you don’t have at least 4-6Gb of memory, it will probably never start, and with a single slow CPU you better take your time because … you will be waiting a lot.

For the required packages needed, the documentation gives precise versions: honestly, I generally go by the rule of “that version or newer should work, hopefully”. On Linux, you can use your package manager (yum or dnf for example) to find what package provides the required dependency.
What does work on Oracle Linux 8 for me is to install these packages: binutils gcc gcc-c++ glibc glibc-devel libaio libaio-devel libgcc libstdc++ libstdc++-devel libnsl sysstat motif motif-devel redhat-lsb redhat-lsb-core openssl make xorg-x11-utils compat-libgfortran-48 (the last one isn’t an FMW requirement but an OAS requirement for machine learning).

Last but not least, installing a valid Java is required. You must use Oracle JDK 8, the newer the better (but still in the Oracle JDK 8 family, forget JDK 11, 17 or 21) but at least the version listed in the table where you found the supported OSs.
Recently there has been a lot of noise about a change in Oracle licensing rules for Java. I didn’t read the whole license agreement, but don’t worry: you need Java to run OAS and therefore it is covered by the OAS licensing.

What account should own OAS?

This is probably the most obvious thing, but always worth repeating it. Never ever install and owns OAS as root. Why are you even using that account? You shouldn’t.
Similarly, if you are installing in a compute instance in Oracle Cloud, do not use the opc account: it has passwordless sudo permissions, and you don’t want to have a tool like OAS running with that account (remember the log4j vulnerability a few years ago giving access to the server? Imagine what can happen if the user running the tool has passwordless sudo permissions…).

To avoid making your life more complicated than needed, the product has to be installed with the account you will use to run it. This will avoid you from having an unpleasant time changing ownership and permissions on files and directories.

Also, do not install it with your own personal account. You could leave the company or change job tomorrow, while OAS will still be there. No need to guess what will happen if your account is locked, or removed, as part of your offboarding process.

Create a technical account used to install and own OAS, this way the product is safe against any employee movement. And that technical account has little permissions on the environment, in case of security vulnerability you limit the damages.

Installing OAS is mainly extracting files and directories

Once your OS is prepared for the installation, you can start the real installation process. It isn’t as exciting as the word makes it sound.
Installing OAS is mainly extracting a bunch of files and directories.

The installation will create the ORACLE_HOME, the directory containing the binaries of the product. I highly suggest placing the ORACLE_HOME into a folder identified by the product (name and) version. Why? Because, in a year or two, you will be able to do an in-place upgrade, which consists of the replacement of the ORACLE_HOME with a new one using the new binaries, and preserving (but upgrading) the domain. Having the version in the path will help you easily identify what is what when you will be upgrading, and more importantly when deleting the old ORACLE_HOME, and also to quickly identify what is installed on the server.

There isn’t much more needed for the installation, that’s why the response files, text files containing all the parameters for the installation, are mainly empty and only ask for the ORACLE_HOME path.
Talking about response files: you can generate them by running the GUI wizard and saving the response file before performing the installation. As an alternative, you can find them in my OAS 2023 Docker image: weblogic.rsp and oas_install.rsp. As you can see inside there is a single placeholder, ###ORACLE_HOME###, that is replaced by the path of the ORACLE_HOME (in my Docker this will be /opt/oracle/product/7.0.0).

The installation is as simple as running 2 commands:
java -jar fmw_12.2.1.4.0_infrastructure.jar
java -jar Oracle_Analytics_Server_2023_Linux64.jar

With OAS 2023 be careful to not execute the wrong file, there are 2 .jar files with a very similar name, but Oracle_Analytics_Server_2023_Linux642.jar is used automatically during the install (it does provide the “disk 2” sources) and shouldn’t be used directly.

Patching, patching, and patching again!

I already explained in the first part why you must patch a product released just a few days ago. As a reminder: FMW 12.2.1.4 is around for quite some time, this is the one requiring patching mainly.

The issue with the requirement of patching is that you need access to My Oracle Support (MOS) site.
First, that’s where you find the exact list of what patches should be installed. Second, that’s where the patches can be downloaded.

You should first start by looking at Critical Patch Update (CPU) Advisor For Oracle Analytics Server and Oracle Business Intelligence (Doc ID 2832967.2). It is a page you should bookmark because it provides, in a single place, the full list of patches required by the whole OAS stack.

Patches on Oracle products are generally applied with the OPatch utility. OAS comes with a version of OPatch, but it will quickly be outdated. This is why before patching I like to first update OPatch itself.

What is OPatch?

OPatch is a platform-dependent utility that requires installation of the Oracle Universal Installer.

Patches are a small collection of files copied over to an existing installation. They are associated with particular versions of Oracle products. When applied to the correct version of an installed product, patches result in an upgraded version of the product.

Interim patches are bug fixes available to customers in response to specific bugs. They require a particular base release or patchset to be installed before you can apply them. They generally address specific bugs for a particular customer. These patches are not versioned and are generally available in a future patchset as well as the next product release.

Below are the main functionality of opatch:

• Applying the patch
• Rollback the patch
• Conflict check
• Report the installed components and patches

https://support.oracle.com/epmos/faces/DocContentDisplay?id=1486109.1

Some patches are individual patches and they always come with a README file saying how to install them. It is generally a call to OPatch from inside the directory of the patch. Some other patches are bundles and their installation is slightly different, but still performed with OPatch.

Have a look at the Dockerfile of the OAS 2023 image for the list of patches currently (April 2023) required by OAS 2023 and how to install them (between rows 146 and 209 there is the update of OPatch and the installation of all the needed patches).

The next part will go through the optional creation of the FMW database schemas with the RCU, and most importantly the configuration of OAS: the step that will result in a working environment.