Wann wurde Torn Page Detection and Checksum in SQL Server eingeführt und wie verhält sich das Upgrade?

In modernen SQL Server gibt es zwei verschiedene Optionen für die Seitenüberprüfung. wobei torn Page Detection und Checksum . Keiner ist natürlich auch eine Option.

Ich glaube, dass Checksum in SQL Server 2005 eingeführt wurde und dass das Aktualisieren oder Wiederherstellen einer Datenbank von einer früheren Version die vorherige Seitenüberprüfungsmethode beibehalten würde. dh es gab kein implizites Upgrade.

Das Problem besteht darin, dass wir eine Produktionsdatenbank haben, die mit SQL Server 2000 in Produktion gegangen ist und seitdem auf einen SQL Server 2008 R2-Server umgezogen ist. Die Seitenüberprüfung ist auf Keine gesetzt, als ich erwartet hatte, dass die Seitenerkennung zerrissen ist . Wenn wir diese Zeitspanne zurückverfolgen, glauben wir, dass die Datenbank ursprünglich in SQL Server 7.0 entwickelt und dann auf SQL Server 2000 migriert wurde, und dies könnte das beobachtete Ergebnis erklären.

Ich habe mich gefragt, wann " Torn Page Detection" und " Checksum" zu einer Funktion von SQL Server wurden und wie sie sich bei der Migration oder Aktualisierung auf neuere Versionen verhielten.

Edit: Fasse einige der Antworten zusammen:

Es gibt eine kleine Diskriminierung in Bezug auf einige der Daten, an denen Torn Page Detection in SQL Server eingeführt wurde.
Link 1: http://support.microsoft.com/kb/230785
Link 2: http://technet.microsoft.com/en-us/library/aa337525(v=sql.90).aspx

Der erste Link kennzeichnet SQL 7.0 und der zweite SQL2000. Ich neige dazu, auf den SQL7.0-Vorschlag zu vertrauen, und der zweite Link war verwirrt, weil er in SQL7.0 standardmäßig deaktiviert und in SQL2000 standardmäßig aktiviert ist.

Wenn Sie in SQL Server 2000 beschädigte Seiten identifizieren möchten, sollte die Datenbankoption TORN_PAGE_DETECTION auf TRUE gesetzt sein.

In SQL 2005 und höher hat eine neue Einstellung PAGE_VERIFY die alte TORN_PAGE_DETECTION ersetzt, mit der zwei verschiedene Arten der Seitenüberprüfung ausgewählt werden können: TORN_PAGE_DETECTION und CHECKSUM.

Nun stellt sich die Frage, welches gesetzt werden soll - TORN_PAGE_DETECTION oder CHECKSUM?

TORN_PAGE_DETECTION - Schreibt ein Bit für jeweils 512 Byte auf einer Seite, sodass Sie erkennen können, wenn eine Seite nicht erfolgreich auf die Festplatte geschrieben wurde. Der Haken ist, dass es Ihnen nicht sagt, ob die in diesen 512 Bytes gespeicherten Daten tatsächlich korrekt sind oder nicht, da möglicherweise einige Bytes falsch geschrieben wurden.

CHECKSUM - berechnet eine Prüfsumme der Seite sowohl beim Schreiben als auch beim Lesen einer Seite, vorausgesetzt, sie enthält eine Prüfsumme.

Der SQL Server berechnet die Prüfsumme basierend auf dem Bitmuster auf der Seite, speichert sie im Seitenkopf und gibt dann eine E / A aus, um die Seite zu schreiben. Wenn der SQL Server die Seite liest, berechnet er die Prüfsumme mit derselben Logik neu und vergleicht sie dann mit dem im Seitenkopf verfügbaren Wert. Wenn der Prüfsummenwert übereinstimmt, wird davon ausgegangen, dass die Seite während des Schreib- / Lesezyklus nicht beschädigt wurde.

Da die Kosten für die Berechnung der Prüfsumme beim Lesen und Schreiben jeder Seite anfallen, kann dies den CPU-Overhead erhöhen und möglicherweise den Durchsatz Ihrer Arbeitslast beeinträchtigen. Beachten Sie außerdem, dass die Prüfsumme für ein bestimmtes Bitmuster auf der Seite nicht eindeutig ist. Möglicherweise können zwei Seiten demselben Prüfsummenwert zugeordnet werden. Es besteht also die Möglichkeit, dass eine Seitenbeschädigung unentdeckt bleibt.

Referenz: Prüfsumme in SQL2005

Um Ihre Fragen gezielt zu beantworten:

Ich glaube, dass Checksum in SQL2005 eingeführt wurde und dass das Aktualisieren oder Wiederherstellen einer Datenbank von einer früheren Version die Methode zur Überprüfung der vorherigen Seite beibehalten würde. dh es gab kein implizites Upgrade.

Ja, CHECKSUM wurde in SQL Server 2005 eingeführt und ist das DEFAULT . Wenn Sie von 2000 auf 2005 aktualisieren, müssen Sie die Datenbankoption Page Verify explizit ändern, um CHECKSUM zu verwenden.

Wenn Sie die bereits in SQL 2005 erstellte Datenbank auf einem anderen Server wiederherstellen, auf dem SQL 2005 ausgeführt wird, müssen Sie sie nicht festlegen. Es bleibt so lange bestehen, wie Sie die Option "Seitenüberprüfung" aktiviert haben.

Es ist mir nicht gelungen zu recherchieren, als Torn Page Detection einging

Von: http://support.microsoft.com/kb/230785

Versionen von SQL Server vor 7.0

Frühere Versionen von SQL Server als 7.0 boten keine Protokollparität oder Funktionen zur Erkennung zerrissener Bits. Tatsächlich können diese Versionen dieselbe Protokollseite mehrmals schreiben, bis die Protokolldatensätze die 2-KB-Protokollseite ausfüllen. Dies kann Transaktionen offenlegen, die erfolgreich festgeschrieben wurden. Wenn die Protokollseite während eines Fehlers neu geschrieben wird, wird ein Sektor mit der festgeschriebenen Transaktion möglicherweise nicht ordnungsgemäß neu geschrieben.

Daher gibt es TORN_PAGE_DETECTION seit SQL Server 7.0. Selbst dann war die Standardeinstellung, dass es nicht aktiviert war (gleicher Link) .

Hinweis: Die Erkennung zerrissener Seiten ist in SQL Server 7.0 standardmäßig nicht aktiviert. In sp_dboption erfahren Sie, wie Sie die Erkennung auf Ihrem System aktivieren.

Wenn die Datenbank für eine 7.0-Instanz entwickelt und anschließend aktualisiert worden wäre, hätte sie daher die vorhandene Option PAGE VERIFY von NONE (wie in seiner Antwort unter @ThomasStringer angegeben) aktualisiert.

Edit: 24.09.2013 So verbessern Sie die Antwort:

Unter Bezugnahme auf meine internen SQL Server-Notizen von SQLSkills stellte ich fest, dass Sie mithilfe eines Seitenabbilds überprüfen können, ob die Erkennung von Bitabrissen (TORN_PAGE_DETECTION oder CHECKSUM) aktiviert war oder nicht:

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 : Enthält entweder die Seitenprüfsumme oder die Bits, die durch die Schutzbits für zerrissene Seiten verschoben wurden - je nachdem, welche Form des Seitenschutzes für die Datenbank aktiviert ist.

Hinweis : Ich habe keine älteren SQL Server-Versionen ausgeführt. Unten wird von SQL Server 2000 und höher bestätigt . Wenn du ein 7.0 oder 6.5 hast, kannst du es auch bestätigen :-)

Schauen Sie sich die Referenz von BOL an :

Wenn ein Benutzer oder eine Systemdatenbank auf SQL Server 2005 oder eine neuere Version aktualisiert wird, bleibt der Wert PAGE_VERIFY (NONE oder TORN_PAGE_DETECTION) erhalten. Wir empfehlen die Verwendung von CHECKSUM

Dies schreibt vor, dass vor SQL Server 2005 die Option für TORN_PAGE_DETECTIONvorhanden war, jedoch nicht CHECKSUM.

Und um Ihren zweiten Punkt zu beantworten:

... und dass das Aktualisieren oder Wiederherstellen einer Datenbank von einer früheren Version die vorherige Seitenüberprüfungsmethode beibehalten würde.

Ja, das ist richtig. Sie müssen die Datenbank explizit festlegen, um die CHECKSUMSeitenüberprüfungsmethode zu verwenden.

In modernen SQL Server gibt es zwei verschiedene Optionen für die Seitenüberprüfung

Wie Sie angegeben haben, gibt es drei: TORN_PAGE_DETECTION, CHECKSUM und NONE.

Ich glaube, CHECKSUM wurde in SQL Server 2005 eingeführt

Wie aus diesem MSDN-Artikel mit dem Titel "Buffer Management" (Pufferverwaltung) hervorgeht: In SQL Server 2000 wurde die Erkennung zerrissener Seiten eingeführt. In SQL Server 2005 wurde die Prüfsumme eingeführt.

Eine Übersicht über andere in diesem Artikel erwähnte Dinge ist, dass der Seitenüberprüfungsmechanismus zum Zeitpunkt der Datenbankerstellung angegeben wird. Es hängt also davon ab, wer und wie die Datenbank erstellt hat, auf was sie eingestellt ist. Dies kann auch durch die Konfiguration der Modelldatenbank gesteuert werden. Interessant ist auch, dass eine Änderung der Einstellung nicht für die gesamte Datenbank gilt, sondern nur, wenn auf die nächste Seite geschrieben wird. Paul Randal zufolge erfolgt dies auch nur, wenn die Seite in den Speicher eingelesen, geändert und dann auf die Festplatte zurückgeschrieben wird. Diese Info ist hier .

Ich habe eine Produktionsdatenbank, die mit SQL Server 2000 in Produktion gegangen ist, obwohl sie möglicherweise für SQL Server 7.0 entwickelt wurde und seitdem auf einen SQL Server 2008 R2-Server verschoben wurde. Page Verify ist auf NONE gesetzt, obwohl ich erwartet habe, dass es sich um TORN PAGE DETECTION handelt.

Jeder, der über Berechtigungen für die Datenbankinstanz verfügt, kann diesen Wert ändern. Es könnte durch Upgrades, wie auf MSDN hier angegeben, bestehen bleiben :

Wenn ein Benutzer oder eine Systemdatenbank auf SQL Server 2005 oder eine neuere Version aktualisiert wird, bleibt der Wert PAGE_VERIFY (NONE oder TORN_PAGE_DETECTION) erhalten

Es könnte auch zu einem späteren Zeitpunkt geändert worden sein, weil jemand die Konfiguration falsch verstanden und im Dunkeln fotografiert hat, um ein Problem zu lösen.

Ich habe mich gefragt, wann TORN PAGE DETECTION zu einer Funktion zur Seitenüberprüfung wurde

SQL Server 2000 wie oben angegeben.

wie es sich verhält, wenn es migriert oder auf neuere Editionen aktualisiert wird.

Die vorherige Einstellung bleibt während des Upgrades wie oben angegeben erhalten.

Jetzt möchte ich darauf hinweisen, dass andere von Leuten bereitgestellte Links besagen, dass SQL Server 7.0 zum Zeitpunkt der Erkennung von Seitenrissen verfügbar war. Wie in diesen Artikeln dargelegt, ist es jedoch vielfach bewiesen, dass die Microsoft-Dokumentation nicht unter allen Umständen als wahr angesehen werden sollte. Es gibt viele, bei denen sie falsch liegen. Wie können Sie dann feststellen, welche Antwort akzeptabel ist? Wir alle haben Dokumentation von Microsoft zur Verfügung gestellt, um unsere Antwort zu unterstützen.

Beachten Sie auch, dass die Erkennung von zerrissenen Seiten ab SQL Server 2012 in der Abschreibungsliste aufgeführt ist. Worauf kommt es also an, wie sie für Ihre Datenbanken festgelegt wurden? Wenn ich sah, dass etwas anderes als CHECKSUM eingestellt war, ändere ich es sofort und gehe zu einer anderen wichtigeren Aufgabe über. Ich habe keine Bedenken, wie eine fehlerhafte Konfiguration eingerichtet wurde. Es ist wichtiger, sie zu korrigieren und dann sicherzustellen, dass diejenigen, die über die Berechtigung zum Ändern verfügen, darüber informiert werden, warum dieses Konfigurationselement nicht in etwas anderes geändert werden sollte. Nur meine 0,02 $

Wie sowohl @Thomas Stringer als auch @Kin sagten, wurde es in SQL Server 2005 eingeführt, und ich glaube, es funktioniert in allen Editionen von SQL Server. Für TempDB wurde CHECKSUM in SQL Server 2008 eingeführt

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