Less is more - shared resources and MAX sizings

Less is more. I don't know who to originally credit for that saying and when it comes to shared resource (i.e. thread and JDBC connection) pools this is the motto to live by. Need more than 40 threads to drive 100% CPU then the performance expert needs to look at where the bottleneck is in the application. Think the application needs more than 10 connections to a database? Think again. Too often I come across situations where the application is pegging the CPU and/or the database is so overwhelmed in production we can't bring it down to failover. Next time the team wants to change parameters to shared resource pools encourage them to make them smaller. They'll look at you as if you're crazy and think you'll be the next one to lose your job ... but you won't when they find your solution was actually the correct way to go.

Speaking of which, Alex has roadmaps he didn't work on this past week (well, I did have eye surgery and a hard disk crash both within days of each other).

Why Alex needs a backup

Because Alex's hard disk failed. Alex actually does have a back up of his data but not all the applications so it is going to be quite a bit of effort to get a C drive with what I need on it. That said, I'll start with a fresh Windows XP image and may have lots better performance now!

Disaster Recovery - why you need a plan and execute on it

Problems happen.  Fiber cuts can occur out in the wild.  Hardware fails.  Routers go down.  

The last thing you want is to have no backup.  Put the backup in a separate data center facility on separate ISP inputs.  Have multiple electrical feeds into each data center.  

Otherwise you will have a site outage and there will be nothing that can be done to fix it because you are waiting on someone else who you have no control over to fix the problem.