Voice of the DBA

Category: Editorial

  • Lost in Space

    hammacher-lost-in-space-b9-robotToday’s editorial was originally published on Sept 2, 2008. It is being re-run as Steve is traveling today and out of the office.

    Well perhaps not lost in space, but according to this article, a number of US airports report over 600,000 laptops lost a year. Over 10,000 are lost each week at the 36 largest airports. That’s a lot of bits floating out there in the world. There’s some dispute as to these numbers in another article, so it’s hard to know who’s correct. I tend to think these numbers might be high.

    In any case, what might be even more amazing is that 65% of these laptops are not reclaimed. What’s scary is that 53% of people surveyed said confidential company information was on their laptop and 65% said no effort was taken to secure their data. I found this on Bruce Schneier’s blog, and he sees it as a huge dollar loss for the country if the numbers are correct.

    My wife travels quite a bit, 30-40,000 miles a year, and she’s not surprised by these numbers. She guesses that the main problem is that there is no good way to match a lost laptop with a traveler. Unless you lose it at your home airport, with a lack of staff and the time it might take for something to get your lost and found, it’s likely you would never be able to search for it.

    And how long would you search? After how many days would you just move on and file a claim and replace the laptop? I tend to carry my important data on a USB key (and likely will upload to some service for future travel), so I’d probably spend whatever time I had in the airport, or maybe a day here in Denver, but after that I’d be ordering a replacement and moving on.

    Information has a tremendous amount of value, but to many of us, the information also has a shelf life. We might move on quickly and just accept the losses as part of doing business. I understand that and agree with it for the most part.

    However I think we should all have some sort of encryption and protection for our data. You never know when you might have some letter to a bank you drafted with your account information, or something else. For most thieves, I’d guess that an encrypted laptop isn’t worth dealing with. They’d wipe it and move on.

    Steve Jones from SQLServerCentral.com

    » Join the debate, and respond to today’s editorial on the forums

    The Voice of the DBA Podcasts

    The podcast feeds are now available at sqlservercentral.mevio.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    Overall RSS Feed: or now on iTunes!

  • SQL Server Should Work for Us

    failI ran across a post the other day from someone that was trying to find out why their maintenance plan failed. This person had received a failure notice from SQL Agent, which is good. We should all be aware of failed jobs from some sort of monitoring system. Like any good DBA, this person checked the job history, saw an error, couldn’t figure it out and posted a question at SQLServerCentral, looking for help. That’s a good plan for most anyone 😉

    Experienced DBAs know that to debug this issue, you need to look at the maintenance plan log, which has more details. The job history contains a minimal amount of information and usually doesn’t help. If you examine the maintenance plan log, it’s usually easy to determine which part of the plan failed since the plans are fairly simple constructs. The really exceptional DBAs don’t use maintenance plans and instead would rely on some sort of tool or well known script instead to handle their maintenance.

    However why do we need to go to the maintenance plan’s log? SQL Server includes the job history. It includes maintenance plans. Why doesn’t the job understand there is a maintenance plan, read it’s log, and return the information? Or give us a button on the job history that loads up the maintenance plan log? That’s a simple thing to do, and isn’t the job of software to make tasks easier?

    This is one of those places where SQL Server feels a bit immature and unrefined. I understand the complexity of the entire product and the limited resources that are devoted to enhancing and growing the product. However, where are the resources that make SQL Server easier for the average and accidental DBAs to use? Those are the majority of the people using the platform.

    SQL Server led the industry in producing tools that made it easy to manage and use. Other platforms are quickly catching up, however, and if SQL Server can’t continue to improve its toolset, in addition to its features, people will consider other platforms. The cost of SQL Server has risen, but so has the revenue. Do us, and yourself, a favor, Microsoft. Put a team of 50 people to work on usability and improving the tooling. It will be a great investment for the future.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Best Programmers

    Keeping the best programmers is always a challenge.
    Keeping the best programmers is always a challenge.

    Are you one of the best people at your job? If you are, then do you experience some of these feelings and look to move on?

    • Frustration
    • Boredom
    • Lack of a challenge

    Or have you settled into a routine that you like and can live with? If it’s the latter, you might not really be one of the really talented people. Read this piece on How to Keep Your Best Programmers. I found it interesting that it looks at the motivations and reasons why very talented people might not like a job and move on. I think it’s mostly correct, though it’s not necessarily talent that determines whether people stay or go.

    I think most people find these same frustrations or issues with their jobs. Whether you’re a guru level programmer, or a basic beginner, if you perceive an inversion of meritocracy (or you are bored, or you don’t enjoy the job), you’ll look to leave. Whether you can is another thing completely.

    Many of us have various levels of responsibility, to our families, creditors, or even ourselves. Those responsibilities may cause us to rethink the problems with our current job, and appreciate the security of just having a job. This is especially true in today’s world where loyalty is in short supply from employers, and many of us know that the next position may not be more stable in terms of employment for the foreseeable future. As the saying goes, the devil you know is better than the devil you don’t.

    That’s the crux of the issue. A job is a job. I’ve found that to be true across many positions over the years. Some I enjoy more, but ultimately there are always tasks or duties in every position that are drudgery. They are just work. As long as you understand that, and appreciate the challenging and interesting things about your job, you’ll be fine. It’s also why I place more importance on the other staff than I do on the job responsibilities. It’s much easier to put up with a boring or annoying job if the people are interesting than it is to put up with a great job when the people suck.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Losing Data

    We hate losing data as professionals. We should not make the simple mistakes that make it easier for this to happen.
    We hate losing data as professionals. We should not make the simple mistakes that make it easier for this to happen.

    Most of us that work as data professionals hate the idea of losing data. When the developer calls and says his test database is gone and backups were never set up, we may shrug our shoulders and offer to help next time, but we feel bad. We will try everything we can do to recover the data, usually going out of our way to give it our best effort.

    We will lose data. There will be situations that are out of our control, and we have to accept that. However we should try not to make the easy mistakes ourselves that might cause data loss. I ran across a short piece on Five Sure Ways to Lose Data and I agree with the items, but I think there are a few more things we should watch out for.

    One of the easiest mistakes to make to forget is to set up backups. Too often we implement new databases under time pressure, dealing with software that is dropped in our laps at the last minute. Security permissions are never documented and during the frustration of just getting something deployed, we may forget to set up a backup system, intending to do it next week.

    Don’t do that. Get backups set up immediately. It’s quick, it’s easy, and you should have some automated process or script ready. As soon as you complete backups, invite yourself to a meeting to set up monitoring in the next day or two. That’s one of the other easy things to fix: ensuring your backup schemes are working by monitoring your servers. Your monitoring should include alerts for DBCC checks and high severity errors in addition to backups at a minimum. Automating this, or using a tool, are the best things you can do.

    There are lots of other things we might ignore that can cause data loss, but if you get your backups working, you should be able to recover from most any situation.

    Steve Jones

    Voice of the DBA Podcasts

    The podcasts will return tomorrow.