Dans le cadre d’une base de données stand alone.

Dans SQL Server, les données consultées et modifiées sont chargées en mémoire. Plus exactement, ce sont les pages contenant les données concernées qui sont chargées.

Lors d’une mise à jour, d’une insertion ou d’une suppression de données, dans un premier temps, les pages concernées sont modifiées (celles qui ont été chargées en mémoire) et la transaction qui a entrainée ces évolutions est écrite sur le journal de transactions. Tout ça en parallèle.

Ci-dessous les étapes du parcours de données modifiées d’une base de données stand alone (sans réplication ni mirroring).

1. Exécution de la requête qui entraine la mise à jour, une insertion ou une suppression de données.
2. Chargement en mémoire des pages concernées.
3. Modification de ces pages, en mémoire donc, et écriture sur le journal de transaction.
4. Commit de la transaction et checkpoint exécutés indépendamment et en parallèle. Le commit valide la transaction, le checkpoint lance l’écriture des pages sur le disque. Si le checkpoint est provoqué avant le commit alors les données modifiées et écrites sur le disque peuvent ne pas être lisibles pour les transactions tiers qui tenteraient d’y accéder tant que le commit n’est pas intervenu. Cette accessibilité dépend du niveau d’isolation appliqué (par exemple; le niveau « read commited » attend le commit pour les mettre à disposition au contraire du « read uncommited » qui ne s’encombre pas de ce principe).

Ce que je ne vous ai pas dit.

Ici, je n’ai pas évoqué le commit manuel d’une transaction écrite (par le programmeur), en transact-sql (begin transaction, commit, rollback). A savoir que si un rollback est exécuté alors qu’un checkpoint a déjà provoqué l’écriture des modifications sur le disque alors le moteur SQL Server rétablira les données d’origine grâce au journal de transactions et des informations qui y ont été renseignées préalablement.