Transaktionen mit speicheroptimierten TabellenTransactions with Memory-Optimized Tables

Gilt für: JaSQL Server JaAzure SQL-Datenbank NeinAzure Synapse Analytics (SQL DW) NeinParallel Data Warehouse APPLIES TO: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

In diesem Artikel werden alle Aspekte von Transaktionen beschrieben, die für speicheroptimierte Tabellen und nativ kompilierte gespeicherte Prozeduren spezifisch sind.This article describes all the aspects of transactions that are specific to memory-optimized tables and natively compiled stored procedures.

Die Transaktionsisolationsstufen in SQL Server werden auf speicheroptimierte Tabellen anders angewendet als auf datenträgerbasierte Tabellen, und zudem sind die zugrunde liegenden Mechanismen verschieden.The transaction isolation levels in SQL Server apply differently to memory-optimized tables versus disk-based tables, and the underlying mechanisms are different. Ein Überblick über die Unterschiede kann Programmierern dabei helfen, ein System mit hohem Durchsatz zu entwerfen.An understanding of the differences helps the programmer design a high throughput system. Das Ziel der Transaktionsintegrität wird in allen Fällen geteilt.The goal of transaction integrity is shared in all cases.

Informationen zu Fehlerbedingungen, die für Transaktionen in speicheroptimierten Tabellen spezifisch sind, finden Sie im Abschnitt Konflikterkennung und Wiederholungslogik.For error conditions specific to transactions on memory-optimized tables, jump to the section Conflict Detection and Retry Logic.

Allgemeine Informationen finden Sie unter SET TRANSACTION ISOLATION LEVEL (Transact-SQL).For general information, see SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

Pessimistisch und optimistischPessimistic versus Optimistic

Die funktionalen Unterschiede ergeben sich aufgrund von pessimistischen und optimistischen Ansätzen hinsichtlich der Transaktionsintegrität.The functional differences are due to pessimistic versus optimistic approaches to transaction integrity. Speicheroptimierte Tabellen verwenden den optimistischen Ansatz:Memory-optimized tables use the optimistic approach:

  • Der pessimistische Ansatz verwendet Sperren, um mögliche Konflikte zu blockieren, bevor sie auftreten.Pessimistic approach uses locks to block potential conflicts before they occur. Die Sperre tritt in Kraft, wenn die Anweisung ausgeführt wird, und wird aufgehoben, wenn der Transaktionscommit ausgeführt wird.Lock are taken when the statement is executed, and released when the transaction is committed.

  • Der optimistische Ansatz erkennt Konflikte, während sie auftreten, und führt Validierungsüberprüfungen zur Commitzeit durch.Optimistic approach detects conflicts as they occur, and performs validation checks at commit time.

    • Für eine speicheroptimierte Tabelle darf der Fehler 1205, ein Deadlock, nicht auftreten.Error 1205, a deadlock, cannot occur for a memory-optimized table.

Der optimistische Ansatz bedeutet weniger Aufwand und ist in der Regel effizienter, da Transaktionskonflikte in den meisten Anwendungen selten auftreten.The optimistic approach is less overhead and is usually more efficient, partly because transaction conflicts are uncommon in most applications. Der wichtigste funktionale Unterschied zwischen dem pessimistischen und dem optimistischen Ansatz ist folgender: Wenn ein Konflikt auftritt, wird beim pessimistischen Ansatz einfach gewartet. Beim optimistischen Ansatz dagegen tritt bei einer der Transaktionen ein Fehler auf, und die Transaktion muss vom Client wiederholt werden.The main functional difference between the pessimistic and optimistic approaches is that if a conflict occurs, in the pessimistic approach you wait, while in the optimistic approach one of the transactions fails and needs to be retried by the client. Die funktionalen Unterschiede sind größer, wenn die Isolationsstufe REPEATABLE READ aktiv ist, und sie sind für die Stufe SERIALIZABLE am größten.The functional differences are bigger when the REPEATABLE READ isolation level is in force, and are biggest for the SERIALIZABLE level.

TransaktionseinleitungsmodiTransaction Initiation Modes

SQL Server verfügt über die folgenden Modi für den Start einer Transaktion:SQL Server has the following modes for transaction initiation:

  • Autocommit : Das Starten einer einfachen Abfrage oder DML-Anweisung öffnet eine Transaktion implizit, und das Ende der Anweisung führt den Commit für die Transaktion implizit aus.Autocommit - The start of a simple query or DML statement implicitly opens a transaction, and the end of the statement implicitly commits the transaction. Autocommit ist als Standardeinstellung ausgewählt.Autocommit is the default.

    • Im Autocommitmodus muss ein Tabellenhinweis zur Transaktionsisolationsstufe für die speicheroptimierte Tabelle in der FROM-Klausel in der Regel nicht codiert werden.In autocommit mode, usually you are not required to code a table hint about the transaction isolation level on the memory-optimized table in the FROM clause.
  • Explizit : Ihr Transact-SQL enthält den Code BEGIN TRANSACTION zusammen mit einem eventuellen COMMIT TRANSACTION.Explicit - Your Transact-SQL contains the code BEGIN TRANSACTION, along with an eventual COMMIT TRANSACTION. Mindestens zwei Anweisungen können in eine Transaktion integriert werden.Two or more statements can be corralled into the same transaction.

    • Im expliziten Modus müssen Sie entweder die Datenbankoption MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT verwenden oder einen Tabellenhinweis zur Transaktionsisolationsstufe in der speicheroptimierten Tabelle in die FROM-Klausel schreiben.In explicit mode, you must either use the database option MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT or code a table hint about the transaction isolation level on the memory-optimized table in the FROM clause.
  • Implizit : Wenn SET IMPLICIT_TRANSACTION ON aktiv ist.Implicit - When SET IMPLICIT_TRANSACTION ON is in force. Ein besserer Name wäre wahrscheinlich IMPLICIT_BEGIN_TRANSACTION gewesen, da diese Option lediglich das Äquivalent einer expliziten BEGIN TRANSACTION vor jeder UPDATE-Anweisung implizit ausführt, wenn „ 0 = @@trancount“ gilt.Perhaps a better name would have been IMPLICIT_BEGIN_TRANSACTION, because all this option does is implicitly perform the equivalent of an explicit BEGIN TRANSACTION before each UPDATE statement if 0 = @@trancount. Daher muss Ihr T-SQL-Code ggf. ein explizites COMMIT TRANSACTION ausgeben.Therefore it is up to your T-SQL code to eventually issue an explicit COMMIT TRANSACTION.

  • ATOMIC BLOCK (ATOMISCHER BLOCK): Sämtliche Anweisungen in den ATOMISCHEN Blöcken werden immer als Teil einer einzelnen Transaktion durchgeführt.ATOMIC BLOCK - All statements in ATOMIC blocks always run as part of a single transaction. Entweder werden für alle Aktionen eines atomischen Blocks erfolgreiche Commits ausgeführt, oder es wird, wenn ein Fehler auftritt, ein Rollback für alle Aktionen durchgeführt.Either the actions of the atomic block as a whole are committed on success, or the actions are all rolled back when a failure occurs. Jede nativ kompilierte gespeicherte Prozedur erfordert einen ATOMISCHEN Block.Each natively compiled stored procedure requires an ATOMIC block.

Codebeispiel im Explicit-ModusCode Example with Explicit Mode

Das folgende interpretierte Transact-SQL-Skript verwendet Folgendes:The following interpreted Transact-SQL script uses:

  • Eine explizite Transaktion.An explicit transaction.
  • Eine speicheroptimierte Tabelle namens „dbo.Order_mo“.A memory-optimized table, named dbo.Order_mo.
  • Den Kontext der Transaktionsisolationsstufe READ COMMITTED.The READ COMMITTED transaction isolation level context.

Aus diesem Grund ist es erforderlich, einen Tabellenhinweis auf die speicheroptimierte Tabelle zu verwenden.Therefore it is necessary to have a table hint on the memory-optimized table. Der Hinweis muss für SNAPSHOT oder eine stärker isolierende Stufe erfolgen.The hint must be for SNAPSHOT or an even more isolating level. Für dieses Codebeispiel lautet der Hinweis WITH (SNAPSHOT).In the case of the code example, the hint is WITH (SNAPSHOT). Wenn dieser Hinweis entfernt wird, würde für das Skript Fehler 41368 auftreten, für den eine automatische Wiederholung unangemessen wäre:If this hint is removed, the script would suffer an error 41368, for which an automated retry would be inappropriate:

Fehler 41368Error 41368

Der Zugriff auf speicheroptimierte Tabellen mit der READ COMMITTED-Isolationsstufe wird nur für Autocommittransaktionen unterstützt.Accessing memory optimized tables using the READ COMMITTED isolation level is supported only for autocommit transactions. Er wird nicht für explizite oder implizite Transaktionen unterstützt.It is not supported for explicit or implicit transactions. Geben Sie eine unterstützte Isolationsstufe für die speicheroptimierte Tabelle mithilfe eines Tabellenhinweis wie WITH (SNAPSHOT) an.Provide a supported isolation level for the memory-optimized table using a table hint, such as WITH (SNAPSHOT).

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;  
GO  

BEGIN TRANSACTION;  -- Explicit transaction.  

-- Order_mo  is a memory-optimized table.  
SELECT * FROM  
           dbo.Order_mo  as o  WITH (SNAPSHOT)  -- Table hint.  
      JOIN dbo.Customer  as c  on c.CustomerId = o.CustomerId;  
COMMIT TRANSACTION;

Die Notwenigkeit des Hinweises WITH (SNAPSHOT) kann durch die Verwendung der Datenbankoption MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT umgangen werden.The need for the WITH (SNAPSHOT) hint can be avoided through the use of the database option MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT. Wenn diese Option auf ONfestgelegt ist, wird der Zugriff auf eine speicheroptimierte Tabelle einer niedrigeren Isolationsstufe automatisch auf die SNAPSHOT-Isolation hochgestuft.When this option is set to ON, access to a memory-optimized table under a lower isolation level is automatically elevated to SNAPSHOT isolation.

ALTER DATABASE CURRENT
    SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

ZeilenversionsverwaltungRow Versioning

Speicheroptimierte Tabellen verwenden ein sehr komplexes System zur Zeilenversionsverwaltung, das den optimistischen Ansatz sogar auf der strengsten Isolationsstufe SERIALIZABLE effizient gestaltet.Memory-optimized tables use a highly sophisticated row versioning system that makes the optimistic approach efficient, even at the most strict isolation level of SERIALIZABLE. Weitere Informationen finden Sie unter Einführung in speicheroptimierte Tabellen.For details see Introduction to Memory-Optimized Tables.

Datenträgerbasierte Tabellen weisen indirekt ein System zur Zeilenversionsverwaltung auf, wenn READ_COMMITTED_SNAPSHOT oder die SNAPSHOT-Isolationsstufe aktiviert ist.Disk-based tables indirectly have a row versioning system when READ_COMMITTED_SNAPSHOT or the SNAPSHOT isolation level is in effect. Dieses System basiert auf tempdb. Bei speicheroptimierten Datenstrukturen hingegen ist zum Erzielen einer maximalen Effizienz die Zeilenversionsverwaltung bereits integriert.This system is based on tempdb, while memory-optimized data structures have row versioning built in, for maximum efficiency.

IsolationsstufenIsolation Levels

Die folgende Tabelle enthält die möglichen Stufen der Transaktionsisolation, wobei mit der niedrigsten Isolationsstufe begonnen wird.The following table lists the possible levels of transaction isolation, in sequence from least isolation to most. Informationen zu möglichen Konflikten und der Wiederholungslogik zum Beheben dieser Konflikte finden Sie unter Konflikterkennung und Wiederholungslogik.For details about conflicts that can occur and retry logic to deal with these conflicts, see Conflict Detection and Retry Logic.

IsolationsstufeIsolation Level BESCHREIBUNGDescription
READ UNCOMMITTEDREAD UNCOMMITTED Nicht verfügbar: Auf der Isolationsstufe „Read Uncommitted“ kann nicht auf speicheroptimierte Tabellen zugegriffen werden.Not available: memory-optimized tables cannot be accessed under Read Uncommitted isolation. Der Zugriff auf speicheroptimierte Tabellen auf der Isolationsstufe SNAPSHOT ist weiterhin möglich, wenn TRANSACTION ISOLATION LEVEL auf Sitzungsebene auf READ UNCOMMITTED festgelegt ist. Verwenden Sie hierzu den Tabellenhinweis WITH (SNAPSHOT), oder legen Sie die Datenbankeinstellung MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT auf ON fest.It is still possible to access memory-optimized tables under SNAPSHOT isolation if the session-level TRANSACTION ISOLATION LEVEL is set to READ UNCOMMITTED, by using the WITH (SNAPSHOT) table hint or setting the database setting MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT to ON.
READ COMMITTEDREAD COMMITTED Nur für speicheroptimierte Tabellen unterstützt, wenn der Autocommitmodus aktiviert ist.Supported for memory-optimized tables only when the autocommit mode is in effect. Der Zugriff auf speicheroptimierte Tabellen auf der Isolationsstufe SNAPSHOT ist weiterhin möglich, wenn TRANSACTION ISOLATION LEVEL auf Sitzungsebene auf READ COMMITTED festgelegt ist. Verwenden Sie hierzu den Tabellenhinweis WITH (SNAPSHOT), oder legen Sie die Datenbankeinstellung MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT auf ON fest.It is still possible to access memory-optimized tables under SNAPSHOT isolation if the session-level TRANSACTION ISOLATION LEVEL is set to READ COMMITTED, by using the WITH (SNAPSHOT) table hint or setting the database setting MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT to ON.

Wenn für die Datenbankoption READ_COMMITTED_SNAPSHOT „ON“ festgelegt ist, ist es nicht erlaubt, mit der gleichen Anweisung sowohl auf eine speicheroptimierte als auch auf eine datenträgerbasierte Tabelle auf der Isolationsstufe READ COMMITTED zuzugreifen.If the database option READ_COMMITTED_SNAPSHOT is set to ON, it is not allowed to access both a memory-optimized and a disk-based table under READ COMMITTED isolation in the same statement.
SNAPSHOTSNAPSHOT Dies wird für speicheroptimierte Tabellen unterstützt.Supported for memory-optimized tables.

Intern ist SNAPSHOT die Transaktionsisolationsstufe mit den geringsten Anforderungen für speicheroptimierte Tabellen.Internally SNAPSHOT is the least demanding transaction isolation level for memory-optimized tables.

SNAPSHOT verwendet weniger Systemressourcen als REPEATABLE READ oder SERIALIZABLE.SNAPSHOT uses fewer system resources than does REPEATABLE READ or SERIALIZABLE.
REPEATABLE READREPEATABLE READ Dies wird für speicheroptimierte Tabellen unterstützt.Supported for memory-optimized tables. Die Isolationsstufe REPEATABLE READ garantiert, dass zum Zeitpunkt der Commitausführung keine gleichzeitige Transaktion eine der von dieser Transaktion gelesenen Zeilen aktualisiert hat.The guarantee provided by REPEATABLE READ isolation is that, at commit time, no concurrent transaction has updated any of the rows read by this transaction.

Aufgrund des optimistischen Modells wird nicht verhindert, dass gleichzeitige Transaktionen Zeilen aktualisieren, die von dieser Transaktion gelesen werden.Because of the optimistic model, concurrent transactions are not prevented from updating rows read by this transaction. Stattdessen validiert diese Transaktion zum Zeitpunkt der Commitausführung, dass die REPEATABLE READ-Isolation nicht verletzt wurde.Instead, at commit time this transaction validated that REPEATABLE READ isolation has not been violated. Wenn die Isolation verletzt wurde, wird ein Rollback für die Transaktion ausgeführt, und die Transaktion muss wiederholt werden.If it has, this transaction is rolled back and must be retried.
SERIALIZABLESERIALIZABLE Dies wird für speicheroptimierte Tabellen unterstützt.Supported for memory-optimized tables.

Die Bezeichnung SERIALIZABLE wird verwendet, da die Isolation so streng ist, dass es ein wenig dem aufeinanderfolgenden anstatt dem parallelen Ausführen von Transaktionen entspricht.Named Serializable because the isolation is so strict that it is almost a bit like having the transactions run in series rather than concurrently.

Transaktionsphasen und LebensdauerTransaction Phases and Lifetime

Wenn eine speicheroptimierte Tabelle einbezogen wird, durchläuft die Lebensdauer einer Transaktion die in der folgenden Abbildung veranschaulichten Phasen:When a memory-optimized table is involved, the lifetime of a transaction progresses through the phases as displayed in the following image:

hekaton_transactions

Beschreibungen der Phasen folgen.Descriptions of the phases follow.

Reguläre Verarbeitung: Phase 1 (von 3)Regular Processing: Phase 1 (of 3)

  • Diese Phase setzt sich aus der Ausführung aller Abfragen und den DML-Anweisungen in der Abfrage zusammen.This phase is composed of the execution of all queries and DML statements in the query.
  • Während dieser Phase betrachten die Anweisungen die Version der speicheroptimierten Tabellen als die Version, die zur logischen Startzeit der Transaktion gültig war.During this phase, the statements see the version of the memory-optimized tables as of the logical start time of the transaction.

Überprüfung: Phase 2 (von 3)Validation: Phase 2 (of 3)

  • Die Überprüfungsphase beginnt durch Zuweisen der Beendigungszeit, wodurch die Transaktion als logisch abgeschlossen markiert wird.The validation phase begins by assigning the end time, thereby marking the transaction as logically complete. Mit dem Abschluss werden alle Änderungen an dieser Transaktion für andere Transaktionen, die von ihr abhängig sind, sichtbar.This completion makes all changes of the transaction visible to other transactions which take a dependency on this transaction. Für abhängige Transaktionen darf kein Commit ausgeführt werden, solange kein Commit erfolgreich für diese Transaktion ausgeführt wurde.The dependent transactions are not allowed to commit until this transaction has successfully committed. Darüber hinaus dürfen Transaktionen, für die solche Abhängigkeiten bestehen, keine Resultsets an den Client zurückgeben, damit dem Client nur Daten angezeigt werden, für die ein erfolgreicher Commit in die Datenbank ausgeführt wurde.In addition, transactions which hold such dependencies are not allowed to return result sets to the client, to ensure the client only sees data that has been successfully committed to the database.
  • Diese Phase umfasst die REPEATABLE READ- und SERIALIZABLE-Überprüfung.This phase comprises the repeatable read and serializable validation. Bei der REPEATABLE READ-Überprüfung wird geprüft, ob eine Zeile aktualisiert wurde, nachdem sie von der Transaktion gelesen wurde.For repeatable read validation, it checks whether any of the rows read by the transaction has since been updated. Bei der SERIALIZABLE-Überprüfung wird geprüft, ob Zeilen in einen von dieser Transaktion gescannten Datenbereich eingefügt wurden.For serializable validation it checks whether any row has been inserted into any data range scanned by this transaction. Gemäß der Tabelle im Abschnitt Isolationsstufen und Konflikte können sowohl die REPEATABLE READ- als auch die SERIALIZABLE-Überprüfung bei der SNAPSHOT-Isolation ausgewählt werden, um die Konsistenz von UNIQUE- und FOREIGN KEY-Einschränkungen zu überprüfen.Per the table in Isolation Levels and Conflicts, both repeatable read and serializable validation can happen when using snapshot isolation, to validate consistency of unique and foreign key constraints.

Commitverarbeitung: Phase 3 (von 3)Commit Processing: Phase 3 (of 3)

  • Während der Commitphase werden die Änderungen an dauerhaften Tabellen in das Protokoll und das Protokoll auf die Datenträger geschrieben.During the commit phase, the changes to durable tables are written to the log, and the log is written to disk. Anschließend wird die Steuerung wieder an den Client übergeben.Then control is returned to the client.
  • Nach Abschluss der Commitverarbeitung werden alle abhängigen Transaktionen benachrichtigt, dass sie die Commits ausführen können.After commit processing completes, all dependent transactions are notified that they can commit.

Wie immer sollten Sie Ihre Transaktionsarbeitseinheiten so minimal und kurz halten, wie es Ihre Datenanforderungen zulassen.As always, you should try to keep your transactional units of work as minimal and brief as is valid for your data needs.

Konflikterkennung und WiederholungslogikConflict Detection and Retry Logic

Es gibt zwei Arten von transaktionsbezogenen Fehlerbedingungen, die einen Fehler und ein Rollback für eine Transaktion verursachen können.There are two kinds of transaction-related error conditions that cause a transaction to fail and roll back. In den meisten Fällen muss die Transaktion nach dem Auftreten eines solchen Fehlers wiederholt werden – ähnlich wie bei einem Deadlock.In most cases, once such a failure occurs, the transaction needs to be retried, similar to when a deadlock occurs.

  • Konflikte zwischen gleichzeitigen Transaktionen.Conflicts between concurrent transactions. Hierbei handelt es sich um Updatekonflikte und Überprüfungsfehler, die durch Verletzungen der Transaktionsisolationsstufe oder durch Einschränkungsverletzungen verursacht werden können.These are update conflicts and validation failures, and can be due to transaction isolation level violations or constraint violations.
  • Abhängigkeitenfehler.Dependency failures. Diese werden verursacht, wenn beim Commit einer Transaktion, von der andere Transaktionen abhängig sind, ein Fehler auftritt, oder wenn die Anzahl von Abhängigkeiten zu groß wird.These result from transactions that you depend on failing to commit, or from the number of dependencies growing too large.

Im Folgenden finden Sie eine Auflistung der Fehlerbedingungen, die dazu führen können, dass Transaktionen nicht auf speicheroptimierte Tabellen zugreifen können.The following are the error conditions that can cause transactions to fail when they access memory-optimized tables.

FehlercodeError Code BESCHREIBUNGDescription UrsacheCause
4130241302 Es wurde versucht, eine Zeile zu aktualisieren, die seit dem Start der aktuellen Transaktion in einer anderen Transaktion aktualisiert wurde.Attempted to update a row that was updated in a different transaction since the start of the present transaction. Diese Fehlerbedingung tritt auf, wenn zwei gleichzeitige Transaktionen versuchen, die gleiche Zeile zur gleichen Zeit zu aktualisieren oder zu löschen.This error condition occurs if two concurrent transactions attempt to update or delete the same row at the same time. Eine der beiden Transaktionen empfängt diese Fehlermeldung und muss wiederholt werden.One of the two transactions receives this error message and will need to be retried.

4130541305 REPEATABLE READ-Überprüfungsfehler.Repeatable read validation failure. Eine Zeile einer speicheroptimierten Tabelle, die von dieser Transaktion gelesen wird, wurde von einer anderen Transaktion aktualisiert, für die vor dem Commit dieser Transaktion ein Commit ausgeführt wurde.A row read from a memory-optimized table this transaction has been updated by another transaction that has committed before the commit of this transaction. Dieser Fehler kann bei Verwendung der REPEATABLE READ- oder SERIALIZABLE-Isolation auftreten. Er kann auch auftreten, wenn die Aktionen einer gleichzeitigen Transaktion eine FOREIGN KEY-Einschränkung verletzen.This error can occur when using REPEATABLE READ or SERIALIZABLE isolation, and also if the actions of a concurrent transaction cause violation of a FOREIGN KEY constraint.

Solche Verletzungen von FOREIGN KEY-Einschränkungen sind selten und weisen in der Regel auf ein Problem mit der Anwendungslogik oder der Dateneingabe hin.Such concurrent violation of foreign key constraints is rare, and typically indicates an issue with the application logic or with data entry. Dieser Fehler kann allerdings auch auftreten, wenn in den Spalten, die an der FOREIGN KEY-Einschränkung beteiligt sind, kein Index vorhanden ist.However, the error can also occur if there is no index on the columns involved with the FOREIGN KEY constraint. Es empfiehlt sich daher, in FOREIGN KEY-Spalten einer speicheroptimierten Tabelle immer einen Index zu erstellen.Therefore, the guidance is to always create an index on foreign key columns in a memory-optimized table.

Ausführlichere Überlegungen zu Überprüfungsfehlern, die durch FOREIGN KEY-Verletzungen verursacht werden, finden Sie in diesem Blogbeitrag des SQL Server-Kundenberatungsteams.For more detailed considerations about validation failures caused by foreign key violations, see this blog post by the SQL Server Customer Advisory Team.
4132541325 SERIALIZABLE-Überprüfungsfehler.Serializable validation failure. Eine Zeile wurde in einen Bereich eingefügt, der zuvor von der aktuellen Transaktion gescannt wurde.A new row was inserted into a range that was scanned earlier by the present transaction. Dies wird als Phantomzeile bezeichnetWe call this a phantom row. Dieser Fehler kann bei Verwendung der SERIALIZABLE-Isolation auftreten. Er kann auch auftreten, wenn die Aktionen einer gleichzeitigen Transaktion eine PRIMARY KEY-, UNIQUE- oder FOREIGN KEY-Einschränkung verletzen.This error can occur when using SERIALIZABLE isolation, and also if the actions of a concurrent transaction cause violation of a PRIMARY KEY, UNIQUE, or FOREIGN KEY constraint.

Solche Einschränkungsverletzungen durch gleichzeitige Transaktionen sind selten und weisen in der Regel auf ein Problem mit der Anwendungslogik oder der Dateneingabe hin.Such concurrent constraint violation is rare, and typically indicates an issue with the application logic or data entry. Ähnlich wie bei REPEATABLE READ-Überprüfungsfehlern kann dieser Fehler auch auftreten, wenn für die an einer FOREIGN KEY-Einschränkung beteiligten Spalten kein Index vorhanden ist.However, similar to repeatable read validation failures, this error can also occur if there is a FOREIGN KEY constraint with no index on the columns involved.
4130141301 Abhängigkeitsfehler: Es besteht eine Abhängigkeit von einer anderen Transaktion, bei der später ein Commitfehler auftritt.Dependency failure: a dependency was taken on another transaction that later failed to commit. Für diese Transaktion (Tx1) entstand eine Abhängigkeit von einer anderen Transaktion (Tx2), während die Transaktion (Tx2) sich in der Überprüfungs- oder Commitverarbeitungsphase befand. Der Grund: Tx1 hat Daten gelesen, die von Tx2 geschrieben wurden.This transaction (Tx1) took a dependency on another transaction (Tx2) while that transaction (Tx2) was in its validation or commit processing phase, by reading data that was written by Tx2. Bei Tx2 trat anschließend ein Fehler beim Commit auf.Tx2 subsequently failed to commit. Die häufigsten Ursachen für Fehler beim Commit von Tx2 sind REPEATABLE READ-Überprüfungsfehler (41305) und SERIALIZABLE-Überprüfungsfehler (41325). Eine weniger häufige Ursache ist ein Protokoll-E/A-Fehler.Most common causes for Tx2 to fail to commit are repeatable read (41305) and serializable (41325) validation failures; a less common cause is log IO failure.
41823 und 4184041823 and 41840 Das Kontingent für Benutzerdaten in speicheroptimierten Tabellen und Tabellenvariablen wurde erreicht.Quota for user data in memory-optimized tables and table variables was reached. Der Fehler 41823 bezieht sich auf SQL Server Express/Web/Standard Edition sowie Singletons in Azure SQL-DatenbankAzure SQL Database.Error 41823 applies to SQL Server Express/Web/Standard Edition, as well as single databases in Azure SQL-DatenbankAzure SQL Database. Der Fehler 41840 bezieht sich auf Pools für elastische Datenbanken in Azure SQL-DatenbankAzure SQL Database.Error 41840 applies to elastic pools in Azure SQL-DatenbankAzure SQL Database.

In den meisten Fällen geben diese Fehler an, dass die maximalen Kapazität für Benutzerdaten erreicht wurde. Der Fehler kann behoben werden, indem Daten aus den speicheroptimierten Tabellen gelöscht werden.In most cases these errors indicate that the maximum user data size was reached, and the way to resolve the error is to delete data from memory-optimized tables. Es gibt jedoch seltene Fälle, in denen dieser Fehler nur vorübergehend ist.However, there are rare cases where this error is transient. Deshalb wird empfohlen, dass Sie es zunächst erneut versuchen, wenn dieser Fehler zum ersten Mal auftritt.We therefore recommend to retry when first encountering these errors.

Wie andere Fehler in dieser Liste verursachen die Fehler 41823 und 41840 einen Abbruch der aktiven Transaktion.Like the other errors in this list, errors 41823 and 41840 cause the active transaction to abort.
4183941839 Die Transaktion hat die maximale Anzahl von Commitabhängigkeiten überschritten.Transaction exceeded the maximum number of commit dependencies. Gilt für: SQL Server 2016 (13.x)SQL Server 2016 (13.x)Applies to: SQL Server 2016 (13.x)SQL Server 2016 (13.x). In höhere Versionen von SQL ServerSQL Server und Azure SQL-DatenbankAzure SQL Database ist die Anzahl von Commitabhängigkeiten nicht eingeschränkt.Later versions of SQL ServerSQL Server and Azure SQL-DatenbankAzure SQL Database do not have a limit on the number of commit dependencies.

Eine bestimmte Transaktion (Tx1) kann nur von einer bestimmten Anzahl von Transaktionen abhängig sein.There is a limit on the number of transactions a given transaction (Tx1) can depend on. Diese Transaktionen werden als ausgehende Abhängigkeiten bezeichnet.Those transactions are the outgoing dependencies. Darüber hinaus kann nur eine bestimmte Anzahl von Transaktionen von einer bestimmten Transaktion (Tx1) abhängig sein.In addition, there is a limit on the number of transactions that can depend on a given transaction (Tx1). Diese Transaktionen werden als eingehende Abhängigkeiten bezeichnet.These transactions are the incoming dependencies. Der Grenzwert für beide Arten lautet 8.The limit for both is 8.

Dieser Fehler tritt am häufigsten dann auf, wenn eine große Anzahl von Lesetransaktionen auf Daten zugreift, die von einer einzigen Schreibtransaktion geschrieben werden.The most common case for this failure is where there is a large number of read transactions accessing data written by a single write transaction. Die Wahrscheinlichkeit, dass diese Bedingung eintritt, steigt, wenn die Lesetransaktionen umfangreiche Scans der gleichen Daten durchführen und die Überprüfung oder Commitverarbeitung der Schreibtransaktion lange dauert. Beispiele: Die Schreibtransaktion führt in der SERIALIZABLE-Isolation umfangreiche Scans durch (dies verlängert die Überprüfungsphase), oder das Transaktionsprotokoll ist auf einem langsamen Protokoll-E/A-Gerät platziert (dies verlängert die Commitverarbeitung).The likelihood of hitting this condition increases if the read transactions are all performing large scans of the same data and if validation or commit processing of the write transaction takes long, for example the write transaction performs large scans under serializable isolation (increases length of the validation phase) or the transaction log is placed on a slow log IO device (increases length of commit processing). Wenn die Lesetransaktionen umfangreiche Scans durchführen und nur auf einige wenige Zeilen zugreifen, fehlt möglicherweise ein Index.If the read transactions are performing large scans and they are expected to access only few rows, an index might be missing. Gleiches gilt, wenn die Schreibtransaktion die SERIALIZABLE-Isolation verwendet und umfangreiche Scans durchführt, aber nur auf einige wenige Zeilen zugreifen soll. Auch dies kann ein Hinweis auf einen fehlenden Index sein.Similarly, if the write transaction uses serializable isolation and is performing large scans but is expected to access only few rows, this is also an indication of a missing index.

Die maximale Anzahl von Commitabhängigkeiten kann durch Verwendung des Ablaufverfolgungsflags 9926 erhöht werden.The limit on number of commit dependencies can be lifted by using Trace Flag 9926. Verwenden Sie dieses Flag nur, wenn die Fehlerbedingung weiterhin auftritt, nachdem Sie sichergestellt haben, dass keine Indizes fehlen. Ansonsten könnte dieses Flag die Fehler in den oben genannten Fällen verbergen.Use this trace flag only if you are still hitting this error condition after confirming that there are no missing indexes, as it could mask these issues in the above-mentioned cases. Eine weitere wichtige Überlegung: Komplexe Abhängigkeitsdiagramme, in denen für jede Transaktion eine Vielzahl von eingehenden und ausgehenden Abhängigkeiten besteht und in denen einzelne Transaktionen Abhängigkeiten auf vielen Ebenen aufweisen, können zu Ineffizienzen im System führen.Another caution is that complex dependency graphs, where each transaction has a large number of incoming as well as outgoing dependencies, and individual transactions have many layers of dependencies, can lead to inefficiencies in the system.

WiederholungslogikRetry Logic

Wenn aufgrund einer der oben genannten Bedingungen bei einer Transaktion ein Fehler auftritt, sollte die Transaktion wiederholt werden.When a transaction fails due to any of the above-mentioned conditions, the transaction should be retried.

Die Wiederholungslogik kann Client- oder Serverseite implementiert werden.Retry logic can be implemented at the client or server side. Im Allgemeinen empfiehlt es sich, die Wiederholungslogik auf Clientseite zu implementieren, da dies effizienter ist und Ihnen ermöglicht, von der Transaktion zurückgegebene Resultsets zu verarbeiten, bevor der Fehler auftritt.The general recommendation is to implement retry logic on the client side, as it is more efficient, and allows you to deal with result sets returned by the transaction before the failure occurs.

Beispiel zum Wiederholen von T-SQL-CodeRetry T-SQL Code Example

Eine serverseitige Wiederholungslogik sollte bei der Verwendung von T-SQL nur für Transaktionen verwendet werden, die keine Resultsets an den Client zurückgeben.Server-side retry logic using T-SQL should only be used for transactions that do not return result sets to the client. Ansonsten können durch Wiederholungen unter Umständen neben den Resultsets, die erwartungsgemäß an den Client zurückgegeben werden, zusätzliche Resultsets entstehen.Otherwise, retries can potentially result in additional result sets beyond those anticipated being returned to the client.

Das folgende interpretierte T-SQL-Skript veranschaulicht, wie die Wiederholungslogik für die Fehler aussehen kann, die Transaktionskonflikten zugeordnet sind, die speicheroptimierte Tabellen einbeziehen.The following interpreted T-SQL script illustrates what retry logic can look like for the errors associated with transaction conflicts involving memory-optimized tables.

-- Retry logic, in Transact-SQL.
DROP PROCEDURE If Exists usp_update_salesorder_dates;
GO

CREATE PROCEDURE usp_update_salesorder_dates
AS
BEGIN
    DECLARE @retry INT = 10;

    WHILE (@retry > 0)
    BEGIN
        BEGIN TRY
            BEGIN TRANSACTION;

            UPDATE dbo.SalesOrder_mo WITH (SNAPSHOT)
                set OrderDate = GetUtcDate()
                where CustomerId = 42;

            UPDATE dbo.SalesOrder_mo WITH (SNAPSHOT)
                set OrderDate = GetUtcDate()
                where CustomerId = 43;

            COMMIT TRANSACTION;

            SET @retry = 0;  -- //Stops the loop.
        END TRY

        BEGIN CATCH
            SET @retry -= 1;

            IF (@retry > 0 AND
                ERROR_NUMBER() in (41302, 41305, 41325, 41301, 41823, 41840, 41839, 1205)
                )
            BEGIN
                IF XACT_STATE() = -1
                    ROLLBACK TRANSACTION;

                WAITFOR DELAY '00:00:00.001';
            END
            ELSE
            BEGIN
                PRINT 'Suffered an error for which Retry is inappropriate.';
                THROW;
            END
        END CATCH

    END -- //While loop
END;
GO

--  EXECUTE usp_update_salesorder_dates;

Containerübergreifende TransaktionCross-Container Transaction

Eine Transaktion wird als containerübergreifende Transaktion bezeichnet, wenn Folgendes auf sie zutrifft:A transaction is called a cross-container transaction if it:

  • Sie greift über interpretiertes Transact-SQL auf eine speicheroptimierte Tabelle zu.Accesses a memory-optimized table from interpreted Transact-SQL; or
  • Sie führt eine native Prozedur aus, wenn eine Transaktion bereits geöffnet ist (XACT_STATE() = 1).Executes a native proc when a transaction is already open (XACT_STATE() = 1).

Der Begriff „containerübergreifend“ bezieht sich auf die Tatsache, dass diese Transaktionen in den beiden Transaktionsverwaltungscontainern ausgeführt werden – einer für datenträgerbasierte Tabellen, einer für speicheroptimierte Tabellen.The term "cross-container" derives from the fact that the transaction runs across the two transaction management containers, one for disk-based tables and one for memory-optimized tables.

Bei einer einzelnen containerübergreifenden Transaktion können verschiedene Isolationsstufen verwendet werden, um auf die datenträgerbasierten und speicheroptimierten Tabellen zuzugreifen.Within a single cross-container transaction, different isolation levels can be used for accessing disk-based and memory-optimized tables. Dieser Unterschied kann auf verschiedene Weise ausgedrückt werden: durch explizite Tabellenhinweise, z.B. WITH (SERIALIZABLE), oder durch die Datenbankoption MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT, die implizit die Isolationsstufe für die speicheroptimierte Tabelle erhöht, für die die Momentaufnahme erstellt werden soll, wenn TRANSACTION ISOLATION LEVEL als READ COMMITTED oder READ UNCOMMITTED konfiguriert ist.This difference is expressed through explicit table hints such as WITH (SERIALIZABLE) or through the database option MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT, which implicitly elevates the isolation level for memory-optimized table to snapshot if the TRANSACTION ISOLATION LEVEL is configured as READ COMMITTED or READ UNCOMMITTED.

Folgendes gilt für das folgende Transact-SQL-Codebeispiel:In the following Transact-SQL code example:

  • Auf die datenträgerbasierte Tabelle, Table_D1, wird auf der Isolationsstufe READ COMMITTED zugegriffen.The disk-based table, Table_D1, is accessed using the READ COMMITTED isolation level.
  • Der Zugriff auf die speicheroptimierte Tabelle Table_MO7 erfolgt auf der Isolationsstufe SERIALIZABLE.The memory-optimized table Table_MO7 is accessed using the SERIALIZABLE isolation level. Mit Table_MO6 ist keine spezifische Isolationsstufe verknüpft, da Einfügungen immer konsistent sind und im Wesentlichen auf der Isolationsstufe SERIALIZABLE ausgeführt werden.Table_MO6 does not have a specific associated isolation level, since inserts are always consistent and executed essentially under serializable isolation.
-- Different isolation levels for
-- disk-based tables versus memory-optimized tables,
-- within one explicit transaction.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
go

BEGIN TRANSACTION;

    -- Table_D1 is a traditional disk-based table, accessed using READ COMMITTED isolation.

    SELECT * FROM Table_D1;


    -- Table_MO6 and Table_MO7 are memory-optimized tables.
    -- Table_MO7 is accessed using SERIALIZABLE isolation,
    --   while Table_MO6 does not have a specific isolation level.

    INSERT Table_MO6
        SELECT * FROM Table_MO7 WITH (SERIALIZABLE);

COMMIT TRANSACTION;
go

EinschränkungenLimitations

  • Datenbankübergreifende Transaktionen werden für speicheroptimierte Tabellen nicht unterstützt.Cross-database transactions are not supported for memory-optimized tables. Wenn eine Transaktion auf eine speicheroptimierte Tabelle zugreift, kann die Transaktion nicht auf eine andere Datenbank zugreifen. Ausnahme:If a transaction accesses a memory-optimized table, the transaction cannot access any other database, except for:

    • tempdb-Datenbank.tempdb database.
    • Von der Masterdatenbank schreibgeschützt.Read-only from the master database.
  • Verteilte Transaktionen werden nicht unterstützt: Wenn BEGIN DISTRIBUTED TRANSACTION verwendet wird, kann die Transaktion nicht auf speicheroptimierte Tabellen zugreifen.Distributed transactions are not supported: When BEGIN DISTRIBUTED TRANSACTION is used, the transaction cannot access a memory-optimized table.

Systemintern kompilierte gespeicherte ProzedurenNatively Compiled Stored Procedures

  • In einer systemeigenen Prozedur muss der ATOMISCHE BLOCK die Transaktionsisolationsstufe für den gesamten Block deklarieren. Beispiel:In a native proc, the ATOMIC block must declare the transaction isolation level for the whole block, such as:

    • ... BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, ...) ...
  • Es sind im Hauptteil einer systemeigenen Prozess keine expliziten Transaktionssteueranweisungen zulässig.No explicit transaction control statements are allowed within the body of a native proc. BEGIN TRANSACTION, ROLLBACK TRANSACTION usw. sind nicht zulässig.BEGIN TRANSACTION, ROLLBACK TRANSACTION, and so on, are all disallowed.

  • Nähere Informationen zur Transaktionssteuerung mit ATOMISCHEN Blöcken finden Sie unter ATOMIC-BlöckeFor more information about transaction control with ATOMIC blocks, see Atomic Blocks