Voice of the DBA

Category: Editorial

  • A Live Node

    We don't seem to have this kind of focus in the modern world.

    Today we have an editorial reprinted from March 29, 2006 as Steve is on vacation.

    Do you want to be a node on the network of life? Constantly alive and in touch? Maybe you suffer from continuous partial attention. The article is kind of funny actually. The author doing the interview while driving around, giving her own partial attention to the interview. At least that’s what I hope and it’s not partial attention to the road. Or at least, less partial attention.

    I think this is a huge problem in today’s world, especially as we are more connected with technology. It used to be that you could have some time to yourself on your commute or any other time in transit. You could get a few minutes to walk around the office, stop by a Starbucks for a latte, something to unwind. Your kids competed for your attention with others that they could see you talking with. You could enjoy a movie in peace. Even answering machines, as much as they were first decried by many people, gave you a chance to escape from unwanted calls.

    Now most people carry cell phones. Or worse, Crackberrys. Conversations with someone face to face are interrupted constantly by call phones on the sports field, in movies, the restroom, and the worst, when you’re writing some SQL content. No place is safe these days and as connectivity grows, with data services and wireless connections being deployed further and further, it becomes harder to get away.

    Now I don’t think that the advances are all bad. I like being able to call someone while driving on an errand, or even taking a call while shoveling manure when my wife is traveling. I get two things done at once, one usually not requiring much thought, and save some time in the day for other things. Like spending time with my kids. But I think you have to draw some lines. Turn off your cell phone in places. Set the expectation that you’re not always available. I know every call from your spouse could be an emergency, but you don’t need to answer in the middle of a movie to hear that milk is low at home. Your kids don’t deserve to be interrupted from their baseball or soccer game because your boss wants to ask you something.

    There are definite times where you need to be reached and it’s great that you can. But setup some code or page. Use 911 or something similar if someone really has an emergency, but wanting to ask if you want pizza for dinner is not an emergency. A query about how your project is going is not an emergency. Your child going to the hospital for stitches is.

    As we become more connected, the need for boundaries becomes more important. Not only to show respect for those around us, but also to keep our sanity. The thresholds for alerts in life are as important as the need for alerts. Learn to miss a few calls or emails and pick them up later.

    Those of us standing in front of you, trying to carry on a conversation with you will appreciate it.

  • The Care of Data

    It's not just a Dropbox problem

    DBAs are supposed to be trustworthy. After all, they are the custodians of data and often have access to sensitive information because of the nature of their system administrator level privileges. Their turnover ought to be low, and hopefully they have spent years building skills and a reputation that will provide them with a good job. They ought to value this investment and treat it seriously. Customer Service people are not usually in the same position in their careers, often at the beginning of their technical careers and usually change jobs regularly.

    Recently Dropbox had to back off the stance that it’s employees can’t view your data, with this note that their staff can access your files in some circumstances. There’s no evidence that employees have mis-used their access, but it could happen, and that’s a concern. It’s a concern with any cloud based service, and I think this is one area that cloud-type vendors really need to assure their customers that it won’t happen.

    Another major concern is overall security. If a cloud vendor’s employees can access your files, so can a hacker that gains access. That is, likely, an overriding concern of many customers, and it’s an area that I think that we really need to disclose openly the measures taken, the auditing in place, and the monitoring to detect any issues. Better encryption that actually prevents access by the vendor or it’s employees is a better solution.

    I hope we get encryption methods because the third major concern with cloud data is access by legal authorities. There are cases where the government might have a right to access your data, but that should be when they serve you with notice, not some company that is holding your data.

    There are many great customer service people and DBAs with strong worth ethics and morals. They take their responsibility as the custodian of your data seriously. There are a few, however, that are not so professional, and release information, sell data, put stories or video on some site like YouTube or TheDailyWTF for a laugh. Something that I’m not sure most of us that store data in the cloud would like to see happen with our pictures or video, and definitely something that companies would not want to see with proprietary information.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Ad Hoc Change

    Ad Hoc changes are not what I like to makeHow many times have you been asked to change data in a production system? If your career has been like mine, it’s probably too many times to count. It seems that there are always data issues in production, and the DBA is asked to fix or correct something. In my mind, there are two many causes of this: user error and code bugs.

    In both cases, you would hope that some application contains the feature to allow a user to fix an error: either one they created or one the application slipped in. However in the reality of today’s IT world, too often there are not enough tools to allow an application to be used to correct issues. Just like testing, it seems that too often we haven’t spent enough resources before deployment in an area where they are needed: tools. As a result, it’s time for the DBA to change things.

    I saw a blog from Jon Russell recently that pointed out a few things that it’s easy to forget when making these changes. Many DBAs know their systems very well, understand the data relationships between tables, and hopefully, have declarative referential integrity (DRI) in place to ensure data integrity. However it’s easy to forget about some business rule coded in a trigger, or the downstream implications of a data change. That’s was a problem at SQLServerCentral at one point when I corrected someone’s question of the day response, but didn’t realize that their total points are stored elsewhere and needed to be updated separately. In that case I ended up with a lot of data to fix.

    We do have to make manual changes to data at times. When we do, Jon’s list of steps to include in the process is important, especially in many companies where auditing is demanded or even required. Keep copies of the old data, document what you did, and most importantly, make sure you’ve sent notifications. Often if an error crops up, it will be noticed by the end-users that usually work with the data. An email from the DBA just might help them find mistakes quicker, and prevent even more problems.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Backup Passwords

    Hopefully you have better password management

    One of the things that my boss was excited to implement a few years back were passwords for our backups. Actually we were using a third party backup utility, like SQL Backup, for our SQL Server instances. We purchased the tool because of the compression, but the encryption feature was appealing to management in the wake of so many data loss reports in the media.

    It seemed like a good idea, and we started to make plans for the backups. However we quickly ran into a concern: how would we manage the passwords for the backups? After all, if we lost track of the passwords, then the backups couldn’t be restore and that would be a problem. Keeping the same password forever was only slightly better than not having a password given the turnover we had seen at the company.

    We used Password Safe to track current administrative passwords for our team, and that worked well, but backups introduced  the new dimension of time into our password storage.  We wrestled with the problem and came up with a solution, but I thought it would make an interesting Friday poll:

    How do you deal with key management across time?

    This mostly applies to backups because most other systems or accounts only have one password at any given time. However backups could exist for a long time, and even in a short period of time, you might have 3 or more passwords to manage. If you changed passwords one day and had an administrator quit the next day, you might end up with another change and 3 passwords across 3 days of backups.

    I want to know if you’ve thought about this and how you deal with it, or if you ignore it, keep the same password, avoid encryption or any other ideas.

    Steve Jones

    The Voice of the DBA Podcasts