Voice of the DBA

Author: way0utwest

  • I Hate Planes

    A few short bloopers, just for a few friends that fly planes.

    YouTube Link (in case the embed fails)

  • Check Twice, Update Once

    I was reading through this blog from the SQL Server PSS team (a must-follow), and found this note about the SQL Server Best Practices Analyzer (BPA). This isa tool that can examine an installation of SQL Server and report on any deviations from best practices according to Microsoft, as well as warn you of potential issues with your configuration. I had used it with previous versions of SQL Server and it helped me quickly determine if I’d missed anything during setup.

    Now I haven’t much thought about running this regularly. I’d assume this is something I just run once after installation to be sure I’ve configured, but the blog gives me a good reason to run this regularly, and especially whenever I have an issue. In the entry, it talks about not only noting that an error being returned by SQL Server and noting it’s fixed in a CU, but that a trace flag is also needed. Running the BPA would inform the user that the trace flag needs to be enabled.

    I think it’s great that this type of feature is being designed into a tool like the BPA that can really help a DBA. Knowing that this trace flag needs to be enabled is the type of knowledge that someone might gain with experience, but it’s short lived. At least it should be as I would hope the issue is corrected in a Service Pack w/o the need for a trace flag.

    Tools like this don’t eliminate the need for DBAs. We still need people that can make the decision about whether to apply this, perform testing, and more. These tools just make it easier for us to do our jobs more efficiently.

    Steve Jones

    Update: as noted in the discussion, the MS Baseline Configuration Analyzer is required for the BPA tool. MS BCA v2.0

  • SQL Saturday Advice – PhotoJournalism

    I try to carry a camera, and a video camera, most of the time when I’m traveling. I have a camera on my iPhone as well, and for all that, I tend to just forget to take enough images when I travel. Especially at events where I’m often talking to someone, and trying to engage.

    At various events I’ve seen the images and video handled different ways, but I think that SQL Saturday #28 set another bar by having a guy walk around all day, taking pictures, hitting every speaker in every session, and perhaps most importantly, getting a shot of every prize winner.

    Part of running a successful event is being able to market it. The enthusiasm, and the excitement so many people feel is infectious. I think it’s why we’re seeing this resurge in local events as the webinars and remote training, while good, lack some of the buzz and excitement of a live event.

    This is a great video from the SQL Saturday #40 team, and it’s something I’d like to see more of.

    http://www.gohardtv.com/mm_player.swf?http_base_url=http://www.gohardtv.com/&videoid=2584439

    Get some audio, video, images of your event. Post them on the site, make a slideshow, do a voice over, and publish it. You’ll inspire people in other areas, but you’ll also inspire others to support your events in the future.

  • Where Are the Programmers?

    When I was growing up, I thought I wanted to be a computer programmer. I had my own Vic-20, and various other machines, and I wrote code that was used to solve problems. I programmed the computer to handle various calculations or manipulations for school or fun and thought that was very cool. I solved many chemistry labs with the help of my computer.

    The other day someone asked me what I did for a living and I said that I used to work with computers, but now wrote about them. They asked me if I was a computer programmer in the past. That was something I hadn’t heard in a long time.

    I’m not sure when we changed from programmers to developers. Fundamentally we do the same thing, though I’ll admit that developer sounds more important, or more talented. I’m sure at some point a programmer wanted to separate their job from everyone else, called themselves a developer, and the trend caught on.

    I haven’t worried about titles for a long time, but at one point in my career I did press to get the senior DBA title after working with SQL Server for about 6 or 7 years. At that time I felt I knew more about SQL Server than the majority of people that I met, and I deserved to be “senior.” I’m still not sure if I had earned it at that time, but it was a title I was proud of.

    It seems that us data professionals have tried to separate ourselves from the average DBA with database architects and database developers and any number of other database specialties that sound more important than just DBA or developer.

    It makes me wonder what’s coming next. Will we start to advertise ourselves as DSS (data security specialist) or DTS (data transformation specialist) or even BIDS (Business Intelligence developer specialist)? Who knows, those acronyms are already well known in the SQL Server world. They might just impress a manager who knows just a little about SQL Server.

    Steve Jones