Quand la détection de page déchirée et la somme de contrôle ont-elles été introduites dans SQL Server et quels sont les comportements de mise à niveau?

Il existe deux options différentes dans SQL Server moderne pour la vérification de page; étant Détection de page déchirée et somme de contrôle . Aucun n'est bien sûr également une option.

Je crois que Checksum a été introduit dans SQL Server 2005 et que la mise à niveau ou la restauration d'une base de données d'une version antérieure conserverait sa méthode de vérification de page précédente. c'est-à-dire qu'il n'y avait pas de mise à niveau implicite.

Le problème est que nous avons une base de données de production qui est entrée en production à l'aide de SQL Server 2000 et qui a depuis migré vers un serveur SQL Server 2008 R2. La vérification de page est définie sur Aucun lorsque je m'attendais à ce qu'elle soit Détection de page déchirée . En remontant ce laps de temps, nous semblons penser que la base de données a été initialement développée dans SQL Server 7.0, puis migrée vers SQL Server 2000, ce qui peut expliquer le résultat observé.

Je me demandais quand Torn Page Detection and Checksum est devenu une fonctionnalité de SQL Server et comment ils se sont comportés lors de la migration ou de la mise à niveau vers des versions plus récentes.

Edit: Résumant certaines des réponses:

Il y a un peu de distinction sur certaines des dates auxquelles la détection des pages déchirées est entrée dans SQL Server.
Lien 1: http://support.microsoft.com/kb/230785
Lien 2: http://technet.microsoft.com/en-us/library/aa337525(v=sql.90).aspx

Le premier lien indique SQL 7.0 et le second SQL2000. J'ai tendance à faire confiance à la suggestion SQL7.0 et à ce que le lien deux soit confus car il est désactivé par défaut dans SQL7.0 et activé par défaut dans SQL2000.

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 :-)

Jetez un oeil à la référence de BOL :

Lorsqu'une base de données utilisateur ou système est mise à niveau vers SQL Server 2005 ou une version ultérieure, la valeur PAGE_VERIFY (NONE ou TORN_PAGE_DETECTION) est conservée. Nous vous recommandons d'utiliser CHECKSUM

Cela signifie qu'avant SQL Server 2005, l'option pour TORN_PAGE_DETECTIONexistait, mais pas CHECKSUM.

Et pour répondre à votre deuxième point:

... 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 page précédente.

Oui c'est correct. Vous devez définir explicitement la base de données pour utiliser la CHECKSUMméthode de vérification des pages.

Il existe deux options différentes dans SQL Server moderne pour la vérification de page

Il y en a trois, comme vous l'avez indiqué: TORN_PAGE_DETECTION, CHECKSUM et NONE.

Je crois que CHECKSUM a été introduit dans SQL Server 2005

Comme cité dans cet article MSDN intitulé «Gestion des tampons»: la détection des pages déchirées a été introduite dans SQL Server 2000. La somme de contrôle a été introduite dans SQL Server 2005.

Un résumé des autres éléments notés dans cet article est que le mécanisme de vérification de page est spécifié au moment de la création de la base de données. Cela dépend donc de qui et comment ils ont créé la base de données quant à ce qu'elle est définie, pourrait également être contrôlé par le modèle de base de données configuré. Il est également intéressant de noter que si vous modifiez le paramètre, il ne prend pas effet sur toute la base de données, uniquement lorsque la page est écrite à la prochaine. De même, selon Paul Randal, cela n'est fait que lorsque la page est lue en mémoire, modifiée, puis réécrite sur le disque; cette information est ici .

J'ai une base de données de production qui est entrée en production à l'aide de SQL Server 2000, même si elle a peut-être été développée contre SQL Server 7.0 et a depuis migré vers un serveur SQL Server 2008 R2. La vérification de page est définie sur AUCUN bien que je m'attendais à ce qu'il s'agisse de DÉTECTION DE PAGE TORNÉE.

Toute personne disposant d'autorisations sur l'instance de base de données peut modifier cette valeur. Il aurait pu persister à travers les mises à niveau comme indiqué sur MSDN ici :

Lorsqu'une base de données utilisateur ou système est mise à niveau vers SQL Server 2005 ou une version ultérieure, la valeur PAGE_VERIFY (NONE ou TORN_PAGE_DETECTION) est conservée

Il aurait également pu être modifié ultérieurement, car quelqu'un a mal compris la configuration et a tiré dans le noir pour tenter de résoudre un problème.

Je me demandais quand TORN PAGE DETECTION est devenu une fonctionnalité de vérification de page

SQL Server 2000 comme indiqué ci-dessus.

comment il se comporte lors de la migration ou de la mise à niveau vers des éditions plus récentes.

Le paramètre précédent est conservé lors de la mise à niveau, comme indiqué ci-dessus.

Maintenant, je voudrais souligner le fait que d'autres liens fournis par des gens indiquent que SQL Server 7.0 est disponible lorsque la détection des pages déchirées était disponible. Ce qui, comme indiqué dans ces articles, est vrai, mais il est prouvé à plusieurs reprises que la documentation Microsoft ne doit pas être considérée comme une vérité en toutes circonstances. Il y en a beaucoup où ils se trompent. Cela dit, comment pouvez-vous déterminer quelle réponse est acceptable? Nous avons tous fourni la documentation de Microsoft pour appuyer notre réponse.

Notez également que la détection des pages déchirées figure sur la liste d'amortissement à partir de SQL Server 2012, alors quelle est la préoccupation avec la façon dont elle a été définie sur vos bases de données pour commencer. Si je l'ai vu réglé sur autre chose que CHECKSUM, je le change immédiatement et je passe à une autre tâche plus importante. Je ne m'inquiète pas de la façon dont une mauvaise configuration a été mise en place, il est plus important de la corriger et de s'assurer ensuite que ceux qui ont les autorisations pour la modifier sont informés de la raison pour laquelle cet élément de configuration ne doit pas être changé en autre chose. Juste mon 0,02 $

Comme l'ont dit @Thomas Stringer et @Kin, il a été introduit dans SQL Server 2005 et je pense qu'il fonctionne dans toutes les éditions de SQL Server. Pour TempDB, bien que CHECKSUM ait été introduit dans SQL Server 2008

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2008/03/23/checksum-and-tempdb.aspx