『Microsoft Sql server 2008 Internals』読書ノート--第11章DBCC Internals（1）
6750 ワード
『Microsoft Sql server 2008 Internals』読書ノート購読住所：
http://www.cnblogs.com/downmoon/category/230397.html/rss
『Microsoft Sql server 2008 Internals』インデックスディレクトリ：
『Microsoft Sql server 2008 Internal』読書ノート--目次索引
誰がSQL Serverデータベースの整合性をチェックすると言った時、頭の中の第一は「DBCC」であるべきです。SQL Server 7.0では、DBCCはデータベースの整合性検査を代表していますが、その後のバージョンでは、SQL Server 2000において、マイクロソフトは定義を変更して、データベースコンソールコマンドになりました。これはまた，DBCCコマンドが一貫性検査の範囲をはるかに超えているという事実を反映している。
SQL Server自体はデータベースの破損を引き起こしません。しかし、I/Oサブシステム（SQL Serverバッファとディスクドライブのすべての金属酸化物metal oxide）は圧倒的に多くのcoruptionを引き起こします。（このために）一般的な妙技は、すべてのデータベースサーバに何らかの順序付けがあるため、従来の一貫性検査を事前に実行することである。一般的には、週に一回の一貫性検査を実施することが受け入れられます。
整合性検査は、データベースの物理的および論理的構造を検証するプロセスであり、その目的は、破損していないことを確認して、記憶エンジンがデータベースの他の部分を処理することを阻止するか、またはいくつかの不正行為を引き起こす可能性があることを確認することである。
◆耐久性のある計算列の耐久性値の位置が壊れていて、計算結果にマッチしなくなりました。
◆一つ（ページの先の）Page IDがあるデータページの位置が破損しました。
◆記録されたキーの順番がある位置のインデックスが壊れます。
SQL Server 7.0時代に正式に一致検査が行われました。本バージョンではオフライン操作（つまり、テーブルロックが要求されています）を実行するために使用されています。SQL Server 2000では、標準オンラインで動作することを一貫性で確認し、これは新しい効率的なスキャンデータベースの仕組みである。SQL Server 2005において、エンジン内部の整合性チェックと修復コードが著しく書き換えられ、強化されている。SQL Server 2008は新しい機能を追加し、さらに性能と伸縮性を調整しました。
あるデータベースで性能整合性検査を行う最も広範な方法はDBCC CHECKDBを使うことです。詳しい使い方は、http://technet.microsoft.com/zh-cn/library/ms176064.aspxを参照してください。
MSDNコメント：SQL Serverの初期バージョンでは、各テーブル、各インデックス行カウント、およびページカウントの値が正しくない場合があります。特定の場合、1つまたは複数の値は負の値にさえなる。SQL Server 2005およびより高いバージョンでは、これらの値は常に正しいメンテナンスを受ける。したがって、SQL Server 2005およびより高いバージョンで作成されたデータベースにはエラーのカウントは含まれません。しかし、SQL Server 2005およびより高いバージョンにアップグレードすると、エラーのカウントが含まれている可能性があります。これはデータベースに格納されているどのデータも壊れていません。DBCC CHECKDBが強化され、カウント値の一つが負の値になることが検出されます。
DBCC CHECKDBの主な手順は以下の通りである。1、事務レベルの完全かつ静的なデータベースビューを作成する。
2、キーシステム分類のlow-levelの整合性検査を実行する。
3、分配データベースの整合性検査を実行する。
4、データベース内の各テーブルの整合性検査を実行します。
5、前のステップではエラーは発見されていません。以下の表にまたがって一致性検査が行われます。◆service brook erメタデータの一致性検査を行います。
◆各種システム分類（catalog）間の整合性検査を実施します。
◆索引ビューの整合性チェックを行います。
◆XMLインデックスの整合性チェックを行います。
◆空間索引の整合性チェックを行います。
6、出力結果
この章では、私たちは
1、上記の6ステップに基づいて、SQL Server 2008におけるDBCC CHECKDB作業の内幕を知る。
2、各定義可能なオプションについて、DBCC CHECKDB挙動にどのように影響しますか？
3、どうやって修復するかと他のDBCCについての整合性検査コマンドです。
■データベースの持続的なビューを得る
DBCC CHECKDBはデータベースの全割り当てページを分析しなければならないので、multipleを確認する必要があります。 Pagesの各構造間のリンク。これは分析されたページ（データベース全体の）を意味しています。整合性検査が実行されている間は変更できません。DBCC CHECKEDは各種の不正結果を報告します。DBCC CHECKDBコマンドは、データベース内のすべての割り当てられたページを瞬時に読み取ることができないので、データベースの持久図は一貫性検査終了まで継続しなければならない。また、データベースは簡単に凍結されても十分ではないので、DBCC CHECKDBコマンドで見たビューは未完成のものに変更されるように、データベースの耐久ビューも事務レベルの完全なものでなければならない。
ここでは、統合されていないインデックスが記録されたテーブルを挿入することを考慮しながら、一貫性検査のプロセスが実行されていると仮定して、データベースの永続的なビューを強制しませんでした。クエリープロセッサの動作は、最初にテーブルレコードを挿入し、次に一致した非集合インデックスレコードを挿入することである。この仮定の一貫性検査プロセスは、非凝集インデックスを読み込まずにテーブルレコードを読み込むことができ、結果として非凝集インデックスがテーブルと同期されていないという報告をもたらします。
これはどうやって起こったのですか？後ほどお話しします。DBCC CHECKDBは、ある特定の順序でデータベースページを読み、性能を向上させます。この機構を用いて、この例は継続して、非凝集インデックス記録が挿入される前に非凝集インデックスページを読み取ることができ、テーブルレコードが挿入された後にテーブルページを読み取ることもできる。破損があるという結論が出るかもしれません。実際に問題は内部衝突の事務の局所的な結果を見たことである。
■長いビューを取得する
SQL Server 7.0では、トランザクションレベルの永続的なビューは、データベース内のそれぞれの異なるレベルにロックすることによって取得される。これは作業負荷性能に非常に有害である。したがって。SQL Server 2000はオンライン一貫性検査を開始し、閉塞ロックが不要となりました。DBCC CHECKEDは、データベースをスキャンした後、トランザクションログを分析し、必要に応じてデータベース内部ビューの復元を実行することにより、事務レベルのデータベース持久図を作成します。
様々な原因のため、SQL Server 2000ソリューションは不器用で扱いにくいので、SQL Server 2005ではデータベースのスナップショットに取って代わられます。SQL Server 2008では同じ仕組みが使用されている。これは複雑さを大幅に低減した。
第三章でも言及しましたが、データベースのスナップショットは非常に省スペースです。スナップショットが作成されてから変更されたデータベースページだけが含まれます。データベーススナップショットの内容の組み合わせとデータベース内の変化していないページは、変更されていない、トランザクションレベルのデータベースの持続的なビューを提供します。
これはDBCC CHECKDBがオンライン運転を必要とする正確な原因です。データベーススナップショットを作成し、データベーススナップショットを実行する一貫性検査演算は、データベースで実行される読み取り専用コピーの一貫性検査演算概念と同じです。
DBCC CHECKDBはユーザによってアクセスできないデータベーススナップショットを作成します。この隠しデータベーススナップショットは、従来のデータベーススナップショットとは少し違っています。従来のスナップショットはソースデータベースの各データファイルに一つのスナップショットファイルしかありません。各ファイルはデータベーススナップショットが作成された時に明示的に名前を付けなければなりません。DBCC CHECKDBは、隠しデータベースのスナップショットに指定されたファイル名を入力するユーザを許さず、既存のデータベースデータファイルごとにNTFS代替ストリームを作成する。このスナップショットをファイルシステムの隠しファイルと見なしてもいいです。
■ディスク空間衝突
隠しデータベースのスナップショットが実行空間を使い果たして衝突することがあります。既存のデータファイルの代替ストリームを使用して実現されるので、データベーススナップショットはデータファイルと同じ位置で空間を使用する。データベースがチェックされている時に重い作業負荷があると、ますます多くのページがデータベースのスナップショットによって進められ、急速に成長します。このとき、データベースがあるボリュームは、十分なスペースがないと、スナップショットが使えなくなり、DBCC CHECKDBがエラーで停止します。
この場合の解決策は自分のデータベーススナップショットを作成することです。十分なスペースのボリュームを置いてDBCC CHECKDBを再実行すると、DBCC CHECKDBは既に実行されているデータベーススナップショットを認識し、新しいスナップショットを作成しようとしない。
もしスナップショットがDBCC CHECKEDによって作成されたら、一致性検査演算が完了すれば、自動的に廃棄されます。
データベーススナップショットを作成すると同時に、Filestreamゴミ回収プロセスはDBCC CHECKDBを実行する時に保留されています。これにより、任意のFile Stramデータ容器のFileStreamデータの事務レベルの持久図を確認することができます。これは本章の後に紹介されています。
■データベーススナップショットを使う代替案
下記の条件では、データベースのスナップショットは必要ありません。
◆定義されたデータベースはデータベースのスナップショット自体です。
◆定義されたデータベースは読み取り専用、シングルユーザーモードまたはマージモードです。
◆サービスは-mコマンドラインオプションで単一ユーザモードで起動します。
上記の状況では、データベースは完全でなければなりません。他の活動接続による破壊一貫性検査の変化がないからです。
下記の条件ではデータベースのスナップショットを作成できません。
◆指定されたデータベースは非NTFSファイルシステムに格納されています。このとき、データベーススナップショットはNTFSの疎ファイル技術に依存して作成できません。
◆定義されたデータベースはtempdbです（tempdbはデータベーススナップショットを作成できません）
◆TABLockオプションが定義されています。
データベーススナップショットが作成できない場合は、DBCC CHECKDBは、事務レベルのデータベース持久ビューを取得するためにロックを試みる。
まず、それはデータベースレベルの排他的ロックを得て、変化がないという前提で配分一貫性検査を行うことができます。これはマスターデータベースでは不可能です。つまりオフライン一貫性検査はマスターに実行できません。tempdbで、つまりtempdbをスキップすることもあり得ない（SQL Server 2000でも同じ）。この排他ロックは無期限ではありません。DBC CHECKDBは20秒（またはセッションに配置されたロックのタイムアウト時間）待ち後、エラーを報告します。
ロックが要求されたら、分配検査が完了したら、排他的ロックはdropされ、テーブルレベルの共有ロックは要求されます。同時に、テーブルレベルの論理整合性検査が実行されます。同じタイムアウトをこれらのレベルのロックに適用します。
いずれにしてもDBCC CHECKDBはチェックしたデータベースの事務レベルの一致図を得てから、データベースの処理を開始することができます。
以下では、データベースを効果的に処理するいくつかの方法に注目します。実際の生成、クエリプロセッサ、バッチ処理、データページの読み込み、プロセスおよび並列メカニズムを使用します。
http://www.cnblogs.com/downmoon/category/230397.html/rss
『Microsoft Sql server 2008 Internals』インデックスディレクトリ：
『Microsoft Sql server 2008 Internal』読書ノート--目次索引
誰がSQL Serverデータベースの整合性をチェックすると言った時、頭の中の第一は「DBCC」であるべきです。SQL Server 7.0では、DBCCはデータベースの整合性検査を代表していますが、その後のバージョンでは、SQL Server 2000において、マイクロソフトは定義を変更して、データベースコンソールコマンドになりました。これはまた，DBCCコマンドが一貫性検査の範囲をはるかに超えているという事実を反映している。
SQL Server自体はデータベースの破損を引き起こしません。しかし、I/Oサブシステム（SQL Serverバッファとディスクドライブのすべての金属酸化物metal oxide）は圧倒的に多くのcoruptionを引き起こします。（このために）一般的な妙技は、すべてのデータベースサーバに何らかの順序付けがあるため、従来の一貫性検査を事前に実行することである。一般的には、週に一回の一貫性検査を実施することが受け入れられます。
整合性検査は、データベースの物理的および論理的構造を検証するプロセスであり、その目的は、破損していないことを確認して、記憶エンジンがデータベースの他の部分を処理することを阻止するか、またはいくつかの不正行為を引き起こす可能性があることを確認することである。
◆耐久性のある計算列の耐久性値の位置が壊れていて、計算結果にマッチしなくなりました。
◆一つ（ページの先の）Page IDがあるデータページの位置が破損しました。
◆記録されたキーの順番がある位置のインデックスが壊れます。
SQL Server 7.0時代に正式に一致検査が行われました。本バージョンではオフライン操作（つまり、テーブルロックが要求されています）を実行するために使用されています。SQL Server 2000では、標準オンラインで動作することを一貫性で確認し、これは新しい効率的なスキャンデータベースの仕組みである。SQL Server 2005において、エンジン内部の整合性チェックと修復コードが著しく書き換えられ、強化されている。SQL Server 2008は新しい機能を追加し、さらに性能と伸縮性を調整しました。
あるデータベースで性能整合性検査を行う最も広範な方法はDBCC CHECKDBを使うことです。詳しい使い方は、http://technet.microsoft.com/zh-cn/library/ms176064.aspxを参照してください。
MSDNコメント：SQL Serverの初期バージョンでは、各テーブル、各インデックス行カウント、およびページカウントの値が正しくない場合があります。特定の場合、1つまたは複数の値は負の値にさえなる。SQL Server 2005およびより高いバージョンでは、これらの値は常に正しいメンテナンスを受ける。したがって、SQL Server 2005およびより高いバージョンで作成されたデータベースにはエラーのカウントは含まれません。しかし、SQL Server 2005およびより高いバージョンにアップグレードすると、エラーのカウントが含まれている可能性があります。これはデータベースに格納されているどのデータも壊れていません。DBCC CHECKDBが強化され、カウント値の一つが負の値になることが検出されます。
DBCC CHECKDBの主な手順は以下の通りである。1、事務レベルの完全かつ静的なデータベースビューを作成する。
2、キーシステム分類のlow-levelの整合性検査を実行する。
3、分配データベースの整合性検査を実行する。
4、データベース内の各テーブルの整合性検査を実行します。
5、前のステップではエラーは発見されていません。以下の表にまたがって一致性検査が行われます。◆service brook erメタデータの一致性検査を行います。
◆各種システム分類（catalog）間の整合性検査を実施します。
◆索引ビューの整合性チェックを行います。
◆XMLインデックスの整合性チェックを行います。
◆空間索引の整合性チェックを行います。
6、出力結果
この章では、私たちは
1、上記の6ステップに基づいて、SQL Server 2008におけるDBCC CHECKDB作業の内幕を知る。
2、各定義可能なオプションについて、DBCC CHECKDB挙動にどのように影響しますか？
3、どうやって修復するかと他のDBCCについての整合性検査コマンドです。
■データベースの持続的なビューを得る
DBCC CHECKDBはデータベースの全割り当てページを分析しなければならないので、multipleを確認する必要があります。 Pagesの各構造間のリンク。これは分析されたページ（データベース全体の）を意味しています。整合性検査が実行されている間は変更できません。DBCC CHECKEDは各種の不正結果を報告します。DBCC CHECKDBコマンドは、データベース内のすべての割り当てられたページを瞬時に読み取ることができないので、データベースの持久図は一貫性検査終了まで継続しなければならない。また、データベースは簡単に凍結されても十分ではないので、DBCC CHECKDBコマンドで見たビューは未完成のものに変更されるように、データベースの耐久ビューも事務レベルの完全なものでなければならない。
ここでは、統合されていないインデックスが記録されたテーブルを挿入することを考慮しながら、一貫性検査のプロセスが実行されていると仮定して、データベースの永続的なビューを強制しませんでした。クエリープロセッサの動作は、最初にテーブルレコードを挿入し、次に一致した非集合インデックスレコードを挿入することである。この仮定の一貫性検査プロセスは、非凝集インデックスを読み込まずにテーブルレコードを読み込むことができ、結果として非凝集インデックスがテーブルと同期されていないという報告をもたらします。
これはどうやって起こったのですか？後ほどお話しします。DBCC CHECKDBは、ある特定の順序でデータベースページを読み、性能を向上させます。この機構を用いて、この例は継続して、非凝集インデックス記録が挿入される前に非凝集インデックスページを読み取ることができ、テーブルレコードが挿入された後にテーブルページを読み取ることもできる。破損があるという結論が出るかもしれません。実際に問題は内部衝突の事務の局所的な結果を見たことである。
■長いビューを取得する
SQL Server 7.0では、トランザクションレベルの永続的なビューは、データベース内のそれぞれの異なるレベルにロックすることによって取得される。これは作業負荷性能に非常に有害である。したがって。SQL Server 2000はオンライン一貫性検査を開始し、閉塞ロックが不要となりました。DBCC CHECKEDは、データベースをスキャンした後、トランザクションログを分析し、必要に応じてデータベース内部ビューの復元を実行することにより、事務レベルのデータベース持久図を作成します。
様々な原因のため、SQL Server 2000ソリューションは不器用で扱いにくいので、SQL Server 2005ではデータベースのスナップショットに取って代わられます。SQL Server 2008では同じ仕組みが使用されている。これは複雑さを大幅に低減した。
第三章でも言及しましたが、データベースのスナップショットは非常に省スペースです。スナップショットが作成されてから変更されたデータベースページだけが含まれます。データベーススナップショットの内容の組み合わせとデータベース内の変化していないページは、変更されていない、トランザクションレベルのデータベースの持続的なビューを提供します。
これはDBCC CHECKDBがオンライン運転を必要とする正確な原因です。データベーススナップショットを作成し、データベーススナップショットを実行する一貫性検査演算は、データベースで実行される読み取り専用コピーの一貫性検査演算概念と同じです。
DBCC CHECKDBはユーザによってアクセスできないデータベーススナップショットを作成します。この隠しデータベーススナップショットは、従来のデータベーススナップショットとは少し違っています。従来のスナップショットはソースデータベースの各データファイルに一つのスナップショットファイルしかありません。各ファイルはデータベーススナップショットが作成された時に明示的に名前を付けなければなりません。DBCC CHECKDBは、隠しデータベースのスナップショットに指定されたファイル名を入力するユーザを許さず、既存のデータベースデータファイルごとにNTFS代替ストリームを作成する。このスナップショットをファイルシステムの隠しファイルと見なしてもいいです。
■ディスク空間衝突
隠しデータベースのスナップショットが実行空間を使い果たして衝突することがあります。既存のデータファイルの代替ストリームを使用して実現されるので、データベーススナップショットはデータファイルと同じ位置で空間を使用する。データベースがチェックされている時に重い作業負荷があると、ますます多くのページがデータベースのスナップショットによって進められ、急速に成長します。このとき、データベースがあるボリュームは、十分なスペースがないと、スナップショットが使えなくなり、DBCC CHECKDBがエラーで停止します。
この場合の解決策は自分のデータベーススナップショットを作成することです。十分なスペースのボリュームを置いてDBCC CHECKDBを再実行すると、DBCC CHECKDBは既に実行されているデータベーススナップショットを認識し、新しいスナップショットを作成しようとしない。
もしスナップショットがDBCC CHECKEDによって作成されたら、一致性検査演算が完了すれば、自動的に廃棄されます。
データベーススナップショットを作成すると同時に、Filestreamゴミ回収プロセスはDBCC CHECKDBを実行する時に保留されています。これにより、任意のFile Stramデータ容器のFileStreamデータの事務レベルの持久図を確認することができます。これは本章の後に紹介されています。
■データベーススナップショットを使う代替案
下記の条件では、データベースのスナップショットは必要ありません。
◆定義されたデータベースはデータベースのスナップショット自体です。
◆定義されたデータベースは読み取り専用、シングルユーザーモードまたはマージモードです。
◆サービスは-mコマンドラインオプションで単一ユーザモードで起動します。
上記の状況では、データベースは完全でなければなりません。他の活動接続による破壊一貫性検査の変化がないからです。
下記の条件ではデータベースのスナップショットを作成できません。
◆指定されたデータベースは非NTFSファイルシステムに格納されています。このとき、データベーススナップショットはNTFSの疎ファイル技術に依存して作成できません。
◆定義されたデータベースはtempdbです（tempdbはデータベーススナップショットを作成できません）
◆TABLockオプションが定義されています。
データベーススナップショットが作成できない場合は、DBCC CHECKDBは、事務レベルのデータベース持久ビューを取得するためにロックを試みる。
まず、それはデータベースレベルの排他的ロックを得て、変化がないという前提で配分一貫性検査を行うことができます。これはマスターデータベースでは不可能です。つまりオフライン一貫性検査はマスターに実行できません。tempdbで、つまりtempdbをスキップすることもあり得ない（SQL Server 2000でも同じ）。この排他ロックは無期限ではありません。DBC CHECKDBは20秒（またはセッションに配置されたロックのタイムアウト時間）待ち後、エラーを報告します。
DBCC
CHECKDB(
'
msdb
'
)
with
tablock;
go
ロックが要求されたら、分配検査が完了したら、排他的ロックはdropされ、テーブルレベルの共有ロックは要求されます。同時に、テーブルレベルの論理整合性検査が実行されます。同じタイムアウトをこれらのレベルのロックに適用します。
いずれにしてもDBCC CHECKDBはチェックしたデータベースの事務レベルの一致図を得てから、データベースの処理を開始することができます。
以下では、データベースを効果的に処理するいくつかの方法に注目します。実際の生成、クエリプロセッサ、バッチ処理、データページの読み込み、プロセスおよび並列メカニズムを使用します。