Voice of the DBA

Author: way0utwest

  • Solving Problems at Midnight

    I couldn’t sleep last night. I was tossing and turning, struggling to rest, and it seemed I was waking up every 20 minutes.

    My demo broke. I have a talk that I’m giving at the Denver SQL Server User Group on Thursday, as practice for the same talk next week at SQL Intersection. After returning from my travels, I fired up my virtual machine on Monday and went through the talk. I’ve given a version of this as recently as 3 weeks ago, but I like to refresh myself. When I got to the third demo, I couldn’t get it to work.

    I tried a bunch of things, but the test I was sure would fail, wouldn’t. This is a significant part of my demo, and it shows how data volumes affect things. I reset the snapshot. I dropped and rebuilt the database and process. I even took a 3 hour break, going for a walk, picking up kids, and hitting a yoga class. When I returned at night, while my kids were doing their homework, I couldn’t get mine to work. I even faked the test, and caused a failure, but that wouldn’t work with an audience.

    I gave up around 9:30 and went to bed shortly thereafter. At least, I tried to, tossing and turning. My mind was all over the map, thinking about work, some projects at home, kids’ school, etc. At 2am, it hit me. All of a sudden I realized why the test wouldn’t fail. The join that was supposed to be slow, wasn’t, because it was missing some data. I was generating a large volume of data in two of the three tables, but in the third, I hadn’t linked it to my version control system. That’s why it failed.

    I don’t always have such great inspiration at night, but I have found that sometimes walking away from an issue and taking a break can help. I’ve even walked to a colleague’s desk and helped them with their own issue, and all of a sudden I realize how to solve my problem. I’ve learned to learn to be productive in other ways when I’m stuck on a particular problem, letting my subconscious mind analyze things in the background.

    This morning I linked my table and the test started failing. I have rarely been so happy to see red errors on my monitor.

  • Minor Problems

    When I speak to people about blogging to increase the visibility of their brand, one of the questions I often hear from them is “what do I write about?” My advice is to take the every day occurrences, the things that come up in the course of your job, and write about them. It doesn’t matter if everyone else has written about backing up SQL Server databases, or writing a query to find duplicate rows; it matters if you have written about it. A potential employer often your blog as due diligence on your skills, including the way you communicate information to others through your writing.

    However most of us also encounter these seemingly trivial, minor problems that plague our environments. We find creative solutions to the problems, solutions that others might not think of. They don’t seem to be worth sharing. I hear so many SQL Server professionals belittle their work, thinking that anyone could build the same solution. That might be true, but for every problem you solve, there are probably others working with SQL Server that would benefit from hearing about your work.

    New people come into the SQL Server community all the time. There will be people that connect to SQL Server with Management Studio for the first time and back up a database. This week someone is writing their first T-SQL query and executing it. The trivial, simple solutions that you develop for common problems might just help one of these beginners learn something, and solve a problem their first week as an accidental DBA.

    Write about the common things you do. Share the solutions you develop. Pay it forward, since most of us have gotten help already from someone else in the community doing the same thing.

    Steve Jones

     

  • Database Queries and Scalability

    I ran across this post with a very provocative title:  (thanks Brent Ozar Unlimited). It’s an interesting read from a developer, talking about how so many website designs aren’t built for scalable because they rely too heavily on a set of database queries place on every page. If you expect a database query to retrieve or store a user id, or other data on every page, then you are limited to the scalability of your database back end. There’s no doubt there, but the author has ideas that can help you overcome these issues.

    One of the problems is that systems read and write account information (or registrations) to the database directly. That’s definitely a scale issue, and the author suggests generating the client information on the web server and storing it in a more robust and scalable backend. That makes sense, but it’s with the caveat that ” As long as you eventually write the data to the db later on, you’re good to go.” Good point, but now you need a replication process of some sort (or messaging) that gets the data to your database. This ignores some of the synchronization issues across multiple servers as well, but it’s not a bad idea.

    The idea of avoiding joins, by using a cached set of data to iterate through and pull data from other tables may work in some cases, but I’m not sure this is the most efficient way of grabbing data from a database, ensuring it’s the latest data, and not impacting concurrency. This technique seems to invalidate the power of an RDBMS by not using joins to effectively, and efficiently, retrieve data. I suspect replicated copies of slowly changing data is a better way of scaling your system than avoiding joins.

    Overall I don’t love the article, and depending on which platforms and technologies you’re using, it might be better, or worse, advice. I would say that building better systems involves considering alternative techniques, allowing for failures, and using new techniques like messaging, caching, asynchronous processes and more. As we try to improve the quality of our software, we should be talking about, writing about, and trying out new techniques, learning what can work better in our environments.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 22.3MB) feed

    MP4 iPod Video ( 25.7MB) feed

    MP3 Audio ( 5.2MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Speaking at the October Denver SQL Server User Group

    I have a talk this Thursday at the Denver SQL Server Users Group. I’ll be talking about Continuous Integration for databases, looking at ways you can automate database builds and perform some automated testing as you move forward in your development.

    If you’re in Denver, come out and do some networking. I’m happy to do either talk, or even something else if people want.