The Curious Case of… the aborted xdes map

(The Curious Case of… used to be part of our bi-weekly newsletter but we decided to make it a regular blog post instead so it can sometimes be more frequent. It covers something interesting one of us encountered when working with a client, doing some testing, or were asked in a random question from the community.)

Last week I was emailed a question about weird messages in someone’s error log on an Azure Managed Instance, similar to these:

[DbId:12]. Removing xdes id: 0000:8112c9d0 from aborted xdes map.
[DbId:12]. Removing xdes id: 0000:8112b45e from aborted xdes map.
[DbId:12]. Removing xdes id: 0000:8112b403 from aborted xdes map.

First off, an XDES is a data structure (and C++ class) in the Storage Engine that represents a transaction; it stands for ‘transaction descriptor’. The XDES ID is the same one that you see in the Transaction ID column in the output from the fn_dblog function for examining transaction log contents (see here for examples).

The messages are benign and are to do with the internal workings of the Accelerated Database Recovery feature, that allows instantaneous rollback of transactions through a clever versioning mechanism.

The aborted transaction map (ATM) contains a list of transactions that have rolled back (internally called ‘aborted’), but their effects have not yet been ‘removed’ from the database. The ATM is used:

• when a query reads a row, to see whether the current version of the row is from a transaction that subsequently rolled back, and so a previous version of the row should be used
• when a query is updating a row, to see whether the current version of the row is from a transaction that subsequently rolled back, so the updated row should overwrite the current version of the row

When the effects of a rolled-back transaction no longer need to be considered, the transaction ID is removed from the ATM.

You can read a great post that explains the internals of Accelerated Database Recovery here.