Loading...

MERGE T-SQL for Dedicated SQL pools is now GA!

MERGE T-SQL for Dedicated SQL pools is now GA!

We are thrilled to announce that the MERGE T-SQL command for Azure Synapse Dedicated SQL pools is now Generally Available! MERGE has been a highly requested addition to the Synapse T-SQL library that encapsulates INSERTs/UPDATEs/DELETEs into a single statement, drastically easing migrations and making table synchronization a breeze.

 

MERGE_visual.gif

 

A key scenario common to many data warehousing workloads is updating Slowly Changing Dimension tables. Previously, in Synapse Dedicated SQL pools, one table could only be synced with another through manual INSERT / UPDATE / DELETE operations. In addition, migrations from other codebases required a breakdown of each individual MERGE statement into these comprising commands, making the transition less than optimal.

 

Today, users of Azure Synapse can leverage the all-encompassing MERGE T-SQL statement to make the most out of their data processing operations. Let’s take a look at an example below to demonstrate the power and simplicity of MERGE.

 

Syncing HackneyLicense of the New York Taxicab dataset with new data

 

In this example, we’ll be using the New York Taxicab dataset, which you can load following this tutorial. In particular, we will show how MERGE can help sync our current working dimension table HackneyLicense with data from our daily refresh of the table (we call HackneyLicenseNew, a new table I have created based on HackneyLicense).

 

Emily_Tehrani_1-1663785399229.png

 

The above shows how our modified HackneyLicenseNew compares to the original dimension table. All records up to ID 42954 are the same, but beyond that we have a few differences:

  1. Record with ID 42955 in HackneyLicenseNew has different Key and Code values than HackneyLicense. Perhaps the Key and Code was incorrectly inserted in our original dimension table.
  2. HackneyLicenseNew has two new records for IDs 42959 and 42960. This means we have 2 new Taxi license IDs to begin tracking in Prod.
  3. HackneyLicenseNew is missing rows for IDs 42956, 42957, and 42958. The Taxi licenses for these IDs may have expired, and we need to update our records.

We need to modify HackneyLicense (our working “Target” table) based on the new data in HackneyLicense (our “Source”). In most scenarios, I won’t know the exact differences between the Target and Source, and have to use LEFT OUTER JOINs, INNER JOINs, or other subqueries to identify the differences and sync our Target. With MERGE, we no longer need to manually specify that logic:

 

MERGE mergeDemo.HackneyLicense AS Target USING mergeDemo.HackneyLicenseNew AS Source ON Source.HackneyLicenseID = Target.HackneyLicenseID -- Updates: For shared IDs, update Key and Code in Target with Source values WHEN MATCHED AND Source.HackneyLicenseBKey <> Target.HackneyLicenseBKey AND Source.HackneyLicenseCode <> Target.HackneyLicenseCode THEN UPDATE SET Target.HackneyLicenseBKey = Source.HackneyLicenseBKey, Target.HackneyLicenseCode = Source.HackneyLicenseCode -- Inserts: Source has 2 new licenses we need to begin tracking WHEN NOT MATCHED BY Target THEN INSERT (HackneyLicenseID, HackneyLicenseBKey, HackneyLicenseCode) VALUES (Source.HackneyLicenseID, Source.HackneyLicenseBKey, Source.HackneyLicenseCode) -- Deletes: Target has 3 IDs that Source doesn't have WHEN NOT MATCHED BY Source THEN DELETE OPTION ( LABEL = 'MERGE test - Update 1, Insert 2, Delete 3)' ); GO

 

First, we set our Production table HackneyLicense as the Target and HackneyLicenseNew as the Source, and join on the ‘HackneyLicenseID’ column to begin comparing.

 

On Line 5, we use the ‘WHEN MATCHED’ clause to find cases where Target and Source have matching IDs, then update our Target’s Key and Code columns to the values of Source. We also chose to purposely filter on cases where the Key and Code columns differ, to avoid extra work (but we could have also omitted this filter).

 

On Line 12, we use the ‘WHEN NOT MATCHED [BY Target]’ clause to find cases where IDs exist in Source, but don’t match to anything in Target. In this case, we choose to INSERT those rows from Source into Target.

 

Lastly, on Line 16, we use the ‘WHEN NOT MATCHED BY SOURCE’ clause to find cases where IDs exist in Target, but don’t match to anything in Source. This means we want to remove those records from Target, so we execute a DELETE statement on Target.

 

Emily_Tehrani_0-1664214217198.png

 

Now we look at the tailend of HackneyLicense and HackneyLicenseProd again. Without using a left outer join or writing even one subquery, we’ve effectively synced our Target working table based on the state of a Source table – all within a single, maintainable statement. Simplifying migrations onto Synapse and improving code readability, we hope you give the powerful MERGE statement a try.

 

To ensure you are using the official GA-supported version of MERGE, check that the `@@version` of your Synapse Dedicated SQL pool is on '10.0.17829.0' or beyond. To learn more about the MERGE statement in Synapse Dedicated SQL pools, check out MERGE (Transact-SQL).

Published on:

Learn more
Azure Synapse Analytics Blog articles
Azure Synapse Analytics Blog articles

Azure Synapse Analytics Blog articles

Share post:

Related posts

We're moving!

We’re moving to the Analytics on Azure Tech Community! All new Azure Synapse Analytics content will be published there. In the next few days a...

1 year ago

Upgrade to Azure Synapse runtimes for Apache Spark 3.4 & previous runtimes deprecation

It is important to stay ahead of the curve and keep services up to date. That's why we encourage all Azure Synapse customers with Apache ...

2 years ago

ADF\Synapse Analytics - Replace Columns names using Rule based mapping in Mapping data flows

In real time, the column names from source might not be uniform, some columns will have a space in it, some other columns will not. For exampl...

2 years ago

Interpreting Script activity output json with Azure Data Factory\Synapse analytics

Script activity in Azure Data Factory\ Synapse analytics is very helpful to run queries against data sources mentioned here in this document.&...

2 years ago

Synapse Connectivity Series Part #4 - Advanced network troubleshooting and network trace analysis

Continuing the series of this blog posts I would like to go more advanced on troubleshooting connectivity issues. I would like to thank also&n...

2 years ago

Boost your CICD automation for Synapse SQL Serverless by taking advantage of SSDT and SqlPackage CLI

Introduction   Azure Synapse Analytics Serverless SQL is a query service mostly used over the data in your data lake, for data discovery,...

2 years ago

Metadata-Based Ingestion in Synapse with Delta Lake

  Overview     The crucial first step in any ETL (extract, transform, load) process or data engineering program is ingestion, w...

3 years ago

Missing Fields Added to Dedicated SQL pool Diagnostic Settings Logs

Over the past year, customers have informed the team there were a set of key columns missing in the standalone Dedicated SQL pools (formerly S...

3 years ago

Using Azure DevOps with Synapse Workspaces to create hot fixes in production environments

Have you ever deployed a release to production only to find out a bug has escaped your testing process and now users are being severely impact...

3 years ago

Azure Synapse MVP Corner - March 2023

About this blog series Microsoft Most Valuable Professionals, or MVPs, are technology experts who passionately share their knowledge with the ...

3 years ago

Newsletter

Get the latest Dynamics 365 and Power Platform content in your inbox

A curated digest of community blogs, product news, videos, and podcasts — delivered without the noise.

Weekly updates Unsubscribe anytime Fresh community picks
We use your email only for the newsletter and you can unsubscribe at any time.
By subscribing, you agree to the privacy policy.