Voice of the DBA

Category: Editorial

  • What’s Your Area of Expertise?

    I ran across a great quote that made me laugh, but also struck me as being quite true. The quote is from Scott Curie’s post on the PASS Summit Speaker’s Contract and goes like this: “You would laugh at a lawyer who tried to build their own data warehouse, so why would you try to write your own legal agreement?” Having used lawyers for a few contracts, I am well aware that I’m not remotely qualified to putting together a detailed contract. I know if I need a business agreement, I need to either use a lawyer, or make it really simple. “I’ll cut your grass and you’ll give me $25” is probably the last well written contract I wrote.

    We all have strengths and useful skills, things we are really good at performing. We often improve those skills over time and may develop some level of expertise in our field. However, even if we were the best T-SQL coder in the world, or the hands-down, acknowledged world-renowned expert on replication, that wouldn’t mean that we necessarily had any skill in some other area of the SQL Server platform, such as Integration Services. We might know something, we could learn, and certainly be competent quickly, but would a company that had a mission critical, multi-TB import or export of data want us to patch their ETL process today? Probably not.

    Usually when we have a problem with a specific technology, we want someone that knows that technology well to guide us or do the work. The same thing is true in business. If an inventory specialist questions the way some system works, or a financial guru wonders about the calculations in an application, we should defer to them and ensure that we can explain how the code works, double checking the accuracy. After all, specifications could contain bugs as easily as code, and an expert in the end user of software might have a better idea of whether a system is working properly than the developer.

    We should remember that when we venture outside of our own area of specialization. Many technology professionals are quite intelligent, but they aren’t going to be experts in all problem domains, and they shouldn’t present themselves as such.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Stretch Pricing

    I have to admit that I was really excited about the Stretch Database feature in SQL Server 2016. This will automatically archive older data away from your database, but let the query optimizer go get the data if needed. That’s outstanding. That’s the type of archive solution I’ve struggled to implement in the past, finding the effort complex and requiring application change or active DBA management. Often I’ve found that only 10-20% of the data in my database was accessed often, and the rest relatively rarely. Maybe old data was queried every day, but still somewhat rarely compared to a small percentage of the data.

    Then the pricing for Stretch was released, and I think it’s definitely aimed at the Enterprise. If you stretch a sales database, say a 100GB database and want to move 60GB of that data away, you’re going to pay at least US$930/month for the compute at the lowest performance level. Regardless of whether anyone queries the data. If you want better performance, you can run up in roughly multiples of that amount ($1860, $2790, $3720, etc), however, that’s just for compute. If you add in storage, and you must, it’s a minor cost even 1TB, but still, having a $1k bill for access to archive data, especially when you might find people make the mistakes and do query cold(er) data might seem like a lot for a small or medium sized business (SMB). If you have to get better performance, you’ll pay more per month.

    I’m not the only one that doesn’t love the pricing of stretch. It seems to me that the pricing very much favors the Microsoft share price more than the value of my own business. Perhaps this makes more sense at an enterprise level where storage costs can be high, and separating out older data could result in savings. However for smaller companies, if you’re running a SQL Server, even a 1TB (or 10TB) database, is the addition of another 1TB of storage going to cost much? I’m not sure it does.

    Of course, there are other factors. Less data should mean much better performance from your local system. With some tuning of the feature, I would bet that plenty of people might be able to get 90% of their queries satisfied by on premise resources, when they have a substantial amount of older data stored in Azure. That’s not something I can easily do in my own archival system, or with the addition or more storage.

    What I’d really like to see is a stretch to another SQL Server feature added. I’m guessing we’ll see that, likely in SQL Server 20,18 as I don’t think this would be hard to implement. However since this looks like a cash cow for MS, I bet when we get stretch to an on premise SQL Server, this will be an Enterprise only feature, once again, ignoring SMB needs and desires. Maybe in 2020 or 2022 we’ll be able to stretch on premise at a reasonable cost.

    Steve Jones

    The Voice of the DBA Podcast

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

  • We Manage Algorithms

    “Every business is an algorithmic business.”

    That was a phrase that Microsoft’s Joseph Sirosh used in a keynote at SQL Nexus, talking about the future of software and data. Rather than managing data, many of us will move to manage algorithms, which will determine how data is interpreted, used, processed, and potentially returned to users as information. There are starting to be too many sources of data, too much data itself, being generated at too quick a rate, to the point where algorithms become more important than the actual data in examining, grading, interpreting, filtering, and more.

    This is exciting on one hand, with new opportunities for those that can develop, choose, write, tune, or enhance algorithms. I can easily see greater influence from both developers and DBAs as we work to better manage the floods of data. Especially with 50 billion sensors, IoT devices, and more that are predicted to be online in the 5 years. That’s potentially a tremendous amount of data being generated.

    On the other hand, this is a bit scary as separating good data from bad in the ocean of bits, and choosing helpful rather than hurtful algorithms might create lots of stress, and perhaps even fewer opportunities if few algortihms are reused. This also means we will need algorithms that can help us determine if data is actually good enough to use. After all, in the deluge, there will be bad data, that potentially needs to be excluded from queries. Will software developers become more important than DBAs as we end up with more unstructured data stores, data lakes, or other constructs that might require less administration?

    I’m not sure how things will change, but it will be an interesting world the next few years as we work with larger and larger, more diverse sets of data in our organizations.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Penalty for a Data Breach

    Many of us that work with data are somewhat insulated from the effects of a data breach. Each of us is responsible for writing software, managing the database platform, perhaps even in charge of configuring security. However, in the event of an attack or loss of data, many of us would likely be responsible for the technical aspects of analyzing the weakness or cause of the incident, determining what data might be lost, or perhaps helping to change systems to prevent future incidents.

    Would many of us deal with the penalties or financial liabilities of data loss? Perhaps indirectly, but not much. However our employers (or more likely, their insurance companies) will deal with penalties. Right now there isn’t a lot of liability for companies that lose data. Minor penalties and credit monitoring, but many people are getting upset, which might result in changes.

    What does a company owe you if your information is lost? It’s debatable, and this is likely to become a bigger issue over time as more and more people are affected by this issue. I expect that penalties will increase over time, this will also mean that the requirements and work each of us as data professionals need to do will grow.

    While encryption and other measures can help, they don’t completely protect data. Good security comes about from a number of layers, each of which is designed to thwart, or limit the success of, certain attacks. Those of us that work with data, whether in development or administrative roles, need to educate ourselves and continue to improve our ability to implement secure applications.

    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.