To see why it failed, see my post here.

After obtaining the required files for the 64-bit Windows installation they were unzipped into a staging area. In an effort to rule out a “null pointer” Java error, a common, catch-all error, they were unzipped a second time in sequential order (i.e., zip1, zip2, zip3)… it didn’t help.

The first error said that the target DB for the Oracle Management Server (OMS) needed to be cleaned up.

 

The clean-up got progressively more detailed in the first few attempts. After about five of those clean ups, a new machine image was in order. That way, a fresh installation can be started in 20 minutes, vs. a couple of hours.

Clean up was also done on the Windows side; however, possibly, not all required. Log files on Windows were in three basic locations: C:\Program Files\Oracle\inventory\logs, C:\Users\<username>\AppData\Local\Temp and also in C:\Oracle\em\middleware\logs.

Enterprise Manager did require clean up; but, when the clean up was performed, it failed, as follows:

 

We must not have gotten that far along.

The next error wasn’t the listener. It was the wrong IP address in the Linux /etc/hosts file. Just sort of crazy not to have that worked out right from the beginning.

When I am installing an Oracle database I am careful about Editions and options. Enterprise Edition does not automatically come with the extra cost options, yet, a default install loads (and links) them to Oracle. Some of these extra cost options are used internally by Oracle in lower Editions; but, that’s their problem. If I am not doubling my license cost by buying, let’s say, partitioning, I am not going to install partitioning.

When creating an OMS, it turns out, partitioning is required, as per the following screen shot:

 

The public synonyms were for the MGMT user… not properly deleted when doing the clean up. The recommendation was misleading, as there are over 7000 public synonyms in Oracle… there were 322 for the MGMT user.

Oracle does not always execute “cascade”, “including data files”, “including contents” qualifiers for command syntax. It’s always best to check… did it do what I think I asked it to do?

Re-linking the Oracle binaries to include the partitioning option required the DB to be shut down, two commands executed, and a restart. As it turned out, there were four more pieces of optional software that were required by WebLogic for the Oracle EM 12c installation.

The next four warnings could have been fixed immediately, or as I did, left until the end. The message follows here:

 

I have not investigated the values yet. It will be interesting to see if they fit within the general constraints of my system. Changing redo log size is not trivial though… Let’s get it installed first, and worry about it later.

The next screen was encouraging… showing the ports that the software was going to be using, as follows:

 

Note that this is an Oracle installation of Oracle products including the application server, WebLogic… yet, the ports identified above do not also spell out the WebLogic used ports.

On AWS I used security groups within the Amazon console. On the individual instances (hosts) I use iptables.

Be sure that these ports, and any other that you identify, are not blocked by such groups or rules.

The first big failure came next, at 40% completion, as follows:

 

A quick Bing search said the “40%” failure was anti-virus, and sure enough. It was. Now, with AV disabled, it continued (well, after a clean up and do over)…

Of course, now that AV is turned off, don’t Google for answers to Oracle errors… there are a LOT of Russian sites where Oracle can be found… a LOT of viruses, too.

Step 11 of 13, we’re almost there! LOL (I said that to my son so many times… I’m not superstitious; but, he says I jinxed myself)… almost there… the configuration about to be installed, as follows:

 

WebLogic kept creating a file in the top level directory on my laptop. I kept getting the following message:

 

I do not suppress such checks. In the very beginning, I tried to install OEM in the Program Files directory; but, Oracle does not like that location. It can be escaped properly and used; but, it is usually problematic at some point. The Oracle inventory and some log files are there; but, it’s easier to just not do it.

So I thought that WebLogic was throwing up from something in that first failed install. It is a valuable file to review. Hopefully, in a final installation, it will no longer be created, you know, outside of where it is supposed to be.

The next screen is as far as it goes, install wise, 52%, as follows:

 

The “View Log” link stays active the whole time. It’s pretty easy to follow what is going on here; however, once at 52%, it just sits for hours. Here is a snap shot at 51%, nothing bad has happened yet.

 

That last line contains a process ID… I was never able to find such process. I looked in the OS. I looked in Oracle. It wasn’t until much later that I figured out the WebLogic console, the ports, the user IDs and passwords.

This is a test installation. I used the same password everywhere and it shows in some of these screens. Rest assured, I am not so sloppy in real life; but, for here, the password is “Sc13nt1st”… and I must have typed it 250 times during 25 installation attempts.

I was a bit surprised to find the WebLogic password was “welcome1”. Come on Oracle! Geez!

Somewhere along the line I found out my recovery area was filling up. If you delete archive logs from Oracle at the command line, you still have to go into RMAN to recover the space. To my knowledge the installation never stopped because of this; but, I increased by recovery area to 10 Gb. No more question there.

 

Once the “process” at 52% has run for an hour or more it starts to repeat the same message:

Info: oracle.sysman.top.oms: Still running….

I counted over 15,000 of these info messages after a three hour run (while I slept).

At that point, if you stop the database and restart it, the WebLogic installation continues… I mean, at least it picks up the database connection and display the appropriate log messages… it does not move from 52% though.

If you cancel instead of stopping and starting the database, the installer GUI disappears.

Various messages along the way are informative; but, none lead to the eventual installation. I was able to identify an important directory on the Oracle 11g DB side… /var/opt/oracle/oraInst.loc was missing. This file is located in $ORACLE_HOME by default; but, for some reason, something required it to be elsewhere.

Connect to the host, su to root, md oracle, chmod, chown, and it’s all fixed. Even after doing so though, the installation logs still said the file was missing. It’s not hard to see it getting confused. With the 10 plugins that I selected to install, there were a total of 33 different “Oracle Home”s.

I suspect it was confused more than once. (So was I, btw)

The only “failure” message that appeared in any of the logs was the failure created by the DB restart… and the WebLogic installation continued after that…

 

The next message threw me for a curve… I was never able to find a table or view by this name.

 

It did make me think about another database being out there… I found the WebLogic Server Console; but, still, never found this table. Even after linking the other four extra cost options back in… never found it.

The next snapshot shows an Oracle error at the correct time for the failure… But, all it shows, really, is the statement “SEVERE: Failed Parameter Validation”… that could be as innocent as a mis-typed password.

 

Here is the “still running” message that follows each failure:

 

The following “clean up” command worked for me, of course, substituting my values for those in the three snap shots below. Please excuse that there are three; but, at least the whole command is present… if you need the info, it’s here.

 

> scroll right

 

 

> one more time for third piece of command:

 

 

Close, but no cigar… status 0 sounds encouraging; but, it failed, that process I couldn’t find, doesn’t exist now, for sure.

 

All of that over five days, twenty-five installs, two or three new AMIs. My customer pays for the Amazon resources; but, I do not bill for failed installations unless it was the customer’s fault. This was my fault, or Oracle’s Fault, or ??? Not the customer’s fault.

Remember, you can check out why it failed here.

Thank you Oracle!

Leave a Reply

Your email address will not be published.