• [アーティクル]

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

このトピックでは、データベース エンジンの動作変更について説明します。 動作変更によって、SQL Server 2008 の機能や操作方法が SQL Server の以前のバージョンとは異なっています。

SQL Server エージェント

SQL Server エージェント タスクのスクリプト作成時の動作に対する変更

SQL Server 2008 では、既存のジョブからスクリプトをコピーして新しいジョブを作成する場合、意図に反して新しいジョブが既存のジョブに影響を及ぼす場合があります。 既存のジョブのスクリプトを使用して新しいジョブを作成する場合、パラメーター @schedule\_uid を手動で削除してください。このパラメーターは、通常、既存のジョブ内でジョブ スケジュールを作成するセクションの最後のパラメーターです。 このパラメーターを削除することによって、既存のジョブに影響を及ぼさずに新しいジョブに対する新しい独立したスケジュールを作成できます。

access check cache オプション

SQL Server 2005 では、access check result cache 内部構造は、トレース フラグを使用しなければ構成できませんでした。 SQL Server 2008 では、access check cache オプションを使用して、この構造を変更できます。 詳細については、「access check cache オプション」を参照してください。

フルテキスト検索

SQL Server 2008 では、新しいフルテキスト検索アーキテクチャが導入されています。 フルテキスト検索エンジンは、独立したサービスではなく、SQL Server データベース エンジンに完全に統合されています。 統合により、フルテキスト検索の管理性、スケーラビリティ、セキュリティ、およびパフォーマンスが SQL Server の以前のリリースよりも向上しています。 SQL Server 2005 と SQL Server 2008 のフルテキスト検索の主な相違点と、この新しい統合型フルテキスト検索エンジンに関連するベスト プラクティスの詳細については、MSDN の記事「SQL Server 2008 のフルテキスト検索の内部と改良点」を参照してください。

リンク サーバー

SQL Server 2008 では、ループバック リンク サーバーに対して実行される INSERT...EXECUTE ステートメントのトランザクション セマンティクスが変更されています。 SQL Server 2005 では、このシナリオはサポートされていないのでエラーになります。 SQL Server 2008 では、接続で複数のアクティブな結果セット (MARS) が有効になっていない場合、INSERT...EXECUTE ステートメントをループバック リンク サーバーに対して実行できます。 接続で MARS が有効になっている場合は、SQL Server 2005 と同じ動作になります。

並列処理

パーティション テーブルのクエリ処理と並列処理

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 つのページが割り当てられます。 交換操作および並列クエリ処理の詳細については、「並列クエリ処理」を参照してください。

USE PLAN ヒントを使用するパーティション テーブル クエリ

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 2008 では、プラン ガイドが受け入れられない場合、クエリは別のプランを使用してコンパイルされ、エラーは返されません。 SQL Server 2005 では、エラーが発生し、クエリは失敗します。

SQL Server 2005 で作成されたプラン ガイドは、SQL Server 2008 へのアップグレード後に無効になる場合があります。 無効なプラン ガイドが原因でアプリケーションが失敗することはありませんが、そのプラン ガイドは使用されません。 アプリケーションを新しい SQL Server のリリースにアップグレードした場合は、プラン ガイドの定義を再評価し、テストすることをお勧めします。 新しいリリースでは、パフォーマンス チューニングの要件とプラン ガイドの照合動作が異なる場合があります。 SQL Server 2008 にデータベースをアップグレードした後に、既存のプラン ガイドを sys.fn_validate_plan_guide 関数を使用して検証してください。 また、SQL Server Profiler で、Plan Guide Unsuccessful イベントを使用して無効なプラン ガイドを監視することもできます。

クエリ プロセッサ アーキテクチャ

SQL Server 2008 では、パーティション テーブルとインデックスでのクエリの処理方法が異なります。 SQL Server 2005 で生成されたプランに USE PLAN ヒントを使用する、パーティション分割されたオブジェクトのクエリには、無効なプランが含まれる場合があります。 詳細については、「データベース エンジンのアップグレードに関する注意点」を参照してください。 パーティション分割されたオブジェクトでのクエリ処理の詳細については、「パーティション テーブルとパーティション インデックスに対するクエリ処理の機能強化」を参照してください。

REPLACE 関数

SQL Server 2005 では、REPLACE 関数の最初の入力パラメーターが char 型である場合、その入力パラメーターに指定された末尾のスペースが切り捨てられます。 たとえば、SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>' というステートメントの場合、値 'ABC ' は誤って 'ABC' と評価されます。

SQL Server 2008 では、末尾のスペースは常に保持されます。 この関数の以前の動作に依存するアプリケーションの場合は、最初の入力パラメーターを指定するときに、RTRIM 関数を使用します。 たとえば、 SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>' という構文を使用すると、SQL Server 2005 の動作を再現できます。

システム データベース

Resource データベース

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 データベースを移動することはできません。

tempdb データベース

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

INSERT...SELECT を使用したデータ一括読み込み時の最小ログ記録

以前のバージョンの SQL Server では、ステートメント INSERT INTO <対象テーブル> SELECT <列> FROM <ソース テーブル> を使用して対象テーブルに行を一括読み込みすると、常にすべてのログが記録されます。 SQL Server 2008 では、対象テーブルがヒープであり、データベースの復旧モデルが単純復旧モデルまたは一括ログ復旧モデルに設定されており、対象テーブルに TABLOCK ヒントが指定されている場合、この操作の実行時に最小ログ記録を行うことができます。 最小ログ記録を行うと、ステートメントのパフォーマンスが向上します。また、トランザクションの実行中に、使用可能なトランザクション ログ領域がこの操作でいっぱいになる可能性を低減します。 詳細については、「INSERT (Transact-SQL)」を参照してください。

XML

SQL Server 2005 から SQL Server 2008 への型指定された XML のアップグレード

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 の比較」を参照してください。

lax 検証と xs:anyType 要素

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

変更履歴

変更内容

「access check cache オプション」、「フルテキスト検索」、「並列処理」、および「XML」の各セクションを追加しました。

「INSERT…SELECT を使用したデータ一括読み込み時の最小ログ記録」を追加しました。

「SQL Server エージェント タスクのスクリプト作成時の動作に対する変更」を追加しました。