1.4 Les écritures

proximité au sein du fichier de données, par un savant calcul de contigüité.

Mais comme cela ne suffit pas toujours, on peut même le réveiller si on le souhaite à l’aide de la commande CHECKPOINT qui force les écritures. D’un autre côté le journal des transactions qui est censé relater la vie de la base de données, s’oblige, pour cause d’acidité19, à tracer toutes les informations sur les demandes de lectures et d’écritures faites dans la base ainsi que toutes les données se référant à ces demandes. Non seulement cela peut représenter un volume de données très important, mais lorsque les transactions durent longtemps – ce qui veut dire qu’elles concernent un fort volume de données – la mise à jour qui va en résulter, risque de saturer la mémoire cache !

Il n’est pas rare de voir un développeur se persuader que l’insertion d’un fichier de données dans une table, dans le cas d’une opération d’import de données, doit s’effectuer dans le périmètre d’une transaction. Le problème, c’est que dès que le fichier d’import devient conséquent, la transaction s’allonge et sature le journal comme la mémoire… Une idée plus astucieuse dans ce cas aurait été de découper ce fichier en petits lots et de gérer la mise à disposition des informations soit par de multiples petites transactions si le besoin impérieux d’une telle sécurité s’impose, soit par une logique fonctionnelle reposant sur une donnée la plus basique possible.

De fait, dans une grande transaction impactant la mise à jour de nombreuses lignes, une grande partie du cache est occupée par des données à écrire réduisant ainsi l’espace de celles à lire avant que la fatidique minute du lazywriter ne réveille cet écrivain afin qu’il entame sa scripturale tâche. A moins qu’on ne le force à agir en le frappant d’un vigoureux CHECKPOINT! On en conclut donc notre quatrième et dernier commandement: plus les transactions sont petites, plus elles sont rapidement écrites, moins le cache est mobilisé.