Funny and true; a rare combination.

This link says it all:
http://techdigest.tv/pcmaclinux.jpg

I admit I'm typing this from an installation of Ubuntu 6.10 ("windows fan boy linux") that's rocking beryl but really... Do you know how long I spent trying to get this to run on my dual-21" LCD's at work?? Oh- I could get dual monitor working (with fglrx, open source ati, AND binary ati drivers!) but I could never get it working with beryl (beryl with xgl... it worked with aiglx I think the name was??).
Surprisingly my xp desktop does it just fine.

Funnier still is the the fact that my p-to-v'd (I even spelled it phonetically; deal!) xp desktop image loaded faster as a vm ALONG WITH my ubuntu desktop than my xp desktop can dual booting directly into it!!

Draw your own conclusions. My statement will always be this: 'Why should we worry about hardware to run an OS?' (yeah- I just quoted myself!) The OS manages access to hardware and it should be more integrated and streamlined as time goes on- NOT more bloated and resource intensive.

Update: Newer Ubuntu versions load slower. I have Vista installed on a PC. I'm eagerly awaiting running Windows 2008 as a "workstation".
I also added the picture linked to above in case it disappears.

How to Upgrade SQL 2005 x64 from SP1 to build 2153 (KB918222)

If you don't know what this topic means skip the rest of this post. If however you're here because you're trying to upgrade from 2047 (SP1) to the latest hotfix -build 2153- and you're getting nothing but "Failed" then this is for you.

First things first; read this again:
http://support.microsoft.com/kb/918222

Do things in the order they suggest because why not? Why fight with things for the sake of fighting with them? Oh what's that- you installed the client patch first? Heh... me too. It doesn't really matter. ;)

So anyways, I'm sure you want to know the fix so here goes.
First, figure out where your mssqlsystemresource and distmdl log and data files are. If they're all in the same folder as your master db then you've got a problem that I can't fix with this post. But if you (like me) got this crazy idea somewhere that logs and data should be kept on separate volumes and you happen to do that for system dbs as well because oh, I don't know; you like order, then I may just have the asdfnswer you're looking for.
This problem may or may not be a 2-step fix for you.
First, look at where your master.mdf is- are distmdl.mdf and distmdl.ldf there? No? Copy them there! Try it again- if the upgrade works you're done.

The other problem you may run into is the upgrade of the mssqlsystemresource db. If the .mdf and .ldf files are in different dirs (or more likely; volumes) then you'll have to copy the newer log (.ldf) version that it dumps in the same dir as your mssqlsystemresource.mdf over to the correct location before the upgrade will work. Of course your server needs to be down for this to happen. FYI: the newer file has a date with a timestamp of around 12:13am... I can't remember the exact date but the older version has a timestamp around 3-something am. If you don't normally keep the mssqlsystemresource.ldf file in the same dir as your mdf then you shouldn't have even read this far- go upgrade your system!!

And just in case these didn't help you here's some more advice:
You can find most problems by checking: %windir%\hotfix\sql9\SQL9_Hotfix_KB918222_sqlrun_sql.msp.log
For "value 3"... then look for something about failing to access a file (note the location) and/or any other messages that may help you out. One stupid thing is that the error will state the installer doesn't have access to a file when in reality the file isn't there. Use your head and check it out before assuming it's a permissions issue.

Fixing MOM 2005 MOMXParitioning Job Problems

No, this post is not about how to spay or neutor your mother. It's about Microsoft Operations Manager and one piece of troubleshooting that will save the day for you when the daily partitioning and grooming job fails... and it WILL fail.

Here's how this one goes. There's an error that popped up with a MOM 2005 database I manage where the groom job would continuously fail with something like 'drop failed FK_EventParam18 is not a constraint'... Awesome. At this point your OnePoint database is going to keep on growing forever and ever because it can't purge old data. Too bad that it's no longer supported by MS when it hits >30gb. The solution? Fix the problem yourself of course!

I hunted around the internet for help with this one but was left with nothing. Finally I started stepping through the code of each stored procedure as it would have been executed to find what was being called and when.
I got tired of that and threw up a trace.
I eventually narrowed it down to the fact that it really wanted to drop a constraint named in the error on a table of a similar name. Now of course I'm sure there's a table somewhere that holds what to drop and what not to drop but I really didn't feel like editing that so I took the easy way out: I created a constraint with the required name on the proper table and BAM! It worked.
What was the constraint you ask? heh... 1=1 ;)

Hopefully some other DBA out there (or someone else stuck looking after a bloated and mis-managed MOM 2k5 deployment) will see this and be saved a lot of investigative work. (Legal self-help: I am not making any claim that this will work for you and/or won't harm your database. Use this advice at your own risk!)

Oh- and the other thing I did to purge my db (which was 130gb!)? I modded the sp_purge (or whatever it's called) to be able to groom and purge starting at 125 days rather than the 60 days it maxes out at via the GUI. This allowed me to purge data and shrink the db in a controlled fashion that wouldn't blast the storage system with IOPS it couldn't hope to handle.