SQL Server 2008

企業データベースの変更を追跡する

Paul S. Randal

概要 :

• 変更を追跡する必要性
• SQL Server 2005 における変更の追跡
• SQL Server 2008 における変更の追跡
• SQL Server 2008 の Change Data Capture

目次

SQL Server 2005 における変更の追跡方法
SQL Server 2008 で簡単になった変更の追跡
Change Data Capture のしくみ
変更の追跡のしくみ
まとめ

開発者が SQL Server を使用するときに直面する最も難しい問題は、データベース内のどのデータが変更されたかを追跡することです。また、さらに難しい問題は、ワークロードのパフォーマンスに大きな影響を与えず、簡単に作成、実装、および管理できる単純なソリューションを設計することです。では、なぜわざわざ変更を追跡する必要があるのでしょうか。その作業に見合う成果は得られるでしょうか。よく引き合いに出される 2 つの例は、データ ウェアハウスの更新をサポートすることと、常時接続されない異種システムの同期をサポートすることです。

通常、データ ウェアハウスのオンライン トランザクション処理 (OLTP) データベースには、なんらかの形式で表現されたテーブルが格納されますが、それらのテーブル スキーマは大きく異なる場合があります。これは、データを OLTP データベースからデータ ウェアハウスに移動する ETL (抽出、変換、読み込み) 処理が必要であることを示しています。

考えられる方法は 3 つあります。1 つ目は、データ ウェアハウス全体を定期的に更新する方法です。これはデータの量が多い場合は明らかに現実的ではなく、データ ウェアハウスの更新も連続的に行われません。2 つ目は、OLTP データベースのパーティション構成を使用して、ETL 処理で前回の ETL 処理から変更されたデータのみを処理できるようにする方法です。この方法は、データの挿入に対してのみ有効で、更新や削除に対しては適切に機能しません。また、複雑なメカニズムを使用してパーティション境界の定義やパーティションの切り替えを管理する必要があります。3 つ目は、OLTP データの変更を追跡し、変更されたデータのみを使用した ETL 処理を実行する方法です。これは、データ量の観点から考えると最も効率的な方法です。

今日のビジネス環境では、至るところでモバイル デバイスが使用されるので、常時接続されないシステムへの対処が必要です。データベース システムに関連する問題は、頻繁に接続されないデバイス上のデータ ストアをどのように効率よく更新するかということです。特にデータ ストア自体が小さく、スキーマがメイン データベースとまったく異なる可能性がある場合、この問題に対処することは重要です。

たとえば、移動の多い営業担当者が、非常に大きな製品カタログの一部を管理する場合について考えてみましょう。この担当者は毎晩、モバイル デバイスからメイン データベースに接続して最新のデータをダウンロードします。製品カタログ内でこの担当者が管理している部分の変更はすべて、モバイル デバイスの記憶域用に単純化されます。このデータ転送は、できるだけ効率的に行う必要があります。

まず、製品カタログ内でこの担当者に関連する部分全体をデバイスにダウンロードできるようにデータベース システムでデータを準備し、デバイスでそのデータをダウンロードする方法が考えられます。つまり、データが変更されていない場合でも、デバイスが接続するたびにすべてのデータがダウンロードされます。これは明らかに効率の悪い方法です。

もう 1 つは、データベース システムで、この担当者に関連する部分の変更を追跡する方法です。モバイル デバイスでは、接続時に前回の接続時から変更されたデータを要求します。この方法であれば、データベース システムでデータのサブセットのみを準備すればよいので、ダウンロードを可能な限り効率的に実行できます。

変更を追跡するもう 1 つの理由は、最近では不可欠になった監査をサポートすることです。監査では、発生した変更の内容だけでなく、変更の発生日時や変更元も追跡されます。これによって、監査記録全体にわたって、永続性、セキュリティ、および正確性に関する厳密な制約が適用されるので、あらゆる面で向上が見られます。

SQL Server 2008 で提供されるデータ変更の追跡用に設計されたテクノロジでは、監査のサポートが考慮されませんでした。ただし、SQL Server 2008 では、監査に特化して設計された SQL Server Audit という新機能が提供されます。SQL Server Audit 機能については、Rick Byham が TechNet Magazine 2008 年 4 月号の「SQL Server 2008: セキュリティ」(technet.microsoft.com/magazine/cc434691) で説明しています。

ここまで説明してきた多くの理由を考慮すると、データの変更を追跡しないわけにはいきません。そこで浮かんでくる重要な疑問は、最も効率的に追跡を行うにはどうすればよいかということです。

SQL Server 2005 における変更の追跡方法

SQL Server 2005 (および SQL Server のそれ以前のバージョン) では、あらかじめ準備された単純なソリューションは提供されません。このようなプラットフォームでは、開発者はアプリケーションに応じたカスタム ソリューションを作成し、通常はタイムスタンプ列、DML (データ操作言語) トリガ、および追加のテーブルを含める必要がありました。ただし、このようなソリューションは、さまざまな問題を引き起こす可能性があります。次に例を示します。

• タイムスタンプ列を追加すると、テーブル スキーマが変更されます (それに伴い、ストアド プロシージャとその他のコードも影響を受ける可能性があります)。
• 暗黙的に、DML トリガは自身を起動する DML を含むトランザクションの一部になるので、DML トリガの実行分だけトランザクションの実行時間が長くなります。トリガが複雑になるほど、その実行時間は長くなり、ワークロードのパフォーマンスも低下します。変更の追跡に使用する DML トリガでは、すべての変更を収集して別の追跡テーブルに挿入できるように、挿入および削除されるテーブルを処理する必要があります。
• 追跡テーブルは、扱いきれないほど大きくならないように、なんらかの方法で管理する必要があります。たとえば、エージェント ジョブのようなものを作成して定期的に古いデータを削除します。

SQL Server 2008 で簡単になった変更の追跡

SQL Server 2008 では、データの変更をより簡単に追跡できる、2 つの新しいテクノロジが導入されます。これらは、変更の追跡と Change Data Capture です。どちらの機能でも、変更されたデータが追跡される (さらに挿入、更新、または削除操作によってデータの変更内容が正確に追跡されます) ので、カスタム ソリューションを作成する必要がなくなります。このような類似点を別にすると、これら 2 つの機能のメカニズムと厳密な追跡対象は大きく異なります。

Change Data Capture では、テーブル (または定義された一連のテーブル列) で発生した、列の値自体を含むすべての変更を追跡する非同期メカニズムが使用されます。この機能は、先ほど説明したデータ ウェアハウスの ETL 処理のようなシナリオに対処することを目的としています。

図 1 は、使用される変更データを時間の流れに沿って示しています。Change Data Capture のメカニズムでは、変更されたデータが一連のテーブルに抽出され、最後に発生した変更がテーブルの先頭に配置されます。その後 ETL 処理で、特定の期間内に発生したすべての変更が、変更データを保持するテーブルに照会されます。このメカニズムによって、1 回の ETL 処理で使用する必要があるデータの量を制限できるようになります。

図 1 使用される変更履歴データと時間の流れ (図をクリックすると拡大表示されます)

一方、変更の追跡では、テーブル内の変更された行のみを追跡する (変更された列の一覧も必要に応じて追跡できます) 同期メカニズムが使用されます。この機能は、先ほど説明した、常時接続されないシステムに関するシナリオなどの問題に対処することを目的としています。この機能のしくみを 図 2 に示します。

図 2 常時接続されないシステムによる変更追跡データの使用 (図をクリックすると拡大表示されます)

どちらの機能を使用する場合でも、I/O とログ記録の回数は増加しますが、これはカスタム ソリューションの場合も同様です。変更データは必ずどこかに格納する必要があります。これら 2 つの機能とカスタム ソリューションとの間で異なる可能性があるのは、変更データの格納に使用するテーブルが、追跡するテーブルと同じデータベースに格納されている必要があることです。これは、すべての変更データがバックアップに含まれ、ログ配布やデータベース ミラーリングによってネットワーク経由で転送される可能性があることを意味します。

開発の観点から見ると、これら 2 つの機能によって、変更の追跡に関連する複雑さの多くが取り除かれます。どちらのテクノロジでも、テーブル スキーマを変更したりトリガを用意したりする必要はありません。また、どちらのテクノロジでも、構成可能な自動クリーンアップ処理、トランザクションのコミット回数に基づいた変更の並べ替え、および変更情報を取得するための組み込み関数が提供されます。

管理の観点から見ると、どちらの機能にも長所と短所があります。他のテクノロジと同様、これらの機能を使用するソリューションを開発して展開するには、多くの情報を理解する必要があります。この記事の残りの部分では、各機能の概要を紹介し、それぞれのしくみと、運用環境でこれらを使用する前に実用面で考慮する必要があることについて説明します。

Change Data Capture のしくみ

Change Data Capture は、追跡中のテーブルを変更するトランザクションの一部としては何も処理を行いませんが、通常どおりにトランザクション ログに書き込まれた挿入、更新、および削除操作を、定期的にログから収集します。収集は SQL エージェントのログ リーダー ジョブによって実行され、収集された操作が変更テーブルと呼ばれる別のテーブルに格納されます。後から 2 つの関数のいずれかを使用して、変更テーブルに変更データを照会して取得できます。変更テーブルと 2 つの関数の組み合わせは、キャプチャ インスタンスと呼ばれます。図 3 は、Change Data Capture を使用してデータ ウェアハウスの ETL 処理を実行するときのデータの流れを示しています。

Change Data Capture を有効にするには、2 段階の処理が必要です。まず、sysadmin 固定サーバー ロールのメンバが、sys.sp_cdc_enable_db を使用してデータベースの Change Data Capture を有効にする必要があります。次に、db_owner 固定サーバー ロールのメンバが、sys.sp_cdc_enable_table を使用して特定のテーブルの Change Data Capture を有効にする必要があります。これらのセキュリティ要件が適用される理由は、Change Data Capture が適切に構成されなかった場合、ディスク使用率が高くなる可能性があるからです。テーブルの所有者がこの機能を有効にし、ディスク使用率の上昇によってデータベース管理者を驚かせることがあってはたいへんです。

データベースで Change Data Capture を有効にすると、cdc という新しいスキーマ、いくつかのメタデータ テーブル、データ定義言語 (DDL) イベントをキャプチャするトリガなどがデータベースに追加されます (個人的に気に入っているのは、DDL によってテーブルに加えられた変更の一覧を取得できる機能です)。

Change Data Capture を有効にすると、テーブルのキャプチャ インスタンス (変更テーブルと、変更データを返す最大 2 つの関数) も作成されます。変更テーブル名は、キャプチャ インスタンス名に _CT が付加された名前です。1 つ目の関数は必ず作成され、変更テーブルから変更データを返すために使用されます。2 つ目の関数は、差分変更を許可するオプションを指定したときに使用されます。この場合、キャプチャされたすべての変更の最終的な結果のみが返され、1 つ目の関数によって返される中間の変更はすべて返されません。2 つの関数の名前は、それぞれ fn_cdc_get_all_changes_ と fn_cdc_get_net_changes_ で、これにキャプチャ インスタンス名が付加されます。この機能を使用するには、(変更の追跡機能の場合と同様) テーブルに主キーまたはその他の一意インデックスが設定されている必要があります。

データベース内の 1 つ目のテーブルの構成を変更して Change Data Capture を有効にすると、2 つの SQL エージェント ジョブが作成される場合があります。これらは、キャプチャ ジョブとクリーンアップ ジョブです。作成される "場合がある" と言った理由は、キャプチャ ジョブはトランザクション レプリケーションでトランザクションの収集に使用されるものと同じジョブだからです。既にトランザクション レプリケーションが構成されている場合は、クリーンアップ ジョブのみが作成され、既存のログ リーダー ジョブがキャプチャ ジョブとして使用されます。この機能が優れている理由は、2 つのログ リーダー ジョブが作成された場合、その直後にログで競合が発生し、パフォーマンスが低下するからです。いずれにしても、SQL エージェントが実行中でなければ、Change Data Capture は使用できません。

ログ リーダーのロジック内で、テーブルの Change Data Capture を有効および無効にする処理が自動的に実行され、その結果に応じてトランザクション ログから収集されるデータが変わります。ここで 1 つ重要なことがあります。それは、一度 Change Data Capture を有効にすると、トランザクション ログはトランザクション レプリケーションの場合と同じように動作することです。つまり、トランザクション ログはログ リーダーによって処理されるまで切り捨てられません。これは、単純復旧モードの場合でも、チェックポイントの操作ではログが切り捨てられず、ログ リーダーによって処理された時点で切り捨てられることを意味します。

また、一括ログ復旧モデルを使用してログ記録の回数を減らした場合、Change Data Capture によって、作成、削除、再構築を除くすべての操作が強制的にログに記録されます。このような動作を経験したことがない場合は、これによってトランザクション ログのサイズに関する問題が発生する可能性があることに注意してください。特に、ログが頻繁に処理されないようにキャプチャ ジョブの既定値を変更した場合は、注意が必要です。

既定では、キャプチャ ジョブは連続的に実行され、5 分おきにログをスキャンし、ログに記録されている最大 500 件のトランザクションを処理します。また、クリーンアップ ジョブは既定で毎日午前 2 時に実行され、3 日以上前の変更データ エントリをすべて削除します。これらの設定は sys.sp_cdc_change_job プロシージャを使用して変更できます。変更は、sys.sp_cdc_stop_job と sys.sp_cdc_start_job を使用してジョブを再起動するまで有効になりません。

通常、ログ リーダーの処理はシステムのパフォーマンスにあまり影響を与えませんが、データが頻繁に変更される負荷の高い OLTP システムでは、ログ リーダーの処理が 1 つ増加しただけでも、トランザクション ログで競合が発生する可能性があります。実際の競合は、トランザクションによってログが書き込まれる場所と、ログ リーダーの処理によってログが読み取られる場所との間をディスク ヘッドが行き来することによって発生します。この場合、OLTP のパフォーマンスが低下しないように、キャプチャ ジョブの実行頻度を変更した方がよいでしょう。ただし、これによって、お馴染みのディスク領域とパフォーマンスとの間のトレードオフが生じます。ログの数は、キャプチャ ジョブによって処理されるまで増加し続けます。

クリーンアップ ジョブの頻度や変更データの保有期間を変更した場合にも同じ問題が発生します。変更データがクリーンアップされるまで、変更テーブルのサイズは増加し続けます。このため、大規模な設計では、追跡するデータの種類とその保有期間を検討する必要があります。検討が必要な重要事項を次に示します。

• キャプチャ インスタンスに必要な列の一覧。キャプチャする列の数が増加すると、変更テーブルに挿入される変更データの量も増加します。
• 変更テーブルによって使用されるディスク領域の量。
• 変更データを使用する処理の実行頻度。データは使用されるまで削除できないことを覚えておいてください。
• クリーンアップ処理の実行頻度。たとえば、大量の変更データが生成され、クリーンアップ処理で大量のトランザクション ログが作成されることを理由に、この処理を週末にしか実行できない場合があります。

Change Data Capture の構成を変更して、単にテーブルで発生したすべての変更を追跡したり、テーブル内の列のサブセットを追跡したりできます。重要でない列が非常に大きな varchar 列やバイナリ ラージ オブジェクト (BLOB) 列 (テキスト、イメージ、XML など) である場合は、サブセットを使用すると便利です。サブセットを使用しなければ、変更テーブルによって使用される領域がすぐに増加し、手に負えなくなってしまいます。

Change Data Capture を有効にする場合、ディスク領域の使用率が高くなる可能性を考慮して、変更テーブルのファイル グループを格納する場所を設定するとよいでしょう。これによって、基になるディスク領域を管理しやすくなり、メイン データベースよりもコストのかからない RAID レベルのボリュームにすべての変更データを格納できる可能性があります。また、すべてのキャプチャ インスタンスにクリーンアップ ジョブの設定が適用されますが、ディスク領域に関する問題が発生した場合は、いつでも各キャプチャ インスタンスを個別にクリーンアップできます。キャプチャ テーブルで sp_spaceused を使用すると、ディスク領域の使用状況を簡単に監視できます。

実際に変更テーブルに書き込まれる行には、トランザクションに関するメタデータ (コミット ログ シーケンス番号 (LSN))、トランザクション内で変更が発生した順序、操作の内容、変更された列を示すビットマスク、および実際の列の値が含まれます。

Change Data Capture が有効になっている場合、DDL が加える変更に制約は適用されません。ただし、列が追加または削除された場合、収集される変更データにこれらの変更がなんらかの影響を与える可能性があります。追跡中の列が削除された後で、キャプチャ インスタンスのその列に追加されるエントリは、すべて NULL になります。列が追加された場合、キャプチャ インスタンスはその列を無視します。つまり、キャプチャ インスタンスの構造は作成時に設定されます。

列を変更する必要がある場合は、テーブル用に別のキャプチャ インスタンス (テーブルごとに最大 2 つのキャプチャ インスタンス) を作成し、変更データのコンシューマを新しいテーブル スキーマに移行できる場合があります。ただし、追跡するテーブル用に 2 つのキャプチャ インスタンスを作成すると、使用されるディスク領域、および I/O やログ記録の回数も 2 倍になるので、注意が必要です。

あまり詳しい知識がなくても、これまでに説明した関数を使用すれば、変更テーブルから変更を取得できます。これらの関数では開始 LSN と終了 LSN が使用されますが、通常の時間を LSN に変換できる他の関数も提供されます。また、変更を取得するときに、変更前と変更後の値、または変更前の値のみを取得するよう指定できます。www.technetmagazine.com/video では、私が Change Data Capture の使用方法を紹介するスクリーンキャストが公開されています。

変更の追跡のしくみ

先ほど説明したとおり、変更の追跡は同期処理で、Change Data Capture に比べると複雑さは大幅に低下します。この処理は、追跡するテーブル内の行に変更を加えるトランザクションの一部です。変更された行は、別のテーブル内で追跡されます。このテーブルは内部テーブルと呼ばれ、その名前や格納先は制御されませんが、私はこのことが問題になるとは思いません。その理由は、このテーブル内のデータは、Change Data Capture に使用される変更テーブル内のデータよりも大幅に少なくなるからです。ただし、ディスク領域に関する問題は依然として残ります。これについては、この後すぐに説明します。

変更の追跡は同期を取って行われるので、追跡中のテーブルを変更する各トランザクション内で追加の処理が発生します。パフォーマンスへの影響は、テーブル上に非クラスタ化インデックスが存在し、テーブルで変更が発生するたびにそのインデックスを更新しなければならない場合と同様です。トランザクション自体も、sys.syscommittab 内部テーブル内の行によってコミットされたときに追跡されます。

変更の追跡を有効および無効にするには、通常の ALTER DATABASE 構文と ALTER TABLE 構文を使用します。この場合、Change Data Capture と同じモデルに従い、テーブル レベルよりも前のデータベース レベルで変更の追跡を有効にする必要があります。この一連の操作を次に示します。

ALTER DATABASE AdventureWorks2000 SET CHANGE_TRACKING = ON (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON); GO USE AdventureWorks2000; GO ALTER TABLE Person.Person ENABLE CHANGE_TRACKING WITH (TRACK_COLUMNS_UPDATED = ON); GO

変更の追跡をデータベース レベルとテーブル レベルで有効にするための権限も、Change Data Capture を有効にするための権限とは異なり、前者は db_owner、後者はテーブルの所有者です。データベース レベルで変更の追跡を有効にする場合、保有期間と、変更データを自動的にクリーンアップするかどうかを設定できます。既定の保有期間は 2 日間で、最長 90 日、最短 1 分の期間を設定できます。

自動クリーンアップも既定で有効になっています。これらの設定に変更を加えるときは、先ほど説明した Change Data Capture の場合と同じトレードオフを評価する必要があります。つまり、ディスク領域とパフォーマンスのトレードオフを、アプリケーション要件に基づいて評価します。

既定では、各行の変更されたデータのみがキャプチャされます。この操作では、変更された行の主キー (テーブルで変更の追跡を有効にするには、そのテーブルに主キーが設定されている必要があります)、バージョン番号 (変更の追跡を有効にするとバージョン番号が設定され、操作の順序付けが可能になります)、および変更操作の種類が記録されます。どの列が変更されたかを追跡することもできますが、これには変更された列ごとに 4 バイトの領域が必要です。

ディスク領域の監視は変更の追跡とは若干異なります。ディスク領域の監視では、変更データが内部テーブルに格納されます。使用されている内部テーブルの名前を確認するには、次のように sys.internal_tables システム カタログ ビューを使用するだけです。

SELECT [name] FROM sys.internal_tables WHERE [internal_type_desc] = 'CHANGE_TRACKING'; GO

その後、テーブル名を sp_spaceused に渡して、使用されているディスク領域の量を確認します。

Change Data Capture とは異なり、変更の追跡を有効にすると、追跡中のテーブルで実行できる DDL に関する制約が課されます。最も注意が必要な制約は、どのような方法を使用しても主キーを変更できないことです。ここで紹介しておく必要があるもう一つの制約は、変更の追跡が有効になっているテーブルで ALTER TABLE SWITCH を実行すると、処理が失敗することです。多くの場合、ALTER TABLE SWITCH が失敗する理由は、変更追跡中のパーティションをパーティション テーブルから切り替えるとき、または変更追跡中のテーブルをパーティション テーブルに切り替えるときに、それぞれの変更の追跡を自動的に開始または削除することが適切な処理ではないからです。

変更は、新しい CHANGETABLES (CHANGES …) 関数を使用して内部の変更テーブルから取得します。この関数は、変更を追跡しているテーブルの名前と、そのテーブルが前回使用されたときのバージョン番号を使用し、前回から変更されたすべての行に関する情報を返します。現在の有効なバージョンと最も古い有効なバージョンを確認するには、さまざまな関数を使用できます。その後アプリケーションは、返された情報を使用して、変更を追跡しているテーブルに実際の列の値を照会できます。もちろんこれは複数段階の処理になります。まず現在のバージョンを取得し、そのバージョンを使用して変更の追跡に照会した後、そのバージョンに一致する列データを実際のテーブルに照会します。

絶えず変更が発生するシステムでは、バージョン、変更データ、および実際のデータが変更されないなんらかのビューを用意しなければ、一貫性のない不正確な結果が返される可能性があります。このようなビューを用意するには、スナップショット分離を使用し、複数段階の処理を明示的なトランザクションにラップします。この方法は適切に機能しますが、潜在的な欠点があります。スナップショット分離は、ワークロードのパフォーマンスに影響を与える可能性があります。また、この処理はパフォーマンスと tempdb による領域の使用率にも影響を与えます。詳細については、technet.microsoft.com/library/cc280358 を参照してください。

まとめ

図 4 では、変更の追跡と Change Data Capture を比較しています。この図を使用して、DBA が考慮する必要がある重要な相違点について詳しく理解できます。この比較結果からは、Change Data Capture の方が変更の追跡よりも多くのディスク領域を使用することがわかります。このため、Change Data Capture の追跡対象を判断するときは、より一層の注意が必要です。追跡するテーブルに BLOB 列や非常に大きな行などが含まれている場合、より短い時間で追跡テーブルのサイズが大きくなってしまう可能性があります。また、トランザクション ログの管理に関する問題が発生する可能性もあります。その理由は、ログ リーダーによってトランザクション ログからレコードが収集されるまで、このログが切り捨てられないからです。

図 4 変更の追跡と Change Data Capture の比較

変更の追跡を有効にする場合、必ずなんらかの要件が生じます。たとえば、主キーを設定する必要があります。また、スナップショット分離を使用することも強く推奨されています。スナップショット分離自体はワークロードで大きなオーバーヘッドを発生させる可能性があり、tempdb をより注意深く管理することも必要になります。

さらに、開発者と DBA が対処する必要があるもう一つの問題があります。それは障害回復です。この記事の範囲外なので詳しくは説明しませんが、障害回復というトピックは非常に重要なので、少なくともここで言及だけはしておこうと思います。

どちらの機能でも、優れたバックアップと復元が提供されます。問題は、データベースが復元され、実質的に以前の状態に戻されたときです。このとき、アプリケーションとシステム全体がどのように動作すればよいでしょうか。変更の追跡用にカスタム ソリューションを設計する場合も、この問題に直面します。また、SQL Server 2008 を使用する場合も、引き続きこの問題を考慮する必要があります。

新機能を使用して変更を追跡するソリューションの設計および展開プロジェクトに着手する前に、いつものように、提供されているすべてのドキュメント (technet.microsoft.com/library/bb418491) とホワイト ペーパーに目を通してください。まず、この記事に記載されていないなんらかの問題が使用中の環境で発生する可能性があるかどうかを調べます。また、新しい監視 SP および動的管理ビュー (DMV) の詳細についても確認する必要があります。

全体的に見て、これらの新機能は、データ変更を追跡する以前の方法から飛躍的に進化しています。このため、皆さんが管理するソリューションの開発者が、これらの機能を使用したくなることは間違いないでしょう。

構成と管理について考慮する必要がある重要な問題はいくつかありますが、テクノロジの概要がきちんと説明されているこの記事を参考に、記事内で挙げた問題を予測し、それに備えていただければさいわいです。この記事に関するご意見やご質問は Paul@SQLskills.com (英語のみ) までお寄せください。

Paul S. Randal は SQLskills.com の代表取締役であり、SQL Server MVP でもあります。1999 年から 2007 年までは、マイクロソフトの SQL Server ストレージ エンジン チームに所属していました。また、『DBCC CHECKDB/repair for SQL Server 2005』を執筆し、SQL Server 2008 の開発時にはコア ストレージ エンジンを担当していました。Paul は障害回復、高可用性、およびデータベース メンテナンスの専門家であり、世界中のカンファレンスで定期的に発表を行っています。彼のブログは SQLskills.com/blogs/paul で公開されています。