Voice of the DBA

Author: way0utwest

  • The Brittleness of Replication

    I’ve used replication for years in different positions. I first discovered it in SQL Server 6.5, using it to simulate a queuing system to keep two disparate applications in sync without requiring transactions between the applications and causing errors. As handy as replication was, it was also brittle. Small things would sometimes break replication and the quickest way to repair the system was to drop replication and re-initialize it. Fortunately my data was small in size.

    As I’ve watched replication grow through the years, I’ve been happy to see enhancements, like the ability to replicate schema changes to objects contained in articles. However I’ve been disappointed that the tooling has barely improved and the brittle nature of the process has not been addressed.

    It seems that as SQL Server grows, we find more and more features and subsystems that are being managed like replication. They get built and then languish with few resources devoted to improving their tooling and robustness. Service Broker, spatial data, and more are examples of features that were introduced, but have received little attention in newer versions.

    I have to believe there are developers at Microsoft that would love to make the product better. I understand the need for new features, and continuing sales, but devoting a percentage of time to improving existing features, regardless of the Connect votes or marketing wishes, would help make the platform that much better for everyone.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA 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.

  • T-SQL Tuesday #57–SQL Family and Community

    TSQL2sDay150x150It’s T-SQL Tuesday time again. After missing two months with my sabbatical, I’m back.

    The topic this month is hosted by Jeffrey Verheul and it is SQL Family and Community. That’s a topic near and dear to my heart, and I’m glad to participate this month. Jeffrey asks: How do you feel about SQL Family? Did they help you, or did you help someone in the SQL Family?

    You can participate as well. Setup a blog, watch for the announcement each month (it varies, so search or follow #Tsql2sday on twitter) and then write a post on the second Tuesday of the month.

    Contact Adam Machanic (Blog | @AdamMachanic) if you’d like to host. I also maintain a list of topics.

    SQL Family and Community

    I have a couple thoughts about SQL Family to tell. There are many of them I’ve been a part of, and my apologies if you think I should have chosen another one, but I have to choose. The SQL Server community, the people in it, are just amazing. It’s a closer, and tighter, and friendlier community than I’ve ever been a part of.

    It really is close to family.

    1000

    A few years ago I was on a running streak. I ran at least a mile a day for over 1500 days. I actually retired the streak, but the milestone that might mean the most was day 1000.

    I wrote a bit about the day, where I got a great note from work, and my family ran with me. I got lots of congratulations from the community, as there are quite a few runners who work with SQL Server, and many others who helped support and inspire me to keep going. However the big news came from a phone call.

    Jes Borland (twitter, blog, BrentOzar Unlimited), whom I had never met at the time, contacted me and asked me for my phone number. She called and said that she was working on a gift for me: new shoes. With help from Red Gate, Jes arranged for a custom pair of Nike running shoes to be sent to me, customized with “1000” on the rear.

    I still have those shoes, though the 1000 is coming off. I even wear them on occasion. Every time I look at them, I remember that phone call, and the really, really special gesture that Jes made.

    I was touched, and I’ve been lucky enough to not only meet Jes and develop a friendship, but also run with her in Seattle, Fargo, and probably a few other places.

    The SQLFamily Bond

    The one thing that seems to happen over and over again in the SQL Server professional community is that people care about each other. They help each other, and they respect each other. They pull together, working to help everyone be better.

    Certainly people bicker. They get upset, and they disagree. However, it seems overall that we really are closer to an extended family, giving of ourselves to treat others well when we don’t have to. SQL Saturday is a great example of that, with tremendous growth in seven years, with events where people seem to be more well behaved toward each other than at many other events.

    I see people offering others rides to and from places. I know community members that offer their homes to others to give them a place to stay, or will split a hotel room. We create opportunities to bond and relax with each other outside of events. #SQLRun, #SQLSki, #SQLCruise, #SQLKaraoke and more exist in casual, friendly ways that I haven’t run into when I’ve dealt with other technologies.

    I don’t know that why the SQL Server community is different, but I’ve never seen another niche of professionals to whom I’d apply the word “family.”

  • Do We Care?

    Today’s editorial at SQLServerCental is entitled: We Don’t Care about Data and IT Security. It’s by Brian Kelley (author, blog, twitter), and I think it’s worth a few minutes of your time to read.

    It’s aimed more at executives, and certainly talks about the disconnect between actions and words. People talk about security being important, but rarely seem to make fundamental changes that might improve things.

    I tend to agree, though I also think it’s not as cut and dried, and often we have a disconnect in what we really want or need from security. Do we need chip-and-pin cards v our signature ones? It’s arguable that the former are more secure, but there have been incidents, and without a doubt the large scale of the US credit card market would mean more and more attacks. There is an argument that the devil we know is better than the one we don’t.

    However there certainly are not great coding practices in many organizations. I think we far, far too often do not train or show new developers how to code more securely. We also don’t require older developers to change their habits to implement new techniques that limit issues. We also don’t bother to review code that consultants write and require security. It’s far too easy to “just get it into production” for many people.

    Overall, I tend to agree with Schneier and Brian in that we need to rethink security in our languages, but also fundamentally in how computer systems work. We also need a culture of security, something that won’t take place until we mature as a digital civilization.

  • Data is Not Always Enough

    As data professionals, our jobs deal with ensuring that there is data available, accurate, and relevant to the organizations in which we work. However we often go beyond the simple maintenance, gathering, and manipulation of data to help our clients and customers understand the information contained in our systems. In many of my positions, whether as developer or DBA, I’ve been tasked with working closely with business people to make decisions based on data.

    I’ve always been of the opinion that more data is better, though I certainly understand the problems of Big Data and the potential to reveal false patterns or overwhelm systems with conflicting information. The better I understand the domain, and the better educated the business analysts are, the better we can work to extract information from databases.

    However that’s not always enough to help an organization act. I read an interesting piece this week on data in sports, which talks about one of the NHL team’s managers using data to make decisions on how to restructure his team. It’s interesting to see that additional data gives the general manager more insight, and leads him towards a decision, but the rest of the organization can’t follow through. In this case it’s a matter of money, but resources constrain our efforts in many decisions. I think this is a place where more flexible, and perhaps more in-depth, BI-type analysis of what-if scenarios can be more helpful.

    The other piece that caught my eye had to do with real estate, and housing prices, with the author bemoaning the lack of data in determining the value of a house. It’s interesting, but to me, it’s flawed. More data won’t help because houses aren’t like many other commodities. One house is not fungible with another one, and the market is both fast moving, and inherently full of friction. We rarely buy a house without visiting it, a task that consumes time, and slows the movement of information through the system. I’m as frustrated as the author, but I don’t know that more data would help in this case.

    Data is important, and it should be a part of our decisions, but we should remember that data isn’t necessarily going to make the decision for us. We need to be ready to incorporate our own knowledge and judgment into a data set to help us decide on a course of action.

    Steve Jones