Geeky Project Part 6: Create a WebCenter VM

By Jake • December 10th, 2009 • View Comments

Can has halp?Today, I hit a roadblock in my ongoing project to create a WebCenter VM.

I was all ready to get started with the WebCenter install. I found the installation guide and ran the installer.

Then, I hit the prerequisites.

WebCenter prerequisites

Looks like I need to create the schemas first with the Repository Creation Utility (RCU), available for download here. No problem, download, unzip and off we go into another wizard.

Then, I hit this step.

Uh oh, connect information, knew I should have jotted that down somewhere

Uh-oh. It’s asking for database information that I don’t think I have. Hostname (or IP), I have. Port I assume is 1521, since I don’t recall changing it. Service name, oracle?  Username with SYSDBA privileges? Oy, now I’m hosed.

I should have taken a screenshot of this stuff. I rummaged through all the Post-Its on my desk, but I can’t find anything about usernames and passwords for 11g.

Plus, I can’t seem to find the default password for sys or any default DBA user.

Houston.

My first instinct was to remove the install and try it again. This time, writing down all the configuration details.

I’m totally bumming that I just did some housecleaning and removed the 11g install archives. Grr.

OK, so I downloaded them again and ran the installer.

I should create a database this time.

Oh, maybe I should install the demo database this time.

Server class?

The options are a bit different now. I should install the Server Class version of Enterprise Edition, right? I really don’t want to do this again. So, why not, on the off-chance I need the Server Class version later.

I’ll spare you the gory details, but I chose the Advanced option and then hit this error.

Unexpected errors are bad.

Unexpected errors are not good. OK, back to the drawing board. Remove 11g and restart.

This time through I went with the Typical (vs. Advanced) option to avoid that error I couldn’t diagnose. It went well, and I was able to start the installation.

Then, at 38%, I hit this error:

File not found is also not good.

Weird. Some Googling uncovered this explanation. Somehow managed to bork up the unzip this time. I’m a bit fried at this point.

Back to it after unzipping again. I decided to let the installer run a bit while I grabbed some grub and watch a little “Nerdcore Rising“, which I rented from Amazon Unbox for a very reasonable $0.99 and thoroughly enjoyed.

After a short break, I came back to discover the installer frozen at 69%; its status was “Linking RMAN Utility”.

Ugh, I assumed the VM froze or something. So, remove, run installer again. Rinse, repeat.

This time I monitored the process more closely, and again, it froze at the same step. To prevent failure due to my impatience, I left it for a while and nothing.

By now, I’m running out of ideas.

Then I remember I have Time Machine backups of this VM. So, I can rollback to six hours ago and try to use Enterprise Manager to get the information I need to run RCU.

Note, by this time, I’m having trouble retracing my steps to the original problem.

Great. So, I rollback and try to run Enterprise Manager, only to get an error about environment variables.

At this point, I need to step away and come back fresh.

So, what should I do? Can I salvage my installation and if so, how can I get the information RCU needs, since I failed to make a note of it?

Should I try to configure Enterprise Manager?

Rollback to Part 3 and walk through the 11g installation again?

Please find the comments if you have information.


Possibly Related Posts

  • Chris
    Hey Jake.

    There are two things I do when installing software I've never used before.

    1: Take frequent snapshots. If you screw up getting back to a "known good" state is just three clicks away.
    2: Screen record the entire process. It takes lots of disk space, but makes figuring out the settings I used really easy.

    Chris
  • Sure, good advice. Through Time Machine, I have snapshots, maybe not as frequent as I could get through VBox. Screen recording makes a lot of sense.
  • Hi Jake, Just curious, and I have to admit I have not read all 5 previous parts, but why not simplify the equation and use Oracle Database Express Edition (Universal for proper charset support)? http://www.oracle.com/technology/software/produ...
    The RCU will complain, ignore the compatibility error and it works fine. You will need to bump up the processes > 200, but RCU will let you know this too. I am running an 11.1.1.2.0 SOA Stack on 10g Express without any problems. I actually limited it's memory consumption to 384K total and have no performance issues for the vm-based demos/local testing that I need to do. HTHs, Jordan.
  • Will Fusion Middleware 11gR1 run on XE? I guess I assumed it was tuned for 11g versions. I should be fine after stepping away overnight. I was in the weeds a bit too far and tired, which made it worse. Thanks for the suggestion.
  • I think it depends on WC's requirements. XE is an early version of 10gR2 (10.2.0.1, maybe), and unpatchable. So if the minimum requirements for WC's repository are 10.2.0.4, for example, XE is a non-starter. Furthermore, XE caps out at 4G of data, so if the WC repository is bigger than that, or will quickly get bigger than that you're out of luck. It may also be that WC will still *work* against 10.2.0.1, even if it's not certified, which is fine for a sandbox, so then you just have the 4G data restriction to worry about.

    Anyhoo, if neither of those restrictions apply, and 11g RDBMS continues to be problematic, XE might be the way to go. Nothing beats installing an entire database, software and data files, from an RPM. :)
  • Yeah, the 11g vs. 10g problem is exactly what I was thinking might prevent this. Also, I'm not sure how big the repository is for WC, but the ECM repository alone could get pretty big.

    Plus, I wanted to do this with the latest shiny objects available :)
  • I'm slightly confused as to what state your software stack is in after rollback, because it's late and I've only just lazy-skimmed parts 3-6 again to re-familiarize myself with the process. If, however, you're in a state where you have a stable 11g RDBMS install (that is, before you removed the database software and attempted a re-install), then you can use the Database Creation Assistant (dbca) to create the database, without reinstalling the database software. At a minimum, before running DBCA, you'll need to set the following environment variables:
    ORACLE_BASE
    ORACLE_HOME
    Assuming you kept the defaults when you installed before, ORACLE_HOME will be '/u01/app/oracle/product/11.2.0/dbhome_1' and ORACLE_BASE will walk back a bit from there: '/u01/app/oracle' After those are set, it's useful to set a few more environment variables. So, something like this at the command line, as the owner of the oracle RDBMS software (presumably oracle), not root:
    export ORACLE_BASE=/u01/app/oracle
    export ORACLE_HOME=${ORACLE_BASE}/product/11.2.0/dbhome_1
    export PATH=${ORACLE_HOME}/bin:$PATH
    export LD_LIBRARY_PATH=${ORACLE_HOME}/lib:$LD_LIBRARY_PATH
    dbca &

    As you run through the dbca utility, it's going to ask you where to store data files and stuff, and a handful of other options. I'm not sure what the defaults are going to be, because I always change them ;-), but since this is just a testbed, you might be able to get away w/o tweaking too many defaults. When the the time comes to choose your storage option, I'd suggest selecting the "Regular filesystem" option rather than ASM, which is its own kind of fun but not a core part of this particular venture.

    Sorry to be vague, but at least I didn't just paste a link to the CREATE DATABASE command. ;-)
  • Great, I'll give dbca a shot when I get back into it, and yes, Time Machine has a version with a pristine 11g install. Those environment variables don't stick, do they? I'll need to dig up how to apply them to oracle each time.

    I knew someone would mention the CLI way to do all this, which I considered but didn't have the patience to try. My tiredness wasn't helping me think straight, and I was looking for easy answers.

    Anyway, appreciate the assist.
  • Regarding making environment variables stick: since you're going to have multiple ORACLE_HOMEs on this server (one for the RDBMS and one for WC at a minimum, I recommend putting the commands to set up the oracle environment in a short shell script. For example:
    zathras:~ jpiwowar$ cat 11gdb.env
    #!/bin/bash
    export ORACLE_BASE=/u01/app/oracle
    export ORACLE_HOME=${ORACLE_BASE}/product/11.2.0/dbhome_1
    export PATH=${ORACLE_HOME}/bin:$PATH
    export LD_LIBRARY_PATH=${ORACLE_HOME}/lib:$LD_LIBRARY_PATH
    zathras:~ jpiwowar$ . 11gdb.env
    zathras:~ jpiwowar$ echo $ORACLE_HOME
    /u01/app/oracle/product/11.2.0/dbhome_1

    Invoking the .env script with the leading '. ' will make sure that the environment variables are exported to your current session, and not just set for the (very short) life of the script's execution.

    You might also want to set up a similar script that sets up the WC environment variables, since you'll be dealing with a separate ORACLE_HOME and PATH at least, and maybe some other things specific to the WC environment.

    One drawback to this method is that environment variables like PATH and LD_LIBRARY_PATH can get "polluted" with entries from both ORACLE_HOMEs if you're switching back and forth a lot between environments. I blogged a solution to that a while back, if it's relevant.

    BTW, you leave the CLI as soon as you type dbca, and you're back to a GUI.

    Here ends the latest missive from the Dept of "Way more than I needed to know, thanks." ;-)
  • That wasn't "way more than I needed to know". That's all good stuff for my "stuff I figured someone smarter than me would know" department. Awesome, thanks again.
  • Okay, cool, glad it's useful. Apparently I'd passed my "comment length self-consciousness" threshold, and felt a need to add that last line. :-) Good luck w/ the next steps. :)
  • Also FWIW, unless I'm reading this completely incorrectly, at this point you can't have all of the information that the RCU needs, because there isn't a database there for it to configure. So no SID, no user w/ sysdba privs, etc. So don't feel badly for not writing that stuff down as you went along. :)
  • Yeah, again, what I should have done is remember that I planned to do this at some point before heading into the WC install. I need to work on this stuff earlier in the day :)
blog comments powered by Disqus