die Seilerwerks

Greg over at Structured Data has a fantastic piece titled “Troubleshooting Bad Execution Plans” which is a must-read for all. Learning about the GATHER_PLAN_STATISTICS hint alone was worth the price of admission.

Also time for me to re-evaluate the changes I made to OPTIMIZER_INDEX_CACHING and OPTIMIZER_INDEX_COST_ADJ a few versions back:

SQL> show parameters optimizer_index

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----
optimizer_index_caching              integer     90
optimizer_index_cost_adj             integer     10

While trying to install pastebot on my CentOS5 sandbox for interal IRC usage, I found that I had to install a number of other perl modules upon which pastebot depended. This however became very frustrating as nearly all of them failed.

I ended up following the dependency chain to eventually find out that IO::Compress::Base was failing because the Scalar::Util module, installed stock by CentOS, lacked the “XS” extension. A Google search led me to this bug report confirming it. Fortunately the problem is easily solved by doing a “force install Scalar::Util” in cpan.

I assume that this problem also exists in RHEL5, and some LUGmates have reported similar breakage in Fedora.

A level 0 database backup of my production instance takes over 8 hours, and duplication is just as long, if not longer. I’m going to do some reading and see if we can shore things up. I’ll report back.  The database is around 1.1 terabytes.  Some have told me that their databases of similar size are backed up in only a couple of hours.

My main concern is the duplication, or restore & recovery.  An 8 hour restore/recovery  basically means the loss of a full business day (depending on when it is needed).

MONDAY

Go to work in Green Bay.  Finish xen setup on my CentOS5 sandbox so I can hopefully play around with RAC.  Try to read a chapter in the Lewis CBO book (still).

TUESDAY

Telecommute, otherwise same.  Maybe work out later in the morning.

WEDNESDAY

Work.

THURSDAY

Work.  Red Cross blood drive in Manitowoc.

FRIDAY

Work.

Despite my earlier instructions, my rss reader continues to pile up with posts of “Where I am at OOW” and “I’m at these OOW sessions” and “HAY oracle-l GUYZ LET’S MEET FOR DRINKS AT OOW.”

So I’m just going to save myself some heartache and rage and not read the Oracle blogs this week (or next week when the inevitable reviews come out). Do I sound bitter? Do I, really? Hell yes I’m bitter.

Let me know if OOW or Collaborate 2009 come to Green Bay, Wisconsin. You can all sleep over.

Got my Fedora 8 live cd iso over the torrents yesterday. Just need to find a suitable host now …

UPDATE: Howard isn’t too thrilled.

Please stop blogging about it.  That, or take me with you.

Thanks to everyone who reads this blog and sympathizes with my misadventures. Additional thanks to those bloggers who have seen fit to actually link back to this blog.

If you are in this latter, elite class, I’d like to ask/beg/remind you to update said links to reference the new URL.

If you use technorati, feel free to add me to your favorites.

This concludes the blog/link-whoring section of your program.

It’s for the childrens. Seriously.

This past week has been spent packaging and re-installing some “legacy” SQL reporting scripts. Since before my time here, these scripts have been run out of the oracle OS user’s home directory, running as the oracle user, scheduled in the oracle user’s crontab. It’s been a security bug crawling under my skin for some time now, and I should have fixed it a long time ago. Giving developers (or any non-DBA) access to the oracle OS user means giving them the ability to start or shutdown the instance(s) , and even drop the database if they knew the commands.

Besides the security concerns, these reports were not in our CVS and had no installation package. We create RPMs of all of our in-house software that goes onto our RHEL servers, which makes system administration a LOT easier.

So in the end, the shell and SQL files will be in CVS, have a proper installation method and be inventoried in the RPM database on those machines, and will have their own cron file in /etc/cron.d running as a non-privileged user.

There’s still a lot to be done before I’m satisfied from a security perspective, but it’s nice to get these out of the way.

Update: An added bonus is finding out that some of the scripts are obsolete and can just be taken out!