Category: Editorial

  • The High Availability Poll

    Always On Diagram
    Is it worth it to you to build a highly available database?

    The cost of building highly available databases dropped with the introduction of Database Mirroring in 2005. Without the need to purchase identical hardware for a spare system, it became much easier and less expensive to set up extra systems that could handle a workload in the event of a disaster. This technology was improved in SQL Server 2008, and in SQL Server 2012 we have a new option: Always On.

    When I first heard about the changes coming in SQL Server 2012, I thought for sure that many people might upgrade to take advantage of the HA enhancements and provide more stability for their systems. However as I see the actual changes in detail, and talk to more and more data professionals, I’m not so sure. Many of us have spent years building systems that tolerate most issues meet the majority of our needs. With that in mind, I had a question for the DBAs out there.

    How important is a highly available database with automatic failover to your employer?

    Having a spare system that automatically picked up the load when a database server failed would seem to be on the wish list of every user, but plenty of environments don’t implement one. Many companies desire such a configuration, but when they see the cost or complexity, many forego an implementation.

    This Friday I’m wondering if your business sees this as critical and has implemented such a system, or are you more tolerant of minor issues, and willing to accept some downtime in a simpler environment.

    Steve Jones


    The Voice of the DBA Podcasts

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

  • Password Help

    Keepass Logo
    Use Keepass, Password Safe, or some other password manager.

    In case you haven’t heard, LinkedIn passwords were hacked and posted online. If you haven’t changed your LinkedIn password since the attack, please stop reading and go do it now.

    In reading about the attack, I sent a few friends a note as well to remind them that not only should they change their passwords, but that they should not be using the same password in multiple places. With more and more services intertwined, and more logins needed, it’s no stretch to think that someone that manages to crack your password, or steal it, from one service might use it on another service. Especially banking services.

    As data professionals, it’s easy for us to preach to non-technical people the value of strong passwords, but it can be hard to get them to use them. Strong passwords are problematic for many people to remember and type, and we find that most people prefer the path of least resistance: one short password that’s easy to remember.

    This article talks about a few things that IT people can do to help educate others and make it easier for them to consider strong passwords. Inside of a company, we can try to implement more services and products that secure our systems, but if people continue to use the same password for their personal mail or favorite website, much of that might not matter.

    Ultimately I think the best thing we can do is set a good example, and choose strong passwords stored in a password manager. Once people see that it’s relatively easy to secure passwords with something like KeePass or Password Safe, they may give it a try. That may help keep our data just a little more secure.

    Steve Jones


    The Voice of the DBA Podcasts

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

  • The Redmond Agenda

     

    TechEd 2012
    TechEd 2012 had a lot of cloud focus.

    TechEd was recently held in Orlando, and I watched a few highlights of the event remotely from the ranch in Colorado. One thing was quite apparent from the coverage is that the cloud is very important to Microsoft. They’ve backed off the “everything in Azure” message that we have been seeing for a few years, and I saw quite a few talks and demos about hybrid applications and the private cloud. One that’s located in your data center.

    However the cloud is still important, and I wonder if this piece is true. It talks about five things Redmond doesn’t want you to know, and the first item is that the cloud is first. New releases of products will likely come in the cloud first, and in a version you can buy second. The article mentions Sharepoint, but many other Microsoft products live in the cloud, including SQL Server.

    Is that a bad thing? Many of us complain about the quick release cycles of SQL Server, so having new releases take longer in the box may be preferable. It’s already a challenge supporting two or three versions of SQL Server. If releases continue to come every two years, I suspect many DBAs will be supporting five or six versions in their companies very soon. That will be challenging, especially as many of the monitoring and troubleshooting skills we will build or buy may not work with all those versions.

    I don’t know if the rest of the items listed in the article are true or even important us data professionals. However I do think that if SQL Server moves toward a cloud-first development model, I think it might be something that many DBAs appreciate.

    Steve Jones


    The Voice of the DBA Podcasts

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

  • Documenting the Undocumented

    Evolution of Documentation
    Documentation is important, especially for the platform. Things that are used often, like xp_file_delete, need to be documented.

    There are any number of functions in SQL Server that are undocumented. I have no idea how many there are because, well, they’re undocumented. I can’t see the source code, so I’m not sure what’s actually encoded in the platform.

    I’ve heard arguments that everything should be documented, and while I appreciate the sentiment that complete documentation is a good thing, I also understand the other side. Each item that is documented must be supporter, or at least supported in the lawsuit happy US. That means it must also be tested extensively and this means an increased load on the resources available for SQL Server. While I don’t want to see testing limited, or quicker releases of the platform, I do want everything well tested.

    There are some functions in the platform, such as some DBCC commands, that are added to help support. I can understand that testing, enhancing, and documenting these functions might not make sense. However I think there are some functions, which are used on a regular basis by millions of instances, and should be documented. For example, xp_delete_file is undocumented in Books Online, and a Connect item to provide documentation was closed as “by design”. However this function is called in maintenance plans, and has various bugs filed on cleanup issues and a lack of error reporting.

    Paul Randal has a good blog on why DBCC commands aren’t documented and it makes sense to me. I agree with the overall philosophy, but I would like to see those features that are used in normal operation of the platform completely documented.

    Steve Jones


    The Voice of the DBA Podcasts

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