Deadlock error MERGE

  • I have a step that produces the xml and the MERGE table 1 insert and update, if you run it once

    from the application to operate normally but if you run several times simultaneously

    application from a session ends well and the rest with deadlocks.

    The procedure is inside a TRANSACTION from source code, used EF5.0 and Sql 2014 SP1 CU1.

    The procedure is as follows:

    ALTER PROCEDURE [dbo].[procedure]

    @var1 int,

    @var2 xml,

    @var3 int

    AS

    BEGIN

    SET NOCOUNT ON

    MERGE TABLA AS destino

    USING(

    SELECT

    CampoTabla1 = @var1,

    CampoTabla2 = T.Item.value ('@V', 'char(2)')

    FROM @var2.nodes('/L/I') AS T(Item)

    )AS origen ON

    origen.Campo1 = destino.Campo1 AND

    origen.Campo2 = destino.Campo2

    WHEN MATCHED THEN

    UPDATE SET

    destino.Campo3 = @var3,

    destino.Campo4 = 0

    WHEN NOT MATCHED BY SOURCE AND

    destino.Campo1 = @var1

    AND destino.Campo3 = 0 THEN

    UPDATE SET

    destino.Campo3 = @var3,

    destino.Campo4 = GETDATE()

    WHEN NOT MATCHED THEN

    INSERT

    (Campo1,

    Campo2,

    Campo3,

    Campo4,

    Campo5)

    VALUES

    (origen.Campo1,

    origen.Campo2,

    @var3,

    GETDATE(),

    0);

    END

    I modified the MAXDOP parameter of the instance but still the same error.

    THE BBDD was read commited snapshot.

    The level of parallelism is at 0 (Unlimited)

    The MAXDOP is at 8, since the machine has more than 8 cores.

    How can I fix it, something happens to them.

    Greetings.

  • I'd suggest that you try adding a merge hint to your MERGE. Start with HOLDLOCK and test ... moving up to TABLOCK if necessary.

    You should also take steps to ensure that the MERGE is performing as optimally as possible.

    The absence of evidence is not evidence of absence
    - Martin Rees
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

  • MERGE is a widely known deadlock generator: https://www.mssqltips.com/sqlservertip/3074/use-caution-with-sql-servers-merge-statement/

    -- Gianluca Sartori

  • According to the page that is attached is a known bug, I have seen that there is a hotfix that you can apply

    but the version table only shows up to 201 SQL, I have a sql 2014 with SP1 CU1.

    This procedure was before in a SQL 2008R2 SP2 CU1 engine and not failed or not we had

    produced the error, the application is the same.

    Can you think of any solution to avoid having to modify the procedure.

    I only put one example, but with this extructura have 2000 Procedures.

  • You're not running the latest build for SQL 2014. You're missing SP2 and CU1. Maybe the fix you're referring to is included in one of those.

    I would test in a test environment to see if applying SP2 and CU1 help.

    -- Gianluca Sartori

  • You may want to incorporate deadlock handling into your code, perhaps using something like the following snippet I wrote to handle deadlock processing in one of our procedures:

    -- The following snippet is for building deadlock handling.

    declare @ErrorNumber int,

    @ErrorLine int,

    @ErrorMessage nvarchar(4000),

    @ErrorProcedure nvarchar(128),

    @ErrorSeverity int,

    @ErrorState int;

    while 1 = 1

    begin

    begin transaction;

    begin try;

    -- <-- code goes here -->

    commit;

    break;

    end try

    begin catch

    rollback;

    select

    @ErrorNumber = ERROR_NUMBER(),

    @ErrorLine = ERROR_LINE(),

    @ErrorMessage = ERROR_MESSAGE(),

    @ErrorProcedure = ERROR_PROCEDURE(),

    @ErrorSeverity = ERROR_SEVERITY(),

    @ErrorState = ERROR_STATE();

    if @ErrorNumber = 1205 -- Trap deadlock

    begin

    WAITFOR DELAY '00:00:00.05' -- Wait for 50 ms

    continue;

    end

    else begin

    -- All other errors

    raiserror(@ErrorMessage,@ErrorSeverity,@ErrorState);

    end

    end catch

    end

  • I tested with tests and test HOLDLOCK With ... moving up to TABLOCK, but the error is still playing.

    This occurs when multiple concurrent users try to update.

  • I set up a test environment with S2 CU1 patch level and gives the same error, deadlock.

  • javirsantos (9/30/2016)


    I set up a test environment with S2 CU1 patch level and gives the same error, deadlock.

    There's a strong relationship between transaction duration and deadlock occurrence. Speeding up your transaction will reduce the likelihood of a deadlock.

    Check that the permanent table has an index which will support the update, and consider resolving the xml into a #temp table or @table variable as a separate step.

    Posting an actual (as opposed to estimated) execution plan as a .sqlplan attachment will assist folks in tuning the query.

    “Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

  • The XML file I have gotten into a @xml and #XML and the deadlock is still playing.

  • javirsantos (10/5/2016)


    The XML file I have gotten into a @xml and #XML and the deadlock is still playing.

    The next step would be to post an execution plan here, as a .sqlplan attachment.

    “Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

  • Also, could you also post the deadlock graph?

  • If I add a CTE in Procedure no longer fails, but I need to find a solution to avoid having to modify 1200 Procedures.

  • Adjunto el deadlock graph

  • Key lookups can cause deadlocks. An execution plan, and some table and index definitions would be good.

    Catch-all queries done right [/url]
    Gail Shaw's Performance Blog[/url]

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply