programming4us
         
 
 
SQL Server

SQL Server 2012 : T-SQL Enhancements - The MERGE Statement (part 2)

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
7/13/2013 7:43:58 PM

5. The WHEN NOT MATCHED BY SOURCE Clause

The third, and last, merge clause handles deletions, as shown here, followed by the required semicolon terminator:

WHEN NOT MATCHED BY SOURCE THEN
  DELETE;

The WHEN NOT MATCHED BY SOURCE clause serves as the exact reverse of WHEN NOT MATCHED BY TARGET and returns target (replica) rows not found in the source (original) table. This scenario would occur as the result of removing rows from the original table after they have been replicated. Rows removed from the original table need to be removed from the replica table as well, which is accomplished by the simple DELETE statement in this clause.

Regarding the use of multiple clauses, WHEN NOT MATCHED BY SOURCE has very same rules as WHEN MATCHED. You are permitted up to two WHEN NOT MATCHED BY SOURCE clauses. If you have two, the first one must be qualified with an AND condition. Furthermore, one clause must specify an UPDATE, and the other must specify a DELETE. If two WHEN NOT MATCHED BY SOURCE clauses are specified, MERGE will choose one of them to execute for any given row based on whether the AND condition evaluates to true.

Let’s get started with some data. Both tables are empty at this point (which does in fact mean that they are already in sync). Start by filling the original table with a few rows, as shown here:

INSERT Original VALUES(1, 'Sara', 10)
INSERT Original VALUES(2, 'Steven', 20)

Now call the uspSyncReplica stored procedure to bring the replica table up to date. The first time you call the stored procedure, only the WHEN NOT MATCHED clause will execute. It will execute twice, actually, once for each of the two rows to be added to replica table from the original table. The rows affected count displayed after running the stored procedure conveys this, as shown here:

EXEC uspSyncReplica
GO

(2 row(s) affected)

Examining both tables now verifies that the replica is synchronized with the original, as shown here:

SELECT * FROM Original
SELECT * FROM Replica
GO

PK          FName      Number
----------- ---------- -----------
1           Sara       10
2           Steven     20

(2 row(s) affected)

PK          FName      Number
----------- ---------- -----------
1           Sara       10
2           Steven     20

(2 row(s) affected)

Now perform some more changes to the original table. A mix of insert, update, and delete operations brings the two tables out of sync again:

INSERT INTO Original VALUES(3, 'Andrew', 100)
UPDATE Original SET FName = 'Stephen', Number += 10 WHERE PK = 2
DELETE FROM Original WHERE PK = 1
GO

SELECT * FROM Original
SELECT * FROM Replica
GO

PK          FName      Number
----------- ---------- -----------
2           Stephen    30
3           Andrew     100

(2 row(s) affected)

PK          FName      Number
----------- ---------- -----------
1           Sara       10
2           Steven     20

(2 row(s) affected)

Invoking the stored procedure once again brings the two tables back in sync by replicating changes from the original table to the replica, as follows:

EXEC uspSyncReplica
GO

(3 row(s) affected)

This time, you can see that three rows were affected as the result of one insert (Andrew), one update (Stephen), and one delete (Sara). Examining both tables verifies that the replica is once again synchronized with the original, as shown here:

SELECT * FROM Original
SELECT * FROM Replica
GO

PK          FName      Number
----------- ---------- -----------
2           Stephen    30
3           Andrew     100

(2 row(s) affected)

PK          FName      Number
----------- ---------- -----------
2           Stephen    30
3           Andrew     100

(2 row(s) affected)

6. MERGE Output

The MERGE statement supports the same OUTPUT clause introduced in SQL Server 2005 for the INSERT, UPDATE, and DELETE statements. This clause returns change information from each row affected by DML operations in the same INSERTED and DELETED pseudo-tables exposed by triggers. Being able to capture this information in the OUTPUT clause is often a better choice than capturing it in triggers, because triggers introduce nondeterministic behavior—that is, you cannot guarantee that multiple triggers on the same table will consistently fire in the same order every time. (This is often the cause of subtle bugs that can be very difficult to track down, and thus triggers should generally be avoided when possible.)

In addition to the columns of the INSERTED and DELETED pseudo-table, another virtual column named $action is supported when OUTPUT is used with the MERGE statement. The $action column will return one of the three string values—‘INSERT’, ‘UPDATE’, or ‘DELETE’—depending on the action taken for each row. Example 4 shows a slightly modified version of the uspSyncReplica stored procedure that includes an OUTPUT clause on the MERGE statement. The OUTPUT clause selects the virtual $action column and all the columns of the INSERTED and DELETED pseudo-tables so that the MERGE statement can provide a detailed report of every DML operation it performs. If you have been following along with the steps for the previous version, you’ll need to drop everything (the tables and the stored procedure) first. Then, substitute the implementation of the stored procedure in Example 3 with the code shown in Example 4 and repeat the same steps.

Example 2-19. Using the OUTPUT clause and $action virtual column with MERGE.

CREATE PROCEDURE uspSyncReplica AS

 MERGE Replica AS R
  USING Original AS O ON O.PK = R.PK
  WHEN MATCHED AND (O.FName != R.FName OR O.Number != R.Number) THEN
    UPDATE SET R.FName = O.FName, R.Number = O.Number
  WHEN NOT MATCHED THEN
    INSERT VALUES(O.PK, O.FName, O.Number)
  WHEN NOT MATCHED BY SOURCE THEN
    DELETE
 OUTPUT $action, INSERTED.*, DELETED.*;

Running this modified version of the MERGE statement for the last set of changes in the replication example produces the following output:

$action PK    FName   Number PK    FName   Number
------- ----- ------- ------ ----- ------- ------
DELETE  NULL  NULL    NULL   1     Sara    10
UPDATE  2     Stephen 30     2     Steven  20
INSERT  3     Andrew  100    NULL  NULL    NULL

(3 row(s) affected)

This output shows all the actions taken by the merge and all the before-and-after data involved. Of course, you can use OUTPUT…INTO instead of just OUTPUT like you can with the INSERT, UPDATE, and DELETE statements to send this information to another table for history logging or additional processing. And concluding our treatment of MERGE, you’ll learn about the INSERT OVER DML syntax introduced in SQL Server 2008 that provides even greater flexibility.

7. Choosing a Join Method

SQL Server is very smart about examining MERGE statements, analyzing different combinations of merge clauses, and automatically performing the appropriate type of join to return the source and target data needed on both sides of the operation. There are four types of joins, and SQL Server cleverly picks the right one for the job based on the merge clauses that it finds in the MERGE statement, as shown in Table 1.

Table 1. Source-to-target table join types chosen by SQL Server based on your merge clause(s)

Merge clause

Join type

Returns

Valid actions

WHEN MATCHED

Inner

Matching data in both source and target

Update, delete

WHEN NOT MATCHED [BY TARGET]

Left outer

Source data not found in target

Insert

WHEN NOT MATCHED BY SOURCE

Right outer

Target data not found in source

Update, delete

WHEN NOT MATCHED [BY TARGET] combined with any other clause

Full outer

Source data not found in target, and other matching or nonmatching target data

Insert, update, delete

The WHEN MATCHED clause returns rows that are found in both tables (that is, rows in both tables with matching values in the joining key columns defined with ON). The query processor treats this as an inner join, because you are retrieving only rows that exist on both sides. Either an UPDATE or a DELETE operation on matching target rows is permitted in the WHEN MATCHED clause.

WHEN NOT MATCHED [BY TARGET] is treated as a left outer join, because it retrieves only source rows that do not exist in the target. Therefore, only an INSERT can be performed in the WHEN NOT MATCHED [BY TARGET] clause to “fill the hole” in the target with the missing source data.

The WHEN NOT MATCHED BY SOURCE clause is the complement to WHEN NOT MATCHED [BY TARGET] and results in a right outer join to retrieve only target rows that do not exist in the source. As with WHEN MATCHED, you can perform an UPDATE or a DELETE operation on those target rows missing from the source.

Last, combining WHEN NOT MATCHED [BY TARGET] with either or both of the other two clauses retrieves source data not found in the target as well as target data found or not found in the source. In this case, a full outer join is performed between the two tables. You can perform an INSERT in the WHEN NOT MATCHED [BY TARGET] clause to add source data missing from the target and an UPDATE or DELETE in the other clause(s) to modify or remove target data.

Important

The only valid statement in WHEN MATCHED or WHEN NOT MATCHED BY SOURCE is UPDATE or DELETE, and the only valid statement in WHEN NOT MATCHED [BY TARGET] is INSERT. No other T-SQL statements (including stored procedure calls) are allowed in any of these merge clauses. However, the INSERT and UPDATE statements in a merge clause are permitted to reference user-defined functions.

8. MERGE DML Behavior

As you’ve just learned, the MERGE statement combines the four separate DML statements (SELECT, INSERT, UPDATE, and DELETE) involved in a merge operation. The actual internal implementation of MERGE is the same as the distinct DML statements it encapsulates. This was a good call by Microsoft, because it means that developers can begin using MERGE right away to leverage its improved performance and lower maintenance benefits, without concern for breaking any existing code.

All AFTER and INSTEAD OF triggers that have already been defined in existing tables or updateable views continue to fire when those tables or updateable views are designated as the target of a MERGE statement. For example, the WHEN NOT MATCHED THEN…INSERT clause fires any insert triggers defined for the target; similarly, the WHEN MATCHED THEN…DELETE clause fires delete triggers. There is no concept of a “merge trigger,” so it’s safe for you to immediately start using MERGE in your T-SQL code. Triggers will fire just the same as if you used separate statements instead of MERGE. Existing business logic, constraints, and rules all continue to function as they did before.

The same options and features you are accustomed to using with the separate DML statements are also available with MERGE. For example, you can use a CTE for the source of a merge by defining it using the WITH clause before the MERGE statement and then referencing it with the USING clause. The TOP clause is similarly supported, as are traditional query hints. And of course, both source and target tables can be aliased with AS just like tables in regular queries can.

You can see how SQL Server internally implements the MERGE statement for the stored procedure that handles table replication by examining the database engine’s query execution plan, shown in Figure 1.

Query plan for a MERGE operation to synchronize a replica with an original (screen image has been cropped to fit the printed page).

Figure 1. Query plan for a MERGE operation to synchronize a replica with an original (screen image has been cropped to fit the printed page).

The work begins by scanning the source and target table (query plans are read from right to left). At the right of Figure 1, you can see the advantage of having created indexes on the columns joining the Original and Replica tables for the merge. Because the join predicate uses the primary keys of both tables, the query optimizer uses a clustered index scan for the best possible read performance. You should therefore always create an index (possibly clustered and ideally unique) on the joined columns used for merging two tables.

The plan also reveals that a full outer join is performed between the two tables, as shown in the center of Figure 1. As mentioned earlier, the type of join used depends on which WHEN…THEN merge clauses are (or aren’t) specified in the MERGE statement. In this case, SQL Server performs a full outer join because the MERGE statement uses all three of the possible merge clauses. The clustered index merge operation that follows (at the left of Figure 1) implements the predicate on the first merge clause that selects matching rows only if any of the nonkey columns have changed between the original and replica tables.

The clustered index merge consumes the stream delivered by the full outer join and decides on a row-by-row basis whether the row being passed to this operation should be processed as an update, an insert, or a delete, based on the syntax of the MERGE statement and the data in the source and target tables.

Other -----------------
- Configuring SQL Server 2008 : Memory configuration (part 2) - Setting minimum and maximum memory values
- Configuring SQL Server 2008 : Memory configuration (part 1) - 32-bit memory management
- SQL server 2012 : T-SQL Enhancements - Date and Time Data Types (part 2) - Date and Time Functions
- SQL server 2012 : T-SQL Enhancements - Date and Time Data Types (part 1) - Date and Time Accuracy, Storage, and Format
- SQL server 2012 : T-SQL Enhancements - Table-Valued Parameters (part 2)
- SQL server 2012 : T-SQL Enhancements - Table-Valued Parameters (part 1)
- SQL Server 2008 R2 : Database Files and Filegroups (part 2)
- SQL Server 2008 R2 : Database Files and Filegroups (part 1)
- Installing SQL Server 2012 : The Installation Process (part 4) - Post Installation Tasks
- Installing SQL Server 2012 : The Installation Process (part 3) - Installing SQL Server 2012 Through the Command Line, Installing SQL Server 2012 Through PowerShell
- Installing SQL Server 2012 : The Installation Process (part 2) - Installing SQL Server 2012 Through the Installation Center
- Installing SQL Server 2012 : The Installation Process (part 1) - SQL Server 2012 Installation Center
- Installing SQL Server 2012 : Preparing the Server, Selecting the Edition
- SQL Server 2012 : SQL Server Architecture - SQL SERVER’S EXECUTION MODEL AND THE SQLOS
- SQL Server 2012 : SQL Server Architecture - THE LIFE CYCLE OF A QUERY (part 3) - A Simple Update Query
- SQL Server 2012 : SQL Server Architecture - THE LIFE CYCLE OF A QUERY (part 2) - Plan Cache
- SQL Server 2012 : SQL Server Architecture - THE LIFE CYCLE OF A QUERY (part 1)
- Protecting SQL Server Data : CELL-LEVEL ENCRYPTION - Views and Stored Procedures (part 2) - Creating the Stored Procedures
- Protecting SQL Server Data : CELL-LEVEL ENCRYPTION - Views and Stored Procedures (part 1) - Creating the View
- Protecting SQL Server Data : Implementing Cell-Level Encryption
 
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.