Pythian Group

I just arrived to Minneapolis, MN and will be speaking tomorrow at the Twin Cities Oracle Users Group 2011 Winter Meeting. It’s the first time I’m speaking for this user group so I’m excited to meet the new audience. I will present one hour version of my Grid Infrastructure Internals session. Of course, no demos during presentation as it’s just enough to cover the theory slides but I’ll leave the demo as a homework as usual. :)

Big thanks to Klara Hribkova, Vice President of TCOUG, for picking me up at the airport and organizing a dinner. I’ve had a lovely meal — Bison Pot Roast — melting in my mouth.

I’m staying at Doubletree Hotel Minneapolis-Park Place. Nice and clean and very friendly staff but what’s interesting about this hotel is that they have DSL modems in the rooms so each connection is going via its own DSL line. Isn’t that cool? Read the rest of this entry . . .

The past four days have found me very frustrated and at wits’ end while testing upgrades of standalone Oracle Grid Infrastructure (ASM) 11.2.0.1 to 11.2.0.2 on RHEL/OEL 5 VMs. The upgrade would seem to go fine, but after rebooting, I would see ASM and LISTENER running under the old (11.2.0.1) grid home directories again.

Looking at /etc/oratab, I saw this:

$ grep -i asm /etc/oratab
+ASM:/u01/app/grid/product/11.2.0/grid_1:N              # line added by Agent

grid_1 is the old grid home, I expect to see grid_2. The comment about being added by Agent led me to a path where I eventually took a look at /etc/init.d/ohasd, which is basically the master script that starts everything up. I noticed that this file hadn’t been updated as part of the patching, and contained this:

$ grep -i crs_home /etc/init.d/ohasd
ORA_CRS_HOME=/u01/app/grid/product/11.2.0/grid_1
export ORA_CRS_HOME

Read the rest of this entry . . .

Hello Birmingham!

It’s past Sunday midnight and I’m stuck in my room in the last couple hours finishing my slides for my masterclass tomorrow. Turns out that I’m presenting the very first session of the conference at 9am. I wish there is a keynote instead so that I could grab one more hour of sleep (it’s going to be deep into the night back home in Canada). Strange that the keynote was moved to Wednesday — I hope UKOUG has really good reason for that!

My two hours masterclass will start at the same time as Tom Kyte’s a-la keynote session — what a competition. On the other hand, there is no other sessions in server technology so I expect that folks without interest of database development will automatically end up in my session. I’m in Hall 5 – quite large room. Is it the second biggest room after the Hall 1?

I will need to work hard to keep the audience… maybe I shouldn’t plan for any breaks to make sure I don’t let folks slip out to the next sessions like James Morles’ Sane SAN 2010 or Jeremy Schneider’s Large Scale ASM.

My masterclass is based on the slides that I presented at the Oracle OpenWorld few months ago which, in turn is reworked session on Oracle Clusterware internals that I’ve done number of times as long session with demos. I thought updating this material to 11gR2 would be easy… Boy was I wrong!
Read the rest of this entry . . .

When news of the April 2010 PSU for Oracle 11.2 came out, I was excited to see it, since it marked the first non-one-off patch release for the 11.2 database software. I happened to have an 11gR2 test system running on 11gR2 ASM via standalone Grid Infrastructure. I applied PSU 9352237 to the DBMS home and fired it up, only to see the folly of my ways when any ASM file operations like disk resizing (or auto-extending) failed with ORA-1653. This was due to the DBMS component now having a higher version number than the ASM component, which ASM does not allow. The Grid Infrastucture PSU would need to be applied to bring the ASM component up to snuff, but that patch (9343627) was, at that time, only “announced” with no ETA. Alas, the patch was rolled back and we continued testing without it.

Then this week I check again and saw that PSU 9343627 was released and gave it a whirl. I was a little confused when the README seemed to contain a lot of instructions that always assumed it to be on a clustered, RAC install. My setup was a single-instance Grid Infrastructure installation just to provide ASM. I soon met problem upon problem when going through first this setup step: Read the rest of this entry . . .

The process for applying a patch on top of the CRS, or now called, the Grid Infrastructure, has changed from what we used to do on 11gR1 and prior releases.

The patch I had recently applied was in order to resolve the Oracle bug “11.2.0.1 ONS CORE DUMP or High Resource Usage [ID 988795.1]“.

Database name: TEST
Instance Names: TEST1, TEST2
Grid Infrastructure Home: /u02/app/11.2.0/grid/bin (non-share home)
Grid Infrastructure Home Owner: oracle

Due to the fact that the patch doesn’t require full downtime and could be applied on a rolling basis, the plan below is to be executed on each node at time. Read the rest of this entry . . .

Upgrading to 11g Release Grid Infrastructure? You probably want to read on…

Oracle 11g Release 2 Grid Infrastructure has been dramatically redesigned compare to 10g and 11gR1 Clusterware. Coming with impressive set of new features, Grid Infrastructure also uses much more memory. While RAM is rather inexpensive these days, it does pose an inconvenience in some scenarios. Particularly, for sand-box type installations that I use all the time for my own tests and demonstrations. For production upgrades, you need to be aware of and plan for increased memory usage.

I’ve been able to easily run a 2 node 10g RAC cluster on my MacBook with 4 GB of RAM allocating less than 1 GB of RAM to each virtual machine. That was even enough for a mini database instance with a very small memory footprint. Oracle 11g Release 1 was pretty much the same except maybe the database instance itself required a bit more memory but one node could still fit within 1 GB of RAM.

In 11gR2, bare-bone Grid Infrastructure processes alone consume 10+ times more memory (11.2.0.1 on 32 bit Linux to be precise): Read the rest of this entry . . .