Voice of the DBA

Category: Editorial

  • How Long Before You Upgrade?

    It’s 2014. SQL Server 2000 is 14 years old, but there are still quite of you managing instances. SQL Server 2005 is 9 years old, and I’m sure more of you still deal with that version. I know because I work for a software vendor and I’m constantly asked if our software will run against those two versions.
    For many of you, however, if you’re managing a SQL Server 2000 instance, it might only be 9 or 10 years old. Your company might still have been installing SQL Server 2000 in 2005. The same is true for SQL Serve 2008. I wouldn’t be surprised to find companies still setting up 2005 instances in 2008 or even 2009.
    Companies don’t care much about versions. They tend to mostly care about databases getting the job done, and sometimes, support. Many organizations don’t see value in upgrading too often because of the overhead. I suspect many managers would prefer to get many years usage out of a platform before they change in order to minimize work that doesn’t add value to their business.
    The question this week asks you about the longevity of your database instances. Think about the average instance, or even the majority of your applications and how long they will remain on a particular version.
    How many years will you run a platform before you upgrade it?
    Years ago I heard someone at a large Fortune 100 company say their stated policy was to get 10 years of service out of a database server. At the time I thought that was a long time, but the more I think about it, the more I think that might be a minimum amount of time I’d want from a platform.
    Let us know this week what you experience, and perhaps what you’d prefer.
    Steve Jones

  • If or When?

    I saw this post recently about security and preparing for a data breach. The title caught my eye because it implies that we’re all doomed. Do the rest of you think that? Is it a question of when we’ll have a security breach not if?

    Given the headlines, the news we find out about companies not disclosing security issues, the back doors and poor code in much software, is it any wonder that people think it’s a “when” and not an “if”? Given the lack of realization from many companies that suffer incidents that they were even attacked, perhaps that’s an assumption worth making.

    We’ve been hacked at SQLServerCentral in the past. I don’t think we’ve been hacked in many years, but I also have no way of knowing. That’s the difficult part of dealing with bits. If they get copied, there’s not necessarily a trace of anything amiss. It’s quite possible that many of us have no idea that our bits are being copied. Every read is a copy of data and how long did the NSA read data without most of us being aware? How sure are we that they, or some other organization, hasn’t been reading much more than was disclosed?

    I’d hate to think that our systems are so porous that we’re all likely to get hacked at some point. It’s probably technically possible, but hopefully not likely for most of us. However we should consider that it will happen and ensure we have some handle on our data security. It’s hard, and complex for most of us, and I’d like to think that Microsoft will recognize this and build better controls and features into future versions of Windows and SQL Server that enable easier auditing, granular permissions, and separation of duties.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.0MB) 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.

  • Problems with Big Data

    Big Data is constantly in the news. We’ve been asked at SQLserverCentral to try and develop some articles, perhaps even a stairway to explain what Big Data is and how we might use it. I’m still trying to grasp the concepts myself, and unlike the amorphous cloud, I’m still looking for some good examples of what Big Data really is.

    When I ran across this piece warning that Big Data isn’t the final solution to all our questions in the world, I wasn’t surprised. The piece notes that Google Flu hasn’t been very accurate in its predictions of outbreaks. At first glance, this gives lots of credence to the idea that the good, solid data analysis and mining techniques we’ve used for years are just as good as any new Big Data fad.

    However as I read more about the piece, it’s not that big data and the analysis of large quantities of information is flawed, it’s that a solid hypothesis matters. Researchers need to be willing to evolve their algorithms as they learn more about a problem. Probably they should also assume their algorithms are not correct until they’ve proven their ability to predict actual trends for some period of time.

    We’ll constantly be searching for ways to better interpret information and make better decisions. No new technology or product is going to magically solve our problems. Good solid understanding of the problem domain will continue to matter as much as the data itself.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.8MB) 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.

  • Lobbying for Change

    I ran across a note recently on Twitter from Adam Machanic. He wrote:  Just spent most of the day working through a subtle PK issue – 1 bad row out of 18M. Would have killed for this. The item in question was a Connect item, one with almost 500 votes. It’s a good one, and I’d encourage you to vote for it. I know that it seems many of these items are never worked on, but some changes make it into the product, so I’d ask you to continue to vote for change.

    When Connect was first introduced, Andy Warren and I debated the value of the platform. On one hand it made good sense to directly feed information back to developers, but on the other hand, it was likely that those items that got more notoriety or votes might get fixed, even if they weren’t necessarily good ideas. The popularity of an item doesn’t necessarily mean it’s one that should be fixed in the product first. We also worried about one of the big problems of the platform and that is that a tremendous amount of noise of entered and it becomes hard to triage the submissions.

    As I watch Connect evolve, I can’t help but think that it’s been mostly a failure from my perspective, with a few notable successes, like Service Pack 3 for SQL Server 2005. There’s too much noise and too many items ignored. However I also do think that those items that get lots of vots do get more consideration from Microsoft. More votes doesn’t mean that the feature will get fixed, but I do believe the item gets talked about. (As an aside, please vote for more, final Service Packs)

    Personally, I think that raising awareness of possible suggestions or problems is a good idea. I’d love to see a top 10 list of Connect items from MS for consideration every month. Having them highliht some items they’re considering from the list might help focus attention from customers. I don’t think that’s likely, but I wonder if highly debated suggestions might be worth highlighting at SQLServerCentral. Would you like to see a Connect item of the week? Something you could vote on or even debate as a good idea? I would, and I’d consider adding them as a way to help improve the platform that I enjoy working on the most.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.0MB) 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.