Author: way0utwest

  • Database Mirroring is Back in Azure SQL Database

    Database mirroring was a cool feature in SQL Server 2005. I guess it’s still a feature, though it’s listed as deprecated in the documentation. There is still a mirroring dialog in the SSMS database properties dialog in more recent versions of SQL Server, but I don’t know if there is a good reason to use mirroring over Availability Groups.

    That’s why I was surprised to see a public preview announcement of Azure SQL Database Mirroring to Microsoft Fabric announcement. Apparently you can easily move Azure SQL Database data to Fabric and have it written to Delta Parquet tables in OneLake. No ETL, no need to do the data conversion yourself, or at least not much of an effort. I suspect you still need to understand this and do some configuration for how your Parquet files will get written.

    If you go through the documentation, it’s interesting (and annoying) to me that the docs keep saying replication. I hate when we’ve overloaded terms as mirroring and replication mean specific things in SQL Server, so I wish they would use some other term (copy, extract, ??) to describe what is happening.

    Whether this is useful to analytic workloads remains to be seen. I am curious what the people working with Fabric think of this feature. I wonder if this is useful, or if this might cause headaches or performance issues. Since this feature is in preview, I doubt anyone knows yet, but it will be interesting to see how this compares with Synapse Link and if it is more or less helpful.

    Moving data around for different purposes has always been a challenge. I know that some people might feel the costs involved in this aren’t worth it. I know a lot of technical people that would say “I could do that.” I have no idea what they costs are. but I know that a lot of people have spent a lot of hours managing ETL packages and adjusting them as schemas change and new requirements appear. I get the appeal of Synapse Link and this new Mirroring to Fabric features.

    I do wish this type of feature was more solidly built into the SQL Server instance. I suspect it will come at some point, and it’s being tested and baked in Azure first. However, I hope that if/when it comes, that the feature has good tooling and some polish to its operation. We’ve had too many features in SQL Server that are partially built, with limited tooling, and a lack of performance characteristics that many of us would desire.

    Steve Jones

  • The Journey to Change

    I assume most of you reading this work with SQL Server, at least for some of your workday. I know there are plenty of you who also support Oracle, MySQL, PostgreSQL, or some other database platform. The results in our (Redgate’s) State of Database Landscape report showed that many organizations, indeed most, have more than one database platform in production.

    This was also a theme in our Data Community Summit and Redgate Summit keynotes, where Ryan and Grant discussed their journey to learn a new platform (PostgreSQL). One, a requirement (Ryan) for a new job, and another, an opportunity (Grant) as the company focus shifted. I assume some of you out there have had similar experiences either moving towards, or away from, SQL Server.

    I ran across a breaking up with SQL Server post from David Alcock, noting that his job had evolved from SQL Server to AWS, GCP, PostgreSQL, Python, and more. The author got tired of database work, had an opportunity to learn about new areas, and got excited while doing so. That’s similar to my career, where I did a lot of networking and administration work early in my career but saw an opportunity in databases (and financial rewards), so I worked to change. I enjoyed the new tech and built a great career. I wish David good luck on his journey.

    For many of us, there is regular tension between gaining deeper knowledge and more expertise or broadening the variety of skills we have. We have to decide where we spend our time as time is a limited resource. Hopefully, we realize that improving our skills in some way is a good use of our time and are doing something. Anything is better than nothing.

    At the same time, we need to find some balance and realize there are other demands on our time outside of work. Family, friends, hobbies, faith, all of these need some time for a healthy, balanced life. We might need to lean on our current skills and expertise at times, not investing in ourselves, but it shouldn’t be our long-term strategy. As I’ve said in a few presentations, evaluate your growth every quarter. You might take a few quarters off from learning but don’t take off a year. Or not multiple years. Invest in your skills regularly.

    There are often rewards for improving our skills. These might be a raise, better choice of projects, better employment, or maybe even the spark to build your own business. It takes work, but I’ve not often found the time I spent was wasted. Even if I learn skills I don’t use or enjoy, I learn something about myself that helps me better direct my future career.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • A New Word: 1202

    1202– n. the tipping point when your brain becomes so overwhelmed with tasks you need to do, you feel too guilty to put anything off until later, prioritizing every little thing at the top of the list, leaving you immobilized.

    Not quite a word, but still a fun concept. Do you get so overwhelmed you prioritize everything on the list? Are you immobilized?

    I don’t and I’m not. I don’t get 1202.

    I go get overwhelmed, but I still can add things to my list, or lists. Things to learn, things to fix, etc. Often, however, I’m not immobilized here, even if I prioritize some things. What I might do if I’m overwhelmed is either buckle down and do one thing, or give up and do something completely different.

    FWIW, this comes from the lunar descent of Apollo 11 where the 1202 alarm was the one the computer set off when there was too much data to process.

    From the Dictionary of Obscure Sorrows

  • The Basics of TRY CATCH Blocks–#SQLNewBlogger

    I was working with a customer and discussing how to do error handling. This is a short post that looks at how you can start adding TRY.. CATCH blocks to your code.

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    TRY CATCH

    This is a common error handling technique in other languages. C# uses it, as does Java, while Python has TRY EXCEPT. There are other examples, but these are good habits to get into when you don’t know how code will behave or if there is something in your data or environment that could cause an issue.

    In SQL, I think many of us get used to writing one statement in a query and forget to do error handling, or transactions. However, this can be a good habit as your code might grow and people might add more statements that should execute.

    A classic example of code is someone writing this:

    DECLARE
       @id INT = 2
    , @name VARCHAR(20) = 'Voice od the DBA'
    , @stat INT = 1;
    BEGIN TRAN;
    INSERT dbo.Customer
       (CustomerID, CustomerName, status)
    VALUES
       (@id, @name, @stat);
    IF @@ERROR = 0
       COMMIT;
    ELSE
       ROLLBACK;
    
    

    Note that this does look for an error and then decide what to do. However, we could be better, especially if we wanted to possibly add a second insert or other work. We could do this:

    DECLARE
       @id INT = 2
    , @name VARCHAR(20) = 'Voice od the DBA'
    , @stat INT = 1;
    BEGIN TRY
         BEGIN TRAN;
         INSERT dbo.Customer
         (CustomerID, CustomerName, status)
         VALUES
         (@id, @name, @stat);
         COMMIT
    END TRY
    BEGIN CATCH
         ROLLBACK 
    END CATCH
    
    

    It doesn’t look like much, but this code could easily be enhanced with a better pattern. We can capture the various error messages like this:

    DECLARE
       @id INT = 2
    , @name VARCHAR(20) = 'Voice od the DBA'
    , @stat INT = 1;
    BEGIN TRY
         BEGIN TRAN;
         INSERT dbo.Customer
         (CustomerID, CustomerName, status)
         VALUES
         (@id, @name, @stat);
         COMMIT
    END TRY
    BEGIN CATCH
        DECLARE @ErrorMessage NVARCHAR(4000);
        DECLARE @ErrorSeverity INT;
        DECLARE @ErrorState INT;
    
        SELECT 
            @ErrorMessage = ERROR_MESSAGE(),
            @ErrorSeverity = ERROR_SEVERITY(),
            @ErrorState = ERROR_STATE();
    
        RAISERROR (@ErrorMessage, -- Message text.
                   @ErrorSeverity, -- Severity.
                   @ErrorState -- State.
                   );
    
        WHILE @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRANSACTION;
        END 
    END CATCH
    
    

    In this case, we have a few statements that work with the error, in this case using RAISERROR to raise this. We could also use THROW or add something else. If we had more inserts, like to a child table, we could encapsulate them all here. What’s more, if we had logging, we could log this before the rollback to another system if our logging were not transaction dependent.

    Using TRY CATCH is really just structuring your code differently. Ideally, using something a snippet in SQL Prompt so your developers have an easy way to standardize error handling.

    SQL New Blogger

    This post took me about 15 minutes to structure and test. I looked at a few patterns, and I liked the one in this Stack Overflow answer as a good way to generically implement this structure.

    You could write a similar post showing your next boss how you implement error handling, transactions, anything. Give it a try.