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
Continuez votre lecture sur le blog :
- Modifier PAGE_VERIFY après une migration depuis SQL 2000 (David Baffaleuf) [SQL Server]
- Production SQL Server : Contrôle de cohérence (Benjamin VESAN) [SQL Server]
- Abonnez-vous au blog de la CapData team ! (Benjamin VESAN) [GénéralMySQLOracleSQL ServerSybase]
- Error 8976 / 8978, problèmes de chaînage, comment récupérer les données (David Baffaleuf) [SQL Server]
- Intérêt de créer des indexes cluster uniques (David Baffaleuf) [SQL Server]
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
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.