TheBonsai's Blog

Yesterday was a bad day. I wanted to completely rebuild a database with a corrupt data dictionary. My plan:

• Backup/exports
• Shutdown DB, remove userspace files
• Cleanup files inside ASM
• DBCA to make new one (no scripts available)

You see, nothing unusual. So far so good, everything fine except the last step. The scripts I had from the first installation didn’t run through, so I just wanted to click something together. But DBCA spit out:

DBCA could not startup the ASM instance configured on this node. To proceed with database creation using ASM you need the aSM instance to be up and running. Do you want to recreate the ASM instance on this node?

Er.. what? ASM instance is up and running and some minutes before the old database ran fine with it! So what? Metalink, Google: Environment variables, Listener configuration etc etc etc. Nothing applied. The only thing I really knew 100% was that the ASM setup was rocksolid.

Read the rest of this entry »

At work, we have Oracle and -related systems on top of SLES10. When you need them to work in a shared environment (e.g. shared NFS disk), the user oracle and the group oinstall need the same user ID on all systems (naturally).

Unfortunately, the IDs of these entities depend on the point in the installation process where you install the SUSE orarun packet, since the UID is generated on the fly. This leads to trouble here and then (nothing serious, but it’s a bit of work to fix such an issue afterwards). Of course I think the installation procedure of the SLES orarun package should use a fixed ID here, but that’s something SUSE decides, not me (it tastes like a bug).
Read the rest of this entry »

m00!

Due to a new toy we got at work, I was searching how to massively speed up BZIP2 processing on GNU/Linux systems. It sucks when you have 16 cores but only one process/thread.

I finally found PBZIP2, which basically is just a new controll wrapper around the underlying library (the code has around 60 Kilobytes – with comments and all). It builds in about the half of a second.

Just to imagine a bit:

Test file was a 5.6 Gigabyte file with random binary data (/dev/urandom). A normal BZIP2 took 30 Minutes to finish, a parallelized PBZIP2 made the same in 3 Minutes and 30 seconds.

In case you need to speedup BZIP2 processing on your SMP-servers, consider to use PBZIP2 – it rocks!