I’m posting this because apparently it hasn’t happened to anyone else except me (heavens knows I searched for help!). The root cause certainly wasn’t obvious to me, so hopefully, this will help someone (maybe me, once I forget about it).
All I needed to do was install a default Oracle Database 11g R1 environment with a starter database for some experimentation. Seems simple.
I had archived a copy of linux_11gR1_database.zip from OTN, so I copied that to my Oracle Enterprise Linux 5 U1 virtual machine and unzipped it (no errors or warnings, mind you). I proceeded to launch the installer as the oracle user and it ran me through the 4-6 screens of questions, prerequisite checks, etc, then the summary screen and started installing. The progress bar on the first task (copying files or similar) quickly progressed to 38% and then stopped…forever (I waited an hour).
So, I checked logfiles…nothing. Checked CPU, memory, disk activity…system (VM) was completely idle. So, I killed it and relaunched. Ran through the same screens, but this time once the progress meter started, I ran strace against the installer process (attached when progress was around 20%). Once it got to 38% again, I waited a little bit to ensure it was once again “stuck” and then stopped strace to review the log…nothing different at the start when compared to the end–all looked fine.
On a complete swag (sorry BAAG!), I found another copy of the linux_11gR1_database.zip file on one of the fileservers at the office (original one was from my laptop) and copied it in to the VM. I proceeded to unzip it, then follow the same exact steps to launch the installer, answer the questions, and proceed to the installation. It worked fine.
Now I need to know why these two were different. As many of you probably know, the unzip utility’s default behavior is to scroll a list of extracted files as it extracts them. This means there’s a ton of output (over 2900 lines) scrolling by faster than you can read them. This is the normal behavior and most people, like me, just enter the command and then check back in a few minutes to see the end of the output. In this case, I need to know if there was some error reported part way through the extraction. So, I unzipped it again, but redirected output to a logfile for review (unzip linux_11gR1_database.zip > logfile.txt 2>&1). Reviewing that for the word “error” showed that several files (more than 8) were not decompressed properly due to some error condition. Further investigation of the unzip command syntax showed that the “-q” flag will provide “quiet” output. I tried this and found that the “-q” option does silence the normal verbose list of files shown by default, but still displays the error messages that would have been helpful to me.
Just for kicks, I tried unzipping the “bad” .zip file on my Mac (by double-clicking it which launches the Archiver utility) and it progressed about half way through and then threw an error and refused to continue.
The moral of the story is that from now on, I’ll always use “alias unzip='unzip -q'” to ensure I see the errors without all the noise. It also makes you realize that OUI is not just a single binary, but is comprised of many libraries and files, so just because it launches doesn’t mean it has all the necessary files to complete its tasks.
Good news: I figured it out. Bad news: I lost too much time figuring it out. Happy Friday!
Dan,
Just wanted to ask you a few questions concerning RAC. Is the Clusterware that is delivered with Redhat V5 the same as Oracle Clusterware.
If I already have the Clusterware that comes with Redhat V5 do I still need to install the Oracle Clusterware for RAC?
Thanks,
Miles
Hi Miles,
No, I don't think so. Red Hat doesn't deliver any Oracle software with
any of its releases. Oracle Clusterware must be installed from the
Oracle Clusterware media (CD or .zip file or .cpio archives) after RHEL
is installed.
In any case, you will *always* have to install Oracle Clusterware–even
if you do use a supported 3rd-party clusterware (I don't think RH's
clusterware is supported or necessary for RAC unless it's required for
RH's cluster filesystem–not sure on the support status of that). So, if
you were using, for example, Veritas Cluster Server or Veritas Storage
Foundation for Oracle RAC, you'd install and configure that product and
then install Oracle Clusterware “on top” of it. Oracle Clusterware's
installation process will detect installed and supported 3rd party
clusterware and properly integrate with it as appropriate. If the 3rd
party clusterware is not supported, then Oracle Clusterware very likely
won't detect it which may lead to conflicts in the future if one
clusterware wants to evict a node and the other does not.
Hope that clears it up.
Dan
Dan,
Curious if a checksum of the zip file would have revealed a different number than what is listed on the OTN page. Yeah I know it is after the fact, but another tool at hand to help us with those files we download from the Internet.
Brian
It sure could have, but this .zip file had been successfully been used
previously on other computers, so it was presumed to be “good” and there
was no reason to go through the extra checking step at this point. The
issue must have been when the .zip was copied from the shared drive to
my local machine–somehow a corruption was introduced during that copy.
Good tip, though–it'll definitely be on my list for troubleshooting if
this happens again!
Dan,
Thanks for clearing up this issue with Clusterware and Oracle. Just so you know Oracle RAC with RHEL-5 OS is only certified with Oracle Clusterware.
Thanks,
Miles
I hadn't checked the certification matrix on that, but I am rarely
seeing 3rd party clusterware being used these days (maybe it's just me),
so I haven't had a need to look it up. Thanks for the tip.
Useful tip. I've now started using the -q flag most of the time when I do an unzip. Thanks!
Another “gotya” of this nature is with tar files, especially with the non-GNU versions of tar, some of which have limitations with the length of basename and filename – resulting in tar spitting out files which are not usable – this is especially prevalent in older traditional unix systems (Solaris etc.). The problem is reported however because most people execute tar with the verbose flag that there is so much output you don't notice the errors – $ tar xfv mark.tar. If you drop the verbose flag – only errors and the tar summary are printed.
The resolution to opening tar files with long pathname is to install and use the GNU version of tar (often called gtar) and use it when manually creating and extracting tar files (Note: do not replace the system tar – it's used by pkginfo).
HTH
Ah yeah – and a general good practice is to check the error code of the command you last ran (especially for important steps!).
$ echo $?
Will return the exit status of the last command – generally '0' implies a successful execution – consulting the man page for most commands will give a detailed description of the exit status meanings:
DIAGNOSTICS
The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the following values, except under VMS:
0 normal; no errors or warnings detected.
1 one or more warning errors were encountered, but processing completed successfully anyway. This includes zipfiles where one or more files was skipped due to unsupported compression
method or encryption with an unknown password.
HTH
Mark
Good tips. I am pretty sure I'll remember unzip -q before I'll remember
to check the exit code. Weird how I usually remember to check $? in a
script, but never do it interactively.
Thanks for the ideas!
Another “gotya” of this nature is with tar files, especially with the non-GNU versions of tar, some of which have limitations with the length of basename and filename – resulting in tar spitting out files which are not usable – this is especially prevalent in older traditional unix systems (Solaris etc.). The problem is reported however because most people execute tar with the verbose flag that there is so much output you don't notice the errors – $ tar xfv mark.tar. If you drop the verbose flag – only errors and the tar summary are printed.
The resolution to opening tar files with long pathname is to install and use the GNU version of tar (often called gtar) and use it when manually creating and extracting tar files (Note: do not replace the system tar – it's used by pkginfo).
HTH
Ah yeah – and a general good practice is to check the error code of the command you last ran (especially for important steps!).
$ echo $?
Will return the exit status of the last command – generally '0' implies a successful execution – consulting the man page for most commands will give a detailed description of the exit status meanings:
DIAGNOSTICS
The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the following values, except under VMS:
0 normal; no errors or warnings detected.
1 one or more warning errors were encountered, but processing completed successfully anyway. This includes zipfiles where one or more files was skipped due to unsupported compression
method or encryption with an unknown password.
HTH
Mark
Good tips. I am pretty sure I'll remember unzip -q before I'll remember
to check the exit code. Weird how I usually remember to check $? in a
script, but never do it interactively.
Thanks for the ideas!