SQL Server 2008 におけるデータベース エンジン機能の動作の変更

SQL Server 2008 では、パーティション テーブルのデザインが改良され、SQL Server 2005 に比べて、パーティション テーブルに対するクエリ処理中の並列処理が向上しています。 このデザイン変更の副次的結果として、双方向の結合のみを併置できます。 SQL Server 2008 での双方向の併置結合のクエリ プランは、SQL Server 2005 の場合と同じ外観になり、パフォーマンスも SQL Server 2005 と同様です。 固定パーティション分割が施された追加のテーブルが結合に含まれる場合は、たとえば双方向の併置結合に第 3 のテーブルとのハッシュ結合が続くなどの、異なるプランが選択されます。 3 つ以上のテーブル間の併置結合はまれであり、また併置結合は、SQL Server 2008 での並列処理の向上による恩恵を受けません。 ただし、SQL Server 2005 で 3 方向以上の併置結合を実行するクエリがある場合、テーブルのサイズに比べてメモリの量が少なければ、SQL Server 2008 ではそのクエリの実行速度が低下する可能性があります。 この状況でパフォーマンスを向上させる方法には、使用可能なメモリの量を増やす方法や、結果を組み合わせる前に個々のパーティションが個別に結合されるようにクエリを書き直す方法があります。 併置結合の詳細については、「パーティション テーブルとパーティション インデックスに対するクエリ処理の機能強化」を参照してください。

SQL Server には、スター結合を有するクエリの処理のための、ハッシュ結合とビットマップ フィルターを使用する新しい最適化が含まれています。 ファクト テーブルをディメンション テーブルにスター スキーマで結合することによる大量のデータをクエリで処理する場合、新しい最適化を使用するクエリ プランは、従来よりもはるかに高速に実行できます。 

したがって、既存のクエリがスター結合のパターンに適合する場合は、新しいクエリ プランが表示されることがあります。 クエリ オプティマイザーは、クエリ パフォーマンスが向上すると推定される場合に、このプランを選択します。 しかし、コストの推定に使用される統計が不正確な場合、クエリ オプティマイザーは、別のプランのほうが高速であっても、スター結合の最適化を選択する可能性があります。

max degree of parallelism 構成オプションまたは MAXDOP インデックス オプションが 1 に設定されている場合、クエリ オプティマイザーはスター結合最適化を使用せず、ユーザーは新しいスター結合の最適化によるメリットを実感できません。 クエリ実行システムが、1 つのスレッドのみによる並列プランで最適化されたクエリをディスパッチした場合、一部のビットマップ フィルターが複数ビットマップ フィルターのスター結合プランから削除されることがあります。 この変更により、たとえば 2 つのスレッドを 1 つのスレッドにしたときに、実行が予想以上に遅くなることがあります。

スター結合最適化は、SQL Server の Enterprise Edition、Developer Edition、および Evaluation Edition でのみ使用できます。 ビットマップ フィルターの詳細については、「ビットマップ フィルタを使ったデータ ウェアハウスのクエリ パフォーマンスの最適化」を参照してください。 ビットマップ フィルターを含むクエリ プランを解釈する方法の詳細については、「ビットマップ フィルタを含んだ実行プランの解釈」を参照してください。 スター結合の最適化の詳細については、TechNet Magazine の記事「データ ウェアハウスのクエリ パフォーマンス」を参照してください。

SQL Server 2008 では、結合外部の行が少ない場合に、入れ子になったループ結合の並列処理が促進されます。 SQL Server 2005 では、複数のスレッドが使用可能な場合、各スレッドに結合外部から行のページが割り当てられます。 行が少ない場合、それらの行は同じページに含まれる可能性があります。 その場合、1 つのスレッドしか利用されず、並列処理の潜在的な利点が失われます。SQL Server 2008 では、そのような場合を考慮し、スレッドごとに 1 つの行を割り当てて、使用可能なすべての CPU が利用されるようにする、交換操作が導入されています。 並列処理の向上により、CPU 消費率は SQL Server 2005 に比べて一時的に増加しますが、クエリの実行は高速になります。 この新しい動作は、外部行の数が少なく、クエリのコストが追加の並列処理による恩恵を受けるのに十分な大きさであると推定される場合にのみ行われます。 クエリ コストが小さいと推定される場合、または外部の基数の推定が 1,000 を超える場合、SQL Server では、SQL Server 2005 と同じように、スレッドごとに 1 つのページが割り当てられます。 交換操作および並列クエリ処理の詳細については、「並列クエリ処理」を参照してください。

SQL Server 2008 では、パーティション テーブルとインデックスでのクエリの処理方法が異なります。 USE PLAN ヒントを使用する、パーティション分割されたオブジェクトのクエリには、無効なプランが含まれる場合があります。 SQL Server 2008 にアップグレードした後は、次の手順を実行することをお勧めします。

USE PLAN ヒントがクエリ内で直接指定されている場合 :

1. USE PLAN ヒントをクエリから削除します。

2. クエリをテストします。

3. オプティマイザーによって適切なプランが選択されない場合は、クエリをチューニングし、USE PLAN ヒントを必要なクエリ プランと共に指定します。

USE PLAN ヒントがプラン ガイドで指定されている場合 :

1. sys.fn_validate_plan_guide 関数を使用して、プラン ガイドの有効性を確認します。 また、SQL Server Profiler で、Plan Guide Unsuccessful イベントを使用して無効なプラン ガイドを確認することもできます。

2. プラン ガイドが無効な場合は、プラン ガイドを削除します。 オプティマイザーによって適切なプランが選択されない場合は、クエリをチューニングし、USE PLAN ヒントを必要なクエリ プランと共に指定します。

パーティション分割されたオブジェクトでのクエリ処理の詳細については、「パーティション テーブルとパーティション インデックスに対するクエリ処理の機能強化」を参照してください。

SQL Server 2005 では、Resource データベースのデータ ファイルとログ ファイルは、master データベースのデータ ファイルの場所に依存します。 そのため、master データベースを移動する場合は、Resource データベースも同じ場所に移動する必要があります。 SQL Server 2008 では、この依存関係はありません。 master データベースのファイルを移動する場合に Resource データベースを移動する必要はありません。

SQL Server 2008 では、Resource データベースの既定の場所は、<drive>:\Program Files\Microsoft SQL Server\MSSQL10.<instance_name>\Binn\ です。 Resource データベースを移動することはできません。

SQL Server の以前のバージョンでは、tempdb データベースの PAGE_VERIFY データベース オプションは NONE に設定されており、変更できません。 SQL Server 2008 では、SQL Server の新規インストールに対する tempdb データベースの既定値は CHECKSUM です。 インストール済みの SQL Server をアップグレードした場合、既定値は NONE のままです。 このオプションは変更できます。 tempdb データベースでは CHECKSUM を使用することをお勧めします。

SQL Server 2008 では、lax 検証のサポート、xs:date、xs:time、および xs:dateTime のインスタンス データの処理の強化、list 型と union 型のサポートの追加など、XML スキーマのサポートがいくつかの点で拡張されています。 ほとんどの場合は、アップグレードの際にこれらの変更を意識する必要はありません。 ただし、SQL Server 2005 で、xs:date 型、xs:time 型、または xs:dateTime 型 (またはこれらのサブタイプ) の値を許可する XML スキーマ コレクションを使用していた場合は、SQL Server 2005 データベースを SQL Server 2008 にアップグレードすると、以下のアップグレード手順が実行されます。

1. XML スキーマ コレクションに xs:anyType、xs:anySimpleType、xs:date (またはそのサブタイプ)、xs:time (またはそのサブタイプ)、または xs:dateTime (またはそのサブタイプ) として型指定されている要素や属性、あるいはこれらの型を含む union 型または list 型の要素や属性が含まれる場合、その XML スキーマ コレクションで型指定されているすべての xml 列で、次の状況が発生します。

   1. 列のすべての XML インデックスが無効になります。

   2. SQL Server 2005 の値はすべて Z タイム ゾーンで正規化されているため、引き続き Z タイム ゾーンで表されます。

   3. 1 年 1 月 1 日より小さい xs:date 値や xs:dateTime 値があると、インデックスが再構築されるときや、その値を含む xml データ型に対して XQuery ステートメントや XML-DML ステートメントが実行されるときに、ランタイム エラーが発生します。

2. xs:date ファセット、xs:dateTime ファセット、または XML スキーマ コレクションの既定値に負の年がある場合は、xs:date 基本型または xs:dateTime 基本型で許可されている最も小さな値に自動的に更新されます。 たとえば、xs:dateTime の場合は 0001-01-01T00:00:00.0000000Z になります。

負の年が含まれていても、単純な SQL SELECT ステートメントを使用して xml データ型全体を取得することはできます。 負の年は、新たにサポートされた範囲内の年に置き換えるか、要素や属性の型を xs:string に変更することをお勧めします。 詳細については、「型指定された XML と型指定されていない XML の比較」を参照してください。

SQL Server 2005 では lax 検証がサポートされていなかったため、anyType 型の要素にも strict 検証が適用されていました。 SQL Server 2008 では、anyType 型の要素の内容は lax 検証を使用して検証されます。 詳細については、「ワイルドカード コンポーネントと内容検証」を参照してください。