Pythian Group

Hello everyone !

For my first time posting here on the Pythian Blog, I would like to share some of my tips/notes about patching Oracle Exadata, based on my experiences and not less important, research and googling =).

First, the Oracle Exadata Patch has 3 different components that should be patched. As we know about Oracle Exadata, the Exadata rack has a different components, like Cisco Switch, KVM, Power Distribuion Unit, etc… and we only are responsible for patching the Database Servers (usually referenced as compute nodes), Storage Servers (usually referenced as cell nodes) and the Infiniband Switches.

We can divide the patches in 3 different parts:

Storage Server Patch
Database Server Patch
Infiniband Switches Patch

Before starting, I would like to share and note here 2 documents from My Oracle Support, aka metalink. These notes must be the first place that you need to go to review before patching the Exadata environment.

Database Machine and Exadata Storage Server 11g Release 2 (11.2) Supported Versions (Doc ID. 888828.1)
- This is for the second and third generation (V2 and X2) for Oracle Exadata, using Sun hardware.

Database Machine and Exadata Storage Server 11g Release 1 (11.1) Supported Versions (Doc ID. 835032.1)
- This is for the first generation (V1) for Oracle Exadata, using HP hardware.

Oracle usually updates these documents for every patch that is released, including different information about that.

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 . . .

This is the 182nd edition of Log Buffer, the weekly review of database blogs. Make sure to read the whole edition so you do not miss where to submit your SQL limerick!

This week started out with me posting about International Women’s Day, and has me personally attending Confoo (Montreal) which is an excellent conference I hope to return to next year. I learned a lot from confoo, especially the blending nosql and sql session I attended.

This week was also the Hotsos Symposium. Doug’s Oracle Blog has a series of posts about Hotsos. If all this talk about conferences has gotten you excited, Joshua Drake notes that 14 days and the hotel is almost full for postgresql conference east which is March 25th-28th in Philadelphia. And the Oracle database insider notes that the Oracle OpenWorld call for papers is now open.

According to Susan Visser this week (ending tomorrow) is also read an e-book week. So if you have not already done so, read an e-book! She links a coupon for an e-book in the post.
Read the rest of this entry . . .

Oracle has just released their January installment of their critical patch update (CPU). Vulnerability CVE-2010-0071 is particularly critical, with a CVSS score of 10, the highest possible. It’s a remotely-exploitable listener vulnerability that’s particularly severe on Windows platforms.

Full details are on Oracle’s security site.

In the first part of this blog I tried to shed some light on EBS patch terminology and naming conventions. In this post, I’ll show you how to check your patchset levels and query applied patches.

The very first question is, how do I find out if patch “1234567″ for example, was applied?

Of course you can use OAM, as the current release has made a huge step in enhancing OAM to show all necessary information about applied patches. If, however, you don’t like to rely on the GUI, you have a number of other options, which I’ll show you here.

Essentially there are two tables one can use to check for applied patches: AD_BUGS and AD_APPLIED_PATCHES.

It is important to understand the difference between these two. AD_BUGS contains all bug numbers fixed on your system, while AD_APPLIED_PATCHES contains all patch numbers which were applied to your system only.

For example: if you apply 11.5.10 CU2, it will add a row with patch_name=3480000 to AD_APPLIED_PATCHES and it will insert thousands of entries in AD_BUGS (including 3480000).

Caveat: if you use merged patches, always check AD_BUGS.

So how do you query the above two tables? Read the rest of this entry . . .

A while ago, MySQL developed a Community Contribution Agreement for community contributions to the MySQL source code. While browsing the MySQL Forge Wiki I came across:

http://forge.mysql.com/wiki/Community_Contributions

This page shows that the Community Contribution Agreement has changed — it is no longer the document MySQL AB created. It is now Sun Microsystem’s standard Sun Contributor Agreement, which CEO MÃ¥rten Mickos recently explained to me was “more accepted than the agreement MySQL had come up with.”

I am happy to see some of the great Sun practices trickle down to replace some issues that MySQL did not handle smoothly. All in all, I agree with MÃ¥rten Mickos and think the Sun Contributor Agreement is much better….

….but what do you think?