Geometric Project Managment

In a prominent banking institution a member of the IT staff made the following sarcastic joke; "In any other part of the world, two people might create a baby in 9 months, but here they throw 18 people at the problem and expect results in 1 month."

Simple math, right? Hardly so. There is no parallel dimension where human development happens at a faster rate. Certain things are just hard constraints with absolutely no variables. In other cases, like in the world of IT, the variables do exist, but only with trade-offs or functions that can be illustrated through geometric and mathematical formula. Geometry applied to project management - looks like witchcraft!

The usual real-world constraints of any set of Requirements are Cost, Resources, and Time. Conceptually this is simple. For any given project there exists a set of movable laws of nature. A set of requirements can be produced in a significantly shorter time, but only with an increase in cost and/or resources. Cost can be reduced, but only with an investment of time and/or resources. One can argue that Time and Cost are resources, and normally I would agree in the most broad definitions. Consider though that with an overall reduction or increase in Requirements, there is a direct relationship with the other inputs of this function.

Just as changing a single attribute of a triangle effect the other attributes, the same holds true for a set of requirements in a project.

Job Notification Random Features

If you've worked with job notifications in the past then you probably already know this, but I thought it was worth discussing. Any time you change the name of the operator you want to notify, the event that the operator is notified upon defaults back to 'On Success'.

There are three different events that will generate notification from the job properties:

• When the Job Completes - generates whether the job fails or completes
• When the job Fails - generates notification only upon failure
• When the job Succeeds - generates only upon job success

The problem comes in that intermittently when you change the operator to be notified, the event will default back to 'When the job Fails'. This is a great problem in that you would not be notified in the event of job success.

Using Try-Catch in Transact-SQL

SQL 2005 implemented the TRY-CATCH form of trapping errors in SQL code. The old ON_Error statement no longer applies. This new construct is used in many languages today including C# and VB.NET to name a few. The basic concept is that you place your code within a Try and then use a Catch to find errors it may have encountered. Here is a very simple example you can run:

/* Simple Try Catch Example */
DECLARE @Denominator INT
SET @Denominator = 0

BEGIN TRY
SELECT 1/@Denominator AS [Output]
SELECT 'Computation did not fail' AS [message]
END TRY
BEGIN CATCH
SELECT ERROR_NUMBER() AS Error#, ERROR_MESSAGE() AS [MESSAGE];
GOTO EXITOR
END CATCH;
SELECT 'Catch Did Not Find Error'
EXITOR:


Now set the value of @Denominator to 1 or some other valid value. Notice how the flow of program execution changes.

Enable Database Mail Alerts In SQL2008

While setting up our new SQL 2008 Boxes, I came across the interesting task of configuring SQL Mail. I mean, it would be nice to get an email when your job fails or logfiles grow too big, right? So I went to the web and started looking for articles describing the task.

The articles very nicely describe how to set up mail profiles and operators on your SQL Server. There is lots of material there, so I won't bother to add non-original content. But they do leave out a critical piece, which is to configure SQL Agent to use the profile you have defined. This is funny because my Systems Admin and I were trying to figure out how the two were tied together. The answer is on the Properties Tab of your SQL Agent. Just navigate to SQL Agent, Properties and you should see something like the below. Once you configure your profiles, set up your operators and fill in the below box, you should be good to go.

Moving to SQL2008 64-bit

Moving from SQL2005 32-bit to SQL2008 64-bit sounded very exciting at first. Especially when we managed to budget a box with 32gb of memory, 24 processor cores, and 2 raid controllers hitting an array of 16 drives. Our old box was just quad-core, 32-bit, 12gb of ram, and a single controler on a 5-disk array. It did the job, but very slowly.

Imagine my surprise when the database was copied to the new server and the jobs that had run fine on the old box started filling up the 160 gigabytes of TempDB every time they were executed!!!!!!

Long story, but here is the short answer: Rebuild your indexes - because when you move to a 64-bit OS, it has issues reading a fragmented index that was created on a 32-bit system.