[2008R2] Journalisation des ordres SQL

Bonjour,
Je suis en train de lire l'article suivant :https://technet.microsoft.com/en-us/...2.logging.aspx

Citation:

---

As an example, consider what happens when a single table row is updated in an implicit transaction. Imagine a simple heap table with an integer column c1 and a char column c2. The table has 10,000 rows, and a user submits an update query as follows:

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE '%Paul%';

The following operations take place:

The data pages from SimpleTable are read from disk into memory (the buffer pool) so they can be searched for matching rows. It turns out that three data pages hold five rows that match the WHERE clause predicate.
The Storage Engine automatically starts an implicit transaction.
The three data pages and five data rows are locked to allow the updates to occur.
The changes are made to the five data records on the three data pages in memory.
The changes are also recorded in log records in the transaction log on disk.
The Storage Engine automatically commits the implicit transaction.

---

D'après ce que je lis ci dessus, il semblerait que chaque ordre LMD implique une écriture directe dans le journal des transactions (avant même qu'il soit commité et sans passer par le log buffer).
Est ce que vous confirmez ?
Dans ce cas à quoi sert le log buffer ?
Au final quels événements déclenchent l'écriture du log buffer vers le log file ?

Merci d'avance,

Frédéric

Bonjour Frédéric,

Effectivement les Log records sont écris dans le journal avant le commit de la transaction, mais quand même de manière asynchrone.
C'est le Write-ahead logging.
Au moment ou la transaction est terminée (COMMIT). Il faut bien que les changements aux données soient physiquement sur le disque (Log) pour pouvoir être rejoués en cas de Crash.

Citation:

---

Dans ce cas à quoi sert le log buffer ?

---

Tout ce que fait SQL Server il le fait en mémoire. Aussi, les log records peuvent être utilisés par des technologies comme la réplication, le mirroring, les Availability Groups.

Citation:

---

Au final quel événements déclenchent l'écriture du log buffer vers le log file ?

---

- Quand la transaction commit
- Quand une page (data-file page) est écrite sur le disque, tous les log records associés sont écrit
- Quand un log block (ensemble de log record) atteint la taille maximale de 60KB.

Merci pour votre réponse, toutefois :

Citation:

---

Envoyé par Oishiiii

- Quand la transaction commit

---

Cela est contradictoire avec la première phrase de votre réponse et avec l'extrait de l'article auquel je fais référence dans mon post initial.

Citation:

---

- Quand une page (data-file page) est écrite sur le disque, tous les log records associés sont écrit
- Quand un log block (ensemble de log record) atteint la taille maximale de 60KB.

---

Pourriez vous svp m'indiquer les articles microsoft où vous avez trouvé ces informations ?

Bonjour,

Ce que dit Oishiiii est correct.
Le log buffer est présent depuis quelques versions. Tant qu'il n'y a pas de COMMIT, il n'est pas nécessaire d'inscrire les données physiquement dans le fichier de log, on peut les conserver dans un buffer en mémoire. Comme la transaction n'est pas terminée, il n'est pas nécessaire d'assurer sa durabilité. Au moment du COMMIT, il faut faire une écriture synchrone dans le log pour assurer la durabilité de la transaction. On flushe alors le log buffer.
par exemple : http://blogs.msdn.com/b/sql_pfe_blog...s-monitor.aspx
ou https://books.google.fr/books?id=gQf...ersion&f=false.

L'article de Paul Randal dit ceci :

Citation:

---

The changes are also recorded in log records in the transaction log on disk.
The Storage Engine automatically commits the implicit transaction.

---

donc : juste avant de faire un COMMIT, on flushe. On ne veut pas faire l'inverse, sinon on a un risque de perte de données.

Ce n'est pas tout à fait contradictoire.
Pendant la transaction les log records sont créés dans le buffer, ils remplissent les log blocks.
Il ne sont pas écrits dans le fichier de log de manière synchrone. Ils peuvent y rester un moment avant de recevoir par exemple un ordre COMMIT.
Qui lui va déclencher l'écriture dans le fichier de log avant d'envoyer la confirmation au client.

Il existe d'ailleurs un type d'attente qui s'appelle WRITELOG.


Mes références pour la liste que j'ai fournis sont les notes que j'ai prises du cours Pluralsight de Paul Randal. Je n'y ai plus accès maintenant...
Mais certaines infos ce trouvent ici par exemple :
http://blogs.msdn.com/b/sqlsakthi/ar...ql-server.aspx


EDIT : En fait je n'ai pas été assez précis dans le premier message.
Quand j'ai écris "avant le commit de la transaction", je voulais parler du moment où le client reçoit la confirmation de l’exécution de la commande SQL COMMIT.
Entre le moment de l’exécution de l'ordre COMMIT par le client et celui de la confirmation de l’exécution par SQL Server, il se passe des choses.

Merci à tous les deux, je vais potasser ça.

Citation:

---

Envoyé par fred_04510

D'après ce que je lis ci dessus, il semblerait que chaque ordre LMD implique une écriture directe dans le journal des transactions

---

Une toute petite précision : ce ne sont pas tous les ordres du LMD, mais ceux qui nécessite une écriture ! Le SELECT n'est donc pas concerné, mais il fait bien partie du LMD.

A +

Merci pour cette précision.