Voice of the DBA

Category: Blog

  • Placeholders for Emergencies

    A long time ago I worked in a large corporation where we managed lots of servers, each of which performed a variety of different functions. Some were Exchange, some SQL, some file servers, etc. and they would come and go at a frightening pace.

    We had monitoring in place, but we’d also have plenty of situations where a runaway process would use up a lot of disk space at a rate that exceeded the ability of the monitoring software to alert us before the user encountered a problem. To help us more effectively monitor things, we started adding placeholders do our server build process.

    Placeholders

    What’s a placeholder? It’s a large file that just takes up space on a disk. For example, I’ve created a few on my system:

    placeholders2

    These can be text files, movies, images, whatever you want. The idea is that you just save a particular amount of space. In this case, I have 3 1GB files that are taking up space.

    That’s it.

    If I run out of disk space, I just delete one of these, and voila, instant 1GB space available.

    These have become really, really handy for me. I actually have a few on my laptop. When I run low on space, which will often happen at THE WORST possible time, like the morning of a talk, I can remove a file and free up space.

    Of course, I’ve just deferred the issue, but at least then I can work at that moment and then clean up old files as I have a moment.

    Placeholders are a great way to save yourself in emergencies.

  • Off

    I’m off for a few days. Actually, today and most of next week. I completed my achievement, getting all my vacation scheduled, and this one of those days. I also have most of next week off, so I’ll be taking time with family over the Thanksgiving holiday to relax a bit, and likely, work on my latest woodworking project.

    The blog will be a bit hit and miss as I work around time off. Apart from next week, and the week of Christmas, I’ve mostly got some random days each week, 1-2, where I hope to have views like this:

    Photo Nov 18, 12 45 28 PM

  • Encryption in Colorado Springs – Encrypting in the Application?

    Last night was my annual presentation at the Colorado Springs SQL Server User Group. I try to make sure I get down there at least once a year, and it’s been only once a year for the last few years. Far too busy, and I’m sorry for that, but I am glad I get invited to go down.

    I presented The Encryption Primer, and there were a few interesting questions asked. Always good to see people debating and asking questions.

    One interesting one from a developer – If I can perform encryption in the application, why would I do use something like TDE or column level encryption?

    To me, I prefer to do encryption as close to the source as possible. If I can do the encryption in the application front end, I’d do it there. It reduces the chances of having the data accidentally disclosed. I don’t have to worry about having data read across the wire, or in a backup tape, or anywhere else.

    However that takes time and effort. Developers are expensive, and they have to write good, solid, secure code in the application. They also have to write this encryption code in every application that accesses the database (reports, ETL, etc.).

    Something like TDE is much easier to setup and use. Column level encryption, while still coding, is centralized.

    It’s a balance, and one you need to consider carefully and thoroughly. It also helps to debate and discuss the decisions about what you protect, why, and what it costs.

  • Practical Problems with CI

    I agree. Continuous Integration has issues in the real world, at least it probably does in many companies. The more tests you have, the more likely you refactoring or changes will break something. The more things break, the more people will look to leave them alone, deferring the "fix" into the future.

    This defeats the purpose of CI. The whole idea is to keep your software in releasable condition. That way you can push it out if you need to.

    How do you deal with the constant build breaks? The first thing I’d do is see if I mad a mistake and can fix my code. That should be the first reaction.

    The next thing is stop for a moment and see what tests are failing. It’s entirely possible that the tests aren’t valid or aren’t needed. Maintenance of tests is an issue. If this is a test that regularly breaks, I might call a quick meeting and see if we should remove it.

    The last thing is that I’d rollback my code and then go back to work on it. Perhaps there’s another way to solve the issue and not break the build.

    This isn’t magic. It’s also not easy. However if you are keeping up with your CI process and it’s healthy, I believe it will pay off over time with better software.