Mythe: TORN PAGE DETECTION est moins coûteux que CHECKSUM

Mercredi, septembre 1, 2010
By David Baffaleuf in SQL Server (dbaffaleuf@capdata-osmozium.com) [70 article(s)]

C’est tentant de le penser, parce qu’on sait que le mécanisme de Torn Page Detection (TPD) ne se base que sur les premiers bits de chaque secteur de 512 octets dans chaque page, alors que le checksum calcule une somme de contrôle de toute la page. *

Sauf que pour pouvoir ajouter la signature de 2 bits au début de chaque secteur, SQL Server doit poser un latch exclusif sur la page (PAGELATCH_EX) alors que le checksum ne pose qu’un latch d’update (PAGELATCH_UP) , qui est plus permissif notamment avec les latches en lecture (PAGELATCH_SH). Checksum n’a pas besoin d’un latch exclusif car le résultat de la somme de contrôle va dans l’entête de la page, pas dans les données. Malin !

Donc utiliser des checksums provoque moins d’attente au niveau des pages dans le buffer pool que TPD.

* cf article précédent pour plus de détails sur ce que font TPD et Checksums

http://blog.capdata.fr/index.php/modifier-page_verify-apres-une-migration-depuis-sql-2000/

Continuez votre lecture sur le blog :




Cliquer pour partager cet article sur Viadeo
Cliquer sur "CAPTURER" pour sauvegarder cet article dans Evernote Clip to Evernote

Tags: , , ,

2 Responses to “Mythe: TORN PAGE DETECTION est moins coûteux que CHECKSUM”

  1. Article intéressant.

    Cependant ne crois tu pas qu’il faut relativiser avec le fait que torn page demande moins de ressources CPU que Checksum ?

    A+

    David

    #6475
  2. Effectivement, c’est sur le plan des attentes que le checksum est intéressant, mais il y a aussi un intérêt indirect sur la CPU. Les autres workers en attente du latch sont suspendus dans un InterlockedCompareExchange(un spinlock). Donc même si la tâche qui calcule le TPD prend moins de cycles elle en fait brûler plus à celles qui sont en attente. Les workers qui demandent un LATCH_UP ou un LATCH_SH sur une page en cours de calcul de checksum sont grantés tout de suite et ne rentrent pas dans le test sur InterlockedCompareExchange.

    #7043

Leave a Reply