Sloučit prohlášení deadlocking sám

Nebyl by problém, pokud by proměnná tabulky obsahovala pouze jednu hodnotu. U více řádků existuje nová možnost zablokování. Předpokládejme, že dva souběžné procesy (A a B) probíhají s tabulkovými proměnnými obsahujícími (1, 2) a (2, 1) pro stejnou společnost.

Proces A přečte cíl, nenajde žádný řádek a vloží hodnotu '1'. Drží exkluzivní zámek řádku na hodnotě „1“. Proces B přečte cíl, nenajde žádný řádek a vloží hodnotu '2'. Drží exkluzivní zámek řádku na hodnotě „2“.

Nyní proces A musí zpracovat řádek 2 a proces B musí zpracovat řádek 1. Žádný proces nemůže dosáhnout pokroku, protože vyžaduje zámek, který je nekompatibilní s exkluzivním zámkem drženým jiným procesem.

Aby se zabránilo zablokování s více řádky, musí být řádky zpracovány (a přístup k tabulkám) ve stejném pořadí pokaždé. Proměnná tabulky v plánu provádění zobrazeném v otázce je halda, takže řádky nemají žádné vnitřní pořadí (je docela pravděpodobné, že budou čteny v pořadí vkládání, i když to není zaručeno):

Nedostatek konzistentního pořadí zpracování řádků vede přímo k možnosti zablokování. Druhým hlediskem je, že absence klíčové záruky jedinečnosti znamená, že stolní cívka je nezbytná pro zajištění správné ochrany Halloweenu. Cívka je dychtivá cívka, což znamená všechny řádky jsou zapsány do tempdb před opětovným načtením a přehráním pro operátora Insert.

Předefinování TYPE proměnné tabulky tak, aby zahrnovala seskupený PRIMARY KEY:

DROP TYPE dbo.CoUserData;

CREATE TYPE dbo.CoUserData
AS TABLE
(
    MyKey   integer NOT NULL PRIMARY KEY CLUSTERED,
    MyValue integer NOT NULL
);

Plán provádění nyní ukazuje skenování seskupeného indexu a záruka jedinečnosti znamená, že optimalizátor je schopen bezpečně odebrat zařazování tabulky:

V testech s 5000 iteracemi příkazu MERGE na 128 vláknech nedošlo k žádné zablokování s proměnnou seskupené tabulky. Měl bych zdůraznit, že je to pouze na základě pozorování; proměnná seskupené tabulky by také mohla ( technicky ) produkovat své řady v různých řádech, ale šance na konzistentní pořadí jsou velmi značně vylepšeny. Pozorované chování bude samozřejmě nutné znovu testovat pro každou novou kumulativní aktualizaci, aktualizaci Service Pack nebo novou verzi SQL Serveru.

V případě, že definici proměnné tabulky nelze změnit, existuje další alternativa:

MERGE dbo.CompanyUser AS R
USING 
    (SELECT DISTINCT MyKey, MyValue FROM @DataTable) AS NewData ON
    R.CompanyId = @CompanyID
    AND R.UserID = @UserID
    AND R.MyKey = NewData.MyKey
WHEN NOT MATCHED THEN 
    INSERT 
        (CompanyID, UserID, MyKey, MyValue) 
    VALUES
        (@CompanyID, @UserID, NewData.MyKey, NewData.MyValue)
OPTION (ORDER GROUP);

Tím se také dosáhne eliminace cívky (a konzistence řádků) za cenu zavedení explicitního druhu:

Tento plán také nevyprodukoval žádné slepé uličky pomocí stejného testu. Reprodukční skript níže:

CREATE TYPE dbo.CoUserData
AS TABLE
(
    MyKey   integer NOT NULL /* PRIMARY KEY */,
    MyValue integer NOT NULL
);
GO
CREATE TABLE dbo.Company
(
    CompanyID   integer NOT NULL

    CONSTRAINT PK_Company
        PRIMARY KEY (CompanyID)
);
GO
CREATE TABLE dbo.CompanyUser
(
    CompanyID   integer NOT NULL,
    UserID      integer NOT NULL,
    MyKey       integer NOT NULL,
    MyValue     integer NOT NULL

    CONSTRAINT PK_CompanyUser
        PRIMARY KEY CLUSTERED
            (CompanyID, UserID, MyKey),

    FOREIGN KEY (CompanyID)
        REFERENCES dbo.Company (CompanyID),
);
GO
CREATE NONCLUSTERED INDEX nc1
ON dbo.CompanyUser (CompanyID, UserID);
GO
INSERT dbo.Company (CompanyID) VALUES (1);
GO
DECLARE 
    @DataTable AS dbo.CoUserData,
    @CompanyID integer = 1,
    @UserID integer = 1;

INSERT @DataTable
SELECT TOP (10)
    V.MyKey,
    V.MyValue
FROM
(
    VALUES
        (1, 1),
        (2, 2),
        (3, 3),
        (4, 4),
        (5, 5),
        (6, 6),
        (7, 7),
        (8, 8),
        (9, 9)
) AS V (MyKey, MyValue)
ORDER BY NEWID();

BEGIN TRANSACTION;

    -- Test MERGE statement here

ROLLBACK TRANSACTION;

Myslím, že SQL_Kiwi poskytla velmi dobrou analýzu. Pokud potřebujete problém vyřešit v databázi, měli byste se řídit jeho návrhem. Samozřejmě je třeba znovu otestovat, že stále funguje pro vás pokaždé, když upgradujete, použijete aktualizaci Service Pack nebo přidáte/změníte index nebo indexované zobrazení.

Existují další tři alternativy:

1. Servery můžete serializovat tak, aby se nekolidovaly: na začátku transakce můžete vyvolat sp_getapplock a získat exkluzivní zámek před provedením MERGE. Samozřejmě to musíte ještě stresovat.

2. Všechny vložky můžete zpracovat jedním vláknem, takže váš aplikační server zpracovává souběžnost.

3. Můžete automaticky opakovat po zablokování - to může být nejpomalejší přístup, pokud je souběžnost vysoká.

Ať tak či onak, pouze vy můžete určit dopad vašeho řešení na výkon.

Obvykle v našem systému nemáme uváznutí na mrtvém bodě, i když máme pro ně velký potenciál. V roce 2011 jsme udělali chybu v jednom rozmístění a během několika hodin jsme měli několik desítek mrtvých míst, všichni sledovali stejný scénář. Brzy jsem to napravil a to byly všechny zablokování roku.

V našem systému většinou využíváme přístup 1. Funguje to pro nás opravdu dobře.