破損ページ検出とチェックサムがSQL Serverに導入されたのはいつですか？アップグレードの動作は何ですか？

最新のSQL Serverには、ページ検証用の2つの異なるオプションがあります。されているページの検出破れやチェックサムを。もちろん、オプションもありません。

私は信じているチェックサムが、 SQL Server 2005およびそのアップグレードで導入されたか、以前のバージョンからDBを復元する方法を確認し、その前のページを維持するであろう。つまり、暗黙的なアップグレードはありませんでした。

関係する問題は、SQL Server 2000を使用して運用環境に移行し、その後SQL Server 2008 R2サーバーに移行した運用データベースがあることです。破損ページの検出であると予想していたときに、ページ検証がなしに設定されました。この時間をさかのぼると、DBは元々SQL Server 7.0で開発され、その後SQL Server 2000に移行されたと思われるため、観察された結果を説明できます。

Torn Page Detection and ChecksumがSQL Serverの機能になった時期と、新しいバージョンに移行またはアップグレードされたときの動作について疑問に思いました。

編集：いくつかの答えをまとめる：

Torn Page DetectionがSQL Serverに導入された日付には、若干の不一致があります。
リンク1：http : //support.microsoft.com/kb/230785
リンク2：http : //technet.microsoft.com/en-us/library/aa337525(v=sql.90).aspx

最初のリンクはSQL 7.0を示し、2番目のリンクはSQL2000を示します。私はSQL7.0の提案を信頼する傾向があり、リンク2は、SQL7.0ではデフォルトでオフになり、SQL2000ではデフォルトでオンになるということで混乱していました。

SQL Server 2000では、破損したページを特定する場合、データベースオプションTORN_PAGE_DETECTIONをTRUEに設定する必要があります。

ただし、SQL 2005以降では、新しい設定PAGE_VERIFYが古いTORN_PAGE_DETECTIONに置き換わり、TORN_PAGE_DETECTIONとCHECKSUMの2種類のページ検証から選択できるようになりました。

ここで、どちらを設定するかという質問があります-TORN_PAGE_DETECTIONまたはCHECKSUM？

TORN_PAGE_DETECTION-ページ内の512バイトごとにビットを書き込むことで、ページがディスクに正常に書き込まれなかったことを検出できます。キャッチは、これらの512バイトに格納されたデータが実際に正しいかどうかを教えてくれないことです。これは、数バイトが誤って書き込まれた可能性があるためです。

CHECKSUM-チェックサムがあると仮定して、ページが書き込まれたときとページが読み取られたときの両方で、ページのチェックサムを計算します。

SQL Serverは、ページ上のビットパターンに基づいてチェックサムを計算し、ページヘッダーに保存してから、ページを書き込むためのI / Oを発行します。SQL Serverはページを読み取ると、同じロジックを使用してチェックサムを再計算し、ページヘッダーで使用可能な値と比較します。チェックサム値が一致する場合、書き込み/読み取りサイクル中にページが破損していなかったと見なされます。

チェックサムの計算コストは​​、ページの読み取りおよび書き込みごとに発生するため、CPUオーバーヘッドが増加し、ワークロードのスループットに影響を与える可能性があります。留意すべきもう1つの点は、チェックサムがページ上の特定のビットパターンに対して一意ではないことです。2つのページが同じチェックサム値にマップされる可能性があります。そのため、ページの破損が検出されない可能性がほとんどありません。

参照：SQL2005のチェックサム

質問に具体的に答えるには：

チェックサムはSQL2005で導入され、以前のバージョンからDBをアップグレードまたは復元すると、以前のページ検証方法が維持されると考えています。つまり、暗黙的なアップグレードはありませんでした。

はいCHECKSUMはSQL Server 2005で導入されたDEFAULTです。2000から2005にアップグレードする場合は、CHECKSUMを使用するために、データベースオプションのページ検証を明示的に変更する必要があります。

すでにSQL 2005で作成されたデータベースを、SQL 2005を実行している別のサーバーに復元する場合、設定する必要はありません。これは、ページ確認オプションを設定したものまで保持されます。

Torn Page Detectionが登場したとき、私は研究に成功していません

From：http : //support.microsoft.com/kb/230785

7.0より前のSQL Serverのバージョン

7.0より前のバージョンのSQL Serverは、ログパリティまたは破損ビット検出機能を提供していませんでした。実際、これらのバージョンは、ログレコードが2 KBのログページを満たすまで、同じログページを複数回書き込むことができます。これにより、正常にコミットされたトランザクションを公開できます。障害の発生中にログページが書き換えられている場合、コミットされたトランザクションのあるセクターが正しく書き換えられない場合があります。

したがって、TORN_PAGE_DETECTIONはSQL Server 7.0以降に存在します。それでも、デフォルトでは有効になっていませんでした（同じリンク）。

注 SQL Server 7.0では、破損ページの検出はデフォルトで有効になっていません。システムで検出を有効にする方法については、sp_dboptionを参照してください。

したがって、データベースが7.0インスタンスに対して開発され、その後アップグレードされた場合、既存のPAGE VERIFYオプションNONEを使用してアップグレードされます（@ThomasStringerが回答で述べたように）。

編集：2013年9月24日 答えを改善するには：

SQLSkillsのSQL Server内部メモを参照すると、ページダンプを使用すると、破損ビット検出-TORN_PAGE_DETECTIONまたはCHECKSUMが有効になっているかどうかを確認できます。

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：ページチェックサムまたは破損ページ保護ビットによって置き換えられたビットのいずれかを保持します。これは、データベースのページ保護の形式によって異なります。

注：古いバージョンのSQLサーバーは実行していません。以下は、SQL Server 2000以降で確認されています。7.0または6.5を実行している場合は、それも確認できます:-)

BOLからの参照をご覧ください。

ユーザーまたはシステムデータベースがSQL Server 2005以降のバージョンにアップグレードされると、PAGE_VERIFY値（NONEまたはTORN_PAGE_DETECTION）は保持されます。CHECKSUMを使用することをお勧めします

これは、SQL Server 2005より前のバージョンではTORN_PAGE_DETECTION存在していましたが、ではありませんでしたCHECKSUM。

2番目のポイントに答えるには：

... DBを以前のバージョンからアップグレードまたは復元すると、以前のページ検証方法が維持されます。

はい、それは正しいです。CHECKSUMページ検証メソッドを利用するには、データベースを明示的に設定する必要があります。

最新のSQL Serverにはページ検証用の2つの異なるオプションがあります

述べたとおり、TORN_PAGE_DETECTION、CHECKSUM、およびNONEの3つがあります。

CHECKSUMはSQL Server 2005で導入されたと思います

「バッファ管理」というタイトルのこの MSDN記事から引用したように、破損ページの検出はSQL Server 2000で導入されました。チェックサムはSQL Server 2005で導入されました。

この記事に記載されている他の事柄の概要は、ページ検証メカニズムがデータベース作成時に指定されるということです。そのため、データベースの設定者やデータベースの作成方法に依存し、モデルデータベースの設定によって制御することもできます。また、設定を変更しても、ページが次に書き込まれるときにのみデータベース全体に影響を与えることはありません。同様に、Paul Randalによれば、ページがメモリに読み込まれ、変更されてからディスクに書き戻されるときにのみ行われます。その情報はこちらです。

SQL Server 7.0に対して開発された可能性がありますが、SQL Server 2000を使用して運用環境に入った運用データベースがあり、それ以降はSQL Server 2008 R2サーバーに移行しました。ページ検証は[なし]に設定されていますが、破損ページ検出であると予想していました。

データベースインスタンスへのアクセス許可を持つすべてのユーザーは、その値を変更できます。ここでMSDNに記載されているように、アップグレードしても持続する可能性があります。

ユーザーまたはシステムデータベースがSQL Server 2005以降のバージョンにアップグレードされると、PAGE_VERIFY値（NONEまたはTORN_PAGE_DETECTION）は保持されます

また、誰かが構成を誤解し、問題を解決しようと暗闇で撮影していたため、後で修正することもできました。

引き裂かれたページの検出がページ検証機能になったとき、私は疑問に思っていました

上記のSQL Server 2000。

新しいエディションに移行またはアップグレードしたときの動作。

上記のように、アップグレード中は以前の設定が保持されます。

ここで、人々から提供された他のリンクが、SQL Server 7.0が破れたページの検出が利用可能になったときであると述べているという事実を指摘したいと思います。これらの記事で述べられているとおりですが、Microsoftのドキュメントがすべての状況で真実として保持されるべきではないことは何度も証明されています。彼らが間違っているところはたくさんあります。それで、どの答えが受け入れられるかをどのように判断できますか？マイクロソフトは、回答をサポートするためにすべてのドキュメントを提供しました。

また、SQL Server 2012の時点では、破れたページの検出は減価償却リストに載っていることに注意してください。CHECKSUM以外に設定されているのを見た場合は、すぐに変更して他のより重要なタスクに進みます。悪い構成がどのように配置されたかについて心配する必要はありません。それを修正し、それを変更する権限を持っている人に、その構成アイテムを他のものに変更してはならない理由を確実に通知することがより重要です。 ちょうど私の0.02ドル

@Thomas Stringerと@Kinの両方がSQL Server 2005で導入されたように、SQL Serverのすべてのエディションで機能すると考えています。CHECKSUMはSQL Server 2008で導入されましたが、TempDBについて

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