Voice of the DBA

Category: Editorial

  • Scaling Out

    Scaling Out
    One way to scale out

    When I first heard about Service Broker coming in SQL Server 2005, I knew it would be slow to gain traction, and many people would not see the power of guaranteed messaging. However I thought over the next 3-4 years it would catch on as we companies looked to scale out their databases to multiple physical servers.

    That hasn’t really happened, and it seems Service Broker has not been widely adopted by many database developers. It surprises me since it seems like a fantastic way to move data between servers. I’m not sure if too many data professionals think a message means a substantial delay in the movement of data, or if they don’t trust the architecture, but there don’t seem to be many people using this feature in SQL Server.

    They should, however, and I saw a great writeup on scaling out SQL Server with Service Broker. It talks about ways in which you might think about improving your application’s performance, especially at larger scales, but implementing Service Broker as a part of your architecture. It has advantages over replication, and it makes sense to me that this could be an extremely flexible way to handle your peak loads.

    However it isn’t the solution to all problems. It has a steep learning curve, the tools have not advanced very far, and the documentation and descriptions can be confusing and incomplete. I had hoped that things would improve over time, but this feature seems to have been largely ignored. However Service Broker and messaging are great technologies, and I’d encourage you to spend some time learning about it, and look for places in your environment that it might solve scale problems.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Data Gravity

    gravity
    Does data have gravity? And will it affect DBAs’ jobs?

    Many of us have worked with distributed applications at this point in our careers, with different parts of the application located on different physical servers. Some of us might have worked with applications that actually have different servers in different locations, potentially even different countries. That can be challenging, dealing with different time zones, different collations and regional settings on servers and more.

    While many of us are not looking to implement cloud computing now, we may do so in the future, but not for simple cost reasons. There’s a piece about data gravity in the cloud, and how the law can drive the location of data in some cases. Just as many companies that wanted to offer gambling services moved to countries with fewer laws about that business, I would expect that we see some companies moving pieces and parts of their data to other countries to take advantage of more lax or lenient privacy or other laws in the future.

    Most companies won’t bother trying to avoid laws like this right now, but at some point in the future, the cost of moving an application to another country might be tiny. We constantly build better tools for distributed development, deployment, and management, and whether it’s a cloud infrastructure, or just a rented VM, we may find that it becomes worthwhile in some cases to move data, not just for cost reasons, but potentially to reduce the costs of compliance with local laws.

    It’s hard to know whether compliance with the law will ever significantly affect the work a DBA does, but I certainly expect that we will have distributed applications with their various components more widely distributed to challenge us in the future.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Code Scanning

    Code Review
    I think we need better tools for scanning code.

    When I started writing code, the applications I wrote for various companies would only receive manual code reviews from my peers, and then limited testing from a group of people that were usually bored and unchallenged in their jobs. More often than not, I’d be asked by people what to test, how the various parts of the application worked, and receive a basic double check on the tests I’d run, not any extensive analysis. I think a lot of people had, or even still have, a similar experience, which is one reason we have such poor security in many applications.

    These days I know there are much better tools for testing applications, and I have heard of black box scanning of static source code. I haven’t heard of too much real time scanning of the executable code by the authors of code, but I’m sure there are tools out there to help you find vulnerabilities. I saw recently there are even better tools for scanning code that combine both techniques into something being called glass-box scanning.

    Security is a problem in many applications, and it’s great to see more tools being put into place to help uncover issues before our customers do. I don’t know to what extent we are vulnerable in these ways at the database level, but I suspect that we do need better tools to help us comb through access logs, as well as double check permissioning for users and objects. When we do have security problems, they are usually large security problems because of the large amount of data that can be exposed inappropriately, yet we don’t have very mature tools and processes for monitoring and detecting problems.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • 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.