Voice of the DBA

Author: way0utwest

  • Lesson #6: What CIOs Really Care About

    What Do CIOs Care About?

    I saw a blog by Dave Rosenberg and it was interesting in a few ways. First of all, Dave works for OSDL, which promotes the use of open source software.

    There were a number of basic things that you could probably guess like costs are important, blogs aren’t, and more. But there were two things that I really thought made sense to a SQL Server guy.

    The first was that security was mentioned as a big item, but more importantly, one of the examples was “don’t build SQL Server apps using sa.” I’ve preached against this many times, but still developers want to do it. And I don’t understand why it’s so hard to just create a login and get away from the all access development. Especially given the security issues across all platforms in recent years.

    The second one was something that I think more CIOs should stand behind and not just “talk” about. Hiring and maintaining staff was listed with this comment: “This is my number one issue.”

    And it should be. Retaining staff is a big deal, especially as more and more systems are integrated or even running side by side in new and innovative, and most often, complex ways. Having some knowledge of the journey that got you to a place is important and it’s hard to rebuild that in new people. Making good hiring decisions and then making an effort on a regular basis to be sure those people stay is important in all businesses, large and small.

    Not that you won’t have to turn over staff at times or cut your losses. After all, not every person fits in every job and circumstances certainly change.

    It should just be the exception rather than a regular practice.

    (update, Info World has removed the original blog)

  • Self-aware Instances

    I like the idea of limited self-awareness in our systems.

    I’ve been seeing lots of monitoring solutions written up lately. I saw this blog from Phil Darmanin on SQLServerCentral and we have had numerous articles written over the years on building monitoring solutions. The build vs. buy debate is one that companies regularly have, and if time is an issue, my company, Red Gate, sells a great solution in SQL Monitor that’s worth checking out.

    However most of the solutions I see use a similar architecture. They have a central monitoring server that reaches out to all other servers and gathers information from them, which is rolled up into a database for reporting. That’s fine, but in many cases there isn’t a ton of testing or error handling built into home grown solutions, and when they fail, you lose data for the day. You also either go into fire-fighting mode to get things working, or you just drop data for a few days.

    However I’ve had a different approach in the past. I’ve typically had a set of monitoring scripts that I’ve deployed to each instance, having them run on a schedule that gathers all the data on settings, changes, backups, jobs, etc. for that instance. I then have a central server that just reads that data from each instance, so if I have an issue with my rollup process, I still have the data on each instance. For this Friday, I wanted to ask this question of you:

    Do you like the idea of architecting processes to be more self aware and distributed, or do you prefer some central process that reaches out to control everything?

    It’s an interesting debate, and one that reminds me of an MIT competition years ago. Early in the 90s, there was a competition where different professors were trying to build robots to navigate a space. One team used a central CPU with complex instructions that controlled the legs and eyes and made decisions. The other used smaller, less powerful controllers in each leg and eye and had them “learn” to work together. Both worked well in different ways, but the latter approach always struck me as a more interesting one.

    For your SQL Server, or application code, which approach to you prefer and why? Let us know this Friday.

    Steve Jones

    The Voice of the DBA Podcasts

  • The IF Statement in a T-SQL Query

    I’ve seen quite a few posts from people asking how to do something like this:

    SELECT 
  a.ID
, IF a.MyChar = 'A' THEN 'Success'
  ELSE 'Fail'
FROM MyTable a

    Of course, that doesn’t work in T-SQL, and you’ll get something like this:

    Msg 156, Level 15, State 1, Line 3

    Incorrect syntax near the keyword ‘IF’.

    Msg 156, Level 15, State 1, Line 3

    Incorrect syntax near the keyword ‘THEN’.

    There’s not IIF, no IF( x, then y, else z) construct. There is an IF … ELSE statement, but it’s use in code flows as a control statement such as

    DECLARE @i CHAR(1)
SELECT @i = mychar FROM MyTable

IF @i = 'A'
  SELECT 'Success'
ELSE 
  SELECT 'Fail'

    Instead we have a CASE statement, which is designed to give you multiple choices. In the example above, I’d write:

    SELECT 
  a.ID
, CASE WHEN a.MyChar = 'A' THEN 'Success'
  ELSE 'Fail'
  END
FROM MyTable a

    I can even add multiple “WHEN” clauses if I want:

    SELECT 
  a.ID
, CASE 
    WHEN a.MyChar = 'A' THEN 'Success'
    WHEN a.MyChar = 'B' THEN 'Close'
    WHEN a.MyChar = 'C' THEN 'Far'
    ELSE 'Fail'
  END
FROM MyTable a

    Let your developers know that when they are looking for an inline IF type of logical statement, T-SQL gives them CASE instead.

  • Measurements

    Measurements are important to growth.

    “If you cannot measure it, you cannot improve it” – Lord Kelvin.

    That’s a quote that comes from this blog post, talking about ways in which you might measure your performance. Numbers are not the only important thing to measure, and you certainly don’t want to just pick one measure. The blog post talks about performance of employees, looking at different ways to not only measure the performance of one job, but also using different measures for different jobs.

    The idea of measurement is applicable to both people and systems. Having a constant way to measure performance, track those measurements, and perform analysis of the data is an important way to know if you are actually making strides toward building better performance and more efficient systems.

    However it seems that even though many people know these things, they don’t actually capture the measurements regularly. As I talk to people, asking them if they know things like the backup growth for their critical databases, they don’t. I’ve asked people if they know how much time they spend on blogging, or if they are reaching more people, or really for any metrics, and they often don’t have any idea.

    Numbers aren’t everything, but they ought to be a thumb-in-the-air measurement that guides you to find ways to improve over time. You can be on the schedule that works in your environment, and on the pace to improve things that fits the situation, but if you don’t measure yourself or your systems regularly, it’s hard to know if you’re actually moving forward or backward.

    Steve Jones

    The Voice of the DBA Podcasts