Voice of the DBA

Author: way0utwest

  • Short Names

    I started using computers a long time ago, and in the PC world, we were often limited to an 8 character name and a 3 character extension. Unix and MacOS allowed longer names, and many of us in DOS and Windows were jealous. Eventually Windows evolved, allowing long names, spaces, and really quite a bit of latitude in what you want to name a file. For example, try this and see what happens on your SQL Server:

    BACKUP DATABASE Sandbox TO DISK = 'Sandbox.thisisafullbackupthatIusetostartarestore'

    However, the three character extension still dominates, and many applications still use this. Microsoft has started to get away from this, as we have .docx, .xlsx, etc. Other vendors and software systems have started to expand names slightly. I was reading about the SQL Server Diagnostics Preview and noticed that the engineers will take a dump file (.dmp) as well as a mini dump (.mdmp) and a filtered dump (.hdmp).

    Now I know developers are lazy, and they don’t like to type, but in these days of auto-completion and other tools, why are we limiting ourselves. Why wouldn’t we use .minidump or .filtereddump as descriptive way of identifying the file? If we are no longer bound, why not include a better extension? I can’t imagine that the filesystem for many tools would be stressed by longer names.

    I’m assuming that people still feel bound to using the shortest set of letters that they think are unique, but with the growth of software applications from many, many sources, why not just be more descriptive? Would you want to see better filenames? I know I would.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Cool Projects

    This editorial was originally published on Aug 23, 2013. It is being re-published as Steve is on vacation.

    I had a conversation recently with a developer that was working on a rather neat problem. This had to do with a financial system and it involved some complex calculations and real time interactions with a variety of systems. It was important for their company, and a lot of pressure was on this developer to not only deliver this software quickly, but also to have it perform at a very high level. This particular person was using Red Gate’s ANTS Performance Profiler to dig into their code, feeling pressure to make it as efficient as possible.

    However this developer was also enjoying the work. It was a challenge, and it was a cool project.

    I know this community is made up of people working in all sorts of industries, in a variety of roles. We develop many different kinds of software. Some may be for employers, some may be for ourselves, some may be for a side business, but  across that spectrum of work, there are some interesting applications.

    What cool things are you working on?

    It might not be software. Perhaps you’re working on an interesting data application, like a super collider. Maybe you work on some gaming software or a large hardware system. Perhaps you deal with a system that makes people’s lives better, easier, or even possible. I’m sure more than a few of you work on some real time systems, which have all kinds of data challenges.

    Let us know this week what type of interesting work you’re doing.

    Steve Jones

     

  • T-SQL Tuesday #92–Hard Lessons

    A quick post, written last week as I’m relaxing in the mountains.

    This month the topic is lessons learned the hard way, from Raul Gonzalez. It’s interesting, and certainly one where I have experience. I make mistakes regularly, though I tend to fix them.

    You can read more about T-SQL Tuesday and learn how to participate, or even respond to old prompts at tsqltuesday.com.

    A Hard Lesson in Preparation

    I worked for a financial services company at one point, managing the live systems as well as performing database development. I had a few people working for me, some in each area, and we had contracts with a number of clients. Quite a few of these contracts specified a yearly DR test at a remote facility.

    The first year I was there, we packed up tapes and documentation, carpooled for 4 or 5 of us as if this were a disaster, and started rebuilding systems. Our contractor supplied xx servers as per our contract, and we had to start from scratch.

    We didn’t do well, and couldn’t get our web app or client server apps running completely. The db restored, but the system and docs were out of date. I knew this, and we updated some things, but we didn’t take the process seriously.

    A few months later our largest client was unhappy. Since we couldn’t get the website running, they wanted another test. At their site.

    Myself and another were chosen to fly to their site, shipping out spare servers and software. We had to wipe the drives and rebuild the system from scratch. Since the two of us had been at the DR test, we assumed we’d learned enough to do this in two days, sure we could rectify all the mistakes from the test team.

    We couldn’t. After two days, we didn’t have everything running, with too many dependencies and issues from various web components. Our developers had been running wild, with admin access to the webserver and database server, resulting in wonderful unique, snowflake servers that were hard to reproduce.

    Inadequate preparation, as well as poor security for years, contributed to the failure. I did get the database working, but that didn’t matter since this client used web access only. I had to take a large portion of the blame since I managed systems, and our company paid a penalty.

    It was embarrassing for me, personally and professionally. I hadn’t done a good enough job being ready for a disaster. This did server to motivate me to start cleaning up the systems and ensuring we could rebuild a new web server if needed, but it was a hard, and expensive lesson, to learn.

  • Taking a Break

    No blogging this week. I’m taking a much needed break in the Colorado mountains with my family.

    I’ll likely be unwired for the most part, so not responding to email, tweets, texts, comments, etc.

    Enjoy the week everyone.