Voice of the DBA

Category: Editorial

  • No Works of Art

    I used to pride myself on being able to run through menu selections and configuration options from memory. There have been times when I could describe over the phone  the process for using a GUI. I’ve been able to direct people to log onto SQL Server, choose a database, right click it, and choose restore. Then select device, choose NORECOVERY, etc, etc. I could walk people through many Windows dialogs, IIS configurations, and more, with verbal commands, picturing what they would see on the screen as I was holding my phone to my ear.

    People would be impressed, and I’d rarely make mistakes. I knew what was coming next, and where to click. However I did make mistakes at times, and while that’s human, that’s not what we want during software configurations. These days we find plenty of administrators and developers running an install program, and either selecting options from memory or using some sort of document that was given to them. The thing that concerns me is that any of those processes could be full of mistakes. Documents never get rev’ed to keep up with changes. Human memory is faulty, and certainly we find ourselves clicking the wrong button at times.

    When we install, or deploy, software in this manner, we’re asking for problems. Not every time, but if we manually configure, click, or select anything, then we are building individual works of art. That’s not what we want from our software environments. We want to know that the production environment is configured the same way every time, and if we need to recreate it in a DR situation, we can. We want confidence that the software that was tested in the QA environment will work correctly in production, which means we know that the states of the system are the same. We might even want to be sure that we’ve configured our development environments the same as production.

    As our tools get better, especially around virtualized systems, there isn’t a good excuse for not automating our installation and configuration through some sort of scripting. These days there ought to be no reason for a Windows, SQL Server, IIS, and most other platforms to not be easily scripted and deployed in a hands-free fashion. That’s one of the keys to engineering software at scale instead of sculpting it one system at a time.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.2MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Patching Problems

    I applied the Windows 8.1 update a few weeks ago and had some issues with my machine. Windows was fine, but I lost my SQL Server service. A few other users, including some of the SQLServerCentral community also had issues and sent me ideas, but their fixes didn’t work for me. That was OK because the problems gave me a chance to use PoSh to solve a real problem. I’ll be blogging about that in the next week.

    However the 8.1 update has caused lots of issues, and Microsoft is acknowledging these problems. That’s good, but the process gives me pause, and to a large extent, I think this makes more and more people suspect about all of Microsoft’s patching processes. I bet there are companies that feel even more justified in waiting for SP1 for SQL Server 2014 before upgrading, even though there is a chance that the patch itself will cause problems.

    This is one reason I’ve been hesitant to remain current with Cumulative Updates (CUs). Microsoft doesn’t stand behind them, with the text on each CU page that users should only apply the patch if they are experiencing specific problems. Otherwise users are told to wait for the next Service Pack, which seem to be coming less and less often.

    Any patch can cause issues, and I certainly don’t like the idea of automatic updates always being applied because if there are issues, they can become much more widespread than controlled updates. There is also the issue of vendor responsiveness. Microsoft has pushed out patches that caused issues, and while they’ve try to fix issues quickly, I don’t want to have all of my desktops, or all of my SQL Servers, down because of a bad patch.

    I don’t know how we patch in a more effective manner, but I do know that I want to have some control over updates as an end user, and I also want ways to remove patches. Moving to the app model of always applying patches over patches, and never rolling back seems to be a step in the wrong direction.

    PS – If you want better servicing for SQL Server, vote for final service packs for products still under support.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Laptop Dreams

    The Surface 3 was announced last week, and I was underwhelmed by the event, especially the presentation itself. The entire spectable didn’t seem to compare to some other companies’ announcements. I did, however, find myself thinking about replacing my laptop with a tablet that’s lighter and allows me to forgo a keyboard. As much as I use a keyboard and depend on a responsive set of keys to get work done, there are definitely times when I’d like to just have a screen, and certainly a lighter form factor.

    Today is Memorial Day in the US, and I’ll be outside in a variety of situations today. Every year my son recognizes and remembers our soldiers at a Memorial Day ceremony with his fellow Boy Scouts. I like to capture some photos and video of the occasion, as well as track which Scouts are supposed to be there and have actually shown up. I can do it on a phone, but a laptop is too cumbersome. A tablet is actually the best option. It seems funny to use a larger device, but being able to capture and playback video on a tablet for others is much nicer than using a small phone. 

    I’ll also be cooking outside in the afternoon, and while my memory is pretty good, I’d like to be able to pull up a recipe on a screen I can easily see with my aging eyes. My iPad works well for this, but for many tasks that require the creation of content, it’s not always a good choice, and the upgrade to the Surface is tempting.

    Then there’s work. I’ve been struggling with finding a powerful laptop to run the suite of products that I present on, especially when I have some of the server systems running. The best solution for a small, powerful device, might be this Gigabyte BRIX for me, but I’d still need some keyboard and display to access it. While an iPad w/ keyboard can work, I’m wondering if a Surface might be better. I’d love to not only be able to access the device, but do so while I’m walking around. If I can get that to work, maybe I’ll have found the perfect device for me.

    Have a great Memorial Day.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • The Development Backup

    Have you ever had a development server crash? Have you lost work because of this? Had delays or had to recreate code? You shouldn’t, or at least you shouldn’t lose much work or time..

    There was a time when I offered to manage backups on all development servers. This was in a large environment with hundreds of instances.  I wasn’t worried. I had scripts to do the work of setting up, running, and reporting on backups for instances. I knew how to deploy these scripts to hundreds of servers.

    My reasoning was the our development servers were really our manufacturing environment for software. Wouldn’t you ensure your machinery was well maintained and kept in top condition if you had a factory? I know I would.

    The developers passed and once in awhile they’d call and ask of we could recover a server. 

    “Do you have backups?,” I’d ask. “No” was the usual reply. I’d appligize and reiterate my offer to manage the system. They were always resistent and that was fine. They were responsible, and these were their systems. However they had a backup system already. They just didn’t use it.

    Almost all of these people were using a version control system (VCS) for their code, but not for database code. Do me a favor; put your database object code in source control. Add all your DDL for tables, views, functions, stored procedures, and anything else you use.

    As long as it’s on a different physical machine than the development server, you’ll thank me one day.

    Just as long as you also run backups of that VCS database.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.7MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.