SQL Server 6.5 から 7.0 にアップグレードする場合のよく寄せられる質問

文書翻訳 文書翻訳
文書番号: 195444 - 対象製品
この記事は、以前は次の ID で公開されていました: JP195444
この資料は、アーカイブされました。これは "現状のまま" で提供され、更新されることはありません。
すべて展開する | すべて折りたたむ

概要

この資料は、SQL Server 6.5 から SQL Server 7.0 への変換に関してよく聞かれる質問にお答えするものです。

詳細

  1. (問) 変換にはどれくらい時間がかかりますか?

    (答) SQL Server 6.x データベースを SQL Server 7.0 への変換に必要な時間を決める要素にはいろいろあります。SQL Server 6.x データベースの各オブジェクトは SQL Server 7.0 データベースで再構築されなければなりませんし、各行も転送されなければなりません。各データベースの複雑性によって、行とオブジェクトの数が異なっている2つの 10-GB データベースを変換するのにかかる時間は大幅に異なります。また、ハードウェア プラットフォーム、プロセッサの数、ディスク サブシステム、RAM の容量が変換に必要な時間を決める重要な要素になります。セットアップの際、"data validation" を選択すると、2つのうち1つの要素によってアップグレードを行うのにかかる時間が増加します。

    元に戻す全体を表示する
    データベースサイズ 変換にかかる見込み時間
    400 MB 20 分以下
    1 GB 1 時間以下
    10 GB 4 時間以下
    50 GB 12 時間以下
    100 GB 24 時間以下
  2. (問) SQL Server 7.0 のディスク使用量は SQL Server 6.5 に比べてどのくらい多いですか?

    (答) コンピュータ1台あたり、SQL Server 6.x から SQL Server 7.0 へ移行するのに、SQL Server 6.x のデータが使用しているスペースの 1.5 倍が必要です。ほとんどの場合、実際に使われる容量は SQL Server 6.x のデータが現在使っている容量より少なくなります。十分なディスク容量がない場合には、コンピュータ1台ならテープ変換、あるいはコンピュータを2台使った変換を考えたほうがいいでしょう。これらの方法を次に説明します。

    コンピュータ1台のテープ変換方法

    この方法では、SQL Server 6.x のデータは SQL ダンプにバックアップされます。オンで物理ファイルのファイル バックアップも行われるように指定することができます。これが完了したら、データ デバイスはドライブから削除され、新しい SQL Server 7.0 データベースのローディングの間は SQL ダンプが使われます。何か障害があったら、SQL Server 6.x を再インストールし、データ ファイルの物理バックアップからオリジナルのデータ ファイルを復旧できます。

    コンピュータ2台のコンバージョン方法

    この方法では、新しいコンピュータに SQL Server 6.x データベースが現在使っているディスク容量の 1.5 倍が必要となります。使用されているデータ型や SQL Server 6.x データベースの実際の空き容量によっては最終的に使用される容量はこれより少なくなります。データベースを変換するとき、SQL Server 7.0 は適当なデータ ファイルのサイズを示し、最初のログ ファイルには前のログ ファイル サイズを使います。この動作は SQL Server 7.0 で新しいデータベースを作るときとは異なります。この場合、SQL Server 7.0 はデフォルト サイズの 2 MB で新しいデータベースを作ります。
  3. (問) 変換処理が実行されている最中にユーザーは SQL Server 6.x コンピュータに接続できますか?

    (答) できません。アップグレード処理の間、SQL Server 6.x コンピュータは止まり、オブジェクトがスクリプティングされたり、データの抽出されたりすると動き始めます。またデータ転送が始まると、SQL Server 7.0 だけは動きますが、SQL Server 6.x にアクセスすることはできません。
  4. (問) アップグレードを行う前にサーバーをどのように設定しておいたらよいですか?

    (答) SQL Server 6.x を SQL Server 7.0 が動作している新しいコンピュータへアップグレードするには、両方のコンピュータが MSSQLServer サービス用のドメイン ユーザー名とパスワードが使えるようになっている必要があります。ドメイン ユーザー アカウントもまた両方のコンピュータで Administrators グループに所属していなければなりません。コンピュータ1台でのアップグレードならローカル システム アカウントが1つで十分です。異なるドメインの間でアップグレードを行う場合は、アップグレード前にドメイン間の信頼関係をセットアップをしておかなければなりません。

    注 : コンピュータ1台のアップグレード処理でローカル システム アカウントを使い、ローカル アカウントも使っている場合、統合ログインをアップグレードすることはできません (setuser が失敗するからです)。
    ですから、統合セキュリティでなく標準セキュリティを使っているならば、コンピュータ1台のアップグレード処理ではローカル システム アカウントだけを使います。
  5. (問) SQL Server 4.21 を直接 SQL Server 7.0 に変換できますか?

    (答) できません。QL Server 4.21 と SQL Server 6.x のデータベース構造には違うところがたくさんあるので、SQL Server 4.21 データベースを使うと変換処理が行われません。SQL Server 4.21 のサーバーを SQL Server 7.0 にアップグレードするには、まずそのサーバーを SQL Server 6.0 か SQL Server 6.5 にアップグレードしてから SQL Server 7.0 に変換します。


    注 : SQL Server 4.21 から SQL Server 6.x に変換を行うとき、Chkupg65.exe あるいは Chkupg60.exe の実行を忘れないでください。これは SQL Server 4.21 データベースの構造と内容が、SQL Server 6.x に実装されている新しい ANSI 92 の必要条件と競合がないことを確認するものです。
  6. (問) SQL ダンプを新しいコンピュータにロードしてその新しいコンピュータを SQL Server 7.0 にアップグレードできますか?

    (答) できます。ただし、しいコンピュータに master データベースもコピーするのを忘れないでください。別のコンピュータからのデータベースを新しいコンピュータにロードすると、SQL Server のログイン ID が master データベースになくなります。アップグレードで master データベースにログイン ID を持たないユーザーにはオブジェクトが作られません。また、統合セキュリティが使われていて、SQL Server にロードされているデータベースのユーザーに対してローカル グループが存在しないと、ログインは失敗します。
  7. (問) 2 つ以上の SQL Server 6.x を 1 つの SQL Server 7.0に統合することはできますか?

    (答) できません。アップグレード処理ではサーバーのアップグレード状況が常にチェックされ、アップグレードできるデータベースは 1 つの SQL Server 6.xからのものだけです。異なるサーバーからデータベースを統合しようとすると、ユーザー ログイン ID、ユーザー アカウント、オブジェクト権限で問題が起こる可能性があります。異なる SQL Server 6.x から複数のデータベースを統合する場合は、統合するすべてのデータベースをすべて 1 つの SQL Server 6.x サーバーに移し、アプリケーションが正常に動作することを確認してから、SQL Server 7.0 にアップグレードします。
  8. (問) データベースをアップグレードする前にデータベース一貫性チェッカ (DBCC) ステートメントをサーバー上で実行する必要がありますか?

    (答) 必ずしもアップグレード前に DBCC ステートメントを実行する必要はありませんが、それは推奨されます。データベースに存在する論理的な不一致の程度によってはアップグレード処理が完全に行われないことがあります。メンテナンスウィンドウでアップグレードおよび DBCC チェックを完了する十分な時間がない場合は、アップグレードするデータベースのダンプを使ってバックアップ サーバーかセカンダリサーバー上で DBCC チェックを実行する方法もあります。
  9. (問) 1 つあるいは 2,3 のデータベースを SQL Server 7.0 にアップグレードできますか?

    (答) できます。1つでも、2,3でも、あるいは SQL Server 6.x のデータベースすべてでも SQL Server 7.0 にアップグレードできます。個別のデータベースをテストあるいは練習として変換してから、サーバーのデータベースすべてをアップグレードすることもできます。しかし、推奨されるのはサーバーにあるすべての製品データベースを同時に変換することです。こうすると障害発生の可能性を最小限にすることができます。SQL Server 6.x データベースのサブセットだけを変換したいならば、同時にすべてを変換すべきです。

    同時にすべてのデータベースをアップグレードするのでなければ、気をつけておかなければならない問題がいくつかあります。ビュー、ストアド プロシージャ、トリガといった他のデータベースの内容に依存するオブジェクトは、そのオブジェクトやその依存するデータベースが存在しないと作られません。

    SQL Server 6.x の model データベースにオブジェクトを追加するような変更をしている場合、他の SQL Server 6.x データベースすべてと同時にか最後に変換される必要があります。SQL Server 6.x model データベースにデフォルトでないオブジェクトを追加したことによって SQL Server 6.x につくられたオブジェクトはアップグレード処理の間に書かれます。

    model データベースが変換されてしまった後に他の SQL Server 6.x データベースをアップグレードした場合、SQL Server 6.x model データベースに基づいたデフォルトでないオブジェクトを含むことになります。そのオブジェクトが SQL Server 7.0 model データベースで最初につくられるとき、それは新しい SQL Server 7.0 に追加されるので、作成スクリプトはそのデータベースに既に存在しているオブジェクトの作成に失敗します。ですから、model データベースを最後に変換することで、データベース構造の変更は新しい SQL Server 7.0 データベースだけに適用されることになります。変換された SQL Server 6.x のデータベースのデフォルトでないオブジェクトはすべて、データベースの更新処理の間にスクリプトによって作られます。
  10. (問) 1 台のコンピュータで同時に SQL Server 6.x と SQL Server 7.0 を実行することはできますか?

    (答) できません。所定の時間に実行できるのはどちらか1つだけです。両バージョンとも同じ Windows NT リソースとレジストリ情報を共有しているので、1度に起動できるのは1つのバージョンだけとなります。しかし、Switch ユーティリティを使えば SQL Server 7.0 と SQL Server 6.x の切り替えができます。Switch ユーティリティは変換処理とテスト用に提供されています。運用環境で1台のコンピュータに 2 つのバージョンの SQL Server を運用するためのものではありません。

    SQL Server 6.x をインストールしてあるコンピュータでデータベースを SQL Server 7.0 に変換する場合、これら2つのデータベースは独立していることを理解しておくことが重要です。それらは同期してもいませんし、SQL Server 6.x が動作している際に SQL Server 6.x のデータに加えられた変更は、SQL Server 7.0 データベースには反映されません。反対に、SQL Server 7.0 データの変更は SQL Server 6.x データベースに反映されません。

    注 : SQL Server version 6.x のある同じコンピュータに SQL Server 7.0 をインストールするときは、SQL Server 6.x と同じディレクトリに SQL Server 7.0 をインストールしないようにしてください。別々のディレクトリにインストールしなければなりません。
  11. (問) 変換の際、"@@servername not valid" というエラーが出るのはなぜですか?

    (答) アップグレードしている SQL Server 6.x に名前がないときこのエラー メッセージが出力されます。この問題を解決するためには次のようにします。

    1. ISQL または ISQL/w で SELECT @@Servername ステートメントを使用して、サーバーに名前があることを確認します。
    2. サーバーに名前がなければ、次のストアド プロシージャを使って名前を追加します。
      sp_addserver <server_name>, local
      
  12. (問) "Cannot open default database" および "Error querying @@servername"エラーの原因は何ですか?

    (答) システム管理者 (SA) のデフォルト データベースが復旧していないか、サスペクトのマークがついていると、Upgrade Wizard がこのようなエラー メッセージを出力します。デフォルト データベースの問題を解決し、もう1度アップグレード ウィザードを実行します。
  13. (問) 変換処理が応答をやめ、失敗したようになるのはなぜですか?

    (答) 変換処理の際、アプリケーションやサービスが SQL Server 6.x サーバーへの ODBC 接続を開くと、SQL Server は完全にシャットダウンできません。変換処理では、SQL Server 6.x サーバーが完全に止まったという確認を受け取らないと次の段 階に進みません。この場合、変換処理は応答を止め失敗してしまったように見えます。これを解決するには、ODBC 接続を行っていたもしくは更新を行う前に SQL Server を使っていたと思われるアプリケーションとサービスをクローズします。プロファイラ や SQL トレース が SQL Server 6.x に接続していると、同じ問題にぶつかります。サーバーが実際には応答を止めていないで、急に起こったタスクが大量の CPU 時間を使い急激に遅くなってくるのです。
  14. (問) 変換処理で発生するエラーはどこに記録されますか?

    (答) 換処理の際、詳しいログは SQL ディレクトリにつくられ保存されます。変換処理で発生したエラーは処理の最後にダイアログ ボックスで示されます。このダイアログ ボックスはエラー ファイルの内容を表示します。この出力ファイルは MSSQL\Upgrade\<servername>_ <date>_<time> ディレクトリにあります。各データベースに対して、変換処理でつくられた出力とエラー ファイルが格納されるサブディレクトリがあります。
  15. (問) ストアド プロシージャの中に正しく変換されないもの、まったく変換されないものがありますが、何がいけないのですか?

    (答) ストアド プロシージャが正しく変換されない場合、次のような理由が考えられます。

    • ストアド プロシージャのテキストは CREATE PROCEDURE で始まらなければなりません。プロシージャが BEGIN TRANSACTION で始まり、その後に CREATE PROCEDUREがある場合、ストアド プロシージャは作成されません。
    • 列名の変更とシステム カタログの構造変更のため、システムテーブルに基づくストアド プロシージャは作成されません。
    • ストアド プロシージャの名前が sp_rename ストアド プロシージャで変更された場合、syscomments システムテーブルのストアド プロシージャのオリジナル名は変更されません。この場合、ストアド プロシージャはオリジナル名でつくられます。そこで別に同じ名前のストアド プロシージャやオリジナルの前に作られたストアド プロシージャが存在したりすると、二番目のストアド プロシージャはつくられません。その名前のオブジェクトはすでに存在していることになるからです。
    • 他のストアド プロシージャによって作成されたストアド プロシージャは、syscomments テーブルにエントリがないため、作成されません。
変換問題について詳しくは、SQL Server 7.0 Books Online の "アップグレードする前に : チェックリスト" のトピックを参照してください。

詳細

この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 195444 (最終更新日 1999-11-17) を基に作成したものです。

プロパティ

文書番号: 195444 - 最終更新日: 2014年2月10日 - リビジョン: 3.0
この資料は以下の製品について記述したものです。
  • Microsoft SQL Server 1.1 Standard Edition
キーワード:?
kbnosurvey kbarchive datatypes dataype dimmed gray grayed grey greyed hang hangs hung kbfaq kbinfo localsystem out type KB195444
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com