Erstellen PK für die #temp-Tabelle ist fehlgeschlagen, wenn das Skript ausgeführt wird, parallel

Ich habe den folgenden code in eine gespeicherte Prozedur.

....
select ... into #temp from ....
alter table #temp add constraint PK_mytemp13 primary key (....)
....

Und ich bekomme folgende Fehlermeldung von Zeit zu Zeit, wenn die gespeicherte Prozedur ausgeführt wird, parallel.

Es ist bereits ein Objekt mit dem Namen 'PK_perf322dsf" in der Datenbank.
Es konnte keine Einschränkung. Finden Sie in Vorherige Fehlern.

Ich denke, es kann vermieden werden, indem die folgenden Ansätze. Gibt es eine andere elegantere Lösung?

  1. Erstellen Sie eine temporäre Tabelle mit primary key-ersten. Dann die Zeilen einfügen.
    create table #temp (... primary key (....))
  2. Erstellen PK dynamisch mit session-id dynamisch.
    declare @s varchar(500) = 'alter table #temp add constraint PK_temp' + @@spid + ' primary key (....)

InformationsquelleAutor ca9163d9 | 2012-01-16

  1. 3
    1. Sie versuchen, einfügen, um die gleichen temporäre Tabelle aus verschiedenen verbindungen (was unmöglich ist, statt Globale temporäre Tabellen),
    2. oder Sie versuchen, einfügen in verschiedenen Tabellen.

    wenn 2. - Sie können sich einfach Folgendes tun - ALTER TABLE #temp ADD PRIMARY KEY(...)

    wenn 1. Sie haben, um die Tabelle zu erstellen (regelmäßig oder Globale temporäre) mit Schlüssel vor der Verwendung in parallelen Operationen

    Dieser Fehler hat damit zu tun, erstellen Sie eine lokale temporäre Tabelle, so dass eine benannte primäre Schlüssel in einem code-block und mit mehr als 1 Verbindung aufrufen, die code-block. SQL Server erlaubt keine 2 PKs mit dem gleichen Namen, auch in lokale temporäre Tabellen.

    InformationsquelleAutor Oleg Dok

  2. 11

    Dies kann nur geschehen, wenn die gleiche client-Verbindung Instanziierung (das entspricht einer SPID oder die Verbindung in SQL Server) wird erneut für 2 verschiedene Anrufe. Zwei parallele Anrufe sollten andere Verbindung Instanziierungen und separate SPIDs

    SPIDs sind vollkommen getrennt von einander mit lokalen (einzelne #temp-Tabellen)

    Edit:

    Ignorieren über

    Habe ich noch nie benannte Einschränkungen auf temp-Tabellen vor. Ich Indizes verwenden, wie ich Sie brauche oder einfach nur add PRIMARY KEY, nachdem die Spalte. Constraint-Namen sind Datenbank-einzigartig in sys.Objekte

    PK ist im Grunde eines nicht eindeutigen gruppierten index. So verwenden CREATE UNIQUE CLUSTERED INDEX stattdessen als index-Namen sind einzigartig pro Tabelle in sys.Indizes.

    Dieser schlägt fehl, wenn die Ausführung im 2 SSMS-Abfrage windows

    CREATE TABLE #gbn (foo int NOT NULL);
ALTER TABLE #gbn ADD CONSTRAINT PK_gbn PRIMARY KEY (foo);

    Msg 2714, Ebene 16, Status 5, Zeile 2

    Es ist bereits ein Objekt mit dem Namen 'PK_gbn" in der Datenbank.

    Msg 1750, Ebene 16, Status 0, Zeile 2

    Es konnte keine Einschränkung. Finden Sie in Vorherige Fehlern.

    Neugierig, die Fehler und die constraint-Namen entsprechen, im Gegensatz zu Ihrem Fehler

    Dies funktioniert

    CREATE TABLE #gbn (foo int NOT NULL);
CREATE UNIQUE CLUSTERED INDEX PK_gbn ON #gbn (foo);
    aus dem Fehler, den constraint-name wird ignoriert. Wenn ich mich Recht erinnere, als ich erstellte Indizes (nicht PKs wohlgemerkt) auf temporäre Tabellen dann viel Unterstrichen und einige hex Hinzugefügt wird. Ich hatte noch nie eine Parallelität problem. Ich würde vorschlagen, der Fehler ist nicht um temp-table-handling
    benannte Einschränkungen noch mit einem eindeutigen Namen in tempdb wie Sie sind einzigartig in sys.objects. Genannten Indizes müssen nicht sein. Tatsächlich ist die OP soll wohl nur mit einem eindeutigen index oder einem unamed Einschränkung. (Edit: Sehe was du meinst, über die Fehlermeldung, obwohl...)
    Gerade verifiziert. Siehe update. Ich habe nie gedacht, über die Verwendung von benannten constraints auf temporären Tabellen. Immer auf persistente Tabellen, obwohl

    InformationsquelleAutor gbn

  3. 9

    Ich war versucht sich zu erinnern, wie Sie dies tun, aber Sie können erstellen Sie eine namenlose primary key auf eine temp-Tabelle und vermeiden Sie diese Fehler. Dies ist anders, als das eine Spalte-level-PK, denn es unterstützt mehr als 1 Spalte. Hier ist ein Beispiel:

    CREATE TABLE #test
(
  AccountNumber INT NOT NULL,
  TransactionNumber INT NOT NULL,
  PRIMARY KEY CLUSTERED (tranid, sys_process_dt)
);

    Dies ermöglicht dem end-Ziel plus verhindert name Vervielfältigung. Die Abfrage wird angezeigt, dass SQL Server eine GUID in den Namen der PK für Sie in sys.der sysobjects-Tabelle:

    SELECT *
FROM tempdb.sys.sysobjects
WHERE name LIKE '%#test%'

    name | xtype

    --------------------------------

    #test___..._000000000407 | U

    PK__#test_____B88A05A770B3A6A6 | PK

    Können Sie Ihren Kuchen haben und ihn auch Essen.

    InformationsquelleAutor CDC

  4. 1

    Ich weiß, das beantwortet wurde und akzeptiert, aber noch nicht sehen, den richtigen Punkt wurde rufen.

    beim erstellen von Benannten Einschränkung, name der Einschränkung hat, um genau zu sein am Tisch Niveau. Sie stammen aus dem Bereich auf der Datenbank-Ebene. also entweder erstellen Sie nicht namens gebunden und können sql pick eigenem Namen oder, wenn Sie Namen geben stellen Sie sicher, es s einzigartig, DB. auch für die TEMP-DB.

    InformationsquelleAutor Anup Shah

Schreibe einen Kommentar