Voice of the DBA

Author: way0utwest

  • Caching

    How many of you have worked with a cache of data for your application? I would bet that the vast majority of you have never built a caching system. There’s not shame in this, as most of us don’t work with very high levels of concurrency in our applications. Even if we hit them, it’s rare enough that we wouldn’t bother with the extra coding when we designed the application because, well, it’s extra coding. It takes time, requires more testing, and our project managers might not be willing to invest in this “just in case” we hit some concurrency issue. Actually, most of us probably would view this as a “good problem”, one that would then be worth re-architecting the application.

    The problem is that often no one wants to re-architect a working application and potentially delay other, more exciting enhancements. Many highly visible web sites have gone through this, experienced growing pains, and only those that have a tremendous amount of resources to devote to the problem usually solve it.

    However it doesn’t have to be hard. Brent Ozar published a piece on caching results that uses a creative solution, scaling out to a new database and table that exists only to return results. In some sense, this is a great application of the KISS principle that doesn’t use replication or any other complex technology. It even employs a technique those NoSQL platforms often hawk: eventual consistency.

    That’s the idea behind caching. The data isn’t necessarily the most up to date, and it’s not dependent on being synced with your other data. Ideally you’d have some system that updates your cache when the base data changes, but even then there’s an “eventual consistency” delay at work. It might be tens, or hundreds, of ms, which is often what we find with distributed systems, but that’s usually fine. It’s very rare that a problem requires absolute synchronization of all data in the application.

    I’d urge you to consider thinking about  building some scaffolding into your application that can potentially be built out later to incorporate caching, or some other scaling technology, in the event that you find your system is more popular than anyone might expect. It shouldn’t be too hard, especially if you think about it early on.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and Mevio . 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.

  • Lawsuits and Data Breaches

    After the breach of the Target payment systems, a class action lawsuit was filed against the company. The action alleges that Target failed to implement strong enough security. Regardless of the merits of this action, it does bring to light a few things that we, as data professionals, should be aware of.

    The first is that if our companies store any PII, financial, medical, or other sensitive data, we need to ensure that our management is aware of potential security pitfalls we see, as well as the possibility for legal action if the data is somehow disclosed. The risk and mitigation actions taken need to be weighed by management, and we should approach this as we might any other upgrade or enhancement to a system. With logic, and rational discussion about the issues, providing guidance and potential solutions.

    However we also should be aware that no matter what security efforts we undertake, criminals are going to be finding ways around our defenses. As this piece notes, Target likely had security in place, but it’s never going to be enough because the attack vectors and techniques are out-pacing the ability of security techniques to provide protection. The solution, or at least a potential mitigating action, is one that data professionals can help with.

    We, and the businesses that employ us, should be incorporating analytics into our defenses to detect abnormal actions, by both external and internal, users. We should be looking for potential ways that data is disclosed, and perhaps even scanning the Internet for potential leaks of data. We won’t prevent all problems, but if we can detect them early, we can limit the damage.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and Mevio . 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.

  • Auditing Matters

    There’s been some reporting about Yahoo Mail getting hacked and potential issues recently. I ran across this piece that talks about what happened and it’s an interesting read, but there’s one quote that stuck with me: “Yahoo reported on its Tumblr that it had detected “a coordinated effort”—basically, an attack—by somebody trying to gain access to user accounts.”

    It’s not the notification or the proactive resetting of accounts, but the detection that resonates with me. We’ll never stop all hack attacks. We’ll never plug all the holes in software. We’ll never anticipate the ways in which our systems might be compromised, but we can detect issues. I think more often than not we can deal with any hacks or attacksif we are aware they took place.

    We have some login auditing in SQL  Server, an auditing and eventing framework, and the ability to capture and store this data. However we don’t have good proactive tools to help us detect issues. I’d like to see enhanced tooling to allow us to review log data, write alerts that look for patterns, and more. While much of this can be built by DBAs, it requires use to develop and maintain software, and even then it’s easy to miss potential attack vectors if you don’t constantly supplement your knowledge and enhance your tools.

    Given what we have to work with, I’d encourage you to learn a bit about the different frameworks and gain some basic skills with the tools. I’d also encourage you to think about writing queries to look for potential hacking issues, like updating all of your lookup values to the same string, or embedding script tags in your data. I’d encourage you to write or speak about what you learn, and how you use the information. If you’d like to write software to make the task easier, that would be great.

    I’d also encourage you to befriend your network or security administrators and teach them how to query their own lo data. Lots of their tools collect data, but provide poor query tools for the information. Perhaps you can even build them a data warehouse that allows them to tighten security by examining their own data.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and Mevio . 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.

  • The SQLCLR Impact

    While I’m sure there are a few of you still using SQL Server 2000 instances, I think at this point that most companies have moved to SQL Server 2005 and later. Even if you still manage a pre-2005 instance, chances are you have a few 2005, 2008, or 2012 instances as well.

    It’s been a little over 8 years since the CLR subsystem was added in SQL Server 2005. At the time this was announced, we had any number of DBAs worrying about the impact. Before SQL Server 2005 was released there were lots of concerns that developers would embed most of their database logic in SQLCLR procedures and cause lots of performance issues. That doesn’t seem to have been the case, but this week I wanted to ask you about your experience.

    Have you had to review and implement custom SQLCLR assemblies on your instances?

    I’m looking for an idea here of the impact of the SQLCLR in your environment. Do you have standard assemblies on multiple instances or have you dealt with an ad hoc object here and there? Do you think SQLCLR is a normal part of your applications or a one-off that’s rarely used? Do you go through the code and understand how the logic is implemented? Do you ensure error handling is implemented? Perhaps you’ve not dealt with it at all?

    I haven’t seen much of a call for SQLCLR objects from the various developers that have worked on the SQLServerCentral site. Most of them seem content to use their traditional tools: they use .Net code in the front end or T-SQL code in the database.

    Let us know this week. Has the SQLCLR been a regular part of your SQL Server environment.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and Mevio . 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.