Dlaczego ta instrukcja MERGE powoduje zabicie sesji?

23

Mam poniższe MERGEoświadczenie wydane przeciwko bazie danych:

MERGE "MySchema"."Point" AS t
USING (
       SELECT "ObjectId", "PointName", z."Id" AS "LocationId", i."Id" AS "Region"
         FROM @p1 AS d
         JOIN "MySchema"."Region" AS i ON i."Name" = d."Region"
    LEFT JOIN "MySchema"."Location" AS z ON z."Name" = d."Location" AND z."Region" = i."Id"
       ) AS s
   ON s."ObjectId" = t."ObjectId"
 WHEN NOT MATCHED BY TARGET 
    THEN INSERT ("ObjectId", "Name", "LocationId", "Region") VALUES (s."ObjectId", s."PointName", s."LocationId", s."Region")
 WHEN MATCHED 
    THEN UPDATE 
     SET "Name" = s."PointName"
       , "LocationId" = s."LocationId"
       , "Region" = s."Region"
OUTPUT $action, inserted.*, deleted.*;

Jednak powoduje to zakończenie sesji z następującym błędem:

Wiadomość 0, poziom 11, stan 0, wiersz 67 Wystąpił poważny błąd w bieżącym poleceniu. Ewentualne wyniki należy odrzucić.

Wiadomość 0, poziom 20, stan 0, wiersz 67 Wystąpił poważny błąd w bieżącym poleceniu. Ewentualne wyniki należy odrzucić.

Złożyłem krótki skrypt testowy, który powoduje błąd:

USE master;
GO
IF DB_ID('TEST') IS NOT NULL
DROP DATABASE "TEST";
GO
CREATE DATABASE "TEST";
GO
USE "TEST";
GO

SET NOCOUNT ON;

IF SCHEMA_ID('MySchema') IS NULL
EXECUTE('CREATE SCHEMA "MySchema"');
GO

IF OBJECT_ID('MySchema.Region', 'U') IS NULL
CREATE TABLE "MySchema"."Region" (
"Id" TINYINT IDENTITY NOT NULL CONSTRAINT "PK_MySchema_Region" PRIMARY KEY,
"Name" VARCHAR(8) NOT NULL CONSTRAINT "UK_MySchema_Region" UNIQUE
);
GO

INSERT [MySchema].[Region] ([Name]) 
VALUES (N'A'), (N'B'), (N'C'), (N'D'), (N'E'), ( N'F'), (N'G');

IF OBJECT_ID('MySchema.Location', 'U') IS NULL
CREATE TABLE "MySchema"."Location" (
"Id" SMALLINT IDENTITY NOT NULL CONSTRAINT "PK_MySchema_Location" PRIMARY KEY,
"Region" TINYINT NOT NULL CONSTRAINT "FK_MySchema_Location_Region" FOREIGN KEY REFERENCES "MySchema"."Region" ("Id"),
"Name" VARCHAR(128) NOT NULL,
CONSTRAINT "UK_MySchema_Location" UNIQUE ("Region", "Name") 
);
GO

IF OBJECT_ID('MySchema.Point', 'U') IS NULL
CREATE TABLE "MySchema"."Point" (
"ObjectId" BIGINT NOT NULL CONSTRAINT "PK_MySchema_Point" PRIMARY KEY,
"Name" VARCHAR(64) NOT NULL,
"LocationId" SMALLINT NULL CONSTRAINT "FK_MySchema_Point_Location" FOREIGN KEY REFERENCES "MySchema"."Location"("Id"),
"Region" TINYINT NOT NULL CONSTRAINT "FK_MySchema_Point_Region" FOREIGN KEY REFERENCES "MySchema"."Region" ("Id"),
CONSTRAINT "UK_MySchema_Point" UNIQUE ("Name", "Region", "LocationId")
);
GO

-- CONTAINS HISTORIC Point DATA
IF OBJECT_ID('MySchema.PointHistory', 'U') IS NULL
CREATE TABLE "MySchema"."PointHistory" (
"Id" BIGINT IDENTITY NOT NULL CONSTRAINT "PK_MySchema_PointHistory" PRIMARY KEY,
"ObjectId" BIGINT NOT NULL,
"Name" VARCHAR(64) NOT NULL,
"LocationId" SMALLINT NULL,
"Region" TINYINT NOT NULL
);
GO

CREATE TYPE "MySchema"."PointTable" AS TABLE (
"ObjectId"      BIGINT          NOT NULL PRIMARY KEY,
"PointName"     VARCHAR(64)     NOT NULL,
"Location"      VARCHAR(16)     NULL,
"Region"        VARCHAR(8)      NOT NULL,
UNIQUE ("PointName", "Region", "Location")
);
GO

DECLARE @p1 "MySchema"."PointTable";

insert into @p1 values(10001769996,N'ABCDEFGH',N'N/A',N'E')

MERGE "MySchema"."Point" AS t
USING (
       SELECT "ObjectId", "PointName", z."Id" AS "LocationId", i."Id" AS "Region"
         FROM @p1 AS d
         JOIN "MySchema"."Region" AS i ON i."Name" = d."Region"
    LEFT JOIN "MySchema"."Location" AS z ON z."Name" = d."Location" AND z."Region" = i."Id"
       ) AS s
   ON s."ObjectId" = t."ObjectId"
 WHEN NOT MATCHED BY TARGET 
    THEN INSERT ("ObjectId", "Name", "LocationId", "Region") VALUES (s."ObjectId", s."PointName", s."LocationId", s."Region")
 WHEN MATCHED 
    THEN UPDATE 
     SET "Name" = s."PointName"
       , "LocationId" = s."LocationId"
       , "Region" = s."Region"
OUTPUT $action, inserted.*, deleted.*;

Jeśli usunę OUTPUTklauzulę, błąd nie wystąpi. Ponadto, jeśli usunę deletedodwołanie, błąd nie wystąpi. Przejrzałem więc dokumenty MSDN pod kątem OUTPUTklauzuli, która stwierdza:

USUWANEJ nie można używać z klauzulą ​​OUTPUT w instrukcji INSERT.

Ma to dla mnie sens, jednak chodzi o MERGEto, że możesz nie wiedzieć z góry.

Ponadto poniższy skrypt działa doskonale bez względu na podejmowane działanie:

USE tempdb;
GO
CREATE TABLE dbo.Target(EmployeeID int, EmployeeName varchar(10), 
     CONSTRAINT Target_PK PRIMARY KEY(EmployeeID));
CREATE TABLE dbo.Source(EmployeeID int, EmployeeName varchar(10), 
     CONSTRAINT Source_PK PRIMARY KEY(EmployeeID));
GO
INSERT dbo.Target(EmployeeID, EmployeeName) VALUES(100, 'Mary');
INSERT dbo.Target(EmployeeID, EmployeeName) VALUES(101, 'Sara');
INSERT dbo.Target(EmployeeID, EmployeeName) VALUES(102, 'Stefano');

GO
INSERT dbo.Source(EmployeeID, EmployeeName) Values(103, 'Bob');
INSERT dbo.Source(EmployeeID, EmployeeName) Values(104, 'Steve');
GO
-- MERGE statement with the join conditions specified correctly.
USE tempdb;
GO
BEGIN TRAN;
MERGE Target AS T
USING Source AS S
ON (T.EmployeeID = S.EmployeeID) 
WHEN NOT MATCHED BY TARGET AND S.EmployeeName LIKE 'S%' 
    THEN INSERT(EmployeeID, EmployeeName) VALUES(S.EmployeeID, S.EmployeeName)
WHEN MATCHED 
    THEN UPDATE SET T.EmployeeName = S.EmployeeName
WHEN NOT MATCHED BY SOURCE AND T.EmployeeName LIKE 'S%'
    THEN DELETE 
OUTPUT $action, inserted.*, deleted.*;
ROLLBACK TRAN;
GO

Mam też inne zapytania, które wykorzystują ten OUTPUTsam sposób, co ten, który zgłasza błąd i działają idealnie dobrze - jedyną różnicą między nimi są tabele, które biorą udział w MERGE.

To powoduje dla nas poważne problemy w produkcji. Odtworzyłem ten błąd w SQL2014 i SQL2016 zarówno na maszynie wirtualnej, jak i fizycznej z 128 GB pamięci RAM, 12 x 2,2 GHz w rdzeniu, Windows Server 2012 R2.

Szacowany plan wykonania wygenerowany na podstawie zapytania można znaleźć tutaj:

Szacowany plan wykonania

sql-server sql-server-2014 merge sql-server-2016 Mr.Brownstone
źródło
1
Czy zapytanie może wygenerować szacunkowy plan? ( Nie zaszkodzi to również wielu ludziom, ale i tak zalecam starą metodologię upsert - na przykład MERGEnie ma jej HOLDLOCK, więc nie jest odporna na warunki rasowe, a są jeszcze inne błędy, które należy rozważyć po rozwiązaniu - lub zgłoszeniu - wszystkiego, co powoduje ten problem.)
Aaron Bertrand
1
Daje zrzut stosu z naruszeniem dostępu. O ile widzę podczas odwijania stosu tutaj i.stack.imgur.com/f9aWa.png Powinieneś to podnieść za pomocą Microsoft PSS, jeśli powoduje to poważne problemy. Wydaje się, deleted.ObjectIdże właśnie to powoduje problem. OUTPUT $action, inserted.*, deleted.Name, deleted.LocationId, deleted.Regiondziała w porządku.
Martin Smith,
1
Zgadzam się z Martinem. W międzyczasie sprawdź, czy możesz uniknąć problemu, nieużywając tego MySchema.PointTabletypu, a po prostu używając VALUES()pustej klauzuli, tabeli #temp lub zmiennej tabeli wewnątrz USING. Może pomóc w wyodrębnieniu czynników przyczyniających się.
Aaron Bertrand
Dzięki za pomoc, próbowałem użyć tabeli tymczasowej i wystąpił ten sam błąd. Podniosę go przy wsparciu produktu - w międzyczasie przepisałem zapytanie, aby nie używać scalania, abyśmy mogli nadal działać.
Mr.Brownstone

Odpowiedzi:

20

To jest błąd.

Jest to związane ze MERGEspecyficznymi optymalizacjami do wypełniania dziur wykorzystywanymi w celu uniknięcia wyraźnej ochrony Halloween i wyeliminowania złączenia, a także ich interakcji z innymi funkcjami planu aktualizacji.

Szczegółowe informacje na temat tych optymalizacji znajdują się w moim artykule The Halloween Problem - Part 3 .

Podarunkiem jest Wstawka, a następnie Scalanie w tym samym stole :

Fragment planu

Obejścia

Istnieje kilka sposobów na pokonanie tej optymalizacji, więc unikaj błędu.

  1. Użyj nieudokumentowanej flagi śledzenia, aby wymusić wyraźną ochronę Halloween:

    OPTION (QUERYTRACEON 8692);

  2. Zmień ONklauzulę na:

    ON s."ObjectId" = t."ObjectId" + 0

  3. Zmień typ tabeli, PointTableaby zastąpić klucz podstawowy:

    ObjectID bigint NULL UNIQUE CLUSTERED CHECK (ObjectId IS NOT NULL)

    Część CHECKograniczenia jest opcjonalna, dołączona w celu zachowania oryginalnej właściwości odrzucania wartości zerowej klucza podstawowego.

„Proste” przetwarzanie zapytań o aktualizację (sprawdzenie klucza obcego, unikalne utrzymanie indeksu i kolumny wyjściowe) jest wystarczająco złożone, aby rozpocząć. Korzystanie MERGEdodaje do tego kilka dodatkowych warstw. W połączeniu z konkretną optymalizacją wspomnianą powyżej, masz świetny sposób na napotkanie takich błędów.

Jeszcze jeden do dodania do długiej linii zgłoszonych błędówMERGE .

Paul White mówi GoFundMonica
źródło