Microsoft SQL Server 2000 Service Pack 4

データベース コンポーネント

2005 年 3 月 21 日

© Copyright Microsoft Corporation, 2004. All rights reserved.

 
SQL Server ドキュメント チームは、技術サポートの質問にお答えすることはできませんが、この Readme ドキュメントに関する提案やコメントは歓迎します。以下のリンクを使用して、電子メール フィードバックを直接お送りください。フィードバックは、すべて英語でお願いします。

このドキュメントに関するフィードバックを送信するには、次のリンクをクリックしてください。  フィードバックの送信
 

目次

1.0 はじめに

    1.1 必要なシステム

    1.2 データベース コンポーネント SP4 にアップグレードする前に

    1.3 Microsoft Data Access Components のバージョンの確認

    1.4 SQL Server 2000 の現在のバージョンの確認

    1.5 SP4 に関する追加情報

    1.6 SQL Server 2000 Books Online の利用可能な更新

2.0 データベース コンポーネント SP4 の検索およびダウ ンロードの場所

    2.1 正しい言語の選択

    2.2 データベース コンポーネント SP4 のダウンロード

    2.3 データベース コンポーネント SP4 ファイルの展開

    2.4 展開フェーズ ガイドラインのダウンロード

    2.5 データベース コンポーネント SP4 セットアップ ドキュメント

3.0 Service Pack のインストール

    3.1 データベース コンポーネント SP4 インストールの準備

    3.2 データベース コンポーネント SP4 のインストール

    3.3 サービスおよびアプリケーションの再起動

    3.4 フェールオーバー クラスタへのインストール

    3.5 レプリケートされているサーバーへのデータベース コンポーネントのインストール

    3.6 レプリケーション トポロジ内の読み取り専用データベースまたはファイル グループへの SP4 の適用

    3.7 リンク サーバーのカタログのアップグレード

    3.8 データベース コンポーネント SP4 のアンインストール

    3.9 データベース コンポーネント SP4 の再適用

4.0 その他のインストールの情報

    4.1 自動インストール

    4.2 データベース コンポーネント SP4 の再配布

    4.3 Systems Management Server 配布インストール

5.0 特記事項

    5.1 データベースの機能強化

    5.2 レプリケーションの機能強化

    5.3 SQL Server エージェントと共有ツールの機能強化

    5.4 SQL Server 接続コンポーネントの機能強化

    5.5 Meta Data Services の機能強化

    5.6 データ変換サービスの機能強化

    5.7 XML の機能強化

    5.8 Virtual Backup Device API の機能強化

    5.9 エラー報告

    5.10 サービス性の機能強化

    5.11 English Query の機能強化

    5.12 DB-Library と Embedded SQL for C

[先頭に戻る]

1.0 はじめに

この Readme ファイルでは、Microsoft® SQL Server™ 2000 Service Pack 4 (SP4) のデータベース コンポーネント部分を使用して、SQL Server 2000 データベース エンジンの既存のインスタンスを SQL Server 2000 SP4 にアップグレードする方法について説明します。

SP4 の一般的なインストール手順は次のとおりです。

  1. SP4 を使用できるかどうかを判断します。使用できる場合は、SP4 のどの部分をインストールする必要があるかを判断します。「1.0 はじめに」のすべての部分を再確認してから、SP4 のダウンロードとインストールを行ってください。

  2. Service Pack インストール ファイルをダウンロードして展開します。SP4 インストール ファイルの入手方法については、「2.0 データベース コンポーネント SP4 の検索およびダウ ンロードの場所」を参照してください。

  3. SP4 へのアップグレードのためにインスタンスを準備します。SP4 をインストールする前に行う準備手順の詳細については、「3.1 データベース コンポーネント SP4 インストールの準備」を参照してください。

  4. SP4 をインストールします。SP4 セットアップを実行する際のオプションの詳細については、「3.2 データベース コンポーネント SP4 のインストール」を参照してください。

SQL Server 2000 SP4 は 4 つの部分に分かれています。

SQL Server の Service Pack はすべて累積的なものなので、SQL Server SP4 には、SP1、SP2、SP3、および SP3a で提供された修正プログラムが含まれています。

データベース コンポーネント SP4 は、Enterprise Edition、Standard Edition、Developer Edition、または Personal Edition の SQL Server 2000 データベース エンジンのインスタンスに対してのみ使用できます。SQL Server 2000 SP4 のその他の部分は、Analysis Services、MSDE 2000、SQL Server 2000 (64-bit) など、その他の SQL Server 2000 コンポーネントに適用されます。Analysis Services SP4、MSDE 2000 SP4、および SQL Server 2000 SP4 (64-bit) の使用については、それぞれの Reame ファイルを参照してください。他の Readme ファイルは、Microsoft Web サイトで入手できます。

[先頭に戻る]

1.1 必要なシステム

ここでは、必要なシステムの変更点、およびデータベース エンジン SP4 のインストールに影響するシステム関連の問題について説明します。SQL Server 2000 に必要なシステムの一般的な情報については、Microsoft Web サイトを参照してください。

サポートされるシステムの変更点
サポートされるシステムでのインストールの問題

以下のセキュリティ ポリシーのいずれかが [インストールを許可しない] に設定されている場合は、データベース コンポーネント SP4 をインストールできません。

[インストールを許可しない] 設定を使用している場合は、データベース コンポーネント SP4 をインストールする前に [警告なしで許可する] に変更する必要があります。インストール完了後に、必要に応じてポリシーを以前の設定に戻すことができます。

注意  [インストールを許可しない] はこれらのセキュリティ ポリシーの既定の設定ではありません。

セキュリティ ポリシーを設定するには、次の操作を行います。

  1. [コントロール パネル] で、[管理ツール] をダブルクリックします。

  2. [ローカル セキュリティ ポリシー] をダブルクリックします。

  3. [ローカル ポリシー] を展開します。

  4. [セキュリティ オプション] を選択します。

  5. データベース コンポーネント SP4 をインストールする前に、右側のウィンドウで次のオプションが [警告なしで許可する] に設定されていることを確認します。

  6. Windows XP と Windows 2003: [デバイス: 署名されていないドライバのインストール時の動作]

  7. Windows 2000: [署名されていないドライバ以外のインストール時の動作]

[先頭に戻る]

アプリケーションの要件

SQL Server 2000 のインスタンスがアプリケーションによって使用されている場合は、データベース コンポーネント SP4 にアップグレードする前に、そのアプリケーションに適用される SQL Server 2000 アップグレードの考慮事項があるかどうかをアプリケーションのプロバイダに確認します。

[先頭に戻る]

1.2 データベース コンポーネント SP4 にアップグレードする前に

ここでは、データベース コンポーネント SP4 を使用して SQL Server 2000 用のデータベース エンジンの既存のインスタンスをアップグレードする前に対応する必要がある問題、およびアップグレード前に実行する必要がある作業について説明します。

データベース コンポーネント SP4 のインスタンス上で作成されるデータベースまたはデータベース バックアップは、以前のバージョンの SQL Server 2000 上でアタッチまたは復元できます。ただし、レプリケーション トポロジ内のデータベースについては制限があります。詳細については、「1.2.2 レプリケーションまたはログ配布トポロジ内のインスタンスに関する考慮事項」を参照してください。

データベース コンポーネント SP4 Setup プログラムは、アップグレードする SQL Server 2000 のインスタンスにどのエディションの SQL Server 2000 が存在するかを自動的に検出します。Setup は、そのインスタンスにインストールされているコンポーネントだけをアップグレードします。たとえば、SQL Server 2000 Standard Edition を実行しているコンピュータに Service Pack を適用するときは、Service Pack は SQL Server 2000 Enterprise Edition にのみ含まれるコンポーネントはアップグレードしません。

データベース コンポーネント SP4 は、SQL Server の 1 つの "既定のインスタンス" または "名前付きインスタンス" に適用できます。SQL Server 2000 の複数のインスタンスを SP4 にアップグレードする場合は、各インスタンスに対して SP4 を適用する必要があります。SQL Server 2000 の 1 つ以上のインスタンスを持つ 1 台のコンピュータ上の 1 つのインスタンスを SP4 にアップグレードするときは、すべてのツールが SP4 にアップグレードされます。インスタンスごとに独立したツールのコピーは存在しません。

SQL Server 2000 のインスタンスがアプリケーションによって使用されている場合は、まずそのアプリケーションに固有の SQL Server 2000 アップグレードの考慮事項があるかどうかをアプリケーションのプロバイダに確認します。

[先頭に戻る]

# 1.2.1 データベース コンポーネント SP4 を削除する方法の決定

データベース コンポーネント SP4 を使用してデータベース エンジンの既存のインスタンスをアップグレードする前に、後で必要になる場合に場合に備えて、インスタンスを以前の状態に戻す方法を計画しておくことをお勧めします。SQL Server 2000 データベース コンポーネント SP4 をインストールすると、保守の目的でシステム テーブルに変更が加えられます。レプリケーション トポロジのメンバであるユーザー データベースとディストリビューション データベースもアップグレードされます。これらの変更の性質から、データベース コンポーネント SP4 は簡単には削除できません。データベース コンポーネント SP4 をインストールする前に実行していたビルドに戻すには、まず SQL Server 2000 データベース エンジンのインスタンスをアンインストールし、その後 SQL Server 2000 のインスタンスを再インストールする必要があります。次に、以前に SQL Server 2000 Service Pack を実行したか、または修正プログラムを適用した場合は、その Service Pack と修正プログラムをインスタンスに再適用する必要があります。

注意  SP4 を削除する場合は、SP4 を適用する直前の master、model、および msdb データベースのバックアップを所持している必要があります。詳細については、「3.1.1 SQL Server データベースのバックアップ」を参照してください。

詳細については、「3.8 データベース コンポーネント SP4 のアンインストール」を参照してください。

[先頭に戻る]

1.2.2 レプリケーションまたはログ配布トポロジ内のインスタンスに関する考慮事項

SQL Server 2000 SP4 Setup はレプリケーション トポロジのメンバであるユーザー データベースをアップグレードします。このアップグレード要素は、レプリケートされたユーザー データベースのバックアップおよび復元機能に影響する場合があります。SP4 をインストールする前に、レプリケーション データベースおよびファイル グループが書き込み可能であることを確認してください。レプリケーション トポロジに関係するデータベースに SP4 を適用することに関する詳細については、「3.5 レプリケートされているサーバーへのデータベース コンポーネントのインストール」を参照してください。レプリケーションに関するその他のバックアップと復元の考慮事項については、「5.2.6 マージ レプリケーションのバックアップと復元の問題点」を参照してください。

注意   SQL Server のインスタンスがレプリケーション トポロジの一部でない場合は、ユーザー データベースをバックアップし、SQL Server 2000 のその他のリリース上で復元することができます。

SP4 Setup が書き込み可能ではないユーザー データベースまたはファイル グループを検出した場合は、以下のことを行います。

Setup ログに一覧表示された一部のデータベースがレプリケーション トポロジのメンバではない場合は、この警告を無視できます。Setup ログに一覧された書き込み可能ではないデータベースのいずれかがレプリケーション トポロジのメンバである場合は、これらのデータベースを書き込み可能にし、SQL Server 2000 のインスタンスに SP4 Setup を再適用する必要があります。

データベースを書き込み可能にすることに関する詳細については、「3.6 レプリケーション トポロジ内の読み取り専用データベースまたはファイル グループへの SP4 の適用」を参照してください。SP4 の再適用の詳細については、「3.9 データベース コンポーネント SP4 の再適用」を参照してください。

ログ配布およびデータベース コンポーネント

書き込み可能ではないデータベースによって Setup が失敗することはないので、データベース コンポーネント SP4 にアップグレードする前に、ログ配布を削除する必要はありません。ただし、そのデータベースがレプリケーション パブリッシャであるデータベースにログを配布している場合は、以下のことを実行する必要があります。

  1. SP4 を適用する前に、そのデータベースをオフラインにします。

  2. そのインスタンスに SP4 を適用します。

  3. データベースをオンラインに戻します。

  4. クエリ アナライザにログオンして、以下のスクリプトを実行します。
    USE master
    GO
    EXEC sp_vpupgrade_replication
    GO

パブリケーション データベースにログを配布しているすべての書き込み可能ではないデータベースをオフラインにしないで SP4 を適用すると、次のエラー メッセージが表示されます。

スクリプト実行エラー : sp_vpupgrade_replication (1)

このエラーが表示される場合は、前の手順に従います。

注意  Setup は、インストール中に読み取り専用のデータベースと、オフラインまたは問題のあるデータベースを区別しません。インストール中にオフラインまたは問題のあるレプリケーション データベースまたはファイル グループが存在し、レプリケーション トポロジに関連している場合は、データベースを書き込み可能にした後、Service Pack を再適用する必要があります。

[先頭に戻る]

1.3 Microsoft Data Access Components のバージョンの確認

データベース コンポーネント SP4 Setup は、インストールされている Microsoft Data Access Components (MDAC) のバージョンを MDAC 2.8 SP1 にアップグレードするかどうかを判断します。

注意   コンピュータ上の MDAC のバージョンを確認する方法については、サポート技術情報の文書 301202 を参照してください。

データベース コンポーネント SP4 は MDAC 2.8 SP1 をインストールします。この MDAC の言語バージョンは、データベース コンポーネント SP4 の言語バージョンと同じです。データベース コンポーネント SP4 とは異なる言語バージョンの MDAC を保持する場合は、データベース コンポーネント SP4 Setup を実行する前に、目的の言語バージョンの MDAC 2.8 SP1 をダウンロードしてインストールする必要があります。言語固有のバージョンの MDAC 2.8 SP1 は、Microsoft Web サイトからダウンロードできます。

MDAC 2.8 SP1 は MSXML 3.0 SP7 へのアップグレードも含んでいます。MDAC 2.81 は、Microsoft SQL Server 2000 に付属する SQLXML 1.0 も更新します。この Service Pack は、SQLXML 3.0 のインストールまたは更新を行いません。アプリケーションが SQLXML 3.0 を必要とする場合は、Microsoft Web サイトからダウンロードしてインストールする必要があります。MDAC 2.8 SP1 の詳細については、Microsoft Web サイトを参照してください。MDAC のバージョンの詳細については、サポート技術情報の文書 822758 を参照してください。MDAC 2.8 SP1 に含まれる修正プログラムについては、サポート技術情報の文書 884930 に説明があります。

注意   プレリリース版の SQL Server 2000 SP4 は、プレリリース版の MSXML 3.0 SP7 をインストールします。プレリリース版の SQL Server 2000 SP4 をインストールした場合は、最終リリース版の MSXML 3.0 SP7 を Microsoft Web サイトからダウンロードしてインストールすることをお勧めします。

[先頭に戻る]

1.4 SQL Server 2000 の現在のバージョンの確認

Setup を実行する前に、アップグレードするデータベース コンポーネントのインスタンスのバージョンを確認する必要があります。

インストールされている SQL Server 2000 データベース コンポーネントのバージョンを確認するには、次の操作を行います。

  1. isql、osql、またはクエリ アナライザを使用して、データベース エンジンのインスタンスに対して以下のクエリのいずれかを実行します。
  2. 次の表を使用してデータベース コンポーネントのバージョンを確認します。
    SQL Server 2000 バージョンとレベル @@VERSION 製品レベル
    SQL Server 2000 製品版 8.00.194 RTM
    データベース コンポーネント SP1 8.00.384 SP1
    データベース コンポーネント SP2 8.00.534 SP2
    データベース コンポーネント SP3、SP3a、または MSDE 2000 Release A 8.00.760 SP3
    データベース コンポーネント SP4 8.00.2039 SP4

    注意   製品をインストールした後、または以前の Service Pack をインストールした後で修正プログラムを適用した場合は、製品のバージョンがこれらの値とは異なることがあります。たとえば、@@VERSION は、SQL Server 2000 SP3a にセキュリティ修正プログラム MS03-031 を適用した後では、値 8.00.818 を返します。

  3. (省略可能) SQL Server 2000 データベース エンジンのエディションと MSDE 2000 のどちらを実行しているかわからない場合は、isql、osql、またはクエリ アナライザを使用して、問題のインスタンスに対して以下のクエリを実行します。

    このクエリが "desktop engine" を返す場合は、MSDE 2000 のインスタンスを実行しています。そうでない場合は、SQL Server 2000 データベース エンジンのインスタンスを実行しています。

[先頭に戻る]

1.5 SP4 に関する追加情報

この Service Pack で解決された問題点の一覧は、マイクロソフト サポート技術情報の文書 888799 にあります。888799 の一覧にある問題はそれぞれ、解決された問題点について説明されているサポート技術情報の文書にリンクされています。それぞれの問題点についての情報を参照するには、サポート技術情報の各文書へのリンクをクリックしてください。

この Readme ファイルを記述している時点で利用できなかった SQL Server 2000 Service Pack 4 関連のすべての情報は、マイクロソフト サポート技術情報の文書 884525 で公開する予定です。

この Readme ファイルで言及されているサポート技術情報の文書は、マイクロソフト サポート技術情報で検索できます。

サポート技術情報の文書を検索するには、次の操作を行います。

  1. [高度な検索] の [キーワード] ボックスに、目的の文書の番号を入力します。

  2. [検索の種類] で [文書番号] を選択します。

  3. [検索の実行] 右矢印ボタンをクリックします。
修正プログラム

これまでに公開されたすべての SQL Server 2000 SP3a および SQL Server 2000 (64-bit) のセキュリティ更新が SP4 に含まれています。

2004 年 12 月 2 日以降に SQL Server 2000 の修正プログラムを受け取っている場合は、その修正プログラムは SP4 に含まれていません。SQL Server 2000 SP4 に対して同じ修正プログラムを入手する方法については、ご購入元に相談してください。

SQL Server 2000 SP4 ではサービス性が拡張されており、修正プログラムを将来アンインストールすることができます。詳細については、「5.10 サービス性の機能強化」を参照してください。

Slammer ワーム関連の修正プログラム

Microsoft SQL Server 2000 SP4 は、Slammer ワームで生じた問題点に対処する SQL Server 2000 コンポーネントに以下の変更点を組み込んだものです。

SQL Server CE と SQL Mobile の サーバー ツールの更新

SQL Server 2000 データベース サーバーおよびパブリッシャ サーバーを SP4 にアップグレードした、またはアップグレードする予定の Microsoft SQL Server 2000 Windows® CE Edition (SQL Server CE) ユーザーと SQL Server 2005 Mobile Edition (SQL Mobile) ユーザーは、Microsoft インターネット インフォメーション サービス (IIS) サーバーのサーバー レプリケーション コンポーネントも更新する必要があります。更新されたサーバー ツール インストーラには、SQL Server CE 用と SQL Mobile 用があります。

注意   SQL Server 2000 SP3 または SP3a へアップグレードした後でサーバー レプリケーション コンポーネントを更新した場合でも、最新の SP4 固有の更新をサーバー ツール コンポーネントにインストールする必要があります。

OPENXML の更新

SQL Server 2000 SP4 は、オペレーティング システムによってインストールされる MSXML のバージョンに対する OPENXML の従属関係を削除します。データベース コンポーネント SP4 は、MSXML 2.6 との下位互換性を備えた内部バージョンの MSXML テクノロジをインストールします。

[先頭に戻る]

1.6 SQL Server 2000 Books Online の利用可能な更新

SQL Server 2000 Books Online は、データベース コンポーネント 2000 用の主要なユーザー ドキュメントです。Books Online は、修正と新しい情報によって定期的に更新されます。

利用できる更新された SQL Server 2000 サンプル

SP3 および SP3a で更新された SQL Server 2000 データベース エンジンのサンプルと Analysis Services のサンプルを利用できます。更新されたサンプルは、Microsoft Web サイトからダウンロードできます。

[先頭に戻る]

2.0 データベース コンポーネント SP4 の検索およびダウ ンロードの場所

SQL Server 2000 SP4 は以下の方法で配布されています。

[先頭に戻る]

2.1 正しい言語の選択

SQL Server 2000 データベース コンポーネント Service Pack は言語によって異なります。SQL Server 2000 のインスタンスをアップグレードするには、インスタンスと同じ言語の Service Pack を取得する必要があります。Service Pack は、SQL Server 2000 SP4 CD-ROM から、またはデータベース コンポーネント SP4 ファイルをダウンロードして取得します。たとえば、日本語を使用する SQL Server 2000 のインスタンスをアップグレードする場合は、日本語版のデータベース コンポーネント SP4 を取得する必要があります。

SQL Server 2000 のインスタンスの言語がわからない場合は、次の操作を行います。

[先頭に戻る]

2.2 データベース コンポーネント SP4 のダウンロード

データベース コンポーネント SP4 の自己解凍形式のインストール パッケージをダウンロードするには、次の操作を行います。

[先頭に戻る]

2.3 データベース コンポーネント SP4 ファイルの展開

インストール パッケージを含む自己解凍形式ファイルをダウンロードした後、データベース コンポーネント SP4 ファイルを展開する必要があります。

[先頭に戻る]

2.4 展開フェーズ ガイドラインのダウンロード

インターネットからデータベース コンポーネント SP4 インストール ファイルをダウンロードして展開するときは、以下のガイドラインに従ってください。

[先頭に戻る]

2.5 データベース コンポーネント SP4 セットアップ ドキュメント

データベース コンポーネント SP4 インストール ファイルには、更新されたセットアップ ドキュメントが含まれていて、データベース コンポーネント SP4 のセットアップ中に [ヘルプ] をクリックすることによってアクセスできます。このセットアップ ドキュメントは、既にコンピュータにインストールされているバージョンの SQL Server 2000 Books Online を更新しません。更新されたバージョンの SQL Server 2000 Books Online を入手する方法の詳細については、「1.6 SQL Server 2000 Books Online の利用可能な更新」を参照してください。SQL Server 2000 Books Online をアップグレードしないで、更新された SQL Server 2000 SP4 セットアップ ドキュメントだけにアクセスする場合は、Setupsql.chm ファイルを実行します。Setupsql.chm は、SP4 CD-ROM から展開した Service Pack ファイルを含むローカル フォルダまたはネットワーク共有の \Books サブフォルダにあります。

[先頭に戻る]

3.0 Service Pack のインストール

データベース コンポーネント SP4 をインストールするには、以下の指示に従います。データベース コンポーネント SP4 をインストールする前に、「1.0 はじめに」の内容を確認してください。データベース コンポーネント SP4 をインストールする手順は次のとおりです。

  1. データベース コンポーネント SP4 インストールの準備

  2. データベース コンポーネント SP4 のインストール

  3. サービスおよびアプリケーションの再起動

[先頭に戻る]

3.1 データベース コンポーネント SP4 インストールの準備

データベース コンポーネント SP4 をインストールする前に、以下を実行する必要があります。

  1. SQL Server データベースのバックアップ

  2. システム データベースの空き領域の確認

  3. サービスおよびアプリケーションの停止

[先頭に戻る]

3.1.1 SQL Server データベースのバックアップ

データベース コンポーネント SP4 をインストールする前に、master、msdb、および model データベースをバックアップします。SP4 のインストールにより、master、msdb、および model データベースには変更が加えられ、SP4 以前のバージョンの SQL Server とは互換性がなくなります。SP4 を使用しないで SQL Server 2000 を再インストールする必要が生じる場合は、これらのデータベースのバックアップが必要になります。

SP4 はレプリケーション トポロジのメンバであるユーザー データベースだけに更新を行いますが、ユーザー データベースのバックアップも検討することをお勧めします。

レプリケーションを考慮した既存のバックアップ手法は、障害が発生した場合に、SP4 にアップグレード後の既知の時点にデータベースを回復することを可能にします。SP4 の適用後に、レプリケーション トポロジに関係するすべてのユーザー データベースのログ バックアップまたは完全データベース バックアップを行うことをお勧めします。バックアップを行っておくと、レプリケーション データベースで障害が発生した場合に、データベースの復元後に SP4 を再適用する必要がありません。

[先頭に戻る]

3.1.2 システム データベースの空き領域の確認

master データベースおよび msdb データベースに対して自動拡張オプションが設定されていない場合、少なくとも 500 KB の空き領域が必要です。空き領域を確認するには、master データベースまたは msdb データベースで sp_spaceused システム ストアド プロシージャを実行します。いずれかのデータベースの未割り当て領域が 500 KB 未満の場合は、データベースのサイズを大きくしてください。詳細については、SQL Server 2000 Books Online の「データベースの拡張」を参照してください。

master データベースと msdb データベースで自動拡張オプションが選択されていて、ドライブに十分な空き領域がある場合は、前の領域確認手順を省略できます。

SQL Server 2000 で自動拡張オプションが設定されていることを確認するには、SQL Server Enterprise Manager を開き、データベースのアイコンをマウスの右ボタンでクリックして、[プロパティ] をクリックします。[ファイルの自動拡張] チェック ボックスがオンになっていることを確認します。

[先頭に戻る]

3.1.3 データベース コンポーネント SP4 セットアップを実行する前のサービスおよびアプリケーションの停止

データベース エンジン SP4 をインストールする前に、すべてのアプリケーションおよびサービスを停止する必要があります。これには、コントロール パネル、プログラムの追加と削除、SQL Server 2000 Reporting Services、SQL Server Notification Services、およびアップグレードされるデータベース エンジンのインスタンスに接続するすべてのアプリケーションが含まれます。

最初にサービスをシャットダウンしなくてもデータベース コンポーネント SP4 を適用できますが、その場合はシステムを再起動しないと再開しないサービスがいくつかあります。サービスをシャットダウンしない場合は、Setup の完了時にコンピュータの再起動を求められます。システムを再起動しない場合、以下のサービスは開始できないことがあります。

データベース コンポーネント SP4 をインストールした後で、コンピュータの再起動が必要となる可能性を減らすことができます。この可能性を減らすには、Setup を実行する前に、前の一覧のサービスおよびアプリケーションを停止します。

クラスタ環境では、サービスを停止できません。詳細については、「3.4 フェールオーバー クラスタへのインストール」を参照してください。

[先頭に戻る]

3.2 データベース コンポーネント SP4 のインストール

以下の情報は、SQL Server 2000 のデータベース コンポーネント部分にのみ適用されます。

次のいずれかの場所から Setup.bat スクリプトを実行します。

注意  ネットワーク共有からデータベース コンポーネントをインストールするには、まず次のいずれかの処理を行う必要があります。

データベース コンポーネント SP4 Setup の実行

Setup.bat はダイアログ ボックスを表示し、SQL Server 認証または Windows 認証のどちらを使用するかなどの情報を問い合わせます。SQL Server 認証を選択する場合は、Setup プログラムに sa ログインのパスワードを提供する必要があります。Windows 認証を選択する場合は、アップグレードする SQL Server 2000 のインスタンスに対する sysadmin 固定サーバー ロールのメンバである Windows ログイン アカウントで Windows にログオンしているときに、Setup プログラムを実行する必要があります。

その後セットアップ プログラムは以下の作業を行います。

[先頭に戻る]

[認証モード] ダイアログ ボックス

[認証モード] ダイアログ ボックスは、現在の設定値をインストールの既定として選択しません。このダイアログ ボックスの既定の設定値は Windows 認証です。このダイアログ ボックスを使用して、認証モードを Windows 認証、またはブランクではない sa ログイン パスワードを使用する混合モード認証に切り替えます。

注意  sa ログインの認証モードまたはパスワードを切り替える前に、この切り替えが既存のアプリケーションに影響しないことを確認します。たとえば、混合認証モードを選択した SQL Server のインスタンスを Windows 認証だけを使用するように変更する場合、SQL Server 認証を使用して接続しようとする既存のアプリケーションは、接続の認証モードを Windows 認証に変更するまで接続できません。また、sa ログイン パスワードを変更する場合、古いパスワードを使用しているアプリケーションまたは管理プロセスは、新しいパスワードを使用するように設定を変更するまで接続できません。

重要  セキュリティ上の理由から、sa ログインでブランク パスワードを使用しないでください。

Setup プログラムは、実行した操作を Sqlsp.log ファイルに記録します。このログ ファイルは、セットアップを実行したコンピュータの Windows フォルダに格納されます。複数のインスタンスをアップグレードする場合は、最後に行ったアップグレードだけがこのログに記録されます。

[先頭に戻る]

[旧バージョンとの互換性チェックリスト] ダイアログ ボックス

[旧バージョンとの互換性チェックリスト] ダイアログ ボックスには、SP3 より前のバージョンの SQL Server へ Service Pack を適用するときに発生する可能性がある問題点が一覧表示されます。チェックリストに表示される互換性の問題点は、アップグレードする SQL Server 2000 のインスタンスの設定によって異なります。

以下の旧バージョンとの互換性の問題点が、このダイアログ ボックスで対処されます。

[先頭に戻る]

3.3 サービスおよびアプリケーションの再起動

Setup が完了すると、システムの再起動を要求されることがあります。「3.1.3 データベース コンポーネント SP4 セットアップを実行する前のサービスおよびアプリケーションの停止」に、再起動が必要な場合のガイドラインが記載されています。システムの再起動後 (または、再起動が要求されないで Setup が完了した後)、コントロール パネルの [サービス] アプリケーションを使用して、Service Pack の適用を行う前に停止させたすべてのサービスが実行されていることを確認します。Service Pack を適用する前に停止させた可能性があるサービスには、DTC と Microsoft Search、MSSQLServer、MSSQLServerOLAPService、および SQLServerAgent サービスまたはそれらのインスタンス固有のサービスがあります。

Service Pack のセットアップを実行する前に終了したアプリケーションを再開します。

念のため、この時点でアップグレードした master データベースと msdb データベースをバックアップします。

[先頭に戻る]

3.4 フェールオーバー クラスタへのインストール

以下は、フェールオーバー クラスタの一部である SQL Server 2000 コンポーネントだけに適用されます。

フェールオーバー クラスタにこの Service Pack をインストールするには、次の操作を行います。

  1. SQL Server リソースと従属関係を持つ任意のリソースを追加していた場合は、SP4 をインストールする前に、これらの従属リソースを削除するか、オフラインにしておく必要があります。従属関係を削除しない場合、SP4 のインストールによりこのリソースはオフラインになります。

    注意   クラスタ リソースがオフラインになると、クラスタサービスにより従属リソースもオフラインになります。

  2. アップグレードする予定の仮想サーバーを含んでいるグループを所有するノードからこの Service Pack を実行します。この結果、Service Pack ファイルがすべてのフェールオーバー クラスタ ノードにインストールされます。

  3. [セットアップ] ダイアログ ボックスで、アップグレードする予定の仮想サーバーの名前を入力します。

  4. セットアップ中はクラスタのすべてのノードをオンラインのままにします。この結果、クラスタの各ノードにアップグレードが適用されることが保証されます。

  5. 手順 1. で従属関係を削除するか、リソースをオフラインにした場合は、従属関係を元に戻すか、リソースをオンラインに戻します。

注意  Setup はフェールオーバー クラスタ ノードの再起動を必要とすることがあります。この再起動により、Setup 実行中に使用中だったファイルを、更新されたファイルに置き換えます。

SQL Server の既定の (クラスタ化されていない) インスタンスを仮想サーバーにアップグレードする場合は、既定の (クラスタ化されていない) インスタンスから仮想インスタンスにアップグレードしてから、SP4 を適用する必要があります。アップグレードの詳細については、SQL Server 2000 Books Online の「既定のインスタンスから SQL Server 2000 の既定のクラスタ化インスタンスにアップグレードする方法 (セットアップ)」を参照してください。

フェールオーバー クラスタへの SP4 のインストール方法に関する詳細については、サポート技術情報の文書 811168 を参照してください。

フェールオーバー クラスタでノードを再構築する必要がある場合

  1. フェールオーバー クラスタでノードを再構築します。ノードの再構築の詳細については、SQL Server 2000 Books Online の「フェールオーバー クラスタ障害回復の例 1」を参照してください。

  2. 元の SQL Server 2000 Setup プログラムを実行して、そのノードを再度フェールオーバー クラスタに追加します。

  3. 追加したノードでデータベース コンポーネント SP4 Setup を実行します。このセットアップ処理により、新しいノードのバイナリだけが SP4 に更新されます。

注意   仮想サーバーを実行しているノードから Setup を実行する場合は、すべてのノードに SP4 を再適用する必要があります。データベース アップグレード スクリプトも再実行する必要があります。

[先頭に戻る]

3.5 レプリケートされているサーバーへのデータベース コンポーネントのインストール

以下は、レプリケーション トポロジの一部である SQL Server 2000 の既存のインスタンスだけに適用されます。

[先頭に戻る]

パブリッシャおよびサブスクライバとして動作するサーバーへの SP4 のインストール

以下の場合には、システムを停止し (つまり、すべての更新を中止し)、すべてのサーバーを同時にアップグレードする必要があります。

例 1: 同時アップグレードを必要とするトポロジ

以下の表は、サブスクライバで更新できるパブリケーションのパブリッシュとサブスクライブを両方行うサーバーを示しています。前に説明したように、サブスクライバでの更新を許可するトポロジでは、ディストリビュータ、パブリッシャ、サブスクライバの順にアップグレードする必要があります。この順序により、マージ パブリケーションではサーバー A を最初にアップグレードする必要があり、更新サブスクライバを使用するトランザクション パブリケーションではサーバー B を最初にアップグレードする必要があります。このような場合には、システムを停止し、サーバーを同時にアップグレードする必要があります。

サーバー A サーバー B
マージ レプリケーションのパブリッシャ/ディストリビュータ マージ レプリケーションのサブスクライバ
更新を伴うトランザクション レプリケーションのサブスクライバ 更新を伴うトランザクション レプリケーションのパブリッシャ/ディストリビュータ

例 2: 順番にアップグレードできるトポロジ

読み取り専用のトランザクション パブリケーションでは、パブリッシャ/ディストリビュータをアップグレードする前にサブスクライバをアップグレードできるので、この例ではサーバー A を最初にアップグレードできます。

サーバー A サーバー B
マージ レプリケーションのパブリッシャ/ディストリビュータ マージ レプリケーションのサブスクライバ
読み取り専用トランザクション レプリケーションのサブスクライバ 読み取り専用トランザクション レプリケーションのパブリッシャ/ディストリビュータ

[先頭に戻る]

3.6 レプリケーション トポロジ内の読み取り専用データベースまたはファイル グループへの SP4 の適用

以下は、レプリケーション トポロジの一部である SQL Server 2000 コンポーネントだけに適用されます。

書き込み可能ではないデータベースまたはファイル グループが存在するとき、Setup プログラムは以下のメッセージを表示します。

書き込み可能ではない 1 つ以上のデータベースとファイル グループを検出しました。

一般的には、このメッセージを無視し、セットアップを続行します。ただし、Setup ログに一覧された書き込み可能ではないデータベースのいずれかがレプリケーション トポロジのメンバである場合は、これらのデータベースを書き込み可能にし、SQL Server 2000 のインスタンスに SP4 Setup を再適用する必要があります。

注意  このメッセージは自動インストールには影響しません。自動インストールの詳細については、「4.1 自動インストール」を参照してください。

Setup は、インストール中に書き込み可能ではないデータベースと、オフラインまたは問題のあるデータベースを区別しません。レプリケーション トポロジ内のデータベースまたはファイル グループがセットアップ中に書き込み可能ではない場合は、Service Pack を再適用してこのデータベースをアップグレードする必要があります。データベースをオンラインにする方法の詳細については、SQL Server 2000 Books Online の「データベースをアタッチまたはデタッチする方法」を参照してください。また、問題のあるデータベースの診断の詳細については、SQL Server Books Online の「サーバーおよびデータベースに関するトラブルシューティング」を参照してください。

読み取り専用データベースにデータベース コンポーネント SP4 を適用するには、次の操作を行います。

  1. 次のように、ALTER DATABASE ステートメントを使用して読み取り専用データベースを書き込み可能にします。
    ALTER DATABASE database SET READ_WRITE
  2. すべての読み取り専用データベースに対して手順 1. を繰り返します。

  3. SP4 を適用 (または再適用) します。

  4. 必要に応じて、次のように、ALTER DATABASE ステートメントを使用してファイル グループを再度読み取り専用にします。
    ALTER DATABASE database SET READ_ONLY

読み取り専用ファイル グループに SP4 を適用するには、次の操作を行います。

  1. 次のように、ALTER DATABASE ステートメントを使用してファイル グループを再度読み取り専用にします。
    ALTER DATABASE Database 
    MODIFY FILEGROUP filegroup_name READWRITE 
  2. すべての読み取り専用ファイル グループに対して手順 1. を繰り返します。

  3. Service Pack を適用 (または再適用) します。

  4. 次のように、ALTER DATABASE ステートメントを使用してファイル グループを再度読み取り専用にします。
    ALTER DATABASE Database 
    MODIFY FILEGROUP filegroup_name READONLY

ALTER DATABASE の詳細については、SQL Server Books 2000 Online の「ALTER DATABASE」を参照してください。SP4 の再適用の詳細については、「3.9 データベース コンポーネント SP4 の再適用」を参照してください。

[先頭に戻る]

3.7 リンク サーバーのカタログのアップグレード

SQL Server 2000 データベース エンジンのインスタンスをデータベース コンポーネント SP4 にアップグレードするときは、一部のシステム ストアド プロシージャが SQL Server または MSDE の他のインスタンスで更新されることを確認する必要があります。

データベース コンポーネント SP4 は、Microsoft Data Access Components (MDAC) を MDAC Version 2.8 SP1 にアップグレードします。MDAC 2.8 SP1 には、SQLOLEDB プロバイダおよび SQL Server ODBC ドライバへの更新が含まれています。詳細については、「1.3 Microsoft Data Access Components のバージョンの確認」を参照してください。プロバイダまたはドライバが SQL Server または MSDE のインスタンスに接続すると、カタログ ストアド プロシージャと呼ばれる一連のシステム ストアド プロシージャが使用されます。インスタンスでのカタログ ストアド プロシージャのバージョンは、プロバイダおよびドライバが使用するバージョンと同じか、またはそれ以降である必要があります。以前のバージョンのカタログ ストアド プロシージャを含む SQL Server または MSDE のインスタンスに接続しようとすると、次のエラーが表示されます。

The ODBC catalog stored procedures installed on server <サーバー名>
are version <古いバージョン番号>; version <新しいバージョン番号> or later
is required to ensure proper operation. Please contact your system
administrator.

[先頭に戻る]

Instcat.sql スクリプトの実行

プロバイダおよびドライバの各バージョンには、Instcat.sql という名前のスクリプトが付属しています。Instcat は、以前のバージョンのカタログを含む SQL Server または MSDE のインスタンス内のすべてのカタログ ストアド プロシージャを更新します。

データベース コンポーネント SP4 をインストールした後、以下の特性を備えた、SQL Server 2000 SP4 より前のバージョンの SQL Server または MSDE のインスタンスに対してデータベース コンポーネント SP4 から Instcat.sql スクリプトを実行する必要があります。

Windows 認証モードを使用してインスタンス上のカタログ ストアド プロシージャをアップグレードするには、次の操作を行います。

  1. SQL Server の sysadmin 固定サーバー ロールのメンバであるログインを使用して Windows にログオンします。

  2. コマンド プロンプト ウィンドウを開きます。

  3. osql ユーティリティを実行します。

混合モードを使用してインスタンス上のカタログ ストアド プロシージャをアップグレードするには、次の操作を行います。

  1. 任意のログオンを使用して Windows にログオンします。

  2. コマンド プロンプト ウィンドウを開きます。

  3. osql ユーティリティを実行します。

ここで、

Instcat.sql スクリプトは多くのメッセージを生成します。通常、このメッセージはエラーを示すものではありません。単に、スクリプト内の各 Transact-SQL ステートメントによって影響を受けた行数を通知します。最後のメッセージは、スクリプトが正しく実行されたかどうかを示します。

[先頭に戻る]

3.8 データベース コンポーネント SP4 のアンインストール

データベース コンポーネント SP4 を削除するには、以下の手順を実行します。

注意  MDAC の更新はアンインストールされません。詳細については、「1.3 Microsoft Data Access Components のバージョンの確認」を参照してください。

SP4 を適用する以前のバージョンに SQL Server 2000 コンポーネントを戻すことができるようにするには、SP4 をインストールする前に master、msdb、および model データベースをバックアップしておく必要があります。詳細については、「3.1.1 SQL Server データベースのバックアップ」を参照してください。

レプリケーションに関係しているデータベースが存在する場合は、パブリッシュを無効にする必要があります。

パブリッシュを無効にするには、次の操作を行います。

  1. SQL Server Enterprise Manager で、SQL Server グループを展開し、サーバーを展開して、[レプリケーション] フォルダを右クリックします。その後、[パブリッシング、サブスクライバ、およびディストリビューションの設定] をクリックします。

  2. [パブリケーション データベース] タブをクリックします。

  3. レプリケーションに関係しているデータベースごとにチェック ボックスをオフにします。この結果、そのデータベースがデタッチされます。

SQL Server を SP4 を適用する以前のバージョンに戻すには、次の操作を行います。

  1. すべてのユーザー データベースをデタッチします。詳細については、SQL Server Books Online の「データベースをアタッチまたはデタッチする方法 (Enterprise Manager)」を参照してください。

  2. SQL Server をアンインストールします。[コントロール パネル] で、[プログラムの追加と削除] をダブルクリックし、アンインストールする SQL Server のインスタンスを選択します。次に、[削除] をクリックします。

  3. CD-ROM または最初に SQL Server をインストールした場所から、SQL Server 2000 を再インストールします。

  4. データベース コンポーネント SP4 より前にインストールしていた Service Pack および修正プログラムを適用します。

  5. インストールする前に作成した最新のバックアップから master、msdb、および model データベースを復元します。データ ファイルの場所が変更されていない場合、この復元により、バックアップが作成された時点でアタッチされていたすべてのユーザー データベースが自動的にアタッチされます。

  6. master データベースを最後にバックアップした後に作成したすべてのユーザー データベースをアタッチします。

  7. 必要に応じて、レプリケーションを設定します。

    警告  SQL Server 2000 を SP4 以前のバージョンに戻すと、SP4 の適用後に master、msdb、および model データベースに対して行われたすべての変更が失われます。

[先頭に戻る]

3.9 データベース コンポーネント SP4 の再適用

以下は、すべてのコンポーネントに適用されます。

以下の場合に、SP4 を再適用する必要があります。

SP4 を再適用するには、「3.0 Service Pack のインストール」の手順に従います。

[先頭に戻る]

4.0 その他のインストールの情報

ここでは、特殊な場合にのみ適用される Service Pack インストールのその他の考慮事項について説明します。

[先頭に戻る]

4.1 自動インストール

データベース コンポーネント SP4 には、定義済みのセットアップ初期化 (.iss) ファイルは含まれていません。ただし、データベース コンポーネント SP4 の有人インストールを実行するたびに、セットアップ オプションがシステム フォルダにある setup.iss ファイルに書き込まれます。この .iss ファイルを後で使用して、データベース コンポーネント SP4 の自動インストールを実行できます。自動インストールの実行に関する詳細については、SQL Server 2000 Books Online の「自動インストールの実行」を参照してください。

[先頭に戻る]

自動インストールの考慮事項

自動インストールに関して以下の考慮事項があります。

自動インストール スイッチ 説明
UpgradeMSSearch フルテキスト カタログの必須の再構築の考慮事項に対処するためにこのスイッチが必要になります。フルテキスト検索が有効な場合は、このスイッチを 1 に設定する必要があります。詳細については、「5.1.4 セットアップ完了後のフルテキスト カタログの再構築」を参照してください。
MSXTSXUpgraded マスタ/対象サーバー設定のアップグレードの問題に対処するためにこのスイッチが必要になります。マスタ サーバーまたは対象サーバーに SP4 を適用しているときは、このスイッチを 1 に設定する必要があります。詳細については、「5.3.2 マスタ/対象サーバー設定の変更」を参照してください。
EnableCrossDBChaining (省略可能) 複数データベースの組み合わせ所有権を有効にするためにこのスイッチを使用します。複数データベースの組み合わせ所有権を有効にするには、このスイッチを 1 に設定します。詳細については、「5.1.10 複数データベースの組み合わせ所有権」を参照してください。
EnableErrorReporting (省略可能) エラー報告を有効にするためにこのスイッチを使用します。エラー報告を有効にするには、このスイッチを 1 に設定します。詳細については、「5.9 エラー報告」を参照してください。

[先頭に戻る]

4.2 データベース コンポーネント SP4 の再配布

データベース コンポーネント SP4 には自己解凍形式のファイル Sqlredis.exe が含まれています。Sqlredis.exe を実行すると以下のことを行います。

  1. Microsoft Data Access Components (MDAC) 2.8 Service Pack 1 から Mdac_typ.exe を実行します。この操作により、MDAC 2.8 SP1 の主要なコンポーネント (同じバージョンまたはより新しいバージョンを検出しなかった場合) と、SP4 に含まれるバージョンの SQL Server および Desktop Engine のクライアント接続コンポーネントがインストールされます。詳細については、「1.3 Microsoft Data Access Components のバージョンの確認」を参照してください。

  2. Microsoft Jet ODBC ドライバと接続コンポーネントをインストールします。

Sqlredis.exe ファイルは、SP4 に同梱されている Redist.txt ファイルに記載されている条件で再配布できます。

[先頭に戻る]

4.3 Systems Management Server 配布インストール

遠隔地からデータベース コンポーネント SP4 をインストールすることはできません。ただし、Microsoft Systems Management Server を使用して、Windows Server 2003、Windows XP、または Windows 2000 を実行している複数のコンピュータに SP4 を自動的にインストールすることができます。これを行うには、Systems Management Server での SQL Server パッケージの作成を自動化するパッケージ定義ファイル (Smssql2ksp4.pdf) を使用する必要があります。その後、SQL Server パッケージを Systems Management Server を実行しているコンピュータに配布し、インストールできます。Sms2kdef.bat は、Systems Management Server を使用して自動セットアップを開始するバッチ ファイルです。この種類のインストールでは、Setup プログラムは必要な関連システム情報を自動的に検出します。ユーザーの入力は必要ありません。

[先頭に戻る]

5.0 特記事項

ここでは、データベース コンポーネント SP4 の適用後に発生する可能性のある問題点と、SP4 を実行すると利用できる新機能について説明します。これらの問題点に当てはまるのは、以前のバージョンの SQL Server 2000 からアップグレードするために Service Pack を実行する場合です。ここでは、SP4 で提供される問題点の解決について、すべて説明するわけではありません。SP4 で解決された問題点の解決の完全な一覧については、マイクロソフト サポート技術情報の文書 888799 を参照してください。

この Readme ファイルを記述している時点で利用できなかった SQL Server 2000 Service Pack 4 関連のすべての情報は、マイクロソフト サポート技術情報の文書 884525 で公開する予定です。

[先頭に戻る]

5.1 データベースの機能強化

以下の機能強化は、データベース コンポーネント SP4 がインストールされた SQL Server 2000 インスタンスに適用されます。

[先頭に戻る]

5.1.1 ハッシュ チームの削除

(SP1 からの機能)

ハッシュ チームが削除されました。SQL Server 2000 に対する一定の機能強化により、ハッシュ チームは SQL Server Version 7.0 にもたらしたようなパフォーマンス上の利点を生じなくなりました。さらに、ハッシュ チームを削除することにより、SQL Server 2000 はより安定したものになります。

そのため、クエリ オプティマイザはハッシュ チームを使用したクエリ プランを生成しなくなりました。

めったにないケースですが、ハッシュ チームを削除したことにより、クエリの処理速度が低下する場合があります。より適したインデックスを作成することでクエリのパフォーマンスを以前のレベルに戻せるかどうかを確認するために、このようなクエリを分析します。

[先頭に戻る]

5.1.2 Affinity Mask スイッチの追加

(SP1 からの機能)

この Service Pack では 2 つの Affinity Mask スイッチが追加されました。

Affinity Mask I/O スイッチ

この Service Pack では、ディスク入出力操作のスレッドを実行するために、どの CPU を使用するかを指定できるようになりました。このスイッチは、affinity mask オプションと併せて使用する必要があります。詳細については、文書 298402 を参照してください。

Affinity Mask Connection スイッチ

この Service Pack では、特定のネットワーク カードから 1 つのプロセッサまたはプロセッサのセットに SQL Server 接続をバインドするために、VIA (Virtual Interface Architecture) を有効にするように、システムを設定できます。このスイッチは、affinity mask オプションと併せて使用する必要があります。詳細については、文書 299641 を参照してください。

[先頭に戻る]

5.1.3 フィルタ選択されたインデックス付きビュー

(SP2 からの機能)

マイクロソフト サポート技術情報の文書 306467 で説明されている SQL Server 2000 のバグ 355069 が発生した場合、この Service Pack を適用して、それ以後データ変更による予期しない結果が生じることだけを防ぎます。したがって、この修正プログラムを適用するだけでなく、フィルタ条件を使用したビューに基づくすべてのインデックスを再作成する必要があります。

[先頭に戻る]

5.1.4 セットアップ完了後のフルテキスト カタログの再構築

(SP3 からの機能)

SP2 以前からアップグレードする場合、SP4 のインストールの一部としてすべてのフルテキスト カタログが再構築されます。この再構築は自動的に行われ、リソースを大量に使用します。この再構築が完了するまで、フルテキスト カタログに対するクエリは部分的な結果しか返さないか、まったく結果を返さないことがあります。SP4 のインストール後に、カタログが壊れていたこと、カタログのバージョンが古かったこと、および再構築する必要があったことを示すメッセージがシステム イベント ログに含まれています。

詳細については、サポート技術情報の文書 327217 を参照してください。この文書には、再構築プロセス中にフルテキスト検索を利用できるようにする回避策や、自動的な再構築を防ぐ方法も記載されています。

[先頭に戻る]

5.1.5 sp_change_users_login の構文変更

(SP3 からの機能)

@Action=Auto_Fix 引数を指定して sp_change_users_login を実行するときに、パスワードの指定が必要になりました。sp_change_users_login は、そのユーザー用に作成する新しいログインにパスワードを割り当てます。以下の例は新しい @Password 引数を示しています。

sp_change_users_login [ @Action = ] 'action' 
    [ , [ @UserNamePattern = ] 'user' ] 
    [ , [ @LoginName = ] 'login' ]
    [ , [ @Password = ] 'password' ]

@Action=Auto_Fix を指定するときのみ @Password 引数を使用します。以下の例は、Auto_Fix を使用するときの sp_change_users_login コマンドの新しい構文を示しています。SQL Server Books Online のその他の例は、変更されていません。

USE pubs
go
EXEC sp_change_users_login 'Auto_Fix', 'Mary', NULL, 'B3r12-36'
Go

[先頭に戻る]

5.1.6 既定で無効になっている OLE DB プロバイダへのアドホック アクセス

(SP3 からの機能)

DisallowAdhocAccess レジストリ オプションを明示的に設定していない場合、既定では OLD DB プロバイダへのアドホック アクセスは許可されません。これは、OPENDATASOURCE や OPENROWSET などのアドホック クエリ構文がリモート サーバーに対して機能しないことを意味します。アドホック アクセスを許可するためには、DisallowAdhocAccess オプションを明示的に 0 に設定する必要があります。

[先頭に戻る]

5.1.7 新しい SqlServerLike プロバイダ オプション

(SP3 からの機能)

LIKE 述語を含むリモート クエリのより効率的な処理を可能にするために、SP3 で SqlServerLike オプションが追加されました。SQL Server 2000 SP3 以降では、リンク サーバーに LIKE 演算を送信するために、2 つの選択肢を持つようになりました。リンク サーバーの OLE DB プロバイダが LIKE 演算子やワイルド カードに対して SQL Server 構文をサポートする場合、SqlServerLIKE オプションを指定して、SQL Server が SQL Server 構文を使用して LIKE 演算を送信するようにすることができます。リンク サーバーの OLE DB プロバイダが、Entry Level ANSI/ISO SQL-92 構文をサポートすることをレポートする場合、または SQLPROP_ANSILIKE プロパティを返す場合、SQL Server は SQL-92 構文を使用して、LIKE 演算をリンク サーバーに送信します。SQLPROP_ANSILIKE の詳細については、SQL Server 2000 Books Online の「SQLPROPSET_OPTHINTS プロパティ セットのプログラミング」を参照してください。

OLE DB プロバイダの SqlServerLIKE オプションを有効にするには、レジストリ キー値を追加する必要があります。

セキュリティ上の注意  レジストリの編集を誤ると、オペレーティング システムの再インストールが必要になる深刻な問題が発生する恐れがあります。Microsoft は、レジストリを誤って編集したことにより発生した問題に関しては、一切責任を負わないものとします。レジストリを編集する前に、重要なデータをすべてバックアップしてください。

  1. Regedit32 を開きます。

  2. 以下の適切なレジストリ キーを検索します。
  3. <プロバイダ名> キーに SqlServerLIKE という名前の DWORD 値を追加し、その値を 1 に設定します。

[先頭に戻る]

5.1.8 分散クエリの拡張エラー メッセージ

(SP3 からの機能)

分散クエリでは、SQL Server はサーバー エラー情報以外にプロバイダ エラー情報も返します。SQL Server はリンク サーバー間のクエリがエラーになるときに、プロバイダが IErrorRecords OLE DB インターフェイスをサポートするかどうかを確認します。このインターフェイスをサポートする場合、SQL Server は GetErrorInfo 関数を呼び出してプロバイダから詳細エラー情報を取得し、この情報をエラー メッセージの一部としてユーザーに返します。IErrorRecords インターフェイスをサポートしていない場合は、SQL Server の動作は以前と同じです。SQL Server は汎用のエラーを返します。

たとえば、MSDASQL を使用するサーバーに対して以下のクエリを実行します。MSDASQL は sql_variant をサポートしません。

SELECT * FROM remote2k.dqtable.dbo.sqlvariantnotnull 
--Remote2k はループバック サーバーです。

SP3 以前は、SQL Server は以下のエラー メッセージを返しました。

サーバー:メッセージ 7356、レベル 16、状態 1、行 1

OLE DB プロバイダ 'msdasql' は列に対して一貫性のないメタ データを提供しました。
実行時にメタ データ情報が変更されました。

SP3 以降を適用後は、SQL Server は以下のエラー メッセージを返します。

サーバー:メッセージ 7356、レベル 16、状態 1、行 1

OLE DB プロバイダ 'msdasql' は列に対して一貫性のないメタ データを提供しました。
実行時にメタ データ情報が変更されました。

OLE DB エラー トレース [Non-interface error:  Column 'sql_variant' (compile-time
ordinal 3) of object '"dqtable"."dbo"."sqlvariantnotnull"' was reported
to have a DBCOLUMNFLAGS_ISFIXEDLENGTH of 16 at compile time and 0 at run time]。

[先頭に戻る]

5.1.9 SQL ステートメントを返す新しい関数 fn_get_sql

(SP3 からの機能)

SP3 以降には、指定した SQL ハンドルに SQL ステートメントのテキストを返す新しい関数 fn_get_sql が含まれています。さらに、この関数をサポートするために、sysprocesses システム テーブルに新しく 3 つの列を追加しました。sql_handle、stmt_start、および stmt_end です。

fn_get_sql については、SQL Server 2000 Books Online の最新コピーに説明があります。最新バージョンの SQL Server 2000 Books Online のインストールについては、「1.6 SQL Server 2000 Books Online の利用可能な更新」を参照してください。英語版のリファレンスは、「fn_get_sql」です。

[先頭に戻る]

5.1.10 複数データベースの組み合わせ所有権

(SP3 からの機能)

この Service Pack では、複数データベースの組み合わせ所有権をオンまたはオフにする新しいオプションを提供しています。

データベース コンポーネント SP4 をインストール中に、[旧バージョンとの互換性チェック リスト] ダイアログ ボックスに複数データベースの組み合わせ所有権を設定するためのオプションが表示されます。既定では、セットアップがすべてのユーザー データベースに対して複数データベースの組み合わせ所有権をオフにします。ここで、すべてのデータベースに対して複数データベースの組み合わせ所有権を有効にできます。詳細については、「[旧バージョンとの互換性チェックリスト] ダイアログ ボックス」を参照してください。

注意   すべてのデータベースに対して複数データベースの組み合わせ所有権を有効にすることはお勧めしません。

インストール後に、以下の手法を使用して、インスタンスのすべてのデータベースに対して複数データベースの組み合わせ所有権をオンまたはオフにできます。

そのインスタンスで複数データベースの組み合わせ所有権がオフになっている場合は、個別のデータベースに対してこのオプションを設定できます。以下の手法を使用して、あるデータベースに対して複数データベースの組み合わせ所有権をオンおよびオフにします。

詳細については、セットアップ実行時に [旧バージョンとの互換性チェックリスト] ページで [ヘルプ] をクリックするか、SQL Server 2000 Books Online の更新されたエディションをダウンロードするか、サポート技術情報の文書 810474 を参照してください。

[先頭に戻る]

5.1.11 トレース フラグ 1204 の機能強化

(SP3 からの機能)

トレース フラグ 1204 は、デッドロックに陥っているロックの種類と、影響する現在のコマンドを返します。SP3 以降ではこのトレース フラグがオンになっていると、デッドロック情報が自動的にエラー ログに記録されます。

[先頭に戻る]

5.1.12 sp_changedbowner の権限の変更

(SP3 からの機能)

sysadmin 固定サーバー ロールのメンバだけが sp_changedbowner システム ストアド プロシージャを実行できます。

[先頭に戻る]

5.1.13 デバッグ機能の変更

(SP3 からの機能)

Microsoft Visual Studio® 6.0 以前または SP3 以前の SQL Server クエリ アナライザでのストアド プロシージャのデバッグ機能は、既定でオフになります。(クライアント アプリケーションのデバッグ中に SQL Server Transact-SQL にブレークポイントを指定して停止する) アプリケーションのデバッグも既定でオフになります。デバッグ機能を有効にするには、パラメータ legacy_on を渡して、sp_sdidebug を実行します。デバッグ機能を無効にするには、このプロシージャに legacy_off を渡します。

注意   運用サーバーで sp_sdidebug ストアド プロシージャを実行することはお勧めしません。

詳細については、マイクロソフト サポート技術情報の文書 328151 を参照してください。

注意   Books Online では、クライアント側のデバッグ コンポーネントである sqldbreg.exe について説明しています。SP3 では、このコンポーネントのファイル名が sqldbreg2.exe に変更されました。

[先頭に戻る]

5.1.14 クラスタ化されたサーバー上で名前付きパイプを無効にできない

(SP3 からの機能)

Service Pack の適用後、フェールオーバー クラスタに参加しているデータベース エンジンのインスタンス上では、名前付きパイプ プロトコルを無効にできなくなります。

[先頭に戻る]

5.1.15 UDP ポート 1434 での操作

(SP3a からの機能)

SQL Server 2000 SP3a からは、ネットワーク通信をサポートするように設定されていない SQL Server 2000 データベース エンジンおよび MSDE 2000 のインスタンスは、UDP (User Datagram Protocol) ポート 1434 の使用を停止します。ネットワーク通信をサポートするように構成されているインスタンスは、UDP 1434 を使用します。

SP3a 以降にアップグレードされたインスタンスは、そのインスタンスの共有メモリ Net-Library を除くすべてのサーバー Net-Library が無効になると、必ず UDP 1434 の使用を停止します。任意のサーバー Net-Library を有効にすると、そのインスタンスはポート 1434 の使用を開始します。サーバー Net-Library の有効化または無効化に関する詳細については、SQL Server 2000 Books Online の「SQL Server ネットワーク ユーティリティ」を参照してください。

コンピュータによる UDP ポート 1434 の使用は、そのコンピュータ上の SQL Server 2000 および MSDE 2000 のすべてのインスタンスが SP3a 以降にアップグレードされ、ネットワーク通信をサポートしないように設定されるまで停止されません。

UDP ポート 1434 が開かれるか閉じられるかは、共有メモリ Net-Library の状態には依存しません。共有メモリ Net-Library はローカル接続にのみ使用され、ネットワークを使用しません。共有メモリ Net-Library は常にアクティブで、有効または無効にできません。

SQL Server 2000 データベース エンジンのインスタンスをインストールまたはアップグレードするときに、すべてのサーバー Net-Library を無効にすることはできません。

[先頭に戻る]

5.1.16 最大ネットワーク パケット サイズの変更

(SP4 からの機能)

SP4 では、ネットワーク パケット サイズのオプションの最大値 (sp_configure を使用して設定) は 32767 です。これは、以前の最大値 65,536 の半分より少し小さな値です。アップグレード中に、32,767 より大きい既存の値は自動的に 32,767 に調整されます。スクリプトが sp_configure を使用して 32,767 より大きく、65,536 以下の値を設定しようと試みた場合も、値は 32,767 に設定されます。ネットワーク パケット サイズを 65,536 より大きい値に設定するとエラーになります。

[先頭に戻る]

5.1.17 大きな IN リストまたは多数の OR 句を使用したクエリの最適化

(SP4 からの機能)

SP4 には、大きな IN リストまたは多数の OR 句を使用した述語を含むクエリに影響を与える、SQL Server オプティマイザの動作の変更が含まれています。具体的には、この変更 (SQL Server 2000 修正プログラム 789 で導入) は、以下のものを含むクエリ (または、以下のものを含む同等の式を使用した書き換えが可能なクエリ) に影響します。

この変更によって、これらの種類のステートメントをコンパイルするときに SQL Server が使用するメモリの量が減少するため、その結果メモリ不足のエラーが回避されています。めったにないケースですが、非常に大容量のメモリを備えている、並列処理の少ないシステムでこのようなクエリを実行すると、オプティマイザによって低パフォーマンスのクエリ プランが選択される場合があります。オプティマイザの動作の変更を優先させるため、この Service Pack ではトレース フラグ 9060 が提供されています。既定では、トレース フラグ 9060 はオフです。トレース フラグがオンの場合、修正プログラム 789 以前の SP3 の動作が有効になります。トレース フラグがオンのときに エラー 701 (システム メモリ不足) が発生する場合は、IN リスト内の値のために一時テーブルまたはテーブル変数を使用してクエリを書き換えることを検討してください。数値の範囲については、BETWEEN 句、または > (より大きい) 演算子や < (より小さい) 演算子を使用してください。トレース フラグの詳細については、SQL Server Books Online の「Trace Flags (トレース フラグ)」を参照してください。

[先頭に戻る]

5.1.18 今後のネットワーク プロトコル サポート

(SP4 からの機能)

SP4 では、Banyan VINES、Multiprotocol、AppleTalk、および NWLink IPX/SPX ネットワーク プロトコルがサポートされています。ただし、これらのプロトコルは SQL Server 2005 以降のリリースではサポートされない予定です。これに応じて計画を立ててください。

[先頭に戻る]

5.1.19 Windows on Windows 64 モードで実行中の SQL Server インスタンスの監視

(SP4 からの機能)

Windows Server 2003 x64 SP1 以降で Windows on Windows 64 (WOW) モードで実行する場合、既定の 64 ビット版の Windows パフォーマンス モニタを使用して、SQL Server 2000 SP4 のインスタンスを監視するために使用されている SQL Server パフォーマンス カウンタにアクセスすることはできません。代わりに、32 ビット版の Windows パフォーマンス モニタを使用する必要があります。32 ビット版は次の場所にあります。

%systemdrive%\WINDOWS\SysWOW64\perfmon.exe

WOW モードでは、SQL Server パフォーマンス カウンタを表示できるのは、SQL Server 2000 SP4 のインスタンスと同じコンピュータで 32 ビット版のパフォーマンス モニタを実行している場合のみです。

この制限は、Windows Server 2003 for 64-Bit Itanium-based Systems には適用されません。

[先頭に戻る]

5.2 レプリケーションの機能強化

ここでは、SP4 に含まれる SQL Server 2000 レプリケーションの機能強化について説明します。

[先頭に戻る]

5.2.1 トランザクション レプリケーション UPDATE カスタム ストアド プロシージャ

(SP1 からの機能)

トランザクション レプリケーションのセットアップ中に、操作の挿入、削除、および更新を行うカスタム ストアド プロシージャがサブスクリプション データベースに作成されます。1 つの UPDATE ステートメントで影響を受ける列の数とは無関係に、update カスタム ストアド プロシージャはサブスクリプション テーブルのすべての列を更新します。変更されなかったすべての列は、単純に UPDATE を実行する前と同じ値に再設定されます。一般的には、この操作が問題になることはありません。ただし、これらの中のいずれかの列がインデックスを持つ場合、この再設定には時間がかかります。

トランザクション レプリケーションを使用していて、サブスクリプション テーブルにいくつかインデックスを持ち、更新により値が変更される列が少ない場合、サブスクライバで変更が適用されているときの、インデックスのメンテナンスのオーバーヘッドがパフォーマンスの制限要因になる可能性があります。たとえば、レポート処理の目的で使用されるサブスクリプション データベースは、パブリケーション データベースよりも多くのインデックスを持つ場合があります。実行時に UPDATE ステートメントを動的に構築すると、パフォーマンスが向上する可能性があります。更新処理には変更される列だけを含めるようにして、最適な UPDATE 文字列を作成します。

この Service Pack には、新しいストアド プロシージャ sp_scriptdynamicupdproc が含まれています。このストアド プロシージャは、実行時に動的に UPDATE ステートメントを構築するためにサブスクライバで使用できるカスタム ストアド プロシージャを生成します。ただし、動的に UPDATE ステートメントを構築するための余分な処理が実行時に必要になります。

sp_scriptdynamicupdproc については、SQL Server 2000 Books Online の最新コピーに説明があります。最新バージョンの SQL Server 2000 Books Online のインストールについては、「1.6 SQL Server 2000 Books Online の利用可能な更新」を参照してください。英語版のリファレンスは、「sp_scriptdynamicupdproc」です。

[先頭に戻る]

5.2.2 一意列でのトランザクション レプリケーション UPDATE ステートメント

(SP1 からの機能)

トランザクション レプリケーションでは、通常 UPDATE ステートメントは更新としてレプリケートされます。しかし、更新が一意インデックス、クラスタ化インデックス、または一意制約として使用される式の一部である列を変更すると、サブスクライバでは DELETE ステートメントを実行し、その後 INSERT ステートメントを実行することにより更新が行われます。この種の更新は複数の行に影響し、更新が行から行へ引き継がれていくときに一意性に違反する可能性が生じるため、このような方法がとられます。

ただし、更新が 1 行にしか影響しない場合、一意性に違反する可能性はありません。そのため、1 行だけに影響する一意列への更新を UPDATE ステートメントとしてレプリケートできるように、この Service Pack にはトレース フラグ 8207 が追加されました。この最適化は、サブスクライバにユーザー定義 UPDATE トリガを組み込み、一意列で 1 行だけに影響する更新のためにこれらのトリガを必要とするアプリケーション向けに特別に追加されました。

トレース フラグ 8207 を使用するには、ログ リーダー エージェントを開始する前にコマンド プロンプトからオンにする (sqlservr.exe -T8207) か、実行時に DBCC TRACEON(8207, -1) を使用します。

重要  通常、トレース フラグ 8207 は読み取り専用トランザクション レプリケーションで使用されます。サブスクライバで主キー UPDATE が発生する可能性がある場合、更新可能なサブスクリプションではこのトレース フラグを使用しないでください。

[先頭に戻る]

5.2.3 同時実行スナップショット処理から削除された制限事項

(SP1 からの機能)

SQL Server 2000 では、パブリッシュされているテーブルが主キーまたはクラスタ化キーではない一意キーを持っている場合は、同時実行スナップショット処理は推奨されませんでした。同時実行スナップショットが生成されているときに、クラスタ化キーに対するデータ修正が行われると、同時実行スナップショットがサブスクライバに適用されるときに、レプリケーションは重複キー エラーで失敗する可能性がありました。この Service Pack では、同時実行スナップショット処理の使用に関する制限事項がすべてなくなりました。

[先頭に戻る]

5.2.4 トランザクション レプリケーションのスクリプティング カスタム ストアド プロシージャ

(SP1 からの機能)

非同期サブスクリプション (つまり、初期スナップショットを受け取らないサブスクリプション) をセットアップしているときは、INSERT、UPDATE、および DELETE ステートメントに対するカスタム ストアド プロシージャを手動で作成する必要がありました。通常は、初期スナップショットが配布されるとき、サブスクライバでこれらのステートメントが作成されます。パブリケーション レベルのカスタム ストアド プロシージャ用のスクリプトを生成するために、新しいストアド プロシージャ sp_scriptpublicationcustomprocs が追加されました。この新しい機能により、非同期サブスクリプションのセットアップが容易になりました。

sp_scriptpublicationcustomprocs については、SQL Server 2000 Books Online の最新コピーに説明があります。最新バージョンの SQL Server 2000 Books Online のインストールについては、「1.6 SQL Server 2000 Books Online の利用可能な更新」を参照してください。英語版のリファレンスは、「sp_scriptpublicationcustomprocs」です。

[先頭に戻る]

5.2.5 マージ レプリケーションの保有期間を基準にしたメタ データのクリーンアップ

(SP1 からの機能)

マージ レプリケーションのシステム テーブルにメタ データが大量に存在するときは、メタ データをクリーン アップするとパフォーマンスが向上します。SQL Server 2000 SP1 以前は、メタ データは sp_mergecleanupmetadata を実行することによってのみクリーン アップできました。しかし、SQL Server 2000 SP1 以降には、保有期間を基準にしたメタ データのクリーンアップが含まれています。その結果、以下のシステム テーブルからメタ データを自動的に削除できるようになりました。

注意   パブリケーションで @keep_partition_changes 同期最適化オプションが有効である場合は、変更前イメージ テーブルが存在します。

保有期間を基準にしたメタ データ クリーンアップは以下の場合に発生します。

sp_add_agent_parameter の追加パラメータ

システム プロシージャ sp_add_agent_parameter が MetadataRetentionCleanup パラメータを持つようになりました。このパラメータを使用して、[マージ エージェントのプロファイル] にメタ データ保有期間クリーンアップを追加または削除できます。値 1 はプロファイルがクリーンアップを含むことを示し、値 0 はプロファイルがクリーンアップを含まないことを示します。たとえば、メタ データ保有期間クリーンアップをプロファイルに追加するには、次のステートメントを実行します。

EXEC sp_add_agent_parameter @profile_id=<my_profile_id>,
  @parameter_name='MetadataRetentionCleanup', @parameter_value=1
異なるバージョンの SQL Server を含むトポロジ内のメタ データ クリーンアップ

マージ レプリケーションに関係しているデータベースで、保有期間を基準にした自動クリーンアップが行われるためには、そのデータベースとマージ エージェントの両方が SQL Server 2000 SP1 以降を実行しているサーバー上に存在する必要があります。以下はその例です。

一部のサーバーで自動クリーンアップが行われ、その他のサーバーで自動クリーンアップが行われなかった場合、間違った競合の原因になることがありますが、これはめったに起こりません。SQL Server 2000 SP1 以前のバージョンの SQL Server を含むトポロジでは、自動クリーンアップされないすべてのサーバーで sp_mergemetadatacleanup を実行すると、パフォーマンスが向上することがあります。

間違った競合の回避

保有期間を基準にしたメタ データのクリーンアップによって、他のノードでの変更が、無警告で一貫性を欠いて上書きされることを防止します。ただし、以下の両方の条件を満たす場合に間違った競合が発生する可能性があります。

たとえば、メタ データがパブリッシャでクリーンアップされ、サブスクライバでクリーンアップされていないときに、パブリッシャで更新が行われると、データが同期されているにもかかわらず、競合が発生します。

この競合を回避するには、関連するノードでほぼ同時にメタ データがクリーンアップされるようにします。-MetadataRetentionCleanup を 1 に設定すると、マージが開始される前に、パブリッシャとサブスクライバの両方で自動的にクリーンアップが行われます。その結果、すべてのノードで同時にクリーンアップが行われることになります。競合が発生する場合、マージ レプリケーション競合回避モジュールを使用して、競合を調べ、必要に応じて結果を変更します。

アーティクルが複数のパブリケーションに所属している場合、または再パブリッシュする状況にある場合、指定した行の保有期間がパブリッシャとサブスクライバで異なる可能性があります。一方のメタ データがクリーンアップされ、他方のメタ データがクリーンアップされない機会を減らすには、これらの異なるパブリケーションの保有期間を同じ保有期間に設定することをお勧めします。

注意   システム テーブルにクリーンアップする必要のあるメタ データが大量に存在する場合は、マージ プロセスの実行に時間がかかります。定期的にメタ データをクリーンアップすることにより、この問題を防ぐことができます。

[先頭に戻る]

5.2.6 マージ レプリケーションのバックアップと復元の問題点

(SP1 からの機能)

バックアップから復元されるパブリケーション データベースは、動作が正しく一貫性を保つことを保証するために、まずグローバルなサブスクリプション (つまり、優先度値が割り当てられたサブスクリプション) を持つサブスクリプション データベースと同期する必要があります。同期操作は、パブリケーション データベースで復元操作により失われた変更が正確に再適用されることを保証します。

パブリケーション データベースを、匿名サブスクリプションを持つサブスクリプション データベースと同期しないでください。匿名サブスクリプションは、パブリケーション データベースに変更を適用するのに十分なメタ データを持っていないので、このような同期操作はデータの不一致を生じる可能性があります。

マージ レプリケーションに対してバックアップおよび復元を予定しているときは、以下の点も考慮してください。

サブスクライバがサブスクライブしているすべてのパブリケーションのうち、保有期間が最も短いものよりもバックアップが古くない場合のみ、バックアップからサブスクリプション データベースを復元します。たとえば、サブスクライバが保有期間がそれぞれ 10 日、20 日、30 日の 3 つのパブリケーションをサブスクライブしている場合、データベースの復元に使用するバックアップは、10 日以内のものである必要があります。

バックアップを実行する前に、サブスクライバとパブリッシャを同期することを強くお勧めします。同期をとらないと、サブスクライバをこのバックアップから復元する場合に、システムが正しく一貫性を保たない可能性があります。バックアップ ファイル自体が新しくても、パブリッシャとの最後の同期が保有期間よりも古い可能性もあります。たとえば、パブリケーションの保有期間が 10 日であるとします。最後の同期が 8 日前に行われ、今日バックアップを実行しました。バックアップを 4 日後に適用すると、最後の同期は 12 日前に行われたことになります。これは保有期間を過ぎています。バックアップ前にサブスクライバが正しく同期されていた場合は、サブスクリプション データベースは保有期間内に収まります。

パブリケーションの保有期間値を変更する必要がある場合は、データの一貫性を損なうことを防ぐために、サブスクライバを手動で再初期化します。保有期間を基にしたメタ データ クリーンアップ機能は、パブリケーションの保有期間に達したとき、マージ システム テーブルから保有期間の過ぎたメタ データを削除します。

パブリケーションの保有期間値は、保有期間内に同期されていないサブスクリプションの有効期限がいつ切れるのかを判断するために使用されています。クリーンアップ後に、パブリケーションの保有期間を増加させ、サブスクリプションをパブリッシャにマージしようとすると (メタ データは既に削除されています)、保有期間値が増加されているのでサブスクリプションの有効期限は切れていません。その上、パブリッシャはサブスクライバに変更をダウンロードするための メタ データを十分に持っていないので、一貫性を欠くことになります。

[先頭に戻る]

5.2.7 別のバージョンの SQL Server からレプリケートされたデータベースの復元

(SP1 からの機能)

同じサーバーとデータベース (バックアップを作成したサーバーと同じバージョンを実行している) にバックアップを復元すると、レプリケーションの設定は保持されます。データベースをバックアップするときに使用していたバージョンとは異なるバージョンの SQL Server にレプリケートされたデータベースを復元する場合は、以下の問題点に注意してください。

[先頭に戻る]

5.2.8 ログ リーダー エージェントの新しい -MaxCmdsInTran パラメータ

(SP1 からの機能)

SP1 からは、ログ リーダー エージェント用に新しいコマンド プロンプト パラメータ -MaxCmdsInTran が追加されました。大量のコマンドに影響するトランザクション (一般的には、大量更新や削除) では、サブスクライバへのトランザクションの反映を開始する前に、ディストリビューション エージェントがトランザクション全体をディストリビューション データベースに書き込むために、ログ リーダー エージェントを待機します。この遅延によってディストリビューション エージェントがブロックされ、2 つのエージェント間での並列処理が減少します。

–MaxCmdsInTran を使用することにより、ログ リーダー エージェントは大きなトランザクションを小さなチャンクに分割し、各チャンクが -MaxCmdsInTran の入力と同量か、それよりも少ないコマンドを含むようにします。その結果、ログ リーダー エージェントが後半のチャンクを処理しているときに、ディストリビューション エージェントは同じトランザクションの前半のチャンクの処理を開始できます。

ログ リーダー エージェントとディストリビューション エージェントの間での並列処理が向上することにより、レプリケーション スループット全体が向上します。ただし、トランザクション チャンクはサブスクライバで個別のトランザクションとしてコミットされるので、ACID プロパティの原子性を妨げることに注意してください。このことは、ほとんどの環境では問題になりませんが、テストを行って確認することをお勧めします。

–MaxCmdsInTran パラメータの定義

-MaxCmdsInTran パラメータ値には正の整数 (1 以上) を指定します。値 0 を指定することは、パラメータを使用しないのと同じです。このパラメータはトランザクションが非常に大きいときのみパフォーマンスを向上させるので、このパラメータには一般的に、5,000 を超える値を指定します。以下はその例です。

logread.exe -MaxCmdsInTran 10000

このパラメータを使用するには、パブリッシャで SQL Server 2000 SP 1 以降が実行されていて、ログ リーダー エージェントとディストリビューション データベースが SP3 以降にアップグレードされている必要があります。それ以外の場合には、–MaxCmdsInTran は無視されます。

[先頭に戻る]

5.2.9 一意ではないクラスタ化インデックスの制限

(SP2 からの機能。トランザクション レプリケーションのみに適用されます。)

テーブルがトランザクション レプリケーション用にパブリッシュされた後は、テーブルに一意ではないクラスタ化インデックスを作成できません。インデックスを作成する前に、まずそのテーブルを含むすべてのパブリケーションを削除する必要があります。

[先頭に戻る]

5.2.10 スナップショット エージェントの新しい -MaxNetworkOptimization コマンド ライン引数

(SP2 からの機能)

マージ レプリケーションの通常の処理中に、サブスクライバのパーティションに所属しない行に対して、サブスクライバに DELETE コマンドを送信できます。この種の DELETE コマンドは関連性のない削除と呼ばれます。関連性のない削除は、データの整合性や一貫性には影響しませんが、不必要なネットワーク トラフィックの原因になります。

関連性のない削除によるネットワーク トラフィックを削減するには、マージ レプリケーション パブリケーションで新しいスナップショット エージェント パラメータ -MaxNetworkOptimization を使用します。このパラメータを 1 に設定すると、関連性のない削除の機会が最小限になり、それによってネットワークが最大限に最適化されます。

注意   このパラメータを 1 に設定すると有効なのは、マージ パブリケーションの同期最適化オプションが true (sp_addmergepublication の @keep_partition_changes パラメータ) に設定されている場合のみです。

このパラメータを 1 に設定すると、複数レベルの結合フィルタや複雑なサブセット フィルタが存在する場合は、パブリッシャでメタ データのストレージが増加し、パフォーマンス低下の原因になる可能性があるので、既定値は 0 です。レプリケーション トポロジを注意深く評価し、関連性のない削除によるネットワーク トラフィックが受け入れられないほど高い場合にのみ、-MaxNetworkOptimization を 1 に設定します。

システム プロシージャ sp_add_agent_parameter を次のように実行すると、[スナップショット エージェントのプロファイル] にこのパラメータを追加できます。

EXEC sp_add_agent_parameter 1, 'MaxNetworkOptimization', 1

[先頭に戻る]

5.2.11 マージ レプリケーションが使用する新しいロール

(SP3 からの機能)

SP3 以降では、マージ レプリケーションで使用する新しいロールが自動的に作成されます。新しいロールの名前は、MSmerge-<パブリケーション ID> という形式になります。ロールはパブリッシャでマージ レプリケーション パブリケーションごとに作成され、パブリッシャでマージ パブリケーションへのアクセスを制御するパブリケーション アクセス リスト (PAL) として動作します。このロールが削除された場合は、SP3 以降に含まれる新しいストアド プロシージャ sp_createmergepalrole を実行し、ロールを再作成できます。このストアド プロシージャは、ロールを再作成するためにパブリッシャのパブリケーション データベースで実行されます。

sp_createmergepalrole については、SQL Server 2000 Books Online の最新コピーに説明があります。最新バージョンの SQL Server 2000 Books Online のインストールについては、「1.6 SQL Server 2000 Books Online の利用可能な更新」を参照してください。英語版のリファレンスは、「sp_createmergepalrole」です。

[先頭に戻る]

5.2.12 sysadmin 以外のユーザーが作成したサブスクリプションの新しい要件

(SP3 からの機能)

sysadmin 固定サーバー ロールのメンバではないユーザーがサブスクリプションを作成する場合は、以下のいずれか 1 つのことを行う必要があります。

注意   リモート エージェントをアクティブにする機能では、ジョブ ステップを必ず sysadmin 固定サーバー ロール内のユーザー アカウントのコンテキストで実行する必要があります。

[先頭に戻る]

5.2.13 ストアド プロシージャの権限の変更

(SP3 からの機能)

レプリケーション トポロジの実装、管理、および監視に使用する多くのストアド プロシージャの権限が変更されました。これらの変更の大部分は、ストアド プロシージャの実行に必要な権限を厳しくすることに関係しています。新しい権限の詳細については、更新されたバージョンの SQL Server Books Online のレプリケーション ストアド プロシージャに関する Transact-SQL リファレンス マニュアルを参照してください。更新された SQL Server Books Online の詳細については、「1.6 SQL Server 2000 Books Online の利用可能な更新」を参照してください。

[先頭に戻る]

5.2.14 sp_addmergearticle と sp_changemergearticle の新しいパラメータ

(SP3 からの機能)

sp_addmergearticle と sp_changemergearticle の両方に新しいパラメータ @published_in_tran_pub が追加されました。このパラメータを使用して、トランザクション パブリケーションでマージ パブリケーションのアーティクルもパブリッシュすることを示します。@published_in_tran_pub は nvarchar(5) 型で、既定値は FALSE です。TRUE を指定すると、トランザクション パブリケーションでもアーティクルがパブリッシュされます。

注意   sp_changemergearticle でこのパラメータを変更する場合は、スナップショットを無効にし、サブスクライバを再初期化する必要があります。

[先頭に戻る]

5.2.15 パブリッシングとディストリビューションの設定ウィザードの新しいページ

(SP3 からの機能)

パブリッシングとディストリビューションの設定ウィザードに、新しい [ディストリビュータ パスワード] ページが含まれるようになりました。サーバーをリモート ディストリビュータとして使用するために 1 つ以上のパブリッシャを選択していて、これらのパブリッシャのうち 1 つ以上がパスワードを必要とする場合、このページでパスワードを入力する必要があります。パブリッシャとディストリビュータ間の接続は、リンク サーバーとリモート サーバーによるハイブリッド接続です。この接続では、ログインとして distributor_admin が使用されます。既定では、パブリッシャはリモート ディストリビュータと信頼関係を結ばない形式で設定されるので、パスワードが必要になります。

注意   最新バージョンの SQL Server 2000 Books Online をダウンロードしてインストールしている場合は、新しいページで [ヘルプ] ボタンをクリックするとこの情報を参照できます。

[先頭に戻る]

5.2.16 Windows 同期マネージャ サポートの変更

(SP3 からの機能)

SQL Server は、既存のサブスクリプション (SQL Server Enterprise Manager、SQL-DMO、およびレプリケーション ストアド プロシージャを使って作成されたサブスクリプション) を Windows 同期マネージャで使用できるようにします。また、Windows 同期マネージャを使って新しいサブスクリプションを作成することもできます。Service Pack 適用後にサブスクリプションの同期をとると、Windows 同期マネージャが同期に関係するサーバーに接続するために必要な 1 つまたは複数のパスワードを問い合わせます。

[先頭に戻る]

5.2.17 レプリケーション データベースのアタッチまたは復元の必要条件の変更

(SP3 からの機能)

特定の条件の組み合わせに該当すると、パブリッシュされたデータベースのアタッチまたは復元のプロセスで、レプリケーションが機能しない場合があります。このような条件の組み合わせを以下に示します。

これらの条件にすべて当てはまる場合は、アタッチまたは復元されるデータベースで sp_changedbowner ストアド プロシージャを実行する必要があります。所有権を sa 組み込み管理者ログインに割り当てます。これでレプリケーションが正しく機能することが保証されます。

注意   sp_changedbowner ストアド プロシージャを実行するには、sysadmin 固定サーバー ロールのメンバである必要があります。

複数データベースの組み合わせ所有権の詳細については、「5.1.10 複数データベースの組み合わせ所有権」を参照してください。

[先頭に戻る]

5.2.18 レプリケーション ActiveX コントロールのセキュリティ指定の変更

(SP4 からの機能)

レプリケーション ActiveX® コントロール (sqlinitx.dll、sqldistx.dll、sqlmergx.dll、および replerrx.dll) は "スクリプトを実行しても安全" および "初期化しても安全" とは指定されなくなりました。これらのコントロールのセキュリティと機能の動作は SP3 以降変更されていませんが、セキュリティ標準を満たすためにセキュリティ指定が変更されました。これらの変更は、Web ページに埋め込まれたレプリケーション ActiveX コントロールを起動するアプリケーションに影響を与える可能性があります。

[先頭に戻る]

5.2.19 マージ パブリケーションのアーティクルの新しいパラメータ

(SP4 からの機能)

sp_addmergearticle の呼び出し時に、新しいパラメータ @compensate_for_errors を指定できます。このパラメータは、同期中にエラー (制約違反など) が発生した場合に補正動作を行うかどうかを指定します。TRUE (既定値) に設定されている場合、あるノードで同期中に適用できなかった変更があると、他のすべてのノードでその変更を取り消す補正動作が生じます。これは、場合によっては望ましい動作ですが、問題になる場合もあります。たとえば、正しく設定されていない 1 つのサブスクライバがエラーを生成すると、パブリッシャと他のすべてのサブスクライバで変更が取り消される可能性があります。

値として FALSE を指定すると、補正動作は無効になりますが、エラーはまだログに記録されており、以後のマージでは引き続き変更の適用が試みられます。影響を受ける行のデータの一貫性が失われたように見えますが、エラーに対処するとすぐに変更を適用できるので、データの一貫性が保持されます。

注意   アーティクルのソース テーブルが別のパブリケーションで既にパブリッシュされている場合は、両方のアーティクルについて @compensate_for_errors の値が同じであることが必要です。

[先頭に戻る]

5.2.20 トランザクション パブリケーションの ID 列をレプリケートする新しいスキーマ オプション

(SP4 からの機能)

以前のリリースでは、トランザクション パブリケーションの ID 列は、ID プロパティが設定されずに int のような基本データ型としてレプリケートされていました。この手法は、サブスクライバでの挿入を許可しないアプリケーションには適切です。SQL Server 2000 SP4 では、トランザクション パブリケーションのために新しいスキーマ オプション (0x4) が導入されています。このオプションは、ID 列を ID 列としてレプリケートするために使用されます。これは、双方向のレプリケーションやサブスクライバを warm-standby サーバーとして使用する場合を含めて、多くの場合に役立ちます。これらの場合、サブスクライバで挿入の発生が可能で、挿入によって ID 列の値が増分されることになります。

ID 列を ID 列としてレプリケートする必要があることを指定するには、次の操作を行います。

  1. パブリッシャでテーブルを作成するときに、ID 列に NOT FOR REPLICATION オプションを指定します。これで、ID 列の値を増分させるのはレプリケーション エージェントによる挿入ではなく、ユーザーの挿入のみになります。詳細については、SQL Server Books Online の「CREATE TABLE」を参照してください。

  2. ID 列を持つアーティクルを追加するときに、sp_addarticle の @schema_option パラメータにオプション 0x4 を設定します。このパラメータの詳細については、SQL Server Books Online の「sp_addarticle」を参照してください。

  3. サブスクライバの初期化後に、ID 列を持つ各テーブルに対して DBCC CHECKIDENT を実行します。この操作では、サブスクライバの ID 列に挿入する開始値を指定できるため、サブスクライバに挿入される値は、パブリッシャで挿入される値と同じにはなりません。たとえば、サブスクライバでの挿入を 1,000,000 から開始するには、次のように指定します。
    USE Northwind
    GO
    DBCC CHECKIDENT ('Employees', RESEED, 1000000)
    GO

詳細については、SQL Server Books Online の「DBCC CHECKIDENT」を参照してください。

5.2.21 Windows on Windows 64 モードで実行中のディストリビュータで SQL Server 以外のサブスクライバがサポートされない

(SP4 からの機能)

X64 または互換プロセッサで動作する Windows 2003 SP1 システムにおいて、Windows on Windows 64 モードで実行している SQL Server 2000 (32-bit) のディストリビュータ インスタンスは、SQL Sever 以外のサブスクライバを持つことができません。SQL Server 2000 SP4 では、Windows on Windows 64 モードの実行はサポートされるようになりましたが、ディストリビュータから SQL Server 以外のサブスクライバに接続するために使用されるドライバやプロバイダで、このモードがサポートされていません。

[先頭に戻る]

5.3 SQL Server エージェントと共有ツールの機能強化

ここでは SP4 に含まれる SQL Server エージェントと共有ツールの機能強化について説明します。

[先頭に戻る]

5.3.1 SQL Server エージェント ログ アカウント情報

(SP2 からの機能)

SQL Server エージェント ジョブ ヒストリは、各ジョブ ステップを実行する Windows アカウントを記録するようになりました。レプリケーション タスクやデータ変換サービス (DTS) タスク用に定義された定期ジョブを含めて、定期ジョブでのセキュリティの問題を診断するためにこの情報が役に立ちます。

[先頭に戻る]

5.3.2 マスタ/対象サーバー設定の変更

(SP3 からの機能)

マルチサーバー管理は、SQL Server の複数のインスタンス間の管理作業を自動化するプロセスです。2 台以上のサーバーを管理し、保守作業を集中管理する場合にマルチサーバー管理を使用します。

SP3 以降では、SQL Server エージェント プロキシ アカウントを使用する必要がない場合は、SQL Server エージェント サービス アカウントが Windows 管理者である必要はありません。SQL Server エージェント プロキシ アカウントの詳細については、「5.6.3 SQL Server エージェントのプロキシ アカウントの強化」を参照してください。SQL Server エージェント サービス アカウントは、sysadmin 固定サーバー ロールのメンバである必要があります。

マルチサーバー管理では、少なくとも 1 台のマスタ サーバーと少なくとも 1 台の対象サーバーを持つ必要があります。マスタ サーバーは、ジョブを対象サーバーに配布し、対象サーバーからイベントを受け取ります。マスタ サーバーは、対象サーバーで実行するジョブのジョブ定義の中心となるコピーを格納します。対象サーバーはマスタ サーバーに定期的に接続し、実行するジョブのリストを更新します。マスタ サーバーに新しいジョブが存在する場合は、対象サーバーがそのジョブをダウンロードし、マスタ サーバーから切断します。対象サーバーはそのジョブを完了した後に、マスタ サーバーに再接続し、そのジョブの状態を報告します。

SP4 を適用する前に、いくつかの手順を完了して SQL Server 2000 マスタ/対象サーバー設定をアップグレードする必要があります。SP4 で行われる変更は SQL Server 7.0 対象サーバーとは互換性がありません。また、SP3 以降 を実行していないすべてのサーバーと互換性がありません。これは、元の SQL Server 2000 機能の変更です。

マスタ/対象サーバー設定をアップグレードするには、次の操作を行います。

  1. マスタ サーバーで新しい MSX (マスタ サーバー) アカウントを作成します。これはアップグレードする TSX (対象サーバー) サーバー (単数または複数) を準備するためです。これを行うには、以下のコマンドを実行します。
    --Option A: Windows authentication
    EXEC sp_grantlogin 'DOMAIN\user'
    GO
    USE msdb
    GO
    EXEC sp_adduser 'DOMAIN\user', 'DOMAIN\user', 'TargetServersRole'
    GO
    
    --Option B: SQL Server authentication – see explanation below for 
    --details.
    EXEC sp_addlogin <MSXAccount>, <MSXAccountPassword>, 'msdb' 
    GO
    USE msdb
    GO
    EXEC sp_adduser <MSXAccount>, <MSXAccount>, 'TargetServersRole'
    GO

    <MSXAccount> は選択した SQL ログイン名を表し、<MSXAccountPassword> は関連付けられたパスワードを表します。

    注意   これらの値は単一引用符で囲む必要があります。

    MSX アカウントを選択するときには以下の選択肢があります。

    SQL Server エージェント プローブ アカウント (<コンピュータ名>_msx_probe_login) を指定しないでください。TSX サーバーがプローブ アカウントを使用しなくなったので、SQL Server は SP3 以降へのアップグレードの一部として古いプローブ アカウントを削除します。

  2. TSX サーバーを一度に 1 台ずつ SP4 にアップグレードします。Service Pack を適用する前に、アップグレードするタイミングの詳細について、手順 3. を参照してください。

  3. サーバーがダウンしている時間を最小限にとどめるために、SP4 へのアップグレード完了後すぐに各 TSX サーバーで拡張ストアド プロシージャ xp_sqlagent_msx_account を実行します。

    注意   xp_sqlagent_msx_account 実行後に、各サーバーで SQL エージェントを停止し、再開する必要があります。

    xp_sqlagent_msx_account の詳細については、「5.3.3 新しい SQL Server エージェント拡張ストアド プロシージャ」を参照してください。

  4. マスタ サーバーに SP4 を適用します。TSX サーバーは _msx_probe を使用しなくなったので、SP4 Setup は古い _msx_probe アカウントを削除します。SQL エージェント ジョブを所有しているアカウントは削除されないので、ジョブの所有者を別のユーザーに変更し、このようなアカウントを手動で削除する必要があります。SQL エージェント ジョブを所有する古い _msx_probe アカウントを引き続き使用する場合は、_msx_probe アカウントのパスワードを変更する必要が生じる場合があります。

[先頭に戻る]

5.3.3 新しい SQL Server エージェント拡張ストアド プロシージャ

(SP3 からの機能)

SP3a には、SQL Server エージェント TSX サーバーが MSX サーバーから指示をダウンロードするために使用するアカウントを設定できる新しい拡張ストアド プロシージャ (xp_sqlagent_msx_account) が含まれています。このアカウントは、MSX アカウントまたはマスタ サーバー アカウントとも呼ばれています。

xp_sqlagent_msx_account については、SQL Server 2000 Books Online の最新コピーに説明があります。最新バージョンの SQL Server 2000 Books Online のインストールについては、「1.6 SQL Server 2000 Books Online の利用可能な更新」を参照してください。英語版のリファレンスは、「xp_sqlagent_msx_account」です。

[先頭に戻る]

5.3.4 SQL Server エージェントのアクセス許可の確認

(SP3 からの機能)

SQL Server は、エージェント ジョブの所有者が、各ジョブから出力ログ ファイルに追加または上書きするためのアクセス許可を持っているかどうかを確認するようになりました。この確認は、以下の 3 つの方法で行います。

どの場合も、SQL Server エージェントの資格情報を使ってジョブを書き込みますが、SQL Server はジョブ出力ログ ファイルの書き込み先としてサーバー上で選択した場所に対して、そのユーザーが書き込みアクセス許可を持つかどうかを確認するようになりました。エラーはジョブ ヒストリに表示されますが、ログ ファイルを書き込めなくても、ジョブ ステップは失敗しません。

[先頭に戻る]

5.3.5 SQL Agent Mail MAPI プロファイル

(SP3 からの機能)

32 ビット版の SQL Server 2000 では、電子メール警告の送信に拡張 MAPI 電子メール プロファイルを使用するように、SQL Agent Mail を設定できます。拡張 MAPI プロファイルの作成には、Microsoft Outlook などの拡張 MAPI 電子メール アプリケーションを使用できます。64 ビット版の SQL Server 2000 では、SQL Agent Mail は電子メール警告の送信に簡易 MAPI プロファイルのみを使用できます。32 ビット版の SQL Server 2000 では、簡易 MAPI プロファイルを使用しないでください。

[先頭に戻る]

5.3.6 デザイナのヘルプ トピックの表示を使用できない

(SP4 からの機能)

SQL Server Enterprise Manager で、[ビューのデザイン] や [ビューの作成] からヘルプ トピックの「ビューのプロパティ」を使用できません。更新されたトピックは、Microsoft Web サイトで提供されています。

[先頭に戻る]

5.4 SQL Server 接続コンポーネントの機能強化

ここでは、SP4 に含まれる SQL Sever 2000 の接続コンポーネントの機能強化について説明します。

[先頭に戻る]

5.4.1 QLogic Virtual Interface Architecture のサポート

(SP3 からの機能)

SQL Server は QLogic Virtual Interface Architecture (VIA) System Area Network (SAN) 実装をサポートするようになりました。QLogic VIA 経由の接続に対する SQL Server サポートを有効にするには、クライアント コンピュータとサーバー コンピュータの両方で、それぞれの Windows system32\drivers\etc フォルダ内の Vihosts というファイルで IP アドレス解決を提供する必要があります。

Vihosts ファイルは以下のような形式になります。

<サーバー コンピュータの VI IP アドレス> <サーバー コンピュータ名>

<クライアント コンピュータの VI IP アドレス> <クライアント コンピュータ名>

以下はその例です。

139.4.130.1  SQLCOMPUTER

139.4.130.2  SQLCLIENT

それぞれの QLogic VIA ネットワーク カードからの IP アドレスと、実際のコンピュータ名を使用します。そのように指定しないと、名前付きインスタンスに対する接続や、TCP や名前付きパイプのような他の IP プロトコルを使用した接続はできません。Giganet VIA 接続では Vihosts ファイルは必要ありません。

注意   クライアント コンピュータで、クライアント ネットワーク ユーティリティを使用して適切な VIA ベンダを確認する必要があります。[ベンダ] ボックスの一覧の適切な値をクリックします。サーバー コンピュータでも、サーバー ネットワーク ユーティリティを使用して同様の操作を完了する必要があります。

[先頭に戻る]

5.5 Meta Data Services の機能強化

ここでは、データベース コンポーネント SP4 に含まれる SQL Server 2000 Meta Data Services の機能強化について説明します。

[先頭に戻る]

5.5.1 Unicode でのメタ データ ブラウザ エクスポート

(SP1 からの機能)

メタ データ ブラウザは、XML ベースのメタ データを Unicode でエクスポートするようになりました。SQL Server 2000 SP1 以前は、ブラウザは英文字以外をサポートしない ANSI コードでエクスポートしていました。この機能変更に対して、ユーザーは何もする必要はありません。この SP4 リリース時点では、エクスポートされるデータは常に Unicode で表現されます。現在でも、レジストリ キー HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Repository\Engine\XMLExport の値を 0 に設定すると、ANSI コードでエクスポートできます。以下の一覧は、このレジストリ キーに設定できる値を示しています。

各フラグの詳細については、SQL Server Books Online の「IExport::Export Method」を参照してください。

[先頭に戻る]

5.5.2 無効になったスクリプティング サポート

(SP3 からの機能)

情報モデルでのスクリプト サポートが無効になりました。SP3a 以降をインストールした後に、スクリプトが定義されているプロパティやメソッドにアプリケーションがアクセスすると、次のエラーが表示されます。

EREP_SCRIPTS_NOTENABLED

スクリプト サポートを有効にするには、次の操作を行います。

引き続きスクリプトを実行する必要がある場合は、以下の手順を使用して、スクリプト サポートを有効にするレジストリ設定を作成できます。

  1. レジストリ エディタを開き、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft に移動します。

  2. (存在しない場合は) レジストリ キー Repository を作成します。次にサブキー Engine を作成し、パスが Repository\Engine になるようにします。

  3. Engine レジストリ キーに、AllowScripting という名前の新しい DWORD 値を追加し、値を 1 に設定します。

後でスクリプティングを無効にする場合は、この新しいレジストリ キーの値を 0 に設定します。

重要  セキュリティ上の理由から、sa ログインでブランク パスワードを使用しないでください。

[先頭に戻る]

5.5.3 リポジトリ情報にアクセスするための新しい RepositoryUser ロール

(SP3 からの機能)

SQL Server は msdb データベースに、Meta Data Services リポジトリ エンジンが使用する情報を格納するテーブル、ストアド プロシージャ、およびビューのセットを含んでいます。SP3 では、リポジトリ情報のアクセスと更新に使用する必要のある RepositoryUser という名前の新しい専用ロールが追加されました。このロールには、これらのオブジェクトの作成、読み取り、更新、削除、および実行権限が許可されます。public ロールはこれらのオブジェクトに対して権限を持たなくなりました。

この変更は、今後、リポジトリ エンジンによって追加で作成されるすべてのオブジェクトだけでなく、既存のリポジトリ オブジェクトにも影響します。public ロールを使用してリポジトリにアクセスしているユーザーやアプリケーションは、RepositoryUser ロールに追加する必要があります。

[先頭に戻る]

5.6 データ変換サービスの機能強化

ここでは、SP4 に含まれる SQL Server 2000 データ変換サービスの機能強化について説明します。

[先頭に戻る]

5.6.1 DTS ウィザードが文字列型の文字を 255 文字に制限しない

(SP2 からの機能)

データをテキスト ファイルにエクスポートするときに、DTS インポート/エクスポート ウィザードでは、文字列型のデータを格納するすべての列に最大で 8,000 文字まで書き込むようにパッケージが設定されるようになりました。

[先頭に戻る]

5.6.2 SQL Server エージェントが実行した DTS パッケージのセキュリティ コンテキストをログに記録する

(SP2 からの機能)

SQL Server エージェントは、各ジョブ ステップを実行する際のセキュリティ コンテキストを記録します。SP3 以降では、このセキュリティ コンテキストを [ジョブ ヒストリ] ダイアログ ボックスに表示します。ジョブ内のあるステップから DTS パッケージを実行すると、SQL Server エージェントはそのパッケージを実行するユーザー アカウントをログに記録します。この情報は、サーバーで定期的に実行するように DTS パッケージのスケジュールが設定されている場合に発生する権限や認証の問題を管理者が診断するのに役立ちます。

[先頭に戻る]

5.6.3 SQL Server エージェントのプロキシ アカウントの強化

(SP2 からの機能)

SP2 以前は、SQL Server エージェントのプロキシ アカウントが実行されているサーバー (xp_cmdshell からジョブが実行される場合) またはエージェント (エージェント ジョブの場合) のいずれかのアカウントでユーザーの TEMP フォルダにアクセスできない場合は、サーバーに保存されている DTS パッケージはそのプロキシ アカウントの資格情報では実行できませんでした。このため、ユーザーは SQL Server の開始アカウントまたは SQL エージェントの開始アカウントの TEMP 環境変数を変更して、開始アカウントとプロキシ アカウントの両方がアクセスできるフォルダを指すように変更する (例 : C:\Temp) 必要がありました。SP2 以降では、ユーザーの TEMP フォルダが利用できない場合は、システムの TEMP フォルダを強制的に使用するように DTS が強化されたので、このような変更の必要性が大幅に減少しました。

[先頭に戻る]

5.6.4 既定で無効になっている Meta Data Services への保存

(SP3 からの機能)

SP3 以降では、DTS パッケージを Meta Data Services に保存するオプションが既定で無効になっています。つまり、[DTS パッケージの保存] ダイアログ ボックスの [場所] ドロップ ダウン リストに [Meta Data Services] オプションは表示されません。さらに、DTS インポート/エクスポート ウィザードの [パッケージの保存、スケジュールの設定、およびレプリケート] ページでこのオプションが無効になっています。

パッケージを Meta Data Services に保存できるようにするには、次の操作を行います。

Meta Data Service にパッケージを保存するオプションを無効にしているときには、Meta Data Services から既存のパッケージを読み込み、それを編集し、[上書き保存] オプションを使ってそれを Meta Data Services に保存できます。ただし、[名前を付けて保存] オプションからは Meta Data Services を利用できません。たとえば、異なる名前を付けてパッケージを Meta Data Services に保存し直すことはできません。

[先頭に戻る]

5.7 XML の機能強化

ここでは、SP4 に含まれる XML と SQLXML の機能強化について説明します。

[先頭に戻る]

5.7.1 XPath 式の検証機能の強化

(SP3 で導入され、SP4 で更新された機能)

SP4 を適用すると、MSXML 2.6 との下位互換性があるように特別に構築された XML 解析テクノロジを使用するように、OPENXML が更新されます。

SP3 以前の OPENXML によって使用されるバージョンの XML パーサーでは、XPath 式の中で、現在のコンテキスト ノードを識別する特殊文字省略形 (XPath 構文ではピリオド (.) で示される) の後に述語を記述することが許されていました。これは、この文字の後には場所のパス式を記述する必要があるという XPath の構文仕様に違反しています。

新しい OPENXML の動作では、現在のコンテキスト ノードを表す省略形特殊文字の直後に述語を記述することはできません。SP3 以降にアップグレードした後は、間違った構文を使用する SQLXML クエリ (注釈付きマッピング スキーマに対する XPath クエリや、SQLXML クエリの結果を変換するために記述された XSLT スタイルシート内の XPath クエリ) 内の XPath 式は失敗します。

このようなエラーを防止するため、正しくない構文を使用する式をすべて識別して修正します。たとえば、次の xsl:if 要素で test 属性の値として指定されている XPath 式の構文は、述語 [@ResourceTypeID='2'] が現在のコンテキスト ノードを識別する特殊文字省略形の直後にあるために無効です。

次のステートメントは以前はエラーを生成しませんでしたが、SP3 以降をインストールした後はエラーになります。

<xsl:if test=".[@ResourceTypeID='2']">

このエラーを防ぐには、XPath 式を次のように変更する必要があります。

<xsl:if test="@ResourceTypeID='2'">

[先頭に戻る]

5.8 Virtual Backup Device API の機能強化

次のトピックは SQL Server 2000 Virtual Backup Device API に適用されます。

[先頭に戻る]

5.8.1 1 つのスナップショットへの複数のデータベースのキャプチャ

(SP2 からの機能)

ISV は、Virtual Backup Device API を使用して、SQL Server 2000 を自社の製品に統合できます。この API は、最大限の信頼性とパフォーマンスを提供するように設計されています。この API では、完全な範囲のホット バックアップ機能やスナップショット バックアップ機能など、SQL Server 2000 のバックアップと復元の機能が全面的にサポートされています。

SP1 以前では、一度に複数のデータベースを一度にフリーズしてバックアップする方法はありませんでした。SP2 以降では、VDC_PrepareToFreeze コマンドを使用して 1 つのスナップショットで複数のデータベースのフリーズとキャプチャを行うための、サーバー側サポートが提供されるようになりました。

SP4 の『Virtual Backup Device Interface Specification』には、VDC_PrepareTo Freeze コマンドの更新された情報が含まれています。更新されたバージョンの Virtual Device Interface ヘッダー ファイル (vdi.h) は、SP4 Setup フォルダの \devtools\include フォルダにあります。

更新された仕様書は、Microsoft SQL Server Downloads Web サイトの Microsoft Download Center からダウンロードできます。

[先頭に戻る]

5.9 エラー報告

(SP3 からの機能)

Microsoft SQL Server エラー報告は既定では無効になっています。この機能は、SQL Server セットアップまたは Analysis Services セットアップによるインストール中に有効にできます。または、インストール後に、Enterprise Manager の [サーバーのプロパティ] ダイアログ ボックスまたは分析マネージャの [サーバーのプロパティ] ダイアログ ボックスから有効にすることができます。SQL Server セットアップの実行中にエラー報告機能を有効にすることにより、SQL Server データベース エンジンと SQL Server エージェントの SQL Server エラー報告を許可します。Analysis Services セットアップの実行中にエラー報告機能を有効にすることにより、Analysis Services のエラー報告を許可します。SQL Server と Analysis Services の両方のエラー報告を有効にする場合、SQL Server セットアップの実行中に SQL Server のエラー報告を有効にし、Analysis Services セットアップの実行中に Analysis Services のエラー報告を有効にする必要があります。

この機能を有効にすると、SQL Server データベース エンジン、SQL Server エージェント、または SQL Server Analysis Services で重大なエラーが発生した場合に、Microsoft に報告を自動的に送信するように SQL Server が設定されます。Microsoft はこのエラー報告を SQL Server の機能強化のみに使用し、すべての情報を機密情報として扱います。

エラーに関する情報は、セキュリティで保護された接続 (HTTPS) を経由して Microsoft に送信され、情報はアクセスが制限された場所に格納されます。また、この情報を独自の企業内エラー報告サーバーに送信することもできます。企業内エラー報告サーバーのセットアップに関する詳細については、Microsoft Web サイトを参照してください。

エラー報告には以下の情報が含まれます。

Microsoft は、ユーザーのファイル、名前、住所、電子メール アドレス、またはその他の形式の個人情報を意図的に収集することはありません。ただし、エラー報告にはエラーの原因となったプロセスのメモリまたはファイルにユーザーを特定する情報を含む可能性があります。この情報をユーザーの ID を判断するために使用できる可能性がありますが、Microsoft はこの情報をそのような目的に使用することはありません。

Microsoft のエラー報告データ収集ポリシーについては、Microsoft Web サイトを参照してください。

エラー報告を有効にしている場合に重大なエラーが発生すると、特定のエラーに関するマイクロソフト サポート技術情報の文書を指す Microsoft からの応答が、Windows イベント ログに表示されることがあります。この応答は、次の例のようになります。

Source = MSSQLServerOlapServicesDW 
EventID = 1010
data = http://support.microsoft.com/support/misc/kblookup.asp?id=Q123456
&iBucketTable=1&iBucket=39980&Cab=21474432.cab&LCID=1033
&OS=5.1.2600.2.00010100.0.0

SQL Server データベース エンジンおよび SQL Server エージェントのエラー報告を無効にするには、Enterprise Manager の [SQL Server のプロパティ] ([全般] タブ) に移動し、[エラー報告機能を有効にする] チェック ボックスをオフにします。Analysis Services のエラー報告を無効にするには、分析マネージャの [サーバーのプロパティ] に移動し、[エラー報告機能を有効にする] チェック ボックスをオフにします。SQL Server (データベース エンジンと SQL Server エージェント) と Analysis Services の両方のエラー報告を有効にしている場合は、SQL Server と Analysis Services のエラー報告を個別に無効にする必要があります。

[先頭に戻る]

5.10 サービス性の機能強化

(SP4 からの機能)

SQL Server 2000 SP4 には、サービス機能が新たに導入されています。これにより、Windows XP と Windows Server 2003 上で実行されている SP4 以上のバージョンの SQL Server 2000 に適用された修正プログラムをアンインストールできます (この同じ機能は、SQL Server 2000 にも搭載されていましたが、追加の修正プログラムを適用しないと利用できませんでした)。

[先頭に戻る]

5.11 English Query の機能強化

(SP1 からの機能)

Microsoft は English Query アプリケーションのセキュリティに関する機能強化をリリースしました。この機能強化は、Service Pack の一部としてはインストールされません。ただし、English Query を使用する場合には、この機能強化を適用することをお勧めします。このセキュリティの機能強化は、SP4 CD-ROM の \EQHotfix フォルダにあります。English Query 機能強化の詳細については、サポート技術情報の文書 297105 を参照してください。

[先頭に戻る]

5.12 DB-Library と Embedded SQL for C

(SP1 で導入され、SP4 で更新された機能)

DB-Library および Embedded SQL for C の API は、まだ SQL Server 2000 でサポートされていますが、SQL Server の将来のバージョンには、これらの API を使用するアプリケーションのプログラミング作業に必要なファイルやドキュメントが含まれなくなります。DB-Library および Embedded SQL for C を使用して記述された既存のアプリケーションからの接続は、次のバージョンの SQL Server でもサポートされる予定ですが、将来のリリースではこのサポートも削除されることになります。新しいアプリケーションを記述するときには DB-Library や Embedded SQL を使用しないでください。既存のアプリケーションを変更するときには、これらのテクノロジに依存する部分を取り除いてください。DB-Library や Embedded SQL for C の代わりに、.NET Framework の System.Data.SqlClient 名前空間を使用するか、ADO、OLE DB、ODBC のような API を使用して SQL Server のデータにアクセスしてください。これらのテクノロジの詳細については、SQL Server Books Online または .NET Framework SDK を参照してください。

[先頭に戻る]