Voice of the DBA

Category: Editorial

  • Proving Your Identity

    I caught this article on Dark Reading that talks about the problems of multi-factor authentication. It’s interesting to me as I had written an editorial on passwords and mentioned that I used the fingerprint reader on my laptop. Someone pointed out that my fingerprints are likely all over the machine and could easily be lifted and used to gain access to the machine. That’s true, and it’s something I hadn’t thought of. To me a fingerprint reader is a convenience, but I might need to disable it for travel.

    As database professionals, we often rely on some other system to prove a person’s identity. For SQL Server, we typically rely on two common choices: a simple name and password, or some security token from the operating system. Those two have worked well, and since SQL Server 2005, we have also had additional encryption options that can be used to protect data, including the ability to use certificates to protect the keys that encrypt data. SQL Server 2008 also allowed Extensible Key Management, so that third party products could be used to secure data.

    As we store more and more data, and this data becomes valuable, it is more and more likely that individuals will try to steal data. While we can’t protect the data from insiders that need legitimate access, we do need to ensure that rights are properly granted and that our security systems have some way to verify the identity of the person or application that connects to SQL Server.

    It still feels like that the security mechanisms for SQL Server as a little immature, and the costs of implementing things like EKM are too high. I am hoping that it becomes more practical to implement better security over time, and we get more tools in SQL Server that help administrators manage permissions.

    Steve Jones

  • More Triggers

    In the old days of T-SQL, back when we wrote “CREATE TRIGGER …. FOR INSERT” we could only have one insert/update/delete trigger for each table. Eventually SQL Server allowed us to have multiple triggers, and even have some control over in what order the triggers fired.

    Triggers are often hidden objects that confound DBAs who aren’t aware they exist. It’s not easy to tell when a table has a trigger on it, and since we don’t often use triggers, it’s not the first place people look when something strange happens.

    However triggers are useful, and it seems that there are many people using them. For this Friday, I wanted to ask how people implement triggers in their applications.

    Do you prefer one trigger for each table action or multiple triggers?

    I’m curious what’s the 80 in your 0/20 rule for triggers. Should all update actions be handled in one trigger? Or should there be one trigger for business logic  and a separate one for auditing? I’m not sure it matters a lot for performance, but I can see that it might be easier to manage and track fewer triggers. The flip side is that something like auditing can be handled with one trigger, and business logic with another: a clean separation.

    Triggers aren’t usually my first solution to a problem, but I do think there is value in using them. However I don’t see a lot of guidance about how to best implement them, so I’m hoping your answers today will help.

    Steve Jones

  • Live Monitoring

    My employer, Red Gate Software, recently released a new product called SQL Monitor. This is the 2.0 version of SQL Response, enhanced and renamed after a lot of feedback and input from various DBAs around the globe. It’s very cool and in preparation for the release, they asked if we could install the software on the SQLServerCentral servers. I was happy to have it on the servers for additional monitoring. Even though I don’t have to manage the databases, I wanted to make sure whoever is managing them has some tools.

    Then my boss asked if we could make the data public. He mentioned that the early look at the console showed a lot of alerts, potentially some less than optimal configurations, and more. I said we should definitely show the site, and at The Future of Monitoring, the try it online link shows the live SQLServerCentral database cluster.

    That’s live, as in a few seconds delay to process the data, but if you look at instance 1, the graphs are changing in real time. Keep in mind that it might appear slow with the huge SQLServerCentral community checking the servers, but you probably don’t have a million wannabe administrators checking out your servers.

    We haven’t changed much at all in the configuration since we made the data public, but over the next few months we are going to slowly tune and configure the server live, informing you of the changes, and showing the before/after data. If you’re following along, you can track the performance differences yourself as well. This is a real world performance because just like most of you, we have resource constraints while managing and tuning servers. We can’t optimally design, build, and manage our servers as that’s not our primary job, but we’re trying to get better by using SQL Monitor to help us keep better track of the servers and work more efficiently.

    One of the coolest things I’ve seen is that our IT staff actually has iPads to watch over servers, and they love it. There’s a slide show on the front page of the monitoring site showing lots of people running SQL Monitor with tablets. Maybe I should take on some DBA chores and see if they’ll get me one. Maybe you can convince your boss to get an iPad with a copy of SQL Monitor as well. 😉

  • Automated Driving

    In the book Red Thunder (highly recommended), the highways are under the control of some computer system. You approach a highway, get into some merge lane, and then a freeway computer takes control of your car, disconnecting the steering and foot controls and drives you along. When you want to get off, you signal, the computer moves you to an off ramp, and then releases control. It’s efficient, with the computer putting cars bumper to bumper, with a few inches between them since everything is under control.

    It sounds great to me, but I’m not sure we’ll ever want to completely put our transport under so much computer control. However people are trying, with automated subways and trains, but many of these still have an operator. There are quite a few projects looking at bringing this type of control to cars, though I’m not sure if we’ll ever get approval for something like this without some type of closed track that only allows automated cars.

    Think about all the issues you see in computer software, even supposedly well-written software. There are always bugs and unexpected code paths or even demands being made of the software. There’s also not enough testing to convince many people that we can really write extremely high quality, complex software that can handle something like traffic maneuvers.

    Then there’s the security. Whether it’s a central system that controls flow on a road or a distributed system in each vehicle, can you imagine the possible consequences if there were some security breach? What if someone finds a way to do some sort of SQL-Injection like attack, such as the one I show above?

    As much as I’d like to be able to ride in my own car, but have it handle the driving chores sometimes, I’m not sure our technology is anywhere close to the level it would need to be for me to trust it.