Author: way0utwest

  • Waiting for SP1

    SQL Server 2012
    Is SQL Server 2012 stable enough for you?

    One of the classic tenets in upgrading Microsoft technology seems to be that it’s safer to wait for Service Pack 1 (SP1) before committing to the next version of any platform. There have been people asking if you will upgrade Windows, wait for Dynamics, and more. Last week I saw a blog from Gethryn Ellis that asked if his readers were waiting for SQL Server 2012 SP1.

    I’ve had times when Service Packs that installed smoothly and essentially had no impact on production systems, and I’ve had times when the installation blue screened my test systems. During the latter times I was extremely glad I’d decided to test the SP and not blindly install it on a production system. That is one of the things that worries me about cloud computing. I need to be sure that patches work on my systems.

    This Friday, however, I wanted to take the temperature of the community regarding the latest version of SQL Server. I am not wondering if you are upgrading, or if you have plans to upgrade to SQL Server 2012. Instead, I wanted to ask you this:

    Do you feel SQL Server 2012 RTM is stable enough to install on your production servers?

    I assume you’ll test it, but assuming it works with your application, assuming that cost is not an issue, is the codebase stable enough for you?

    I don’t have any plans to upgrade SQLServerCentral anytime soon. We upgraded last year and not many of the new features will actually make a difference to our application. Licensing is also an issue as we run Standard Edition, and the cost to move to Enterprise Edition s prohibitive. As much as I’d like to implement AlwaysOn in production, it will have to be limited to test systems for me.

    However if cost weren’t an issue, and resources were available, I’d upgrade. I think SQL Server has been getting more and more solid with every release, and I think SQL Server 2012 is as stable as any of the other recent releases. Let us know today if you feel the same way.

    Steve Jones


    The Voice of the DBA Podcasts

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

  • Ownership Chains in SQL Server

    Someone asked the question recently about allowing a user to run a process,but not execute the individual pieces of the process. I replied that ownership chains allow this, and then explained things. Here’s a short example of that.

    Let’s suppose I have a process that removes data from a table and then reloads it. Perhaps it’s a report, perhaps it’s a static look at inventory, it doesn’t matter. Can I allow a normal user to execute the entire process, but not the clear or load pieces?

    I can, and here’s how.

    Suppose I have a clear procedure:

    CREATE PROCEDURE dbo.spClear
    AS
    BEGIN
       select 'Clear'
    END
    go

    For the sake of this example, I don’t have any work here, but the "SELECTClear"’” could be replaced by a TRUNCATE TABLE or other statement.

    By default in SQL Server, I don’t have rights to execute procedures that I haven’t created. In this case, assume a db_owner created this procedure, so a normal user, Joe, would not be able to execute it. In fact, if I log in as Joe and run this, I get:

    SETUSER 'Joe' 
    go
    -- Fails
    EXEC spClear
    go
    

    Msg 229, Level 14, State 5, Procedure spClear, Line 1

    The EXECUTE permission was denied on the object ‘spClear’, database ‘db1’, schema ‘dbo’.

     

    That’s expected, and it’s good.

    Let’s also create a load procedure, as the db_owner.

    CREATE PROCEDURE dbo.spLoad
    as
    BEGIN
       select 'Load'
    END
    go

    Now to manage the process, let’s create a wrapper stored procedure that calls these. For the sake of tracking what’s happening, I have a few statements in there.

    CREATE PROCEDURE dbo.spRefresh
    AS
    BEGIN
       select 'Refresh start'
       EXEC spClear
       EXEC spLoad
       SELECT 'Refresh End'
    END
    go

    If I were to call this process, this is what I’d expect from the call stack:

    • a call spRefresh
    • a result set returning “Refresh Start’”
    • a call to spClear
    • a result set returning “Clear”
    • return to spRefresh
    • a call to spLoad
    • a result set returning “Load”
    • a return to spRefresh
    • a result set returning “Refresh End”
    • end of spRefresh

    Obviously I could have actual delete or truncates in the clear procedure and then some insert in the load procedure. If I attempt to run this as Joe, I get:

    Msg 229, Level 14, State 5, Procedure spRefresh, Line 1

    The EXECUTE permission was denied on the object ‘spRefresh’, database ‘db1’, schema ‘dbo’.

    Expected, because I haven’t granted Joe rights. Let’s do that and execute the procedure:

    GRANT EXECUTE ON dbo.spRefresh TO Joe
    go
    SETUSER 'Joe' 
    GO
    EXEC spRefresh

    I get what I expected for results:

    ownership_a

    I have rights to execute spRefresh. Since the same owner exists for all three objects, dbo in this case, I have a chain that permissions are not checked for spLoad and spClear. I can execute them in the context of spRefresh.

    What about separately?

    EXEC spLoad

    gets me:

    Msg 229, Level 14, State 5, Procedure spLoad, Line 1

    The EXECUTE permission was denied on the object ‘spLoad’, database ‘db1’, schema ‘dbo’.

    and

    EXEC spClear

    gets me

    Msg 229, Level 14, State 5, Procedure spClear, Line 1

    The EXECUTE permission was denied on the object ‘spClear’, database ‘db1’, schema ‘dbo’.

    A nice way to allow someone to execute a group of processes without allowing them to execute any individual one.

  • An Azure Outage

    SQL Azure
    Azure was down recently

    There was a Windows Azure outage on Feb 29, which resulted in the management service being down for about 8 hours. The actual virtual machines that most customers had were unaffected, but the ability to perform management functions was down for a number of customers.

    That’s distressing for customers, and embarrassing for Microsoft, who is spending a lot of resources to promote cloud computing and their Azure services. It lends credence to the fears and concerns of many technology professionals that outsourcing parts of their infrastructure to a cloud provider is a problem.

    However is it a big problem? I’ve had outages in nearly every company I’ve worked, often because of problems in the architectures that are built by those same IT people that disparage the cloud. I’ve found that a few outages were from vendor patches, a few from failures, and a good portion were stupid mistakes, often from a lack of testing. We worked hard to fix things, but we often weren’t able to give management much more of an idea when things would be working than a good status page for Azure would provide.

    It’s easy to disparage outsourced services as less reliable than in-house services, but I’m not sure that’s true. There is definitely a loss of control, but that comes at a cost savings, and the balance between them is something that each company needs to decide. However I think lots of management might prefer in-house infrastructure for a simple reason: it gives them a specific neck to choke, and possibly replace, when things go wrong.

    Steve Jones


    The Voice of the DBA Podcasts

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

  • The Consistency Debate

    How consistent do your systems really need to be?

    One of the questions I constantly see asked about on SQLServerCentral is how can you scale out the database. How can you easily keep multiple copes if your data in sync with one another on different servers, and allow clients to read from any of those servers. The Always On features in SQL Server 2012 will allow readable secondaries, something that wasn’t possible in database mirroring, giving you up to date reads of your data, which is in sync with your primary database.

    However is that really necessary for many applications? The largest applications in the world, Google’s search engine, Facebook, and more, are turning to NoSQL databases and storage to handle their loads. I ran across a nice piece on Ars Technica that talks about how these companies handle the large data storage challenges they have. The one very interesting thing in the piece is the way the consistency challenges are talked about. These phrases, “designed with less concern for consistency of data across the system”, “jobs in progress will still hit stale data”, and “(it) is entirely okay with serving up stale data”, would scare most DBAs I know.

    But should they? For some applications, it is important that we maintain consistency across nodes. The classic bank account example requires that a withdrawal and a deposit between accounts are totally committed or rolled back to ensure the proper balances. However that doesn’t mean that every node in the banking system knows your balance. Only those times when a transaction affects the balance, do we need to be sure of the actual value. Deposits are sometimes not reflected immediately on another node, say a remote ATM. Withdrawals are sometimes approved, even with modern checking machines, when there are insufficient funds, resulting in bounced checks.

    In many of our applications, we are told we need consistency, but I think that’s a goal. It’s like 100% uptime, which is rarely met, and almost never funded. Think about a report. A User might run the report, assuming that the data is accurate, and it may be, but 14ms later it might not be because of changes. If the report had been run 14ms earlier, it might have missed other changes. Most people understand that, even if they are asking for consistent behavior of the system.

    With that in mind, should we be looking for more distributed architectures in our applications? I think that replication and service broker, both excellent techniques for scaling out, should become a more regular tool for our applications, and should receive more attention in future versions of SQL Server. We are only acquiring more and more data, and while hardware continues to get more powerful, we are outpacing the developments in storage bandwidth. We should start thinking about how to anticipate future challenges in application load, not reacting to them later.

    Steve Jones


    The Voice of the DBA Podcasts

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