Skip to content

not forgotten

not forgotten


SQL Server is not a toy



I began my career working with Sybase on UNIX.  Everything was done via the shell. There were strong practices in the space we were in for UNIX shell programming standards and strictly enforced source control procedures that we had to follow. Somewhere down the road I switched to SQL Server and I was usually  the only SQL Server member of a DBA team that was strongly dominated by other RDBMS platforms (DB2, Oracle, etc.). What I learned from the governance practices of those other professionals was specialization. There were Oracle App DBAs, Oracle Sys DBAs, Mainframe DB2 DBAs, UNIX DB2 DBAs, Informatica Developers, Hyperion Developers, etc.  I have never seen Oracle shops (App or Sys) tasked to build and tune Hyperion installs or create Informatica jobs. This is not because Oracle DBAs aren’t smart enough to work with Hyperion or Informatica. Most of the Oracle DBAs I have met (and I have met a few) can hold their own or run circles around me. Oracle DBAs specialize in this way because it maximizes value. I think it’s time we learn from our colleagues that work with other RDBMS platforms.


N.B. – I have no problem with a SQL consultant developing breadth across the entire SQL product as that helps them find work.   I am also not talking about small shops that don’t operate at the Enterprise level.


Within the Enterprise,  I think that it is long past time for SQL Serverdom to accept its maturity and affect governance and specialization practices that maximize value to organizations.  We have separate conferences for the different specialities within our SQL Server product and recruiters certainly know the difference between a Sys DBA and a BI guru.  It’s time for IT to do the same.



this isn’t thunderdome


When I received my first MVP award for SQL Server it was fairly abstract to me until I went to my first TechEd conference after being awarded. There it got real. At that year’s TechEd I recall sitting in the SQL “Birds of a Feather” area with my late friend Kent Tegels and watched in awe as people were lining up to talk to Kent (and me, for that matter) over every and any aspect of the SQL product. I felt like I had a target on my back that said “SQL MVP. Argue with me”.


After one particularly long and intense SQL debate that Kent had with a TechEd attendee, he walked back over to where we were sitting and looked at me and simply said “jousting” and we both laughed out loud.


Jousting is fun. It’s a part of what we do as geeks and it’s how we learn. But it’s not how we should work.


The Beatles will always be my favorite group and John Lennon was a genius. The magic of the Beatles is that they worked hard as a team and the best idea always won – even if it came from a roadie. John Lennon didn’t berate George Harrison because he didn’t have the same gift of songwriting. He helped him write his first song. Ringo didn’t sing in too many harmonies but his drumming in “Rain” and “Tomorrow Never Knows” is iconic. The Beatles were masters as collaborators. Mick Jagger called them the Four-Headed Monster.


Let’s joust but let’s also get over ourselves and collaborate. Life is a lot more fun when we rock out.


the power of people who are trustworthy

If you missed 60 Minutes last night, watch this.

Correlation Does Not Imply Causation

One of the biggest mistakes we can make when troubleshooting is to confuse the necessary responsibility of observing activity that is occurring with what the problem is. It’s not enough to accurately identify that STUFF is happening when you perceive a issue exists. You must identify what, if any, issue EXISTS in the first place and then you must identify the CAUSE(S) of the issue.


A well configured and provisioned RDBMS and the resources that support it can potentially afford large numbers of concurrent transactions. That in itself is a good thing, not a sign of an issue. Think of a highway: one could look at it and say “There are CARS! Lots of ’em! On a HIGHWAY!” Well, yeah. There are. That’s why we built it. That in itself doesn’t signify any problem. Now if you say “There’s a tractor trailer flipped over and it is blocking three lanes!” Now we have a problem. But what if we have volume during rush hour going into New York City? Is it meaningful to say: “Hey, there are a LOT of people trying to drive into New York today and they ALL seem to be in a hurry!” Maybe, but probably not. This happens every day and I don’t think NYC is building any new bridges any time soon.


The challenge is to collect data, apply knowledge and experience, and see if the hypothesis you posit withstands logical reasoning.


Paul Randal is starting a series of posts on Avoiding Knee-Jerk Performance Troubleshooting. That’s a good place to start for all of us to make our troubleshooting skills more effective.

Why no discussion of MarkLogic / NoSQL security in light of Obamacare security fiasco?

We are awaiting Polar Vortex 2 in New England and are set to have more snow dumped on us starting today so I am reluctantly working from home. This leaves me with a RARE opportunity to publish TWO posts to my feed in a day (or close enough…).

In fairness, I know NOTHING about NoSQL (and to my shame, there are unread MongoDB and Hadoop books on my shelf). However, if the security fiasco that is the Obamacare website involved a RDBMS, I am confident that by now a slew of posts would be published on the RDBMS security aspects of the failure.

Obamacare chose to go with NoSQL db MarkLogic. I fully realize that an App Stack is a lot more than just the db, but database security is a huge part of the total security footprint of an application. Why, therefore, are there no good articles or blog posts from a technical perspective detailing how issues like this could have been mitigated or averted were the security features of MarkLogic implemented properly? If you know of any such articles or blog posts on this that I simply missed, please post them to the comments as a courtesy to those that read this. Thanks!

Best advice I ever got on negotiating consulting rates and salary negotiations

Back when I was getting ready to take the plunge and begin consulting I sought advice from a friend who had a successful database consulting practice in New York City (where at the time I was preparing to work).  I thought the price he suggested that I ask for was pretty high and when I questioned him on it he said the following which has stuck with me for the rest of my life:

“No one will ever argue with you if you’re willing to work for less than your market value.”

This is a powerful truth and important to comprehend. This is a tough economy and DBA jobs and consulting opportunities are hard fought and jobs don’t fall from trees like they did back in the Dot Com or Housing Boom days. Nonetheless, if you can see yourself EASILY earning more than a rate or a salary offer presented to you the last person you are doing a favor to in accepting it is yourself.