Dans SQL Server 2000, si vous souhaitez identifier les pages corrompues, l'option de base de données TORN_PAGE_DETECTION doit être définie sur TRUE.
Mais dans SQL 2005 et plus, un nouveau paramètre PAGE_VERIFY a remplacé l'ancien TORN_PAGE_DETECTION qui permet de choisir entre deux types différents de vérification de page: TORN_PAGE_DETECTION et CHECKSUM.
Maintenant, la question est de savoir laquelle définir - TORN_PAGE_DETECTION ou CHECKSUM?
TORN_PAGE_DETECTION - écrit un bit pour chaque 512 octets dans une page vous permettant de détecter quand une page n'a pas été correctement écrite sur le disque. Le problème est qu'il ne vous dira pas si les données stockées dans ces 512 octets sont réellement correctes ou non, car deux octets peuvent avoir été écrits de manière incorrecte.
CHECKSUM - calcule une somme de contrôle de la page à la fois quand une page est écrite et quand une page est lue, en supposant qu'elle a une somme de contrôle.
Le serveur SQL calcule la somme de contrôle en fonction du modèle de bits sur la page, le stocke dans l'en-tête de page, puis émet une E / S pour écrire la page. Lorsque SQL Server lit la page, il recalcule la somme de contrôle à l'aide de la même logique, puis la compare avec la valeur disponible dans l'en-tête de page. Si la valeur de la somme de contrôle correspond, cela suppose que la page n'a pas été corrompue pendant le cycle d'écriture-lecture.
Étant donné que le coût de calcul de la somme de contrôle est engagé à chaque lecture et écriture de page, il peut augmenter la surcharge du processeur et peut éventuellement avoir un impact sur le débit de votre charge de travail. Une autre chose à garder à l'esprit est que la somme de contrôle n'est pas unique pour un modèle de bit spécifique sur la page. Deux pages peuvent éventuellement correspondre à la même valeur de somme de contrôle. Il est donc très possible que la corruption de pages ne soit pas détectée.
Référence: somme de contrôle dans SQL2005
Pour répondre spécifiquement à vos questions:
Je crois que Checksum a été introduit dans SQL2005 et que la mise à niveau ou la restauration d'une base de données à partir d'une version antérieure maintiendrait sa méthode de vérification de la page précédente. c'est-à-dire qu'il n'y a pas eu de mise à niveau implicite.
Oui, CHECKSUM a été introduit dans SQL Server 2005 et est la valeur par défaut . Lorsque vous effectuez une mise à niveau de 2000 à 2005, vous devez modifier explicitement l'option de base de données Page Verify pour utiliser CHECKSUM.
Si vous restaurez la base de données déjà créée sur SQL 2005 sur un autre serveur exécutant SQL 2005, vous n'avez pas besoin de la définir. Il persistera jusqu'à ce que vous ayez défini l'option Vérifier la page.
Je n'ai pas réussi à faire des recherches lorsque Torn Page Detection est entré
De: http://support.microsoft.com/kb/230785
Versions de SQL Server antérieures à 7.0
Les versions de SQL Server antérieures à 7.0 ne fournissaient pas de parité de journal ni de fonctionnalités de détection de bits déchirés. En fait, ces versions peuvent écrire plusieurs fois la même page de journal jusqu'à ce que les enregistrements de journal remplissent la page de journal de 2 Ko. Cela peut exposer les transactions validées. Si la page de journal est en cours de réécriture lors d'un échec, un secteur avec la transaction validée peut ne pas être réécrit correctement.
Ainsi, TORN_PAGE_DETECTION existe depuis SQL Server 7.0. Même alors, le défaut était qu'il n'était pas activé (même lien) .
Remarque La détection des pages déchirées n'est pas activée par défaut dans SQL Server 7.0. Voir sp_dboption pour savoir comment activer la détection sur votre système.
Par conséquent, si la base de données avait été développée contre une instance 7.0 et avait été mise à niveau par la suite, elle aurait mis à niveau l'option avec l'option VERIFIER PAGE NONE (comme @ThomasStringer l'a noté dans sa réponse).
Edit: 24/09/2013 Pour améliorer la réponse:
En me référant à mes notes internes SQL Server de SQLSkills, j'ai trouvé qu'en utilisant un vidage de page, vous pouvez vérifier si la détection des bits déchirés - TORN_PAGE_DETECTION ou CHECKSUM était activée ou non:
use database_name -- change here for your database !!
checkpoint
go
dbcc traceon (3604) -- send output to screen
go
dbcc page (dbaalert, 1,1,0)
dbcc traceoff (3604) -- turn off the trace flag
go
m_tornBits : cela contient la somme de contrôle de page ou les bits qui ont été déplacés par les bits de protection de page déchirée - selon la forme de protection de page activée pour la base de données.
Remarque : Je n'ai aucune ancienne version de serveur SQL en cours d'exécution. Ci-dessous est confirmé à partir du serveur SQL 2000 et supérieur . Si vous avez un 7.0 ou 6.5 qui tourne, vous pouvez également le confirmer :-)
