Comments on: Geeky Project Part 6: Create a WebCenter VM

By: jpiwowar

jpiwowar — Sun, 13 Dec 2009 08:36:17 +0000

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.

By: jpiwowar

jpiwowar — Sun, 13 Dec 2009 00:36:17 +0000

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.

By: Jake

Jake — Fri, 11 Dec 2009 15:09:48 +0000

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.

By: jpiwowar

jpiwowar — Fri, 11 Dec 2009 14:19:26 +0000

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." ;-)

By: Jake

Jake — Fri, 11 Dec 2009 14:15:07 +0000

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

By: jpiwowar

jpiwowar — Fri, 11 Dec 2009 13:53:53 +0000

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.

By: Jake

Jake — Fri, 11 Dec 2009 13:42:16 +0000

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

By: Jake

Jake — Fri, 11 Dec 2009 13:41:08 +0000

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.

By: Jake

Jake — Fri, 11 Dec 2009 13:35:30 +0000

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.

By: Jake

Jake — Fri, 11 Dec 2009 13:31:31 +0000

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.

By: Chris

Chris — Fri, 11 Dec 2009 12:42:59 +0000

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

By: JordanOAtOracle

JordanOAtOracle — Fri, 11 Dec 2009 10:13:46 +0000

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.

By: jpiwowar

jpiwowar — Fri, 11 Dec 2009 06:11:17 +0000

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.

By: jpiwowar

jpiwowar — Fri, 11 Dec 2009 05:18:17 +0000

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.