Ist diese gespeicherte Prozedur, thread-safe? (oder wie auch immer die entspr ist auf SQL-Server)

Mit Hilfe anderer, ALSO habe ich geklopft, bis ein paar Tabellen und Gespeicherten Prozeduren an diesem morgen, da bin ich weit von einem DB-Programmierer.

Wäre jemand Verstand casting ein Auge auf und sagt mir, ob es thread-safe? Ich denke, das ist wohl nicht der Begriff DBAs/DB-Entwickler verwenden, aber ich hoffe, Sie bekommen die Idee: im Grunde, was passiert, wenn dieses sp ausführt, und ein anderer kommt zusammen zur gleichen Zeit? Könnte einen stören die anderen? Ist dies auch ein Problem in SQL/SPs?

CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
    @ticketNumber int OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    INSERT INTO [TEST_Db42].[dbo].[TicketNumber]
               ([CreatedDateTime], [CreatedBy])
         VALUES
                (GETDATE(), SUSER_SNAME())
    SELECT @ticketNumber = IDENT_CURRENT('[dbo].[TicketNumber]');
    RETURN 0;
END

Ich Stimme völlig mit gbn Antwort, möchte aber noch hinzufügen, dass können Sie einfach herausfinden, sich selbst - Sie können nur das ausführen der gespeicherten Prozedur, die gleichzeitig von zwei oder mehr verbindungen in einer Schleife mnay mal (>1mln), und sehen Sie selbst.

InformationsquelleAutor serialhobbyist | 2009-09-27

17

Werden Sie wahrscheinlich nicht wollen, um mit IDENT_CURRENT - dies gibt die Letzte Identität, die auf dem Tisch in Frage, in einer Sitzung oder einem Gültigkeitsbereich. Wenn jemand anderes hat eine insert-zur falschen Zeit erhalten Sie Ihre id anstelle!

Wenn Sie wollen, um die Identität erzeugt, die durch das einfügen, dass Sie nur durchgeführt, dann ist es am besten, um die AUSGABE - Klausel, um es abzurufen. Früher war es üblich, dass die SCOPE_IDENTITY() für diese, aber es gibt Probleme mit, dass Sie unter parallele Ausführung von Plänen.

Den wichtigsten SQL-entspricht der thread-Sicherheit ist, wenn mehrere Anweisungen ausgeführt werden, dass es zu unerwarteten oder unerwünschten Verhalten. Die beiden wichtigsten Arten von Verhalten, die ich denken kann, sind sperren (insbesondere deadlocks) und Parallelität Probleme.

Locking-Probleme, die auftreten, wenn eine Anweisung hält andere Aussagen aus dem Zugriff auf die Zeilen mit dem es arbeitet. Dies kann die Leistung beeinträchtigen und im schlimmsten Fall zwei Aussagen, die änderungen vornehmen, die nicht in Einklang gebracht werden und ein deadlock Auftritt, verursacht eine Anweisung beendet werden.

Jedoch eine einfache einfügen wie die, die Sie haben, sollte nicht dazu führen, sperrt, es sei denn, etwas anderes beteiligt ist (wie Datenbanktransaktionen).

Concurrency-Probleme (Beschreibung sehr schlecht) werden verursacht durch eine Reihe von änderungen an der Datenbank-Datensätzen überschreiben andere änderungen an denselben Datensätzen. Auch das sollte kein problem sein, wenn das einfügen eines Datensatzes.
- +1 für die Empfehlung SCOPE_IDENTITY
- -1 für die Empfehlung SCOPE_IDENTITY; support.microsoft.com/kb/2019779. Y ' all sein sollte, mithilfe der OUTPUT-Klausel in allen Fällen.
- vielen Dank - habe ich behoben. Hatte nicht gehört, des Problems vor. Haben Sie zufällig wissen, Wann es entdeckt wurde?
- In der Veröffentlichung von SQL Server 2005 ist, wenn Sie eingeführt OUTPUT. Ich werde zurückziehen, mein downvote und bieten ein upvote 🙂
InformationsquelleAutor David Hall

Den sichersten Weg zu gehen, hier wäre wahrscheinlich die Verwendung der Output-Klausel, da gibt es einen bekannten bug in scope_idendity unter bestimmten Umständen ( multi-parallel-processing ).

CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
AS
BEGIN
  DECLARE @NewID INT

  BEGIN TRANSACTION
  BEGIN TRY
    declare @ttIdTable TABLE (ID INT)
    INSERT INTO 
      [dbo].[TicketNumber]([CreatedDateTime], [CreatedBy])
    output inserted.id into @ttIdTable(ID)
    VALUES
      (GETDATE(), SUSER_SNAME())

    SET @NewID = (SELECT id FROM @ttIdTable)

    COMMIT TRANSACTION
  END TRY
  BEGIN CATCH
    ROLLBACK TRANSACTION
    SET @NewID = -1
  END CATCH

  RETURN @NewID
END

Diese Weise sollten Sie thread-sicher, da die output-Klausel verwendet die Daten, dass der Einsatz tatsächlich fügt, und Sie werden keine Probleme haben, über Bereiche oder Sitzungen.

Link zur MSKB scope_identity: support.microsoft.com/default.aspx?scid=kb;en-US;2019779

InformationsquelleAutor druzin

CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
    @NewID int OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRY
        BEGIN TRANSACTION
        INSERT INTO 
            [dbo].[TicketNumber] ([CreatedDateTime], [CreatedBy])
        VALUES
            (GETDATE(), SUSER_SNAME())

        SET @NewID = SCOPE_IDENTITY()

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF XACT_STATE() <> 0
            ROLLBACK TRANSACTION;
        SET @NewID = NULL;
    END CATCH
END

Würde ich nicht verwenden GEGENZUG für die sinnvolle Verwendung von Daten: entweder recordset-oder output-parameter. ZURÜCKKEHREN würden, die normalerweise verwendet werden, für die Fehler-Zustände (wie system stored procs in den meisten Fällen):

EXEC @rtn = EXEC dbo.uspFoo
IF @rtn <> 0
    --do error stuff

Sie können auch die OUTPUT-Klausel zur Rückgabe einer Datensatzgruppe statt.

Dies ist "thread-safe", d.h. es können gleichzeitig ausgeführt werden.

InformationsquelleAutor gbn

1

First off, warum nimmst du nicht einfach die Rückkehr der neuen ticket-Nummer statt der 0 die ganze Zeit? Irgendein besonderer Grund dafür?

Zweitens, um absolut sicher zu sein, sollten Sie wickeln Sie Ihre INSERT-und SELECT-Anweisung in einer TRANSAKTION, so dass nichts von außen eingreifen kann.

Drittens, mit SQL Server 2005 und höher, würd ich wickle meine Anweisungen in einen TRY....CATCH-block und für die Transaktion ein Rollback, wenn es fehlschlägt.

Als Nächstes würde ich versuchen zu vermeiden, die Angabe der Datenbank-server (TestDB42) in meinem Verfahren Wann immer möglich - was ist, wenn Sie bereitstellen möchten, der proc auf einen neuen server (TestDB43) ??

Und zu guter Letzt, würde ich nie ein SET NOCOUNT in einer gespeicherten Prozedur - es kann dazu führen, die der Anrufer irrtümlicherweise denken, die gespeicherte Prozedur fehlgeschlagen ist (siehe mein Kommentar zu gbn unten - dies ist ein potenzielles problem, wenn Sie mit ADO.NET SqlDataAdapter-Objekte; siehe die MSDN docs auf, wie dies zu ändern ADO.NET Daten mit SqlDataAdapter für weitere Erläuterungen).

Also mein Vorschlag für deine gespeicherte Prozedur wäre:
```
CREATE PROCEDURE [dbo].[usp_NewTicketNumber]
AS
BEGIN
  DECLARE @NewID INT

  BEGIN TRANSACTION
  BEGIN TRY
    INSERT INTO 
      [dbo].[TicketNumber]([CreatedDateTime], [CreatedBy])
    VALUES
      (GETDATE(), SUSER_SNAME())

    SET @NewID = SCOPE_IDENTITY()

    COMMIT TRANSACTION
  END TRY
  BEGIN CATCH
    ROLLBACK TRANSACTION
    SET @NewID = -1
  END CATCH

  RETURN @NewID
END
```
Marc
- Sie würde nie die Verwendung von SET NOCOUNT ON? Wirklich?
- Gut, wenn Sie mit ADO.NET's DataAdapter, mit SET NOCOUNT ON kann die Ursache für den DataAdapter irrtümlicherweise denken, eine gespeicherte Prozedur fehlgeschlagen, da es interpretiert den Rückgabewert als die "betroffenen Zeilen" zählen - und wenn es 0 (in dem Fall von SET NOCOUNT ON), dann wird der DataAdapter interpretiert, als "gespeicherte Prozedur fehlgeschlagen".
- Dieser Artikel ist 8 Jahre alt, so vielleicht gilt für v1.0 dot net. Ich habe nicht gesehen, dass dieser Fehler seit Jahren: ich würde davon ausgehen, es wurde jetzt repariert...
- gbn: dieses Verhalten scheint noch immer zu gelten - das ist aus der .NET 3.5 docs: msdn.microsoft.com/en-us/library/59x02y99.aspx
- Microsoft sagt ausdrücklich nicht verwenden das SET NOCOUNT ON in stored procs, wenn du diese mit ADO.NET SqlDataAdapters.
- ja, es sah. stackoverflow.com/questions/1483732/set-nocount-on-usage
- Pflege ich einige SP ' s gibt, die von klassischen ADO(COM/C++) & ADO.NET SqlDataAdapters & dieser Konflikt verursacht mir mögliche Probleme - hat sonst noch jemand dieses Problem & haben Sie es gelöst noch?
- -1 für die Empfehlung SCOPE_IDENTITY; support.microsoft.com/kb/2019779. Dies geplagt hat mein team diese Woche, so nutzen wir jetzt die AUSGABE in allen Fällen. Ich empfehle es empfiehlt Microsoft Sie. Ich dachte nie, es würde die Materie ewig.
InformationsquelleAutor marc_s
1

Ich Stimme mit David Hall ' s Antwort, ich möchte nur erweitern ein wenig, warum ident_current ist absolut die falsche Sache zu verwenden, in dieser situation.

Hatten wir einen Entwickler hier, der es benutzte. Der Einsatz von der client-Anwendung geschah in der gleichen Zeit wurde die Datenbank importieren von Millionen von Datensätzen über einen automatisierten import. Die id zurückgegeben, um ihn von einem der Datensätze mein Prozess importiert. Er verwendet diese id, um das erstellen von Datensätzen für einige untergeordnete Tabellen, die waren jetzt an der falschen Datensatz. Schlimmer noch wir haben jetzt keine Ahnung, wie oft dies geschah, bevor jemand konnte Sie nicht finden die Informationen, die sollten schon in den child-Tabellen (seine änderungen wurden auf prod für mehrere Monate). Nicht nur meine automatisierten import haben, mischte sich mit seinem code, aber einem anderen Benutzer einfügen eines Datensatzes an der gleichen Zeit hätte das gleiche getan. Ident_current sollte nie verwendet werden, um wieder die Identität von einem Datensatz nur eingefügt, wie es beschränkt sich nicht auf den Prozess, der ihn aufruft.
- Das ist genau die Art von Sache, die ich versuche zu vermeiden, also danke sehr viel für das hinzufügen es.
InformationsquelleAutor HLGEM

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.