Voice of the DBA

Tag: high availability

  • High Availability Upgrades

     

    Is SQL Server 2012 worth the upgrade for you?

    SQL Server 2012 will be released soon. I have no idea of the exact date, though I suspect a peek at the SQL Server developers’ vacation schedule in Redmond might provide some clue. The announcement last year was a first half of 2012, so I do expect to see the product RTM sometime between now and July 1.

    One of the highly anticipated features in SQL Server 2012 is the Always Onfeature, which will dramatically increase the ease with which we can build databases that can not only tolerate hardware failures, but be deployed (physically) further apart, and with more flexibility in how backups can be taken. If you haven’t read about Always On, I’d urge you to start looking at this feature and see if it’s something that can help your company.

    Unlike Database Mirroring in SQL Server 2008 R2, which is limited to one secondary database, Always On will allow us to have multiple secondaries. The current mirror databases are unreadable, unless you count the kludgy database snapshot feature. In SQL Server 2012, however, we can actually use the secondary databases to query, providing some limited scale out capabilities. I think that’s fantastic, and it’s a large step forward for the SQL Server platform. I’m wondering if your company feels the same way.

    Will the read only secondaries available in SQL Server 2012 convince your company to upgrade?

    There are lots of other features in SQL Server 2012, some great advances in other parts of the platform that might be worth upgrading for, but I regularly see people struggling with scale issues. With the changes in licensing as well, these new scalability features are worth examining, and I’m wondering how important they are for your business. Important enough to justify the price of an upgrade? Let us know today.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Chance of Failure

    I’ve always worked on the notion that my hardware rarely fails, and while I protect it with backups RAID, etc., I don’t expect failures. That seems to be how most of the RDBMSes are structured, with this idea that things will work well and we have protection mechanisms when they don’t.

    Contrast that with the way Google viewa the world. To them,failure is inevitable at scale, as noted by  Jeremiah Peschaka in The Promise and Failure of Federated Data. At large scales of deployment, Google and other companies assume that there will be a percentage of failures and they have to account for them. This is the same type of accounting that restaurants use (spoilage) and retailers (shrinkage) use for allow for some amount of loss.

    In technology, we account for potential failures with RAID, with HA or DR technologies, and hopefully with substantial testing to ensure that we have properly accounted for potential failures. However it seems that most technology people account for failure as a possibility and not a probability. Many people seem to assume that a serious disaster is not likely in their career.

    I think that a catastrophic, we lost the whole data center, event is unlikely for most of us. As Hurricane Katrina and the recent earthquake in Japan have shown, that is possible. However it’s unlikely for most locations, which is a good thing.

    Failures are inevitable and whether it’s a disk corruption, a server crash, or a building power failure, we have to assume we will experience one and plan for the event. We also have to expect hardware will fail, which means regular checks and monitoring to detect these failures as soon as possible.

    Hope for the best, but plan for the worst.

    Steve Jones

    The Voice of the DBA Podcasts

  • An Overview of SQL Server AlwaysOn

    One of the changes coming in SQL Server v11 (not sure what the name will actually be), also known as “Denali”, is the addition of more High Availability/Disaster Recovery Options. When I first heard about this, I was excited, but the public CTP had limited support for it. I’m hoping the next CTP will substantially improve the feature and this makes it to the RTM.

    In the meantime, here’s a Channel 9 video from Justin Erickson that gives a short explanation of how this works and how it compares with the current Mirroring/Log Shipping/Clustering options.

    SQL Server AlwaysOn

  • What’s a Passive Server?

    Licensing software is often a more complicated process than I think it should be. Licensing database software seems to be even more difficult to understand, especially when you start to talk about the various high availability (HA) scenarios, virtualized  servers, separate machines to process SSIS packages and who knows what other configurations, not to mention the licensing changes with each new version of SQL Server.

    I was following a licensing debate  about how you license passive servers in an HA situation. I have always understood from the SQL Server licensing documents that if you have a passive server, it does not require a license for the SQL Server software. However it’s not that simple, or at least, it doesn’t appear that way to me.

    Suppose you have an primary instance that mirrors its database to another server. The mirror instance doesn’t need a license for that database, but what about if you also log ship your primary database to a third server? Does the third server need a license if it’s also “passive”? I assume that if you had second database on the mirror instance being used for another application, you’d need a license for that instance, but what if you only have a “DBA database” that gathers performance monitoring information for that mirror database? Is that “passive”?

    Suppose I have a 6 node cluster, and I have 4 active nodes and two passive ones, do I still have 2 other “passive” licenses for log shipped servers? Or can I log ship to 4 separate servers? That doesn’t even bring this clause into play:  “The passive server can take the duties of the active server for 30 days. Afterwards, it must be licensed accordingly” (from 2005 licensing). It almost feels like I am studying some type of Microsoft Internal Licensing Framework in preparation for some type of certification.

    To me, the simple way to handle this is to say that passive servers, those not doing any work for the business that owns them, don’t require a license. The exception would be for internal monitoring or maintenance on the passive server (backup restores, DBCC checks, DBA sysadmin monitoring). I doubt we’ll get something that simple, but that’s what I think would be fair.

    Steve Jones

    (originally published at http://www.sqlservercentral.com/articles/Editorial/72338/)

    The Voice of the DBA Podcasts