Aujourd’hui, nous allons explorer une histoire intéressante sur les tables optimisées en mémoire, les transactions, le niveau d’isolation et les erreurs. En travaillant avec un institut financier dans le cadre d’une vérification complète des performances de la base de données, nous avons rencontré une situation unique. L’institut avait un volume élevé de transactions se produisant chaque seconde, et nous avions réussi à mettre en œuvre la technologie In-Memory OLTP pour eux. Cependant, nous avons rencontré un problème lors de la tentative d’accès à la fois aux tables optimisées en mémoire et aux tables régulières basées sur le disque dans une seule transaction.

Chaque fois que nous exécutions une requête qui accédait aux deux types de tables, nous rencontrions une erreur, ce qui n’était pas acceptable pour notre client. Voici un exemple de script qui a entraîné une erreur :

BEGIN TRANSACTION
SELECT *
FROM [dbo].[MemoryOptimizedTable] mt
INNER JOIN [dbo].[DiskBasedTable] dt ON mt.ID = dt.ID
GO
COMMIT TRANSACTION
GO

Le message d’erreur que nous avons reçu était :

Msg 41368, Level 16, State 0, Line 3
L'accès aux tables optimisées en mémoire en utilisant le niveau d'isolation READ COMMITTED est pris en charge uniquement pour les transactions en mode autocommit. Il n'est pas pris en charge pour les transactions explicites ou implicites. Fournissez un niveau d'isolation pris en charge pour la table optimisée en mémoire en utilisant une astuce de table, telle que WITH (SNAPSHOT).
Msg 3902, Level 16, State 1, Line 8
La demande COMMIT TRANSACTION n'a pas de BEGIN TRANSACTION correspondant.

La raison de cette erreur est que dans In-Memory OLTP de SQL Server, l’accès à la fois aux tables basées sur le disque et aux tables optimisées en mémoire dans une seule transaction n’est pas directement pris en charge, à moins de modifier le niveau d’isolation de la requête ou de la base de données.

Alors, quelle est la solution à ce problème ? La solution de contournement est assez simple. En modifiant le niveau d’isolation de la base de données en MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT, l’erreur sera résolue et SQL Server prendra en charge les transactions explicites ou implicites entre les conteneurs (entre le disque et la mémoire).

Voici le script pour modifier le niveau d’isolation :

-- Pour les transactions entre conteneurs
ALTER DATABASE CURRENT 
SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON
GO

En mettant en œuvre cette solution, vous pouvez effectuer sans problème des transactions impliquant à la fois des tables optimisées en mémoire et des tables basées sur le disque sans rencontrer d’erreurs.

C’est tout pour le billet de blog d’aujourd’hui. Nous espérons que ces informations vous aideront à comprendre le concept des tables optimisées en mémoire, des transactions, du niveau d’isolation et comment résoudre les erreurs associées dans SQL Server.