まず最初に行うことは、SQL Server 2000データベースでアップグレードアドバイザーを実行し、それによって報告されたすべての問題に対処することです。
ベストプラクティスとして、SQL Server 2000のレガシデータベースでUpgrade Advisorツールを使用し、分析のためにトレースファイルをUpgrade Advisorツールにインポートします。トレースファイルを使用すると、アップグレードアドバイザーは、アプリケーションに埋め込まれたTSQLなど、データベースの単純なスキャンでは表示されない問題を検出できます。通常の時間にSQL Server 2000サーバーでSQLプロファイラーを使用してTSQLのトレースをキャプチャし、アップグレードアドバイザーを使用してこれらのトレースを分析できます。
したがって、残りのステップは次のようになります。
移行当日：
- sp_help_revloginを使用して、2000サーバーでログインのスクリプトを作成します。
- SQL 2000サーバーからジョブとリンクサーバーをスクリプトアウトします。
- 2000サーバーに接続しているWebサーバーを停止します。2000サーバーに接続しているアプリケーションがないことを確認してください。
- データベースをバックアップし、宛先のSQL 2008 R2サーバーで復元します（注：事態が悪化する可能性があるため、デタッチ/アタッチしないでください。データベースがデタッチされ、バックアップがなくなります！）
- バックアップが2008 R2サーバーで復元されたら、2008 R2サーバーでsp_help_revloginからの出力を実行してログインを再作成します。
- 同期アップ孤児のユーザー（もしあれば）と再作成、SQLエージェントのジョブとリンクサーバー新しいサーバー上。
- 復元されたデータベースの互換性レベルを100に変更します。
- all_errormsgsおよびdata_purityオプションがオンになっているDbcc checkdb：
DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
- 復元されたデータベースでDBCC UPDATEUSAGEを実行します
DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
- 全スキャンですべてのテーブルの統計を更新します。
Update Statistics table_name with FULLSCAN
- オプション：断片化レベルを確認し、断片化レベルに応じて、すべてのインデックスの再編成/再構築を実行します。Olaのスクリプトを使用できます。
- を使用してすべてのSPを再コンパイルします
sp_recompile 'procedureName'
- ビューを更新する
SP_REFRESHVIEW view_name
- 必ずデータベースオプションを変更してください：CHECKSUMへのページ検証。
- 復旧モデルを（SQL 2000と異なる場合）FULLに変更します。完全復旧モデルに変更する場合は、トランザクションログのバックアップを頻繁に行うようにしてください。これは、T-Logを膨張させることなく、ポイントインタイムを回復するのに役立ちます。
SQL Server 2005以降では、データベースメールが導入されました。そのため、SQLMailからデータベースメールに移行する必要があります。
USE [master]
GO
sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO
また、レプリケーションがある場合は、それをリセットする必要があります。ログシッピングやミラーリングなどのDR（2005年以降は新しく、2012年には減価償却）を使用する場合は、同様にリセットする必要があります。
C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTSMigrationWizard.exe（コマンドライン）またはPackage Migration Wizardを使用して、古いDTSパッケージをSSISに移行する必要があります。
また、/dba//a/36701/8783にある私のスクリプトを使用できます。ただし、デタッチ/アタッチメソッドを使用しますが、BACKUP / RESTOREメソッドを使用することを強くお勧めします。それに応じてスクリプトを変更します。
補足として：
質問に答えましょう...
移行を完了するには、他に何をすればよいですか？
私の答えを参照してください。移行計画を適切に立てるのに役立ちます。ビジネスユーザーによる適切なアプリケーションテストと共に、常にUAT（非運用環境）で移行計画をテストしてください。
チェックサムや完全復旧モデルなどの新機能を使用します。
CHECKSUMSQL Server 2005以降の新機能です。上記の移行手順の一部として説明しました。
full recovery model新しくありません。それはあなたのビジネスのタイプに依存し、災害の場合にどれだけのデータを失うことができるかを決定します。
トランザクションログのバックアップを頻繁に行う完全復旧モードでは、データ損失の量を減らすことにより、特定の時点を復元できます。
このデータベースをSQL Server 2008 R2で作成されたとおりに作成します。
このデータベースを完全に互換性があり、正確にし、新しいSQL 2008 R2データベースエンジンに最適なものにします。
これを完全に理解しないでください！ただし、上記の移行手順が役立ちます。データベースを復元し、100上記の手順に従って互換性レベル10を変更するだけです。
古いSQL Server 2000データベースを新しい2008 R2データベースに正しく完全に変換する方法を知りたいと思います。すべてが正しく行われていることを落ち着いて、すべての新機能に満足しています。
これにはアプリケーションコードも変更する必要があるため、注意が必要です。アプリケーションコードがSQL Server 2008 R2の新機能を使用するように変更された場合、問題は発生しません-UATまたはDEV環境でアプリケーションの完全な回帰テストを完全に実行したことを提供します。これにより、PRODで実際の移行を行うときに最高の自信が得られます。
注：上記は覚えておくべき手順であり、何も残されていないことは間違いありません。何か見落としていることがわかったら、このサイトにそれまたは他の専門家を追加します-気軽に追加してください！
上記で概説したすべてのことは、実際の移行中の驚きを避けるために、最初にNON PRODUCTION環境で再生する必要があります。
----------
その他の質問：
バックアップ/復元方法を使用することをお勧めしますが、上記のようにしたので、問題が発生する可能性はありますか？すべてが問題なく機能しました。
すべてがうまく働いて、あなたがデータベースをアタッチすることができました場合は、NOあなたはどんな問題を抱えてする文句を言いません。デタッチ/アタッチとバックアップ/リストアは、データベースを別の場所に移動する方法の単なる方法です。ちょうどFYI .. バックアップ/復元は、何かが（最悪の場合）うまくいかない場合のように、より安全で信頼性が高く、少なくともデータベースを復元および回復するためのバックアップがあります。
チェックサムと完全復旧モデルについて：SQL Server 2000では使用できなかった/有効になっていないため、今すぐ使用したいと思います。データベースプロパティでこれらのオプションを有効にすることだけが必要だとおっしゃいましたか？どこかで読みましたが、それだけでは十分ではなく、インデックスなどを再構築する必要があります。私は本当に知りません、ただ尋ねます。
前述したように、チェックサムはバージョン2005以降で新しく追加されました。これは、特にI / Oによるページの破損をSQL Serverが検出するメカニズムです。私の答えを参照してくださいここでは詳細については。
CHECKSUMを有効にし、復旧モデルをFULLに変更するには、以下のT-SQLコードを使用して実行できます。
USE master;
GO
ALTER DATABASE [your_database_name] -- change this !!
SET RECOVERY FULL, PAGE_VERIFY CHECKSUM;
GO
注：データベースオプションを設定すると、2008R2から2012への移行を行っても保持されます。
このデータベースをSQL Server 2012に移行する準備をしています-最初は2000から2008 R2になりましたが、2008 R2から2012になります（SQLで2000データベースのサポートがないため、これを直接行うことは不可能でした）サーバー2012）。だから私はあなたのガイドに従うべきだと理解しています：2008 R2でそれをバックアップし、2012年に復元してから、残りのヒントをしますか？
はい、お願いします。先ほど言ったように、バックアップの復元は、そうしない理由がない限り、好ましい方法です。
バックアップ/復元の方法を教えてください：SQLクエリへのデータベースのダンプのようなもので、クエリの束を実行して復元しますか？この方法でデータベースを「デフラグ」する方法はありますか？そうでない場合、手動で最適化/最適化する方法は？
バックアップ/復元は、Sybase、Oracle、またはおそらくMySQLで使用されるダンプとロードに似ています。そのまさにSQL Serverはそれを.. backup / restoreと呼びます。
必読：Paul RandallによるSQL Serverバックアップの理解。
単純な構文（完全な構文についてはBOLを参照）：
backup database database_name
to disk = 'D:\backup\database_name_full.bak'
with init, stats =10
次に、宛先サーバーで次のように復元を実行できます。
-宛先のディスクレイアウトがソースサーバーのディスクレイアウトと一致しないと仮定
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
move 'logical_data_fileName' to 'physical_path\database_name.mdf'
move 'logical_log_fileName' to 'physical_path\database_name_log.ldf'
with recovery, stats = 10
-宛先のディスクレイアウトがソースサーバーのディスクレイアウトと一致すると仮定する
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
with recovery, stats = 10
この方法でデータベースを「デフラグ」する方法はありますか？そうでない場合、手動で最適化/最適化する方法は？
バックアップ/復元はデータベースを最適化しません。フラグメンテーションレベルに応じて、Alter Index ReorganizeまたはRebuildを使用する必要があります。
SQL Serverは初めてなので、Ola Hallengrenを使用することを強くお勧めします。
長年（管理インターフェイスなしで）SQL Server 2000 Expressを使用していたため、エンジンを停止してDATAディレクトリをRARするだけでバックアップを行っていました。今のところ、SQL Server 2008を使用しているので、Management Studioでバックアップ機能を使用するよりも優れていますか？
エンジンを停止することは、バックアップを行うためにできる最悪のことです!!
私が言及したバックアップに関するPaulのリンクを読んで、Olaのスクリプトを使用してください。Microsoftには、自動バックアップを行うスクリプトに関するKB記事があります-SQL Server ExpressでSQL Serverデータベースのバックアップをスケジュールおよび自動化する方法
トランザクションログのバックアップを頻繁に行う完全復旧モード -トランザクションログの保存場所-LDFファイルですか？適切にバックアップするにはどうすればよいですか？
すべてのSQL Serverデータベースには、すべてのトランザクションと各トランザクションによって行われたデータベースの変更を記録するログがあります。トランザクションログは、データベースの重要なコンポーネントです。
トランザクションログの通常の命名規則の拡張子は「.LDF」ですが、任意の拡張子を使用できます。
これは答えを非常に無駄にするので、これについてはこれ以上書きません。トランザクションログの管理を参照してください
。ここでの私の回答にも優れたリンクがあります。
編集：2016年8月24日..これは、将来の読者に役立ちます：
インスタンス全体をあるバージョンから別のバージョンに移行する場合、PowerShellベースのソリューションを使用することを強くお勧めしますStart-SqlMigration
