SQL Server 2014 In-Memory上一个事务中止异常

Question

I'm working on a large scale project that is currently in production. We have a big process that recently changed to use In-Memory Tables with SQL 2014 for performance efficiency.

The Process uses:

• 51 In-Memory SQL Tables.
• 50 Stored Procedures that loads data(Insert) from about 150 regular SQL Tables.
• 300 Validations (short stored procedure) Selecting from those 50 In-Memory Tables (And insert to In-Memory table that save the validation errors if exists).

We are calling this Process from ADO.Net, loads stored procedure first and then validations, each SP use different SQL Connection . In normal use, everything works fine and takes about 1.5 second.

Under stress test (6 Clients X 100 Tasks) for 30 minutes. After several minutes we are starting to get this SQL Exception (1 SQL Exception for every 20 tasks):

A previous transaction that the current transaction took a dependency on has aborted, 
and the current transaction can no longer commit.

Transactions in Memory-Optimized Tables

The Exception is not clear. We are not using BEGIN TRANSACTION in the process. The SQL Exception occurs in different stored procedures each time.

After days of investigation we are stuck and we have no ideas any more. Asking your help to undersand what can cause this exception and how to deal with it.

Answer 1

There is not enough info to really track down the problem, but we can try to help you by trying to explain what that error means and how it could happen.

First, as you probably know already, when Memory Optimized Table (MOT) participates in transaction, kind of optimistic concurrency control, avoid any locks and block waiting on that locks. Instead, when some kind of concurrency conflict is detected, one of the conflicting transactions is doomed and will be rolled back.

Each row of MOT has several timestamps assigned which define if transaction can see this row or not.

For transactions that access MOT, special validation phase is performed before commit. So whole transaction consists of three phases - regular, validation and commit.

During regular phase, writes to the tables made by transaction are not visible to other transactions, except deletes and updates visible to other deletes and updates, and if one transaction writes the same row as the other, write-write conflict occurs and one transaction is doomed immediatly.

Now most interesting for your problem is validation phase. Here, transaction validates things like was REPEATABLE READ or SERIALIZED isolation levels violated. Suppose transaction runs under REPEATABLE READ, read some row at the beginning of transaction, and in validation phase it sees that the same row was updated by another transaction (remember that writes of other transactions are not visible unless you write to the same row, but here you just read). Transaction is doomed here and will be rolled back.

Now, important thing is when validation phase begins, writes made by this transaction (let's name it transaction A, which is in validation phase) become visible to another transactions. But note they are not commited yet. If another transaction (B) reads such data (written by transaction which is now in validation phase but not yet commited), it gets the dependency on A. That means A should be commited and only after that B could be commited. If for some reason transaction A fails in validation phase, transaction B will be doomed too, with exception you have in your question.

Now remember that even if you don't explicitly begin transactions, each statement is executed inside transaction anyway. You might think that simple statements cannot cause such problems, but there are statements like MERGE that internally might execute several read and write operations, and they will be performed inside transaction.

An example how your error might occur (this is just to give you some ideas):

1. statement A performs MERGE statement on some table
2. It enters validation phase.
3. statement B performs MERGE and reads some data written by A.
4. We run under SERIALIZABLE isolation level, and A in validation phase notices that phantom row was inserted by some other statement C. SERIALIZABLE level is violated and A will be rolled back.
5. B has dependency on A and will be rolled back too with your exception.

Hope this information will help you to find the root of your problem.

What you can do also to track the issue is set isolation level to SNAPSHOT. Then validation step is not performed as I understand and this error should not appear any more.

Answer 2

Since In-Memory tables create COMMIT DEPENDENCIES, you may be facing that kind of situation.

In other words, after some time and under a stress test, is normal your database be more busy and creating some bottlenecks during the VALIDATION PHASE and COMMIT PHASE. So, you may accessing records that ARE NOT COMMITED YET by previous procedures: error 41301 ("a previous transaction that current transaction tool a dependency has aborted...")

You may force the COMMIT of data between transactions and, mainly, before start a new procedure that will utilize data from that transaction. In some scenarios, a simples "Select Count(*)" may force that commit.