SQL Server 2008 徹底検証シリーズ

SQL Server 2008 徹底検証シリーズ
旧バージョンからの移行とアップグレード実践ガイド
Published．2008 年 11 月 10 日
© 2008 Microsoft Corporation. All rights reserved.
本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoft は絶えず変化する市
場に対応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、提示された情報の信憑性につい
ては保証できません。
本評価ガイドは情報提供のみを目的としています。Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるもの
ではありません。
すべての当該著作権法を遵守することはユーザーの責務です。Microsoft 書面による明確な許可なく、本書の如何なる部分について
も、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段（電子的、機械的、複写、レコーディング、
その他）、および目的であっても禁じられています。これらは著作権保護された権利を制限するものではありません。
Microsoft は、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。
Microsoft から書面によるライセンス契約が明確に供給される場合を除いて、本書の提供はこれらの特許、商標、著作権、またはそ
の他の知的財産へのライセンスを与えるものではありません。
Microsoft、Windows、MSDN、Visual Studio、SQL Server は、米国および（または）その他の国において、Microsoft Corporation
の登録商標または商標です。
その他記載されている実際の社名および製品名は、各社の商標です。
Microsoft Corporation ・ One Microsoft Way ・ Redmond、 WA 98052-6399 ・ US
2
はじめに
このホワイト ペーパーは、SQL Server 2008 早期実証プロジェクト「CQI」
（Center of Quality
Innovation）の成果物です。
CQI
(Center of Quality Innovation)
• SQL Server 2008 早期実証
／検証プロジェクト
実際の System Integration
プロジェクトを想定
• 提案依頼書（RFP）
検証内容
• 機能動作検証
• パフォーマンス検証
CQI は、マイクロソフトと日本ユニシス株式会社、日本電気株式会社、日本ヒューレット・
パッカード株式会社の 3 社と共同で実施し、実際のユーザーに対する SI（System Integration）
プロジェクトを想定した「RFP」
（Request for Proposal：提案依頼書）に基づいた「機能動作
検証」や「パフォーマンス検証」を行ったプロジェクトです。
このプロジェクトでは、次の 4 つのシナリオを実施しています。
• データ ウェアハウス
•移行/アップグレード
日本電気
株式会社
日本ユニシ
ス株式会社
日本ヒュー
レット・
パッカード
株式会社
マイクロソ
フト
•サーバー統合

•コンプライアンス
移行／アップグレード シナリオ
日本ユニシス株式会社様との共同検証プロジェクト。SQL Server 2000 および 2005 か
ら、SQL Server 2008 への移行や互換性に関する検証を実施

コンプライアンス シナリオ
マイクロソフトによる検証プロジェクト。内部統制や日本版 SOX 法、情報漏えい対策で
求められるコンプライアンスに対応するためのガイドライン提示を目的とし、
日本版 SOX
法への対応に必要となる機能の実装方法の確立やシステムに与える影響の計測などを実
施

サーバー統合シナリオ
日本ヒューレット・パッカード株式会社様との共同検証プロジェクト。複数 の SQL
Server を 1 台の 64 ビット サーバーへ集約するメリット・運用管理方法などに関する検
証を実施

DWH（データ ウェアハウス）シナリオ
日本電気株式会社様との共同検証プロジェクト。SQL Server 2008 のデータ ウェアハウ
3
ス環境における実装方法の検証を実施
移行／アップグレード シナリオ実施の背景
このシナリオでは、現在、SQL Server 2000 または SQL Server 2005 で稼動しているシステ
ムを SQL Server 2008 へ移行（マイグレーション）／アップグレードする際の最適な移行方
法を検証作業を通して明らかにし、旧バージョンの SQL Server からの具体的な移行／アッ
プグレード手順のガイドラインを作成することを目的としました。また、移行／アップグレー
ドに伴うシステムへの影響（パフォーマンスへの影響など）を測定することも目的としました。
今回のプロジェクトが想定したモデル
今回のプロジェクトが想定したモデルは、次のとおりです。
OLTP系モデル
情報系モデル
OLTP 系データベース
データ統合/相互運用
DWH/DM
データ活用/分析
[データベース エンジン]
[DTS / Integration Services]
[データベース エンジン]
[Analysis Services]
・Excel (ピポットテーブル)
・キューブ
・ディメンション
・データベース
・DTS/SSIS パッケージ
・SSAS キューブ処理
プログラム
・データ パーティション
・クラスタ環境
・DB ミラーリング環境
レポート作成/公開
：
[Reporting Services]
・レポート定義
・レポート モデル
・共有データ ソース定義
OLTP（オンライン トランザクション処理）環境においては、データベースの移行やクラスタ
環境の移行、データベース ミラーリング環境の移行の手順を明確化し、情報系（データ統合
／活用／分析）環境においては、DTS（データ変換サービス）や Integration Services パッ
ケージの移行方法から、データ パーティション、Analysis Services、Reporting Services ま
で、幅広いコンポーネントを対象としました。
実証プロジェクトの成果（移行／アップグレード シナリオ）
詳しくは、文書内へ記述していますが、この実証プロジェクトをとおして、次のことを確認す
ることができました。
4
RFP 要件に対するまとめ

移行およびアップグレードにあたって、SQL Server のすべての機能（データベース エン
ジン、DTS、Integration Services、Analysis Services、Reporting Services）について、
以下の項目を満たしていることを確認することができました。
・現行のシステム（旧バージョンの SQL Server）と同等以上の性能の実現
・できる限り現行のシステムへ修正を加えずに移行／アップグレードを実施
・システム移行後の安定稼働の実現

移行検証では、SQL Server の各機能について、移行手法を検証し、安全に移行できること
を確認できました。
また、移行の際に、複数の実装方法がある場合は、それぞれの実装方法を比較検証したこ
とにより、最適な実装方法を認識することができ、移行指針および手法を確立し、移行計
画の策定が可能になりました。
データベース移行（マイグレーション）に関するまとめ

旧バージョン（SQL Server 2000 または SQL Server 2005）のデータベースを SQL
Server 2008 へ移行するにあたって、最も確実な方法は、バックアップ／復元機能を利用
する方法であることを確認できました。

SQL Server 2008 へのクラスタ環境のインストール手順は、SQL Server 2005 までの手順
から変更になりました（ローリング アップグレードへ対応するために変更になりました）。
クラスタ環境においても、データベースの移行手順は、通常のデータベースの移行とまっ
たく同様に行えることを確認できました（クラスタ環境のための特別な操作は必要ありま
せん）。

SQL Server 2005 のデータ パーティション環境は、アタッチ／デタッチまたはバックアッ
プ／復元でデータベースを移行することで、SQL Server 2008 へ移行できることを確認で
きました。

SQL Server 2005 のデータベース ミラーリング環境は、バックアップ／復元でデータベ
ースを移行後、ミラーリングを再設定することで、SQL Server 2008 へ移行できることを
確認できました。
パフォーマンス検証結果に関するまとめ

今回のパフォーマンス検証結果からは、OLTP 環境での高負荷テスト時には、SQL Server
2000 と SQL Server 2008 では、167.7% の性能差が現れたことを確認することができま
した。この結果は、SQL Server 7.0 から実装されたユーザー モード スケジューラ (UMS)
が、SQL Server 2005 で SQL OS としてアーキテクチャが改善されたため、より効率の
良いスレッド スケジューリングが行われるようになったと考えられます。
5

今回のパフォーマンス検証結果からは、データ パーティションに対する複数パーティショ
ンをまたがったクエリの場合には、SQL Server 2005 と SQL Server 2008 では、51.8%
～71.4% の性能差が現れたことを確認することができました。SQL Server 2008 では、複
数パーティションにまたがるクエリで、パラレル処理（複数 CPU を利用した並列処理）
がサポートされるようになったため、このような顕著な性能差を確認できたと考えられま
す。

今回のパフォーマンス検証結果からは、データベース ミラーリング環境において、SQL
Server 2005 と SQL Server 2008 では、4.4%～42.1% の性能差が現れたことを確認する
ことができました。SQL Server 2008 からは、ミラーリングのログ転送時に、ログを圧縮
する機能が追加されたため、このような顕著な性能差を確認できたと考えられます。

今回のパフォーマンス検証結果からは、SQL Server 2008 からの新機能である「バックア
ップ圧縮」を利用した場合のバックアップ時間は、圧縮なしの場合と比べて 67.6% の性能
差が現れたこと確認できました。また、ファイル サイズは、7.6GB から 2.4GB となり、
圧縮率は 67.9%（3 分の 1 以下のサイズ）となりました。
DTS、Integration Services の移行に関するまとめ

SQL Server 2008 には、SQL Server 2000 の DTS（データ変換サービス）パッケージを
SSIS パッケージへ変換できる「パッケージ移行ウィザード」が用意されているので、基本
的な DTS パッケージを SSIS パッケージへ変換できることを確認できました（ただし、
一部のタスクは変換することができません。変換できないタスクは、アップグレード アド
バイザでチェックすることが可能です）。

SQL Server 2008 には、DTS パッケージを実行するための「DTS 2000 パッケージ実行
タスク」が含まれているので、基本的なパッケージはそのまま実行できることも確認でき
ました。
ただし、「DTS 2000 パッケージ実行タスク」では、一部実行できないタスク（動的プロ
パティ タスクや Analysis Services 処理タスクなど）もあるため、これらに関しては、
Integration Services（SSIS）パッケージとして作成し直す必要があります。したがって、
基本的には SSIS パッケージへの変換または作り直しを実施し、移行期間や移行対象ボリ
ュームによっては、「DTS 2000 パッケージ実行タスク」を使用した暫定対応を検討する
ようにします。

SQL Server 2008 の Integration Services は、SQL Server 2005 の Integration Services
からアーキテクチャがほとんど変更されていないため、容易に移行ができることを確認で
きました。
Analysis Services、Reporting Services の移行に関するまとめ

Analysis Services は、SQL Server 2000 と SQL Server 2008 で大きくアーキテクチャが
変更されていますが、「Analysis Services 移行ウィザード」を利用すれば、OLAP キュー
6
ブを移行できることを確認できました。ただし、移行されたキューブは、SQL Server 2008
へ最適化されているわけではないので、最適化処理を実施しておく必要がありました。

SQL Server 2008 の Analysis Services は、SQL Server 2005 の Analysis Services から
アーキテクチャがほとんど変更されていないため、容易に移行ができることを確認できま
した。

今回のパフォーマンス検証結果からは、移行後の最適化処理を実施した OLAP キューブは、
SQL Server 2000 と比較して、キューブ処理で 46.6% の性能差、キューブ検索（Excel ク
ライアントからのアクセス）では、73.4% の性能差が現れたことを確認することができま
した。

Reporting Services は、内部使用しているデータベースが SQL Server 2000 と SQL
Server 2005、SQL Server 2008 のすべてのバージョンで互換性があるので、容易にアップ
グレードできることを確認できました。
インプレース アップグレードに関するまとめ

クラスタリングの環境において、システムをダウンさせることなく、インプレース アップ
グレードができることを確認しました。

ログ配布の環境において、SQL Server 2000, SQL Server 2005 から共に、フェールオーバ
ーを併用する手順とフェールオーバーを併用しない手順の両方でインプレース アップグ
レードができることを確認しました。

データベース ミラーリングの環境において、ミラー サーバーからアップグレードを行い、
手動でフェールオーバーを行い、もう一方のサーバーのアップグレードを行い、安全にシ
ステムがアップグレードが行われることを確認しました。
7
目次
はじめに .................................................................................................................................. 3
目次.......................................................................................................................................... 8
第 1 章 現状のシステムまたはビジネスの問題点 ................................................................ 10
1.1 旧バージョンからの移行の必要性
10
第 2 章 RFP（Request for Proposal：提案依頼書） .......................................................... 11
2.1 RFP（提案依頼書）の内容
2.1.1 移行およびアップグレードに関する必須要件
2.1.2 SQL Server 2000 からの移行（マイグレーション）に関する必須要件
2.1.3 SQL Server 2005 からの移行（マイグレーション）に関する必須要件
2.1.4 SQL Server 2008 へのアップグレードに関する必須要件
11
11
12
12
13
第 3 章 RFP に対する SQL Server 2008 のソリューション ............................................ 14
3.1
3.2
3.3
3.4
アップグレード アドバイザによる移行可否のチェック
SQL Server 2000 からの移行に対するソリューション
SQL Server 2005 からの移行に対するソリューション
SQL Server 2008 へのアップグレードに対するソリューション
16
17
18
20
第 4 章 ソリューション作成時の実装検証 ........................................................................... 21
4.1 検証環境
4.2 SQL Server 2000 から SQL Server 2008 への移行検証
4.2.1 SQL Server 2000 からの移行検証の結果（まとめ）
4.2.2 データベース エンジン機能の移行検証
4.2.3 DTS（データ変換サービス）の移行検証
4.2.4 Analysis Services の移行検証
4.2.5 Reporting Services の移行検証
4.3 SQL Server 2005 から SQL Server 2008 への移行
4.3.1 SQL Server 2005 からの移行検証の結果
4.3.2 データベース環境の移行検証
4.3.3 Integration Services（SSIS）の移行検証
4.3.4 Analysis Services の移行検証
4.3.5 Reporting Services の移行検証
21
23
23
24
27
31
38
41
41
42
45
47
50
第 5 章 ソリューション作成時のパフォーマンス検証 ......................................................... 53
5.1 SQL Server 2000／2005／2008 パフォーマンス計測
5.1.1 検証環境
5.1.2 検証結果
5.1.3 Analysis Services キューブ処理のパフォーマンス比較
5.1.4 Analysis Services キューブ検索のパフォーマンス比較
5.1.5 OLTP パフォーマンスの比較
5.1.6 バックアップ圧縮のパフォーマンス比較
5.1.7 データ パーティションのパフォーマンス比較
5.1.8 データベース ミラーリングのパフォーマンス比較
5.2 プラットフォーム別パフォーマンス検証
5.2.1 集計処理パフォーマンス検証の環境と手順について
5.2.2 集計処理パフォーマンス検証の結果
53
53
56
56
57
59
59
60
62
64
64
66
第 6 章 まとめ ....................................................................................................................... 68
付録 A ソリューション内にある技術解説（移行手順） ...................................................... 71
8
A.1 SQL Server 2008 アップグレード アドバイザの利用手順
A.2 SQL Server 2000 から SQL Server 2008 への移行手順
A.2.1 データベース エンジンの移行手順
A.2.2 DTS（データ変換サービス）の移行手順
A.2.3 Analysis Services の移行手順
A.2.4 Reporting Services の移行手順
A.3 SQL Server 2005 から SQL Server 2008 への移行手順
A.3.1 データベース エンジンの移行手順
A.3.2 Integration Services（SSIS）の移行手順
A.3.3 Analysis Services の移行手順
A.3.4 Reporting Services の移行手順
71
79
79
100
107
114
123
123
129
132
139
付録 B インプレース アップグレード ............................................................................... 141
B.1 クラスタ環境のアップグレード手順
B.2 ログ配布環境のアップグレード手順
B.2.1 SQL Server 2000 ログ配布環境からのアップグレード
B.2.2 SQL Server 2005 ログ配布環境からのアップグレード
B.3 データベース ミラーリング環境のアップグレード手順
9
142
163
164
194
203
第 1 章 現状のシステムまたはビジネスの問題点
1.1
旧バージョンからの移行の必要性
ある架空のユーザー企業「X 社」では、現在 SQL Server 2000 および SQL Server 2005 で
動作している業務アプリケーションが複数あり、ハードウェアの老朽化や、SQL Server 2000
のメイン ストリーム サポートの終了などを受けて、SQL Server 2008 への移行またはアッ
プグレードを検討しています。
現在、X 社では、次の問題を抱えています。
(1) SQL Server 2000 で構築したシステムの改訂タイミング
リリースから 7 年が経過し、既存システムの見直しを検討する時期がきています。昨今の
アクセス増およびトランザクション量を処理するには、現在のサーバーでは、十分な性能
な発揮できなくなってきているため、サーバーのリプレイスが必要となってきています。
(2) サーバー リプレースに伴う、ソフトウェアの入替
高性能化したハードウェアの能力を有効に活用できるソフトウェアが必要です。
現在のサーバーは、32-bit 環境のため、SQL Server の内部使用しているメモリのうち、
Workspace メモリ（一時作業領域）やプラン キャッシュ（SQL 実行プランの格納領域）
が 4GB のメモリ空間を超えられないという制限があります。このため、クエリの実行性
能に影響が出ています。これを解決するには、64-bit 環境の SQL Server 2008 へ移行し
て、搭載した物理メモリを制限なく、完全に利用できるようにする必要があります。
(3) SQL Server 2000 のメイン ストリーム サポートの終了（2008 年 4 月）
SQL Server 2000 は、メイン ストリーム サポートが終了しているため、引き続き SQL
Server 2000 を使用する場合、
「延長サポート費用が掛かる」、
「サポート範囲が制限される」
といった運用上の懸念があります。
10
第 2 章 RFP（Request for Proposal：提案依頼書）
ある架空のユーザー企業「X 社」から依頼を受けた「RFP」（Request for Proposal：提案依頼書）の内
容は、次のとおりです。
2.1
RFP（提案依頼書）の内容
X 社からの RFP（提案依頼書）では、次の 3 点に関して、具体的な実現手段を求められてい
ます。
(1) SQL Server 2000 から SQL Server 2008 への移行（マイグレーション）
(2) SQL Server 2005 から SQL Server 2008 への移行（マイグレーション）
(3) SQL Server 2008 へのアップグレード（インプレース アップグレード）
移行とは、旧システム環境（SQL Server 2000 または SQL Server 2005）とは別に、新しい
環境（SQL Server 2008）を作成し、そこへデータベースや各種機能を移行することを指し、
アップグレードとは、旧システム環境は残さずに、旧システム環境を SQL Server 2008 へア
ップグレード（インプレース アップグレード）することを指します。
移行とアップグレードの違いは、次のとおりです。
アップグレード（インプレイス アップグレード）
移行（マイグレーション）
稼働中のサーバー
（移行元サーバー）
新規サーバー
（移行先サーバー）
稼働中の
サーバー
Microsoft
SQL Server 2000
Microsoft
SQL Server 2000
2.1.1 移行およびアップグレードに関する必須要件
移行およびアップグレードの際には、SQL Server のすべての機能（データベース エンジン、
DTS、Integration Services、Analysis Services、Reporting Services）について、以下の項目
を満たしていることが、必須要件となります。

現行のシステム（旧バージョンの SQL Server）と同等以上の性能が発揮できること

できる限り現行のシステムへ修正を加えないこと

システム移行後の安定稼働を実現できること

複数の実装方法がある場合には、最適な実装方法を提示すること
・移行指針／手法が確立されており、移行計画の策定ができること
・移行手法が検証されており、安全に移行できること
11
2.1.2
SQL Server 2000 からの移行（マイグレーション）に関する必須要件
RFP（提案依頼書）内の「SQL Server 2000 から SQL Server 2008 への移行」に関する具体
的な必須要件は、次の 4 点です。
(1) データベース エンジンの移行が可能であること
SQL Server 2000 のデータベース エンジン機能を SQL Server 2008 へ移行し、正常に
動作すること。具体的には、次の 5 つの機能が移行可能であること

データベース

クラスタ環境

BCP および osql ユーティリティを利用したバッチ ファイル

DBCC コマンドを利用した監視スクリプト
(2) DTS（データ変換サービス）パッケージの移行が可能であること
SQL Server 2000 上の DTS（データ変換サービス）で作成したパッケージを SQL Server
2008 へ移行し、正常に動作すること
(3) Analysis Services の移行が可能であること
SQL Server 2000 上の Analysis Services で作成した多次元データベース（OLAP キュ
ーブ）を SQL Server 2008 へ移行し、クライアント（Excel 2003 および Excel 2007）
から参照可能であること
(4) Reporting Services の移行が可能であること
SQL Server 2000 上の Reporting Services で作成したレポートを SQL Server 2008 へ
移行し、正常に動作すること
2.1.3
SQL Server 2005 からの移行（マイグレーション）に関する必須要件
RFP（提案依頼書）内の「SQL Server 2005 から SQL Server 2008 への移行」に関する具体
的な必須要件は、次の 4 点です。
(1) データベース エンジンの移行が可能であること
SQL Server 2005 のデータベース エンジン機能を SQL Server 2008 へ移行し、正常に
動作すること。具体的には、次の 6 つの機能が移行可能であること

データベース

データベース ミラーリング環境

データ パーティション環境

BCP および osql ユーティリティを利用したバッチ ファイル

DBCC コマンドを利用した監視スクリプト
12

DMV（動的管理ビュー）を利用した監視スクリプト
(2) Integration Services パッケージの移行が可能であること
SQL Server 2005 上の Integration Services で作成したパッケージを SQL Server 2008
へ移行し、正常に動作すること
(3) Analysis Services の移行が可能であること
SQL Server 2005 上の Analysis Services で作成したキューブを SQL Server 2008 へ移
行し、クライアント（Excel 2003 および Excel 2007）から参照可能であること
(4) Reporting Services の移行が可能であること
SQL Server 2005 上の Reporting Services で作成したレポートを SQL Server 2008 へ
移行し、正常に動作すること
2.1.4
SQL Server 2008 へのアップグレードに関する必須要件
RFP（提案依頼書）内の「SQL Server 2008 へのアップグレード」に関する具体的な必須要
件は、次のとおりです。
(1) データベース エンジンのアップグレードが可能であること
SQL Server 2000 および SQL Server 2005 のデータベース エンジン機能を SQL
Server 2008 へアップグレードすることが可能で正常に動作すること。具体的には、次の 3
つの高可用性構成環境を最小の停止時間で移行できること
 クラスタ環境
 ログ配布環境
 データベース ミラーリング環境
13
第 3 章 RFP に対する SQL Server 2008 のソリューション
この章では、X 社からの RFP（提案依頼書）に対する SQL Server 2008 でのソリューション（具体的
な解決策）を説明します。
SQL Server 2000 から SQL Server 2008 への移行（マイグレーション）のソリューションをまとめる
と、次のようになります。
RFP での必須要件
データベース エンジン
機能の移行
SQL Server 2008 でのソリューション
データベース
1. デタッチ／アタッチによる移行
2. バックアップ／復元による移行
3. データベース コピー ウィザードによる移行
クラスタ
SQL Server 2008 でクラスタをセットアップ後、通常のデータ
ベースを移行する手順と同様、データベースを移行
bcp／osql ユーティリティ SQL Server 2008 にも bcp／osql ユーティリティが付属している
によるバッチ
ため、そのまま移行可能
DBCC コマンドによる監
視スクリプト
SQL Server 2008 にも DBCC コマンドが付属しているため、そ
のまま移行可能
DTS パッケージの移行
1. パッケージ移行ウィザード
2. DTS 2000 パッケージ実行タスクによる移行
Analysis Services の移行
Analysis Services 移行ウィザードによる移行
Reporting Services の移行
1. レポート サーバー データベースの移行
2. BIDS を利用したレポートの移行
3. レポート マネージャを利用したレポートの移行
SQL Server 2005 から SQL Server 2008 への移行（マイグレーション）のソリューションをまとめる
と、次のようになります。
RFP での必須要件
SQL Server 2008 でのソリューション
データベース
1. デタッチ／アタッチによる移行
2. バックアップ／復元による移行
3. データベース コピー ウィザードによる移行
データベース ミラーリング バックアップ／復元後、ミラーリングを再設定
データベース エンジン
機能の移行
データ パーティション
デタッチ／アタッチまたはバックアップ／復元による移行
bcp／osql ユーティリティ
によるバッチ
SQL Server 2008 にも bcp／osql ユーティリティが付属して
いるため、そのまま移行可能
DBCC コマンドによる監視 SQL Server 2008 にも DBCC コマンドが付属しているため、
スクリプト
そのまま移行可能
DMV（動的管理ビュー）
による監視スクリプト
SQL Server 2008 にも DBCC コマンドが付属しているため、
そのまま移行可能
Integration Services パッケージの移行
1. BIDS 配置ユーティリティでの移行
2. パッケージ アップグレード ウィザードでの移行
3. dtutil ユーティリティでの移行
4. パッケージ（.dtsx）のコピーによる移行
Analysis Services の移行
1. バックアップ／復元による移行
2. XMLA 形式のスクリプト ファイルによる移行
3. BIDS での移行
4. Analysis Services 配置ウィザードでの移行
Reporting Services の移行
1. レポート サーバー データベースの移行
2. BIDS を利用したレポートの移行
3. レポート マネージャを利用したレポートの移行
14
SQL Server 2000 または SQL Server 2005 からの移行にあたっては、
「SQL Server 2008 アップグレー
ド アドバイザ」ツールを利用することで、実際に移行が可能かどうかの事前チェックを行うことが可
能です。
SQL Server 2000 または SQL Server 2005 から SQL Server 2008 へのアップグレード（インプレース
アップグレード）のソリューションをまとめると、次のようになります。
RPF で の 必 須 要 件
SQL Server 2008 で の ソ リ ュ ー シ ョ ン
再起動を要る前提パッケージをノードごとにインス
SQL Server 2000/2005 トールした後、データベースエンジンもノードごと
にインストールする
1.フェールオーバーを併用しないアップグレード
SQL Server 2000
データベースエンジン機
2.フェールオーバーを併用するアップグレード
ログ配布環境
能のアップグレード
1.フェールオーバーを併用しないアップグレード
SQL Server 2005
2.フェールオーバーを併用するアップグレード
トランザクションの安全性を FULL に設定し、ミ
データベース ミラーリ
SQL Server 2005
ラーでアップグレードした後に手動フェールオー
ング環境
バーして、新しいミラーをアップグレードする
クラスタ環境
15
3.1
アップグレード アドバイザによる移行可否のチェック
SQL Server 2000 または SQL Server 2005 から SQL Server 2008 へ移行するにあたっては、
「SQL Server 2008 アップグレード アドバイザ」ツール（以下、アップグレード アドバイ
ザ）を利用することで、実際に移行が可能かどうかの事前チェックを行うことができます。
アップグレード アドバイザでは、データベース エンジンや DTS（Integration Services）、
Analysis Services、Reporting Services など、コンポーネントごとに移行にあたっての事前チ
ェックを行うことが可能です。
アップグレード アドバイザでコンポーネントを選択している画面
移行可否のチェックを行う
コンポーネントの選択
トレース ファイル（.trc）やバッチ ファ
イル（.sql）を分析することも可能
アップグレード アドバイザの具体的な利用手順については、付録 A で説明しています。
16
3.2
SQL Server 2000 からの移行に対するソリューション
SQL Server 2000 からの移行要件に対する SQL Server 2008 でのソリューションは、それぞ
れ次のとおりです。
(1) データベースの移行（データベース エンジン機能）
データベースの移行は、次の 3 つの方法で実現可能です。

デタッチ／アタッチによる移行

バックアップ／復元による移行

データベース コピー ウィザードによる移行
詳しくは、4 章で説明しますが、バックアップ／復元による移行がお勧めの移行方法です。
(2) クラスタ環境の移行（データベース エンジン機能）
クラスタ環境を移行するには、移行先となる新環境（SQL Server 2008）でクラスタをセット
アップし、その後、通常のデータベースを移行する手順と同様に、データベースを移行するこ
とが可能です。(1)で挙げた 3 つの方法（デタッチ／アタッチ、バックアップ／復元、データ
ベース コピー ウィザード）のいずれかを利用して、データベースの移行が可能です。
(3) bcp／osql を利用したバッチの移行（データベース エンジン機能）
bcp および osql ユーティリティは、SQL Server 2008 にも付属しているため、そのまま移行
が可能です。
(4) DBCC コマンドによる監視スクリプトの移行（データベース エンジン機能）
DBCC コマンドは、SQL Server 2008 にも付属しているため、そのまま移行が可能です。
(5) DTS パッケージの移行
SQL Server 2000 上で作成した DTS（データ変換サービス）パッケージの移行は、次の 2 つ
の方法で実現可能です。

パッケージ移行ウィザードによる移行

DTS 2000 パッケージ実行タスクによる移行
詳しくは、後述しますが、どちらの移行手段を利用しても、移行できないタスクがあることに
注意する必要があります。
(6) Analysis Services の移行
SQL Server 2000 上 の Analysis Services で 作 成 し た OLAP キ ュ ー ブ は 、「 Analysis
17
Services 移行ウィザード」を利用して、SQL Server 2008 上の Analysis Services へ移行す
ることが可能です。ただし、SQL Server 2000 と SQL Server 2008 の Analysis Services で
は、内部的なアーキテクチャが大きく異なるため、Analysis Services 移行ウィザードで移行
しただけでは、最適なパフォーマンスが得られないことに注意する必要があります。この対処
法については、4 章で説明します。
クライアント ツール（Excel 2000／Excel 2003／Excel 2007）の移行は、Analysis Services へ
の接続文字列を変更することで可能です。
(7) Reporting Services の移行
SQL Server 2000 上の Reporting Services で作成したレポートは、次の 3 つの方法を利用し
て、SQL Server 2008 上の Reporting Services へ移行することが可能です。
3.3

レポート サーバー データベースの移行

BIDS（Business Intelligence Development Studio）を利用したレポートの移行

レポート マネージャを利用したレポートの移行
SQL Server 2005 からの移行に対するソリューション
SQL Server 2005 からの移行要件に対する SQL Server 2008 でのソリューションは、それぞ
れ次のとおりです。
(1) データベースの移行（データベース エンジン機能）
データベースの移行は、SQL Server 2000 からの移行と同様、次の 3 つの方法で実現可能で
す。

デタッチ／アタッチによる移行

バックアップ／復元による移行

データベース コピー ウィザードによる移行
(2) データベース ミラーリング環境の移行（データベース エンジン機能）
データベース ミラーリング環境を移行するには、バックアップ／復元機能を利用して、デー
タベースを移行し（デタッチ／アタッチでのデータベースの移行は不可）
、その後、ミラーリ
ングを再設定することで、移行が可能です。
(3) データ パーティション環境の移行（データベース エンジン機能）
データ パーティション環境の移行は、データベースを移行することで実現可能です。データ
ベースの移行は、(1)で挙げたデタッチ／アタッチまたはバックアップ／復元を利用することで
可能です。
18
(4) bcp／osql を利用したバッチの移行（データベース エンジン機能）
bcp および osql ユーティリティは、SQL Server 2008 にも付属しているため、そのまま移行
が可能です。
(5) DBCC コマンドによる監視スクリプトの移行（データベース エンジン機能）
DBCC コマンドは、SQL Server 2008 にも付属しているため、そのまま移行が可能です。
(6) Integration Services パッケージの移行
SQL Server 2005 上で作成した Integration Services パッケージの移行は、次の 4 つの方法
で実現可能です。

BIDS（Business Intelligence Development Studio）配置ユーティリティでの移行

パッケージ アップグレード ウィザードでの移行

dtutil ユーティリティでの移行

パッケージ ファイル（.dtsx）のコピーによる移行
(7) Analysis Services の移行
SQL Server 2005 の Analysis Services 上で作成したキューブの移行は、次の 4 つの方法で
実現可能です。

バックアップ／復元による移行

XMLA 形式のスクリプト ファイルによる移行

BIDS での移行

Analysis Services 配置ウィザードでの移行
クライアント ツール（Excel 2003／Excel 2007）の移行は、Analysis Services への接続文字
列を変更することで可能です。
(8) Reporting Services の移行
SQL Server 2005 上の Reporting Services で作成したレポートは、SQL Server 2000 から
の移行のときと同様、次の 3 つの方法を利用して、SQL Server 2008 上の Reporting Services
へ移行することが可能です。

レポート サーバー データベースの移行

BIDS を利用したレポートの移行

レポート マネージャを利用したレポートの移行
19
3.4
SQL Server 2008 へのアップグレードに対するソリューション
SQL Server 2000 および SQL Server 2005 からのアップグレード（インプレース アップグ
レード）要件に対する SQL Server 2008 でのソリューションは、それぞれ次のとおりです。

クラスタ環境のアップグレード手順

ログ配布環境のアップグレード手順

データベース ミラーリングのアップグレード手順
20
第 4 章 ソリューション作成時の実装検証
この章では、RFP に対する SQL Server 2008 のソリューションの実装方法として、実際の移行検証を
行った結果を示します。
4.1
4.1
検証環境
4.2
SQL Server 2000 から SQL Server 2008 への移行検証の結果
4.3
SQL Server 2005 から SQL Server 2008 への移行検証の結果
検証環境
検証に利用した OS およびソフトウェアは、次のとおりです。
ソフトウェア
バージョン
OS
Windows Server 2003 Enterprise Edition SP2
SQL Server 2000 Enterprise Edition SP4（Build 2039）
SQL Server
SQL Server 2005 Enterprise Edition SP2（Build 3159）
SQL Server 2008 Enterprise Edition CTP 2 月版（Build 1098）
検証環境は、次の 2 つを利用しました。

移行検証環境（クラスタ環境）

移行検証環境（非クラスタ環境）
クラスタ環境では、データベース エンジンの移行検証を行い、非クラスタ環境では、DTS
（Integration Services）と Analysis Services、Reporting Services の移行検証を行いました。
移行検証環境（クラスタ環境）
クラスタ環境の構成は、次のとおりです。
共有ストレージ
クラスタ 1 64-bit (x64)
クラスタ 2 32-bit
共有ストレージは、
1 台で計 4 ノードが物理的へ接続され、
クラスタは、
32-bit と 64-bit
（x64）
がそれぞれ 1 セットづつあります。
クラスタのハードウェア／ソフトウェア構成は、次のとおりです。
21
クラスタ名
クラスタ 1
64-bit（x64）
クラスタ 2
32-bit
構成
マシン名
HP DL370G4
CPU
Xeon 3.4GHz（4 コア）2 way
メモリ
4 GB
OS
Windows Server 2003 Enterprise Edition R2 SP2 x64
SQL Server
SQL Server 2008 Build 1098 インスタンス数：3
マシン名
HP DL370G4
CPU
Xeon 3.4GHz（4 コア）2 way
メモリ
4 GB
OS
Windows Server 2003 Enterprise Edition R2 SP2 32-bit
SQL Server
SQL Server 2000 SP4 インスタンス数：1
SQL Server 2005 SP2 インスタンス数：3
共有ストレージの構成は、次のとおりです。
ストレージ名
HP MSA100、MSA30
HDD
146GB 15Krpm
RAID
RAID 5（3D+1P）
移行検証環境（非クラスタ環境）
非クラスタ環境においては、DTS（Integration Services）と Analysis Services、Reporting
Services の移行検証を行いました。
OS : Windows Server 2003
R2 SP2 （32-bit 版）
DB ： SQL Server 2000 SP4
DTS： SQL Server 2000 SP4
AS ： SQL Server 2000 SP4
RS ： SQL Server 2000 SP4
OS : Windows Server 2003
R2 SP2 （32-bit 版）
DB ： SQL Server 2005 SP2
SSIS ： SQL Server 2005 SP2
AS ： SQL Server 2005 SP2
RS ： SQL Server 2005 SP2
22
OS : Windows Server 2003
R2 SP2 （x64 版）
DB ： SQL Server 2008 CTP 2月版
SSIS ： SQL Server 2008 CTP 2月版
AS ： SQL Server 2008 CTP 2月版
RS ： SQL Server 2008 CTP 2月版
AS ： Analysis Services
RS ： Reporting Services
SSIS ： Integration Services
4.2
SQL Server 2000 から SQL Server 2008 への移行検証
SQL Server 2000 から SQL Server 2008 への移行については、以下の項目を検証しました。
4.2.2
データベース エンジン機能の移行検証
4.2.3
DTS パッケージの移行検証
4.2.4 Analysis Services の移行検証
4.2.5 Reporting Services の移行検証
前提事項
検証における前提事項は、次のとおりです。
① 用語定義
・新規サーバー = SQL Server 2008 がインストールされているサーバー
・移行対象（移行元）サーバー = SQL Server 2000 がインストールされているサーバー
② SQL Server 2000 と SQL Server 2008 は、別サーバーおよび別ストレージへ存在する
（同一マシンでのアップグレードではなく、新規サーバーへの移行とする）
③ SQL Server 2008 は、新規サーバーへインストール済みである
④ システム データベースは移行できないため、ログイン アカウントなどのシステム デー
タベースのオブジェクトは再作成済みである
⑤ 移行作業は、新規サーバー（SQL Server 2008）上の Management Studio から、移行
対象サーバーとなる SQL Server 2000 のデータベースへ接続して行う
4.2.1
SQL Server 2000 からの移行検証の結果（まとめ）
SQL Server 2000 から SQL Server 2008 への移行検証の結果をまとめると、次のようになり
ました。
コンポーネント
データベース エンジン
DTS
Analysis Services
Reporting Services
○: 移行可能
章番号
移行対象
4.2.2.1
データベース
○
4.2.2.2
クラスタ
○
4.2.2.3
BCP、osql を利用したバッチ プログラム
○
4.2.2.4
DBCC コマンドを利用した監視スクリプト
○
4.2.3
DTS パッケージ
△
4.2.4.1
多次元データベース（OLAP キューブ）
△
4.2.4.2
キューブ処理アプリケーション
○
4.2.4.3
クライアント ツール
△
4.2.5
レポート データベース
○
△: 移行可能だが注意が必要
23
結果
×: 移行不可能
4.2.2 データベース エンジン機能の移行検証
ここでは、SQL Server 2000 のデータベース エンジン機能を SQL Server 2008 へ移行した
際の検証結果として、次の 5 つを説明します。
4.2.2.1 データベースの移行
4.2.2.2
クラスタ環境の移行
4.2.2.3 BCP、osql を利用したバッチの移行
4.2.2.4
4.2.2.1
DBCC コマンドを利用した監視スクリプトの移行
データベースの移行検証
(1) 移行方法
データベースの移行方法には、次の 3 つを利用しました（具体的な移行手順については、付録
A へ記載しています）
。
移行方法
手順の章番号
方法 1
デタッチ／アタッチ
A.2.1.1 - (1)
方法 2
バックアップ／復元
A.2.1.1 - (2)
方法 3
データベース コピー ウィザード
A.2.1.1 - (3)
(2) 移行検証の結果
移行検証の結果をまとめると、次のようになります。
移行方法
移行結果
方法 1
デタッチ／アタッチ
○
方法 2
バックアップ／復元
○
方法 3
データベース コピー ウィザード
○
方法 1、2、3 のいずれを利用しても、問題なく移行できることを確認できました。3 つの方
法の特徴をまとめると、次のようになります。
移行方法
方法 1
デタッチ／アタッチ
方法 2
バックアップ／復元
方法 3
データベース コピー
ウィザード
特徴
データベースをオフラインにする必要はありますが、移行
手順としては一番シンプルな方法です。
バックアップ ファイルの整合性検査なども行えるため、
移行方法として一番安全で確実な方法です。
データベース コピー ウィザードは、移行元と移行先の両
方のサーバーへアクセスできる環境でなければ使用でき
ないため、適用範囲は限られます。
したがって、データベースをオフラインにできる時間を確保できる場合は、方法 1 の「デタッ
チ／アタッチ」によるデータベース移行がお勧めです。オフラインにする時間を極力少なくし
24
たい場合には、方法 2 の「バックアップ／復元」がお勧めです。方法 3 の「データベース コ
ピー ウィザード」は、移行元と移行先の両方のサーバーへアクセス（ネットワーク接続）で
きる環境でなければ利用できないため、適用範囲が限られます。
(3) 移行時の留意点
特にありません。
4.2.2.2
クラスタ環境の移行検証
(1) 移行方法
SQL Server 2000 からのクラスタ環境の移行検証では、新規サーバー上へ SQL Server 2008
のクラスタを構築し、その後、データベースの移行を行いました。具体的な移行方法について
は、付録 A の 4.2.1.3 へ記載しています。
(2) 移行結果
構築手順（インストール方法）は、SQL Server2000 と SQL Server 2008 では変更されまし
たが、問題なくクラスタ環境を構築することができました。また、フェールオーバーも正しく
動作することを確認できました。
(3) 移行の留意点
特にありません。
4.2.2.3
BCP／osql ユーティリティを利用したバッチの移行
(1) 移行方法
BCP および osql ユーティリティは、SQL Server 2008 にも存在するため、バッチ プログラ
ムはそのまま新環境へ移行することが可能です。
(2) 移行結果
バッチ プログラムは、移行後も問題なく動作することを確認できました。
(3) 移行の留意点
BCP／osql ユーティリティを利用したバッチ プログラムで設定している「引数」や「環境変
数」のうち、移行元サーバーへ依存するものは、新規サーバーへ合わせて変更する必要があり
ます。
osql ユーティリティは、将来の SQL Server の新しいバージョンでは、削除される可能性が
あるため、今後を考慮すると、sqlcmd ユーティリティへの移行を検討しておくようにします。
25
4.2.2.4
DBCC コマンドを利用した監視スクリプトの移行
(1) 移行方法
SQL Server 2000 の運用環境において、特に利用頻度が高い DBCC コマンド（CHECKDB、
CHECKTABLE 、 SHOW_STATISTICS 、 SHRINKDATABASE 、 DBREINDEX 、
SHOWCONTIG）を利用した管理スクリプトを新環境に移行します。
(2) 移行結果
検証で利用した DBCC コマンドは、SQL Server 2008 にも、下位互換性機能として提供され
ているため、問題なく稼動することを確認できました。
(3) 移行の留意点
今回対象とした DBCC コマンドは、SQL Server 2008 ではサポートされていますが、一部の
コマンドは、将来のバージョンでは削除される可能性があります。SQL Server 2005 以降で
は、DBCC コマンドの一部が、T-SQL ステートメントや動的管理オブジェクトへ置き換わっ
て い る た め で す 。 た と え ば 、 DBREINDEX は 「 ALTER INDEX ス テ ー ト メ ン ト 」、
SHOWCONTIG は「dm_db_index_physical_stats」へ置き換わっています。この変更は、SQL
Server 2005 から提供された「データ パーティション」機能へ対応するためです。
監視スクリプトは、新環境において動作するか必ず確認しておくことが重要です。
将来のバージョンで削除される予定の DBCC コマンドや旧バージョンからの動作変更につ
いては、オンライン ブックの下記を参照してください。
SQL Server データベース エンジンの旧バージョンとの互換性
http://msdn.microsoft.com/ja-jp/library/ms143532.aspx
26
4.2.3
DTS（データ変換サービス）の移行検証
SQL Server 2000 の DTS（データ変換サービス）を SQL Server 2008 上の Integration
Services パッケージへ移行する検証では、次の 3 種類の DTS パッケージを利用しました。
検証用パッケージ 1
処理概要
CSV ファイルより読み込んだデータをテーブルへロードし、取り込んだデータ
を加工した上でファイルへ出力
パッケージ
イメージ
・Microsoft OLE DB Provider For SQL Server
使用タスク
・Text File（Source）
・Text File（Destination）
・データ変換タスク
検証用パッケージ 2
処理概要
処理内容はパッケージ 1 と同じ。動的プロパティ タスクを使用してファイルや
テーブルの接続先を ini ファイルから取得
パッケージ
イメージ
・動的プロパティ タスク
・Microsoft OLE DB Provider For SQL Server
使用タスク
・Text File（Source）
・Text File（Destination）
・データ変換タスク
検証用パッケージ 3
処理概要
Analysis Services 処理タスクを使用して、キューブ処理を行う
パッケージ
イメージ
使用タスク
・Analysis Services 処理タスク
(1) 移行方法
SQL Server 2000 の DTS と SQL Server 2008 の Integration Services（以下、SSIS 2008）
では、アーキテクチャが大きく異なるため、DTS パッケージを SSIS 2008 上でそのまま使用
することはできません。DTS パッケージを SSIS 2008 上で使用できるようにするには、次の
27
2 つの方法があります。
方法１
移行方法
特徴
「パッケージ移行ウィザード」を
変換後は Integration Services のパ
使用して、DTS パッケージで使用
ッケージとして管理／メンテナンス
し て い る タ ス ク を Integration
ができるのが利点です。ただし、変換
Services パッケージのタスクへ自
できないタスクもあるため、万能では
動的に置き換える
ありません。
手順章番号
A.2.2.1
DTS パッケージを何も変更せずに
方法２
DTS パッケージを構造化ストレ
Integration Services 上で動作させ
ージ ファイル（.dts）へエクスポ
ることができるのが利点です。一方、
ートし、SQL Server 2008 上の
メンテナンス時には、DTS デザイナ
「DTS 2000 パッケージ実行タス
が必要となることと、一部稼動できな
ク」から実行する
いタスクがあることがデメリットで
A.2.2.1
す。
今回使用した各パッケージをそれぞれの方法で移行した際のイメージは次のようになります。
方法 1．パッケージ移行ウィザード
／
方法 2．DTS 2000 パッケージ実行タスク
／
(2) 移行結果
移行結果をまとめると次のようになります。
28
方法 1
方法 2
○: 移行可能
検証用パッケージ 1
検証用パッケージ 2
検証用パッケージ 3
移行
○
×
○
実行
○
－
×
移行
○
○
○
実行
○
×
×
×: 移行不可能
検証用パッケージ 1 について
方法 1 と方法 2 ともに問題なくパッケージの移行を行うことができ、また、パッケージが正
常に実行できることも確認できました。
検証用パッケージ 2 について
方法 1 の「パッケージ移行ウィザード」では、
「動的プロパティ タスク」を移行することがで
きませんでした。
方法 2 の「DTS 2000 実行タスク」では、移行は完了しましたが、実行時に動的プロパティ タ
スクによる、動的な接続先の変更（ini ファイルを利用した変更）ができませんでした。移行
前に Microsoft OLE DB Provider で指定していた接続情報を使用しての処理に関しては、実
行できることを確認できました。Integration Services では、DTS の動的プロパティ タスク
が廃止されているため、この機能を使用しているパッケージは、構成ファイル（.dtsconfig）
などを使用するなど、パッケージを変更する必要があります。
検証用パッケージ 3 について
方法 1 の「パッケージ移行ウィザード」では、パッケージの移行は完了しましたが、パッケー
ジの実行時には、次のエラーが発生しました。
Code: 0x00000000
Source: Analysis Services 処理タスク 未定義
Description: System.Exception: 種類 'System.Exception' の例外がスローされました。
場所 DTS.PackageClass.Execute()
場
所
Microsoft.SqlServer.Dts.Tasks.Exec80PackageTask.Exec80PackageTask.ExecuteThread()
方法 2 の「DTS 2000 実行タスク」でも、方法 1 と同様、パッケージの移行は完了しました
が、パッケージの実行時には、次のエラーが発生しました。
Code: 0x00000000
Source: Analysis Services 処理タスク 未定義
Description: System.Exception: 種類 'System.Exception' の例外がスローされました。
場所 DTS.PackageClass.Execute()
場
所
Microsoft.SqlServer.Dts.Tasks.Exec80PackageTask.Exec80PackageTask.ExecuteThread()
Integration Services には、同じ名前の「Analysis Services 処理タスク」がありますが、DTS
の「Analysis Services 処理タスク」とは、内部動作が異なるため、この機能を使用している
パッケージは、動作しません。したがって、この機能を使用しているパッケージは、Integration
29
Services の「Analysis Services 処理タスク」を使用するように、パッケージを再作成する必
要があります。
(3) 移行の留意点
DTS パッケージ内で使用しているタスクよっては、方法 1 の「パッケージ移行ウィザード」
と方法 2 の「DTS 2000 実行タスク」のどちらでも、移行または実行ができないケースがあ
ります（動的プロパティ タスクや Analysis Services 処理タスクなど）。
DTS の動的プロパティ タスクは、SQL Server 2000 の実運用では使用頻度の高いタスクで
したが、Integration Services では、より柔軟性が高く、利用しやすい「構成ファイル」
（.dtsconfig）が提供されたことによって、動的プロパティ タスクが廃止されました。したが
って、動的プロパティ タスクを利用していた DTS パッケージは、Integration Services パッ
ケージとして再作成しなければなりません。
なお、各タスクごとの移行可否については、オンライン ブックやアップグレード アドバイザ
のヘルプなどで確認しておくことをお勧めします。
パッケージ実行ユーティリティについて（DTSRun から DTExec へ）
SQL Server 2000 の DTS パッケージの実行ユーティリティには、DTSRun.exe を使用して
いましたが、SQL Server 2008 の Integration Services パッケージの実行ユーティリティは
DTExec.exe へ変更されました。したがって、DTSRun.exe を使用したバッチ ファイル等は、
Integration Services パッケージへの移行後に書き換えを行う必要があります。
64-bit 環境で［DTS 2000 パッケージ実行タスク］を使用する場合について
64-bit 版の SQL Server 2008 へ移行した場合は、
「DTS 2000 パッケージ実行タスク」を使
用した Integration Services パッケージは、32-bit モード（WOW64）で実行する必要があ
ります（C:¥Program Files (x86)¥Microsoft SQL Server¥100¥DTS¥Binn フォルダ内の
DTExec.exe を使用する必要があります）。
また、BIDS（Business Intelligence Development Studio）からパッケージの実行をする場合
（パッケージのデバッグ時など）は、プロジェクトのプロパティで、
［構成プロパティ］の［デ
バッグ］を選択し、その中の［Run64BitRuntime］を「False」へ変更してからパッケージを
実行する必要があります。
30
(4) DTS パッケージを移行するポイント
動的プロパティ タスクを利用しているパッケージは、パッケージの修正が必須になりますが、
「DTS 2000 パッケージ実行タスク」でそのまま実行できるパッケージについては、パッケー
ジを修正することなく、移行することができます。今後のメンテナンス性や将来のバージョン
では DTS がサポートされなくなる予定であることを考慮すると、すべての DTS パッケージ
を Integration Services パッケージへ修正していくことが望ましいのですが、暫定対応として、
「DTS 2000 パッケージ実行タスク」で実行可能なものは、実行し、動的プロパティ タスク
を利用する動作しないパッケージなど、移行の優先度が高いパッケージのみを修正して対応す
るのも 1 つの方法です。
4.2.4
Analysis Services の移行検証
SQL Server 2000 の Analysis Services（以下、AS 2000）の多次元データベースを SQL
Server 2008 の Analysis Services（以下、AS 2008）へ移行する検証では、次の 3 つを行い
ました。
4.2.4.1 Analysis Services データベースの移行検証
4.2.4.2 キューブ処理アプリケーションの移行検証
4.2.4.3 クライアント ツールの移行検証
4.2.4.1
Analysis Services データベースの移行検証
(1) 移行方法
AS 2000 と AS 2008 では、アーキテクチャが大きく変更されているため、AS 2000 上で取
得したデータベースのバックアップ（.cab ファイル）を、AS 2008 サーバー上で復元（リス
トア）することはできません。
AS 2000 のデータベースを AS 2008 へ移行するには、
「Analysis Services 移行ウィザード」
を利用する必要があります。今回の検証では、このウィザードを利用しました（利用手順につ
いては、付録 A の 4.2.3.1 へ記載しています）
。
31
(2) 移行結果
「Analysis Services 移行ウィザード」を利用することで、AS 2008 データベース上へ AS
2000 データベースの定義と同等のオブジェクトを作成することができました。
(3) 移行の留意点
データソースに対する接続先は、移行元のデータベースおよびテーブルのままであるため、移
行後に Management Studio または BIDS を使用して、接続先を変更する必要があります。
移行ウィザードによって、ディメンションの属性名など、一部の項目が自動で決定されてしま
うため、移行完了後には、必要に応じて名称を変更する必要があります。
移行ウィザードで移行した Analysis Services データベースは、最適化されたものではないた
め、そのまま使用すると移行前よりもキューブ検索やキューブ処理のパフォーマンスが悪化す
る可能性があります。Analysis Services データベースの最適化方法は、次のとおりです。
Analysis Services データベースの最適化の実装
Analysis Services のパフォーマンス最適化方法については、以下のホワイト ペーパーへ詳し
く記載されています。
SQL Server 2005 Analysis Services パフォーマンス ガイド
http://www.microsoft.com/japan/sql/bible/best_practice.mspx
このホワイトペーパーは、SQL Server 2005 での情報ですが、SQL Server 2008 へも多くの
内容が適用可能なので、一読しておくことをお勧めします。
ここでは、このホワイトペーパーで紹介されている手法のうち、特に重要な 3 つ（属性リレー
ション シップ、集計デザイン、ProcessingGroup プロパティ）の実装方法について説明しま
す。
最適化を実施するには、次のように BIDS（Business Intelligence Development Studio）で
AS 2008 へ移行した Analysis Services データベースを開きます。
32
最適化処理 1．属性リレーション シップの変更（自然階層への変更）
最適化処理の 1 つ目は、属性リレーション シップの設定です。属性リレーション シップは、
AS 2008 のパフォーマンスに最も影響のある重要な設定項目で、Analysis Services 移行ウィ
ザードを実行しただけでは最適化されていません。既定では、次のようにキー属性へ、その他
のすべての属性が関連付けられてしまっています。
キー属性
これを次のように「自然階層」へ変更することによって、キューブ処理およびクエリのパフォ
ーマンスを向上させることができます。
自然階層へ変更
最適化処理 2．集計のデザインの変更（冗長な集計パターンの削除）
最適化処理の 2 つ目は、集計のデザインの変更です。属性リレーション シップを自然階層へ
設定した場合は、下位レベルの項目から上位レベルの集計を計算できるようになるため、冗長
な集計パターンを削除します。
冗長な集計パターンがあるのは、次のような状況です。
33
冗長な集計
パターン
品目分類の「小分類と中分類、大分類」のすべてにチェックが付いている集計と、「中分類と
大分類」の 2 つにチェックが付いている集計が冗長なものです。最適化処理 1 で設定したよ
うに、属性リレーション シップを自然階層として設定している場合は、これらの冗長な部分
を排除することができます。
属性リレーション シップを「小分類 → 中分類 → 大分類」で設定。
この場合は、小分類の集計から中分類の集計を計算可能。
また、中分類の集計から大分類の集計を計算可能。
冗長な集計パターン（既定）
冗長を排除（最適化後）
大分類のチェック
を外す
↓
最適化後の実施
大分類と中分類の
チェックを外す
チェックを外しても
小分類の集計から中分類の集計を計算可能
中分類の集計から大分類の集計を計算可能
このように冗長な集計を排除することで、不要な集計を削除できるで、キューブ処理のパフォ
ーマンスが向上します。
最適化処理 3．ProcessingGroup プロパティの変更
最適化処理の 3 つ目は、ProcessingGroup プロパティの変更です。これは、ディメンション
の処理時に影響のあるプロパティで、
Analysis Services 移行ウィザードの実行後は、
「ByTable」
へ設定されています。
34
有効値
説明
ByTable
単一の SQL ステートメントにより処理
Analysis Services 移行ウィザードで移行したディメンションの既定値
ByAttribute
複数の小さな SQL ステートメントにより処理
AS 2008 でディメンションを新規作成した場合の既定値
「ByTable」と「ByAttribute」のキューブ処理時の違いは、次のとおりです。
ByAttribute によるディメンション処理
ByTable によるディメンション処理
ほとんどの場合において、
「ByAttribute」へ設定することで、軽いクエリを実行できるように
なるので、キューブ処理のパフォーマンスを向上させることができます。
以上で、Analysis Services データベースの最適化処理が完了です。
4.2.4.2
キューブ処理アプリケーションの移行
SQL Server 2000 の DTS では、AS 2000 のキューブを処理する「Analysis Services 処理
タスク」が用意されていましたが、このタスクでは、キューブを並行に処理することができな
いため、複数のキューブまたは １つのキューブの複数パーティションを並行して処理する場
合には、DSO（Decision Support Objects）を使用したアプリケーションを開発する必要があ
りました。
しかし、AS 2005 からは、DSO が AMO（Analysis Management Objects）へ変更されてい
るため、キューブ処理アプリケーションについても、移行検証の対象としました。
(1) 移行方法
移行方法
特徴
1 本のプログラムで複数のキューブやディメンションの
方法 1
AMO を 使 用 したキ ュー
ブ処理プログラムを作成
処理へ対応できるため、汎用性が高く、キューブ数やディ
メンション数が多い場合に役立ちます。また、処理の順番
など、独自のロジックを組み込むことができるのも利点で
す。
方法 2
Integration Services の
コードを記述せずに、キューブやディメンションの処理を
「Analysis Services 処理
実装できるのが利点です。ただし、キューブやディメンシ
タスク」を使用したパッケ
ョンなどの処理の順番を考慮する必要がある場合には、キ
ージを作成
ューブやディメンションごとに個別の Analysis Services
35
処理タスクを作成し、それらの実行順序をフロー定義した
Integration Services パッケージを作成する必要があり
ます。
方法 1．
「AMO によるキューブ処理プログラム」について
AS 2000 では、DSO を使用してキューブ処理プログラムを記述していましたが、AS 2005 か
らは、DSO が AMO へ変更されているため、AMO を利用して、DSO と同機能のアプリケ
ーションを開発することで対応できます。
方法 2．
「Analysis Services 処理タスク」について
DTS の「Analysis Services 処理タスク」を使用した DTS パッケージは、移行することがで
きないため、Integration Services で新しくパッケージを作成し直す必要があります。
Integration Services の「Analysis Services 処理タスク」は、並行処理が可能であるため、キ
ューブの処理に関して、DSO のアプリケーションを代替することが可能です。
(2) 移行結果
移行結果をまとめると、次のようになります。
移行方法
方法 1
方法 2
移行結果
AMO を使用したキューブ処理プログラムの作成
Integration Services の「Analysis Services 処理タスク」
を使用したパッケージの作成
○
○
どの方法も、問題なく移行できることを確認できました。方法 2 の方が開発が容易であるため、
まずは方法 2 での移行を検討することをお勧めします。
(3) 移行の留意点
移行元の環境において、DTS の「Analysis Services 処理タスク」を使用してキューブの処理
を行っている場合は、Integration Services の「DTS 2000 パッケージ実行タスク」へは移行
することができないことに注意する必要があります（4.2.3.1 で説明したように、実行時にエ
ラーが発生します）
。
したがって、DTS の「Analysis Services 処理タスク」は、Integration Services の「Analysis
Services 処理タスク」または AMO を利用したキューブ処理アプリケーションへ移行するよ
うにします。
4.2.4.3
クライアント ツールの移行検証
今回の検証では、Excel 2000／2003／2007 のピボット テーブルを使用して、AS 2000 デー
タベースから AS 2008 のキューブへ接続を切り替えて検索を行う検証を行いました。
36
(1) 移行方法
ピボット
テーブル
移行方法
手順章番号
1. クライアント PC へ「Microsoft OLE DB Provider for
Analysis Services 10.0」をインストール
Excel 2000
Excel 2003
2. ピボット テーブルの接続先やプロバイダを Microsoft
A.2.3
Script Editor を利用して手動で変更
1. クライアント PC へ「Microsoft OLE DB Provider for
Excel 2007
Analysis Services 10.0」をインストール
2. ピボット テーブルの接続先やプロバイダを「データ」
4.2.3
メニューから変更
(2) 移行結果
移行結果は、次のようになりました。
移行結果
Excel 2000
△
Excel 2003
△
Excel 2007
△
△: 移行可能だが注意が必要
すべてのケースで AS 2008 へ接続した時点で、ピボット テーブルへ配置していたディメンシ
ョンがなくなり、再度、配置し直さないとならなくなりました。
移行前
移行後（配置していたディメンションが消える）
AS 2005／AS 2008 からは、ディメンションに「属性」という概念が加わり、AS 2000 と構
造が異なっているために、このような現象が発生しています。したがって、AS 2000 から AS
2008 へ移行した場合には、ピボット テーブルの再定義が必要になります。
(3) 移行の留意点
特にありません。
37
4.2.5
Reporting Services の移行検証
(1) 移行方法
SQL Server 2000 の Reporting Services（以下、RS 2000）で作成したレポートを、SQL Server
2008 の Reporting Services（以下、RS 2008）へ移行する検証では、次の 2 つの方法を利用
しました。
移行方法
特徴
手順章番号
データベースを移行するので、シンプルな手順
方法 1
レポート サーバー デ
で、最新の情報を移行することができます。た
ータベースの移行
だし、特定のレポートを選択して移行すること
A.2.4.1
はできません。
特定のレポートを選択して移行することが可
能ですが、レポートごとに配置を実行する必要
方法 2
BIDS で開発したオブ
ジェクトの移行
があるため、レポート数が多い場合には手間が
かかります。また、レポート ファイルがない
場合は、移行することができないため、最新の
A.2.4.2
A.2.4.3
レポート ファイルが管理されていることが前
提条件となります。
方法 1 について
Reporting Services では、レポート定義などのメタデータを SQL Server 上のデータベース
（Reporting Server および Report Server Temp データベース）へ格納しています。このデ
ータベースは、RS 2000 と RS 2008 で互換性があるため、既存データベースと暗号化キーを
バックアップし、移行先のデータベースへ復元した後で、「Reporting Services 構成マネージ
ャ」からレポート サーバー データベースの構成を実行することで移行することが可能です。
移行手順については、付録 A の 4.2.4.1 で説明しています。
なお、暗号化キーは、レポート内で定義されている接続情報などセキュリティ上保護されるべ
き情報を暗号／復号化する際に使用されます。暗号化キーは Reporting Services のサービス
起動アカウントの GUID を使用して生成されるため、データベース移行時には、再設定が必
要になります。
方法 2 について
BIDS（Business Intelligence Development Studio）で開発したレポート ファイルおよび共
有データソース ファイルを、移行先の環境の BIDS またはレポート マネージャから読み込
み、レポート サーバーへ配置することで、レポートごとに移行することが可能です。
(2) 移行結果
移行結果は、次のようになりました。
38
レポート
共有データ
ファイル
ソース
－
○
○
BIDS で開発したオブ
BIDS
○
○
ジェクトの移行
レポート マネージャ
○
△
移行方法
方法 1
方法 2
レポート サーバー デ
ータベースの移行
○: 移行可能
配置方法
△: 移行可能だが留意点あり
方法 2 では、レポート マネージャを利用した場合に、共有データソースの配置後に、追加の
作業（後述）が必要になるため、方法 1 で移行することをお勧めします。
方法 1.「レポート サーバー データベースの移行」について
移行は、特に問題なく完了しました。
方法 2.「BIDS で開発したオブジェクトの移行」について
この方法では、BIDS（Business Intelligence Development Studio）で配置を行った場合には、
レポート ファイルおよび共有データソースともに、配置と実行（レポート参照）が正常に完
了しました。
これに対して、レポート マネージャを利用して配置した場合は、レポート ファイルの配置と
実行は正常に完了したものの、共有データソースの配置後は、実行（レポート参照）時にエラ
ーが発生しました。このエラーは、共有データソースとレポートの関連付けがなくなってしま
ったことによって発生しています。
したがって、共有データソースを使用している場合には、レポート マネージャからではなく、
BIDS から配置を行うようにするか、次のようにレポート マネージャを使用して共有データ
ソースとレポートの関連付けを設定する必要があります。
共有データソースとレポートの関連付け（レポート マネージャ）
共有データソースを設定するには、レポートのプロパティを開き、［データソース］ページか
ら行います。
39
(3) 移行の留意点
レポート マネージャを使用してレポートの移行を行う際にデータソースの接続先を変更する
場合には、アップロード後にデータソースを変更するか、事前にレポート定義ファイル（.rdl フ
ァイル）の接続情報を変更しておく必要があります。
接続情報を変更するには、共有データソースの場合と同様、レポートのプロパティの［データ
ソース］ページから行います。
40
4.3
SQL Server 2005 から SQL Server 2008 への移行
SQL Server 2005 から SQL Server 2008 への移行については、以下の項目を検証しました。
4.3.2
データベース エンジン機能の移行
4.3.3
Integration Services（SSIS）パッケージの移行
4.3.4 Analysis Services の移行
4.3.5 Reporting Services の移行
前提事項
検証における前提事項は、次のとおりです。
① 用語定義
・新規サーバー = SQL Server 2008 がインストールされているサーバー
・移行対象（移行元）サーバー = SQL Server 2005 がインストールされているサーバー
② SQL Server 2005 と SQL Server 2008 は、別サーバーおよび別ストレージへ存在する
（同一マシンでのアップグレードではなく、新規サーバーへの移行とする）
③ SQL Server 2008 は、新規サーバーへインストール済みである
④ システム データベースは移行できないため、ログイン アカウントなどのシステム デー
タベースのオブジェクトは再作成済みである
⑤ 移行作業は、新規サーバー（SQL Server 2008）上の Management Studio から、移行
対象サーバーとなる SQL Server 2005 のデータベースへ接続して行う
4.3.1
SQL Server 2005 からの移行検証の結果
SQL Server 2005 から SQL Server 2008 への移行検証の結果をまとめると、次のようになり
ます。
コンポーネント
データベース エンジン
Integration Services
Analysis Services
章番号
移行対象
4.3.2.1
データベース
○
4.3.2.2
データベースミラーリング
○
4.3.2.3
データ パーティション
○
4.3.2.4
BCP、osql、sqlcmd ユーティリティを利用した
バッチ プログラム
結果
○
4.3.2.5
DMV を利用した監視スクリプト
○
4.3.2.6
DBCC コマンドを利用した監視スクリプト
○
4.3.3
Integration Services パッケージ
○
4.3.4.1
SSAS データベース
○
4.3.4.2
キューブ処理アプリケーション
○
41
Reporting Services
○: 移行可能
4.3.4.3
クライアント ツール
○
4.3.5
レポートデータベース
○
△: 移行可能だが注意が必要
×: 移行不可能
結果は、すべての機能で移行を行うことができました。
4.3.2 データベース環境の移行検証
ここでは、SQL Server 2005 のデータベース エンジン機能を SQL Server 2008 へ移行した
際の検証結果として、次の 7 点を説明します。
4.3.2.1 データベースの移行
4.3.2.2
データベースミラーリング環境の移行
4.3.2.3
データ パーティション環境の移行
4.3.2.4 BCP、osql、sqlcmd ユーティリティを利用したバッチの移行
4.3.2.5
DMV を利用した監視スクリプトの移行
4.3.2.6
DBCC コマンドを利用した監視スクリプトの移行
4.3.2.1
データベースの移行検証
SQL Server 2005 から SQL Server 2008 へのデータベースの移行は、SQL Server 2000 か
ら SQL Server 2008 への移行の場合と同様です。手順は、付録 A の A.3.1.1 へ記載していま
す。
4.3.2.2
データベースミラーリング環境の移行検証
(1) 移行方法
移行にあたっての前提事項は、次のとおりです。

データベース ミラーリングは、ミラーリング監視サーバーを含めた自動フェール オー
バー構成とする

データベース本体の移行には、バックアップ／復元を利用する
移行方法は、データベースのバックアップと復元を行った後、
新規サーバー（SQL Server 2008）
上で、データベース ミラーリングの再設定を手動で行います。移行手順については、付録 A
の A.3.1.2 へ記載しています。
(2) 移行結果
新規サーバーでデータベース ミラーリングを再設定後、問題なく稼動することを確認できま
した。また、自動フェール オーバーも正常に動作することを確認できました。
(3) 移行の留意点
42
データベース ミラーリング環境では、デタッチ／アタッチによるデータベース移行を行うこ
とができないため、バックアップ／復元によるデータベースの移行を行う必要があります。
4.3.2.3
データ パーティション環境の移行検証
(1) 移行方法
データ パーティション環境の移行は、データベースを移行することで実現可能です。データ
ベースの移行方法には、デタッチ／アタッチを利用して、データベースを新規サーバー（SQL
Server 2008）上へ移行します（バックアップ／復元を利用することも可能）
。移行手順につい
ては、付録 A の A.3.1.3 へ記載しています。
(2) 移行結果
新規サーバーでデータベースのアタッチ後、問題なく稼動することを確認できました。また、
パーティション テーブルに対して検索を行い、問題なく結果が返ることも確認できました。
(3) 移行の留意点
データ パーティション環境は、データベースのデタッチ／アタッチまたはバックアップ／復
元で移行することができます。
4.3.2.4
BCP、osql、sqlcmd ユーティリティを利用したバッチの移行検証
(1) 移行方法
BCP、osql および sqlcmd ユーティリティは、SQL Server 2008 にも存在するため、バッチ
プログラムはそのまま新環境へ移行することが可能です。
(2) 移行結果
バッチ プログラムは、移行後も問題なく動作することを確認できました。
(3) 移行の留意点
BCP／osql／sqlcmd ユーティリティを利用したバッチ プログラムで設定している「引数」や
「環境変数」のうち、移行元サーバーへ依存するものは、新規サーバーへ合わせて変更する必
要があります。
osql ユーティリティは、将来の SQL Server の新しいバージョンでは、削除される可能性が
あるため、今後を考慮すると、sqlcmd ユーティリティへの移行を検討しておくようにします。
4.3.2.5
DMV を利用した監視スクリプトの移行検証
(1) 移行方法
DMV（動的管理ビュー）は、SQL Server 2008 にも存在するため、DMV を利用した監視ス
43
クリプトはそのまま新環境へ移行することが可能です。
(2) 移行結果
監視スクリプトは、問題なく動作することを確認できました。
(3) 移行の留意点
ほとんどの DMV は、SQL Server 2005 と SQL Server 2008 で同様の動作をしますが、一
部の DMV では、列名や出力結果が変更されているものがあります。また、新しく追加され
た DMV も存在します。したがって、移行にあたっては、監視スクリプトが新規サーバー環
境においても同じように動作することを確認しておくことが重要です。
4.3.2.6
DBCC コマンドを利用した監視スクリプトの移行検証
SQL Server 2005 の運用環境において、特に利用頻度が高い DBCC コマンド（CHECKDB、
CHECKTABLE 、 SHOW_STATISTICS 、 SHRINKDATABASE 、 DBREINDEX 、
SHOWCONTIG）を利用した管理スクリプトを新環境に移行しました。これらの DBCC コマ
ンドは、SQL Server 2008 にも存在するため、監視スクリプトはそのまま新環境へ移行する
ことが可能です。
ただし、監視スクリプトは、新環境において動作するか必ず確認しておくことが重要です。
DBCC コマンドの一部には、将来のバージョンで削除あるいは旧バージョンから動作が変更
になっているものがあります。詳細については、オンライン ブックの下記を参照してくださ
い。
SQL Server データベース エンジンの旧バージョンとの互換性
http://msdn.microsoft.com/ja-jp/library/ms143532.aspx
44
4.3.3
Integration Services（SSIS）の移行検証
(1) 移行方法
SQL Server 2005 の Integration Services（以下、SSIS 2005）と SQL Server 2008 の
Integration Services（以下、SSIS 2008）は、アーキテクチャがほとんど変更されていないの
で、SSIS 2005 で作成したパッケージは、基本的には SQL Server 2008 上でも動作します。
SSIS 2005 パッケージの移行検証としては、次の 4 つの方法を利用しました。
移行方法
方法 1
特徴
BIDS の配置ユーティ
リティ
パッケージの開発ツールである BIDS を利用
して、プロジェクトまたはパッケージ単位で移
－
行する方法です。
Management
方法 2
手順章番号
Studio
のパッケージ アップ
グレード ツール
Management Studio から起動可能なパッケー
ジのアップグレード ツールです。データ プロ
A.2.3
バイダのアップグレードもツールで行うこと
ができます。
パッケージの配置が行えるコマンドライン ツ
方法 3
dtutil ユーティリティ
ールです。複数のパッケージをまとめて移行す
－
ることが可能です。
Services
パッケージを OS のファイル（.dtsx）として
パッケージ ファイル
管理している場合に適用できる、一番簡単な移
（.dtsx）のコピー
行方法です。
Integration
方法 4
－
(2) 移行結果
移行結果は、次のとおりです。
移行方法
移行結果
方法 1
BIDS の配置ユーティリティ
○
方法 2
Management Studio のパッケージ アップグレード ツール
○
方法 3
dtutil ユーティリティ
○
方法 4
Integration Services パッケージ ファイル（.dtsx）のコピー
○
どの方法を利用しても、パッケージの移行をすべて正常に行うことができました。
4 つの方法を比較すると、次のようになります。
プロバイダの
移行元リソース
移行単位
方法 1
Visual Studio プロジェクト
プロジェクト
手動
方法 2
パッケージ
複数パッケージ
自動
方法 3
パッケージ
複数パッケージ
手動
方法 4
パッケージ
複数パッケージ
手動
45
アップグレード
プロバイダのアップグレードは、SQL Server 2005 でのプロバイダ「SQL Server Native
Client」を、SQL Server 2008 でのプロバイダ「SQL Server Native Client 10.0」へアップ
グレードするかどうかになります。
方法 1 の「BIDS（Business Intelligence Development Studio） の配置ユーティリティ 」
（.SSISDeploymentManifest ファイル）は、移行というよりは、開発環境からテスト環境へ
のリリース時に使用する機能になります。
方法 2 の「Integration Services パッケージのアップグレード」では、プロバイダのアップグ
レードを行ってくれるので、バージョン アップが伴う移行では、一番お勧めの移行方法にな
ります。
方法 3 の「dtutil ユーティリティ」は、移行というよりは、開発環境から本番環境へ、まと
めてパッケージをリリースする場合に使用する機能となります。
方法 4 の「パッケージ ファイル（.dtsx）のコピー」は、Management Studio のパッケージ
管理機能を利用しない場合には、一番簡単なパッケージ管理方法です。
(3) 移行の留意点
SQL Server 2005 の BIDS（Business Intelligence Development Studio）は、Visual Studio
2005 のシェルを利用していますが、SQL Server 2008 の BIDS は、Visual Studio 2008 の
シェルを利用しています。したがって、SQL Server 2005 で開発した Integration Services の
プロジェクト（.sln ソリューション ファイル）を SQL Server 2008 の BIDS で最初に読み
込む際には、
「Visual Studio 変換ウィザード」が起動して、プロジェクトの自動変換が行われ
ます（Integration Services パッケージの内容は、変更されません）
。
SQL Server 2008 の BIDS で、新規に Integration Services プロジェクトを作成し、そこへ
SQL Server 2005 の Integration Services で開発したパッケージを読み込んだ場合（既存の
パッケージの追加を行った場合）は、パッケージ内のプロバイダ情報が「SQL Server Native
Client 10.0」へ変更されたことを知らせる警告メッセージが表示されて、自動的にプロバイダ
が「SQL Server Native Client 10.0」へアップグレードされます。
46
4.3.4
Analysis Services の移行検証
SQL Server 2005 の Analysis Services（以下、AS 2005）と SQL Server 2008 の Analysis
Services（以下、AS 2008）は、アーキテクチャがほとんど変更されていないので、AS 2005 で
作成した Analysis Services データベースは、AS 2008 上へ簡単に移行することができます。
Analysis Services に関しては、次の 3 つの検証を行いました。
4.3.4.1 Analysis Services データベースの移行検証
4.3.4.2 キューブ処理アプリケーションの移行検証
4.3.4.3 クライアント ツールの移行検証
4.3.4.1
Analysis Services データベースの移行検証
(1) 移行方法
AS 2005 で作成した Analysis Services データベースの移行検証では、次の 4 つの方法を利
用しました。
方法 1
移行方法
特徴
多次元データベースのバ
本番で稼動している多次元データベースの
ックアップ／復元
データを含めた移行が可能です。
XMLA 形式のスクリプト
方法 2
ファイルによるエクスポ
ート／インポート
方法 3
方法 4
BIDS による配置
手順章番号
本番で稼動している多次元データベースの
定義のみを移行可能です。
Visual Studio のプロジェクト ファイルか
ら、定義のみを移行することができます。
Analysis Services 配置ウ
Visual Studio のプロジェクト ファイルか
ィザードによる配置
ら、定義のみを移行することができます。
A.3.3 - (1)
A.3.3 - (2)
A.3.3 - (3)
A.3.3 - (4)
(2) 移行結果
結果は、方法 1～4 のいずれの方法を利用しても、Analysis Services データベースの移行を
すべて正常に行うことができました。
4 つの方法を比較すると、次のようになります。
接続先／プロバイダ
の変更タイミング
定義／データの移行
移行元のリソース
方法 1
復元後
定義とデータ
本番機の多次元データベース
方法 2
スクリプト実行前後
定義のみ
本番機の多次元データベース
方法 3
配置前後
定義のみ
開発環境の VS プロジェクト
方法 4
配置前後
定義のみ
開発環境の VS プロジェクト
方法 1 の「バックアップ／復元」は、Analysis Services データベースの定義だけでなく、デ
47
ータも移行できる唯一の方法です。これは、本番機からデータも含めて移行したい場合にお勧
めの方法です。
方法 2 の「XMLA スクリプトによる移行」は、Analysis Services データベースの定義のみ
を移行することが可能です。移行先サーバーでは、Analysis Services データベース オブジェ
クトの処理を行うことで、データを生成することができます。この方法は、移行先のデータで、
新しくオブジェクトを処理したい場合にお勧めの方法です。
方法 3 の「BIDS による配置」と、方法 4 の「配置ウィザード」は、開発環境の VS（Visual
Studio）プロジェクトを元にしていて、本番で稼動しているリソースを元にしていないため、
移行には適していません。
したがって、AS 2005 から AS 2008 への移行には、方法 1 または方法 2 での移行を推奨し
ます。
(3) 移行の留意点
AS 2000 から AS 2008 への移行の際に使用した「Analysis Services 移行ウィザード」は。
AS 2005 からの移行には使用することができません。
AS 2005 で使用していたプロバイダ「Microsoft OLE DB Provider for Analysis Services 9.0」
は、AS 2008 データベースに対して接続することもできますが、AS 2008 からの新機能が利
用できないなど、使用できる機能へ制限があるため、AS 2008 用のプロバイダ「Microsoft OLE
DB Provider for Analysis Services 10.0」を使用するようにします。
SQL Server 2005 の「SQL Server Native Client」は、SQL Server 2008 のデータベースに
対して接続することも可能です。
4.3.4.2 キューブ処理アプリケーションの移行検証
キューブ処理アプリケーションの移行検証では、次の 2 つの方法を利用しました。
移行方法
特徴
1 本のプログラムで複数のキューブやディメンショ
方法 1
AMO を使用した既存のキューブ
処理プログラムの使用
ンの処理へ対応できるため、汎用性が高く、キュー
ブ数やディメンション数が多い場合に役立ちます。
また、処理の順番など、独自のロジックを組み込む
ことができるのも利点です。
Integration Services の「Analysis
方法 2
Services 処理タスク」を使用したパ
ッケージを作成
コードを記述せずに、キューブやディメンションの
処理を実装できるのが利点です。
(2) 移行結果
移行結果をまとめると、次のようになります。
48
移行方法
方法 1
方法 2
移行結果
AMO を使用した既存のキューブ処理プログラムの使用
Integration Services の「Analysis Services 処理タスク」を使用した
パッケージをそのまま流用
○: 移行可能
△
○
△: 移行可能だが留意点あり
方法 1 の「AMO を使用したキューブ処理プログラム」は、AS 2005 と AS 2008 では、と
もに AMO（Analysis Management Objects）インタフェースが提供されているため、コード
の変更をする必要はありませんでしたが、プログラム実行で以下のエラーが発生しました。
エラーメッセージ：Cannot connect to Analysis Services version '10.0.1098.4'
これは、Microsoft.Analysis.Services.DLL のバージョンが SQL Server 2005 と SQL Server
2008 と で 異 な っ て い る た め に 発 生 し た エ ラ ー で す 。 こ の エ ラ ー を 解 消 す る に は 、
Microsoft.Analysis.Services.DLL を新バージョンへ置き換えて、再度コンパイルを実行する
必要があります（ソースコードの変更は必要ありません）
。
方法 2 の Integration Services の「Analysis Services 処理タスク」は、AS 2005 と AS 2008
で互換性があるため、そのまま移行することが可能です（移行したパッケージを問題なく実行
することができました）
。
(3) 移行の留意点
AMO の場合に、再コンパイルが必要な点以外は、特にありません。
4.3.4.3
クライアント ツールの移行検証
今回の検証では、Excel 2000／2003／2007 のピボット テーブルを使用して、AS 2005 デー
タベースから AS 2008 のキューブへ接続を切り替えて検索を行う検証を行いました。
(1) 移行方法
クライアント ツールの移行方法は、次のように行いました。
ピボット
テーブル
移行方法
手順章番号
1. クライアント PC へ「Microsoft OLE DB Provider for
Excel 2000
Excel 2003
Analysis Services 10.0」をインストール
2. ピボット テーブルの接続先やプロバイダを Microsoft
A.2.3.2 - (1)
Script Editor を利用して手動で変更
1. クライアント PC へ「Microsoft OLE DB Provider for
Excel 2007
Analysis Services 10.0」をインストール
2. ピボット テーブルの接続先やプロバイダを「データ」
メニューから変更
49
A.2.3.2 - (2)
(2) 移行結果
移行結果は、次のようになりました。
移行結果
Excel 2000
○
Excel 2003
○
Excel 2007
○
すべてのケースで正しくピボット テーブルが表示され、データの更新を行い、データの抽出
を行うことができました。
(3) 移行の留意点
特にありません。
4.3.5
Reporting Services の移行検証
(1) 移行方法
SQL Server 2005 の Reporting Services（以下、RS 2005）で作成したレポートを、SQL Server
2008 の Reporting Services（以下、RS 2008）へ移行する検証では、次の 2 つの方法を利用
しました。
移行方法
特徴
手順章番号
データベースを移行するので、シンプルな手順
方法 1
レポート サーバー
で、最新の情報を移行することができます。た
A.3.4
データベースの移行
だし、特定のレポートを選択して移行すること
(A.2.4.1 と同じ)
はできません。
特定のレポートを選択して移行することが可
能ですが、レポートごとに配置を実行する必要
方法 2
BIDS で開発したオ
ブジェクトの移行
があるため、レポート数が多い場合には手間が
かかります。また、レポート ファイルがない
場合は、移行することができないため、最新の
A.3.4
(A.2.4.2 と同じ)
レポート ファイルが管理されていることが前
提条件となります。
方法 1 について
Reporting Services では、レポート定義などのメタデータを SQL Server 上のデータベース
（Reporting Server および Report Server Temp データベース）へ格納しています。このデ
ータベースは、RS 2005 と RS 2008 で互換性があるため、既存データベースをバックアップ
し、移行先のデータベースへ復元した後で、
「Reporting Services 構成マネージャ」から レポ
ート サーバー データベースの構成を実行することで移行することが可能です。移行手順につ
いては、付録 A の A.2.4.2 へ記載しています。
50
方法 2 について
BIDS（Business Intelligence Development Studio）で開発したレポート ファイルおよび共
有データソース ファイルを、移行先の環境の BIDS またはレポート マネージャから読み込
み、レポート サーバーへ配置することで、レポートごとに移行することが可能です。
(2) 移行結果
移行結果をまとめると、次のようになります。
移行方法
方法 1
方法 2
配置方法
レポート サーバー デ
レポート
共有データ
レポート
ファイル
ソース
モデル
○
○
○
－
ータベースの移行
BIDS で開発したオブ
BIDS
○
○
△
ジェクトの移行
レポート マネージャ
○
△
○
○: 移行可能
△: 移行可能だが留意点あり
方法 2 では、レポート マネージャを利用した場合に、共有データソースの配置後に、追加の
作業（後述）が必要になります。また、BIDS でのレポート モデル配置時にはエラーが発生
するるため、方法 1 で移行することをお勧めします。
方法 1.「Reporting Server データベースの移行」について
移行は、特に問題なく完了しました。
方法 2.「BIDS で開発したオブジェクトの移行」について
この方法では、BIDS（Business Intelligence Development Studio）で配置を行った場合には、
レポート ファイルおよび共有データソースについては、配置と実行（レポート参照）が正常
に完了しました。しかし、レポート モデルの配置では、Analysis Services のデータソースを
使用しているレポート モデルの配置の際にエラーが発生しました。
したがって、Analysis Services をデータソースとして使用しているレポート モデルは、レポ
ート マネージャから配置するようにします。
これに対して、レポート マネージャを利用して配置した場合は、レポート ファイルとレポー
ト モデルの配置と実行は正常に完了したものの、共有データソースの配置後は、実行（レポ
ート参照）時にエラーが発生しました。このエラーは、共有データソースとレポートの関連付
51
けがなくなってしまったことによって発生しています。
したがって、共有データソースを使用している場合には、レポート マネージャからではなく、
BIDS から配置を行うようにするか、次のようにレポート マネージャを使用して共有データ
ソースとレポートの関連付けを設定する必要があります（この手順は、4.2.5 で説明していま
す）
。
(3) 移行の留意点
レポート マネージャを使用してレポートの移行を行う際にデータソースの接続先を変更する
場合には、アップロード後にデータソースを変更するか、事前にレポート定義ファイル（.rdl フ
ァイル）の接続情報を変更しておく必要があります（この手順は、4.2.5 で説明しています）。
SQL Server 2008 の Management Studio では、Reporting Services のフォルダ構成へ変更
が あ り 、「 ホ ー ム 」 フ ォ ル ダ が 削 除 さ れ ま し た 。 こ れ に 伴 っ て 、 SQL Server 2005 の
Management Studio から可能であったレポートの配置が、SQL Server 2008 からは行えなく
なりました。レポートの配置には、BIDS またはレポート マネージャから行う必要がありま
す。
SQL Server 2005 の Management Studio では ［ホーム］フォルダからレポートのアップロードが可能
［ホーム］フォルダからレポート
のアップロードが可能
SQL Server 2008 では ［ホーム］フォルダから削除された
［ホーム］フォルダが
削除された
52
第 5 章 ソリューション作成時のパフォーマンス検証
この章では、ソリューション作成時のシステムへの影響（パフォーマンスへの影響）を測定した結果に
ついて説明します。具体的には、次の検証を行いました。
5.1
5.1
SQL Server 2000／2005／2008 パフォーマンス計測
5.2
プラットフォーム別のパフォーマンス計測
SQL Server 2000／2005／2008 パフォーマンス計測
5.1.1 検証環境
SQL Server 2000／2005／2008 のパフォーマンス計測で利用したサーバーおよびクライアン
トのハードウェア環境は、次のとおりです。
ス ペック
No.
用途
プ ロセッサ
機種
内 蔵ディスク
種別
個数
メ モリ
容量
NIC
R A ID リ ンク
レ ベル 速 度
1
DB サーバー #1
ES7000/one（Partition1）
（プリンシパル）
デュアルコア
Xeon 7140
（3.40GHz）
4 CPU
(8 Core)
16 GB
72 GB
1
1Gbps
2
DB サーバー #2
（ミラー）
ES7000/one（Partition2）
デュアルコア
Xeon 7140
（3.40GHz）
4 CPU
(8 Core)
16 GB
72 GB
1
1Gbps
3
Witness サーバー
rE5000/130BE
デュアルコア
5050
（3.00GHz）
1 CPU
(2 Core)
4 GB
73 GB
1
1Gbps
4
AP サーバー兼
クライアント
rE5000/130BE
デュアルコア
5050
（3.00GHz）
1 CPU
(2 Core)
4 GB
73 GB
1
1Gbps
5
クライアント
DELL LATITUDE D531
デュアルコア
TL-50
（1.60GHz）
1 CPU
(2 Core)
2 GB
120 GB
1
1Gbps
ストレージ環境（SANARENA 1895）、データの配置
R A ID G roup
No.
用途
機種
RG
R A ID
N o . レ ベル
L o gical U nit
H D Dコン
H D D R G 容量
ビ ネー
数
( G B)
シ ョン
LU
No.
00
00
1
1D+1M
2
500
01
1
1D+1M
2
500
02
1
1D+1M
2
500
03
1
1D+1M
2
500
04
1
1D+1M
2
500
05
1
1D+1M
2
500
01
02
00
01
02
00
1
DBサーバ#1
（プリンシパル）
ES7000/one
（Cell 1）
01
02
00
53
01
02
00
01
02
00
01
LU
容量
L U 用途
OLTP DB データ領域 1
ミラーリング用 DB データ領域 1
150 －
150 POS DWH データ領域 1
OLTP DB データ領域 2
150
ミラーリング用 DB データ領域 2
150 －
150 POS DWH データ領域 2
OLTP DB データ領域3
150
ミラーリング用 DB データ領域 3
150 －
150 POSDWH データ領域 3
150 OLTP DB Transaction Log 領域
ミラーリング用 DB Txn Log 領域
150 －
150 POS DWH Transaction Log 領域
150 インスタンス tempdb 領域
150 －
残り テンポラリ領域
150 POS 実績キューブ領域
残り テンポラリ領域
150
No.
用途
機種
DBサーバ#2
（ミラー）
2
ES7000/one
（Cell 2）
RAID Group
Logical Unit
HDDコン
RG RAID
HDD RG容量
ビネー
No. レベル
数
(GB)
ション
LU
No.
LU
容量
00
01
02
03
04
05
100
100
100
50
50
残り
06
1
1D+1M
2
500
LU用途
OLTP DB データ領域 1 (Mirror)
OLTP DB データ領域 2 (Mirror)
OLTP DB データ領域 3 (Mirror)
OLTP DB Txn Log 領域 (Mirror)
OLTP DB tempdb 領域 (Mirror)
バックアップ／テンポラリ領域
SANARENA 1895
OLTP DB データ領域
OLTP Txn Log領域
ミラーリング用 DB データ領域
ミラーリング Txn Log
POS DWH データ領域
Tempdb
POS DWH TxnLog
テンポラリ領域
ミラーリング DB
POS 実績キューブ
ミラーリング TxnLog
テンポラリ領域
Tempdb
テンポラリ領域
RG 00
RG 01
RG 02
RG 03
RG 04
RG 05
RG 06
DB サーバー #2
（ミラー）
DB サーバー #1
（プリンシパル）
ソフトウェア環境
サーバーおよびクライアントのソフトウェア環境は、次のとおりです。
No.
1
2
3
4
用途
DBサーバー #1
（プリンシパル）
DBサーバー #2
（ミラー）
Witness サーバー
AP サーバー兼
クライアント
ソフトウェア
Windows Server 2003 R2 Enterprise Edition
x64
SP2
SQL Server 2008 Enterprise Edition RC0
x64
-
SQL Server 2005 Enterprise Edition
x64
SP2
KB 934459
SQL Server 2000 Enterprise Edition
32-bit
SP4
KB 899761
KB 911023
KB 916287
Windows Server 2003 R2 Enterprise Edition
x64
SP2
SQL Server 2008 Enterprise Edition RC0
x64
-
SQL Server 2005 Enterprise Edition
x64
SP2
Windows Server 2003 R2 Enterprise Edition
32-bit
SP2
SQL Server 2008 Enterprise Edition RC0
32-bit
-
SQL Server 2005 Enterprise Edition
32-bit
SP2
Windows Server 2003 R2 Standard Edition
32-bit
SP2
Excel 2003
SP3
Excel 2007
SP1
Windows Server 2003 R2 Standard Edition
5
クライアント
プラット Service
修正
フォーム Pack プログラム
32-bit
SP2
Excel 2003
SP3
Excel 2007
SP1
54
KB 934459
KB 934459
パフォーマンス検証パターン
パフォーマンス検証は、次のパターンで実施しました。
分類
SQL Server
2 000
SQL Server
2 005
SQL Server
2 008
キューブ処理
●
●
●
キューブ検索
●
●
●
OLTP 性能
●
●
●
バックアップ圧縮
●
●
パーティション
●
●
DB ミラーリング
●
●
検証機能
Analysis Services
データベース エンジン
Analysis Services に関しては、キューブ処理時の実行時間およびクライアント（Excel 2003
／Excel 2007）からのキューブ検索時の実行時間を測定しました。測定に利用したデータベー
スと OLAP キューブの構成は、次のとおりです。
パーティション
ディメンション
メジャー
パーティション数：19（ファクトデータ件数：約 1100万件×19 = 約 2億件）
ディメンション数：20（内、仮想ディメンション数：15、
最大ディメンションデータ件数：約 157万件)
メジャー数： 12
（内、計算されるメンバ数：10）
集計数
： 109
（全パーティション共通）
データベース エンジンに関しては、一般的な OLTP（トランザクション処理システム）環境
をシミュレートしたテスト ツールを利用して、高負荷テストを実施しました。このテスト ツ
ールでは、高負荷状態（一般的な OLTP システムにおけるピーク状態）を継続して実行でき
るように作成してあります。
また、バックアップ圧縮を利用した場合と、そうでない場合のバックアップ時間の比較、デー
タ パーティション環境でのクエリ パフォーマンス、データベース ミラーリング環境でのデ
ータ更新パフォーマンスを測定しました。
パフォーマンス計測方法
パフォーマンスの計測方法は、次のとおりです。

各テスト パターンを 3 回ずつ実行し、平均値を取得

ワークロードが完了毎に SQL Server を再起動
55

OLTP テストでは、高負荷ワークロードを 15 分間実行（中間の 5 分間を計測）

実行中のパフォーマンス カウンタの情報を収集して解析
5.1.2 検証結果
以降では、パフォーマンス測定の結果を、次の流れで説明します。
5.1.3 Analysis Services キューブ処理のパフォーマンス比較
5.1.4 Analysis Services キューブ検索のパフォーマンス比較
OLTP パフォーマンスの比較
5.1.6
バックアップ圧縮のパフォーマンス比較
5.1.7
データ パーティションのパフォーマンス比較
5.1.8
データベース ミラーリングのパフォーマンス比較
Analysis Services キューブ処理のパフォーマンス比較
SQL Server 2000／2005／2008 の Analysis Services のキューブ処理パフォーマンスを比較
した結果は、次のとおりです。キューブ処理は、SQL Server 2000 は、DSO（Decision Support
Objects）による並列処理プログラム、SQL Server 2005／2008 は、Integration Services の
「Analysis Services 処理タスク」による並列処理で実行しています。
キューブ処理時間の比較
120
実行時間 （ 相対値）
5.1.3
5.1.5
100
100.0
80
60
53.8
53.4
2005
2008
40
20
0
2000
2000
100
-
キューブ処理時間（相対値）
SQL Server 2000 との差
SQL Server 2005 との差
2005
53.8
46.2
-
2008
53.4
46.6
0.5
結果は、SQL Server 2000 でのキューブ処理にかかった実行時間を 100 とした場合の相対値
56
で示しています。
SQL Server 2005 と SQL Server 2008 では、SQL Server 2000 と比べて、ともに 46% 以
上の性能差が現れたことを確認することができました。また、SQL Server 2005 と SQL
Server 2008 では、ほぼ同等の性能が得られたこと（差は 0.4% のみであり、誤差の範囲であ
ること）も確認することができました。
SQL Server 2000 との差は、SQL Server 2000 の DTS の「Analysis Services 処理タスク」
では、並列処理が実行できないため、今回の検証では DSO によるプログラムを利用して並列
処理を実行したことが 1 つの原因であると考えられます。この方法では、SQL Server 2005
／2008 の Integration Services の「Analysis Services 処理タスク」と比べて、効率が悪い
（CPU 利用の面など）と考えられます。また、SQL Server 2000 は、32-bit 環境であったた
め、64-bit 環境（x64）の SQL Server 2005／2008 と比べて、メモリの使用効率の点で、性
能差が現れたと考えられます。
Analysis Services キューブ検索のパフォーマンス比較
Analysis Services のキューブ検索（Excel 2003 および Excel 2007 ピボット テーブルから
の参照）では、次の結果を取得するときのパフォーマンスを計測しました。
横軸： 店舗（826メンバ）
ページフィールド： 期間月（731メンバ）
月 (24メンバ)
全店舗 (1メンバ)
地区 (9メンバ)
縦軸： 商品（1,570,973メンバ）
全商品 (1メンバ)
大分類 (6メンバ)
メジャー数： 12 (計算されるメンバ数： 10)
中分類 (31メンバ)
小分類 (291メンバ)
細分類 (1,466メンバ)
結果は、次のとおりです。
キューブ検索のパフォーマンス比較 （検索時間）
140
検索にかかった時間 （ 相対値）
5.1.4
122.4
114.3
120
100
100.0
2000
80
61.2
2005
60
40
2008
26.5
20
20.4
0
Excel 2003
Excel 2007
57
2000
2005
2008
100
122.7
26.6
SQL Server 2000 との差
-
-22.7
73.4
SQL Server 2005 との差
-
-
96.1
61.3
114.5
20.4
SQL Server 2000 との差
-
-53.2
40.9
SQL Server 2005 との差
-
-
94.1
Excel 2003
Excel 2007
結果は、Excel 2003 での SQL Server 2000 のときの結果を 100 として、相対値で示してい
ます。
Excel 2003 では、SQL Server 2000 と比較すると、SQL Server 2008 では 26.6 と、73.4%
の性能差が現れたことを確認することができました。
また、Excel 2007 では、SQL Server 2000 は 61.3 であるのに対して、SQL Server 2008 で
は 20.4 と、40.9 の差（66.7% の性能差）を確認することができました。SQL Server 2008 で
は、SQL Server 2005 以前と比べて、MDX 処理や CPU、メモリをより効率的に使用できる
ようになったことが性能結果に反映されているものと考えられます。
58
5.1.5
OLTP パフォーマンスの比較
OLTP 環境での高負荷テスト実施時のパフォーマンス結果は、次のとおりです。
OLTP 処理性能の比較 （トランザクション処理数）
300
262.1
267.7
250
相対値
200
150
100
100.0
50
0
2000
2005
2008
2000
2005
2008
100
262.1
267.7
SQL Server 2000 との差
-
162.1
167.7
SQL Server 2005 との差
-
-
5.6
トランザクション処理数（相対値）
結果は、SQL Server 2000 でのトランザクション処理数（1 秒あたりのトランザクション実行
数）を 100 とした場合の相対値で示しています。
SQL Server 2005 と SQL Server 2008 では、SQL Server 2000 と比べて、ともに 160% 以
上の性能差が現れたことを確認することができました。また、SQL Server 2005 と SQL
Server 2008 では、ほぼ同等の性能が得られたことも確認することができました。
この検証結果の理由として、SQL Server 7.0 から実装されたユーザー モード スケジューラ
(UMS) が、SQL Server 2005 で SQL OS としてアーキテクチャが改善されたため、より効
率の良いスレッド スケジューリングが行われるようになったと考えられます。
5.1.6 バックアップ圧縮のパフォーマンス比較
バックアップを実行したとき（圧縮なし／有り）のパフォーマンス結果は、次のとおりです。
59
バックアップ圧縮のパフォーマンス比較
実行時間 （ 相対値）
120
100.0
100
105.3
80
60
34.1
40
20
0
2005
2008（非圧縮）
2008（圧縮）
2005
2008
2008
(圧縮なし) （圧縮有り）
圧縮なし
との差
バックアップ実行時間（相対値）
100.0
105.3
34.1
71.2
バックアップ ファイル サイズ
7.6 GB
7.6 GB
2.4 GB
5.2 GB
結果は、SQL Server 2005 での実行時間を 100 とした場合の相対値で示しています。
SQL Server 2008 の圧縮なしと圧縮有りでは、71.2 もの差（65.6%の性能差）を確認するこ
とができました。また、SQL Server 2005 と SQL Server 2008 では、ほぼ同等の性能が得ら
れたことも確認することができました。
バックアップ ファイルのサイズでは、圧縮なしと圧縮有りでは、5.2GB もの差となり、圧縮
率は 67.9%（3 分の 1 以下のサイズ）となりました。
バックアップ処理時は、ディスク I/O 処理がメインになるため、バックアップ圧縮によって、
ディスク I/O 量（ファイル サイズ）を減らすことで、実行時間の短縮が実現されました。ま
た、圧縮有りでは、圧縮なしの場合と比べて、圧縮を実行している分、CPU 利用率を多く使
用していることも確認することができました（I/O 負荷と CPU 負荷のトレードオフ）。
5.1.7 データ パーティションのパフォーマンス比較
ここでは、データ パーティション環境で、クエリを実行したときのパフォーマンス測定結果
について説明します。発行したクエリは、次のとおりです。
SELECT s.小分類コード, s.小分類名称, SUM(p.販売数量) AS '売上合計数量'
FROM ＰＯＳ実績パーティション p
INNER JOIN 商品 s ON p.アイテムコード = s.商品コード
WHERE p.日付 BETWEEN 'YYYYMMDD' AND 'YYYYMMDD'
GROUP BY s.小分類コード, s.小分類名称
ORDER BY s.小分類コード
クエリで指定している「ＰＯＳ実績パーティション」テーブル内のデータ件数は 2 億件、1 つ
のパーティションには約 1,200 万件のデータが格納され、月単位で 19 個のパーティションを
60
作成しています。
WHERE 句で指定している日付の条件は、次のように変更して 4 パターン実行しました。
パターン
日付の範囲
クエリ 1
2000年 2月 1日～2000年 2月29日
1つのパーティションが対象
（2月の全データが対象）
クエリ 2
2000年 1月31日～2000年 2月29日
2つのパーティションが対象
（1月 1件 と 2月の全データが対象）
クエリ 3
2000年 1月31日～2000年 3月 1日
3つのパーティションが対象
（1月 1件、2月の全データ、3月の 1件分が対象）
クエリ 4
2000年 1月31日～2000年 3月31日
3つのパーティションが対象
（1月 1件、2月／3月の全データが対象）
パフォーマンス測定結果は、次のとおりです。
データ パーティションのパフォーマンス比較 （検索時間）
700
573.2
検索にかかった時間 （ 相対値）
600
491.4
481.9
500
2005
400
276.3
300
200
100
100.0 96.8
2008
174.2
138.0
0
クエリ1
クエリ
クエリ
クエリ
クエリ
1
2
3
4
クエリ2
クエリ3
2005
100
481.9
491.4
573.2
2008
96.8
138.0
174.2
276.3
クエリ4
差
差(%)
3.2
343.9
317.2
296.8
3.2%
71.4%
64.6%
51.8%
結果は、クエリ 1 の SQL Server 2005 での実行時間を 100 とした場合の相対値として示し
ています。
1 つのパーティションのみを対象としたクエリ 1 に関しては、SQL Server 2005 と SQL
Server 2008 で性能差は現れませんでしたが、2 つ以上のパーティションを対象としたクエリ
2～4 に関しては、SQL Server 2005 よりも SQL Server 2008 のほうが性能が良い（51.8%
～71.4%の性能差）ことを確認することができました。
SQL Server 2008 では、複数パーティションに対するクエリで、パラレル処理（複数 CPU を
利用した並列処理）がサポートされるようになったため、このような顕著な性能差を確認でき
61
たと考えられます。
5.1.8 データベース ミラーリングのパフォーマンス比較
データベース ミラーリングでは、10 万件のデータ更新（UPDATE ステートメントの実行）
を、コミットのタイミングを変更して、パフォーマンスを測定しました。結果は、次のとおり
です。
データベース ミラーリングのパフォーマンス比較
1,200
1,115.7
1,066.1
実行時間 （ 相対値）
1,000
800
600
2005
2008
400
239.7 206.6
200
100.0
57.9
0
10 万件で Commit
（コミット 1回）
10 件で Commit
（コミット 10,000回）
1 件で Commit
（コミット 10万回）
2005
2008
差
差(%)
100
57.9
42.1
42.1%
10 件で Commit（コミット 10,000回）
239.7
206.6
33.1
13.8%
1 件で Commit（コミット 10万回）
1,115.7
1,066.1
49.6
4.4%
10 万件で Commit（コミット 1回）
結果は、コミットが 1 回のときの SQL Server 2005 での結果を 100 として相対値で示して
います。
コミット回数を変更しても、いずれもケースでも SQL Server 2005 と SQL Server 2008 で
は、性能差が現れたことを確認することができました。この傾向は、コミット回数が少ないほ
ど、大きくなり、コミット回数が 1 回だけの場合は 42.1%、コミット回数が 10,000 回の場
合は 13.8%、コミット回数が 1 回の場合は 4.4% の性能差となりました。
SQL Server 2008 からは、ログの転送時に、ログを圧縮する機能が追加されたため、このよ
うな顕著な性能差を確認できたと考えられます。コミット回数が少ないほど、速度差が現れた
のは、1 回あたりのログ転送量が増えたために、1 回あたりの圧縮対象のデータ量が増えて、
圧縮操作をまとめて行えるようになったと考えられます。
なお、10 万回コミットしたとき（1 件ずつコミットしたとき）のデータベース ミラーリング
関連のパフォーマンス カウンタの値は、次のとおりです。
62
カウンタ
採取サーバ
Transaction Deley
Log Bytes Sent/sec
Log Bytes Receive/sec
Log Compressed Bytes Sent/sec
Log Compressed Bytes Rcvd/sec
プリンシパル
プリンシパル
ミラー
プリンシパル
ミラー
2005
702
792,440
799,428
-
2008
25
845,945
825,630
491,358
479,983
トランザクションの遅延（Transaction Deley）が SQL Server 2005 よりも SQL Server 2008
のほうが少ないこと、Log Bytes Sent/sec および Log Bytes Receive /sec（1 秒あたりのログ送受
信量）ともに SQL Server 2008 のほうが多いことからも、性能差の要因を確認することができま
す。
63
5.2
プラットフォーム別パフォーマンス検証
5.1 では、共通のサーバー上で SQL Server 2000／2005／2008 のパフォーマンスを計測し比
較しました。5.2 では各バージョンが出荷された時期に選択された一般的なサーバーと OS の
組み合わせの上に同一のデータベースを同一のストレージ構成に配置して データベースエン
ジンによる集計処理とデータ ロードの性能、および Analysis Services キューブに対する処理
と検索といった BI 操作の性能を計測しています。
5.2.1 集計処理パフォーマンス検証の環境と手順について
集計処理パフォーマンスの評価で使用したサーバー構成は、次のとおりです。
サーバー構成
SQL Server 2000 でのみ awe enabled オプションを使用した以外、各 DB サーバーの設定は
既定のままで検証しました。
ストレージ構成
データベースの名前は、
「tpch1gh」でサイズは、
「19 G」です。ストレージは各サーバーで同
じ RAID0 構成に共通のドライブ文字を割り当て、SQL Server 2000 環境で作成したデータベ
ースをバックアップし、各サーバーに復元する方法で同一のデータベース ファイル構造を配
置しています。
64
データベースの配置
パフォーマンスの検証方法
集計処理のための 22 種類のアドホック クエリをクライアント コンピュータからシリアルに
連続して発行し、すべてのクエリが完了するまでの時間とその間の平均 CPU 使用率とプロセ
ッサ キュー長を計測しました。
テストケースとして同時実行ユーザー数を 1 から始めて 1 接続ずつ増やし、4 接続までの検証
を行いました。複数の接続でクエリを実行する場合、クエリの実行順序をランダムに変更しま
した。
各テスト パターンを 3 回ずつ実行し、平均値を取得しました。
65
5.2.2 集計処理パフォーマンス検証の結果
3 種類のプラットフォームに対する 4 つのテストケースでパフォーマンス測定した検証結果は、
以下のとおりです。
下表では、SQL Server 2000 と SQL Server 2005 および SQL Server 2008 でのクエリ実行
時間の差とその比率を算出しています。いずれも同時実行数を増やすとクエリ完了までに要す
る時間がリニアに増えています。同時実行数を 4 にした場合、Windows Server 2003 と SQL
Server 2005 の組み合わせは、Windows 2000 Server と SQL Server 2000 の組み合わせに対
して 79.21% の実行時間の短縮が確認できました。
更に Windows Server 2008 と SQL Server 2008 の組み合わせで同時実行数を 4 にした場合、
94.96% もの実行時間の短縮が確認できました。
また、SQL Server 2000 の実行時間に対して SQL Server 2005 および SQL Server 2008 で
は、同時実行数が増加するにつれて差が拡大していることが確認できます。これにより、SQL
Server 2005 および SQL Server 2008 の方がより効率の良い同時実行処理を行っていること
が想定されます。
66
以下のグラフは、3 種類のプラットフォームに対する 4 つのテストケースでパフォーマンス測
定した際の平均 CPU 使用率を示しています。SQL Server 2005 および SQL Server 2008 で
は同時実行数の増加に伴い平均 CPU 使用率も上がっていますが、SQL Server 2000 では、同
時実行数が増えても平均 CPU 使用率が 80% 前後で推移していることが分かります。
これらの検証結果の理由として、SQL Server 7.0 から実装されたユーザーモード スケジュー
ラ (UMS) が、SQL Server 2005 で SQL OS としてアーキテクチャが改善されたため、より
効率の良いスレッド スケジューリングが行われるようになったと考えられます。
67
第 6 章 まとめ
この実証プロジェクトをとおして、次のことを確認することができました。
RFP 要件に対するまとめ

移行およびアップグレードにあたって、SQL Server のすべての機能（データベース エン
ジン、DTS、Integration Services、Analysis Services、Reporting Services）について、
以下の項目を満たしていることを確認することができました。
・現行のシステム（旧バージョンの SQL Server）と同等以上の性能の実現
・できる限り現行のシステムへ修正を加えずに移行／アップグレードを実施
・システム移行後の安定稼働の実現

移行検証では、SQL Server の各機能について、移行手法を検証し、安全に移行できること
を確認できました。
また、移行の際に、複数の実装方法がある場合は、それぞれの実装方法を比較検証したこ
とにより、最適な実装方法を認識することができ、移行指針および手法を確立し、移行計
画の策定が可能になりました。
データベース移行（マイグレーション）に関するまとめ

旧バージョン（SQL Server 2000 または SQL Server 2005）のデータベースを SQL
Server 2008 へ移行するにあたって、最も確実な方法は、バックアップ／復元機能を利用
する方法であることを確認できました。

SQL Server 2008 へのクラスタ環境のインストール手順は、SQL Server 2005 までの手順
から変更になりました（ローリング アップグレードへ対応するために変更になりました）。
クラスタ環境においても、データベースの移行手順は、通常のデータベースの移行とまっ
たく同様に行えることを確認できました（クラスタ環境のための特別な操作は必要ありま
せん）。

SQL Server 2005 のデータ パーティション環境は、アタッチ／デタッチまたはバックアッ
プ／復元でデータベースを移行することで、SQL Server 2008 へ移行できることを確認で
きました。

SQL Server 2005 のデータベース ミラーリング環境は、バックアップ／復元でデータベ
ースを移行後、ミラーリングを再設定することで、SQL Server 2008 へ移行できることを
確認できました。
パフォーマンス検証結果に関するまとめ

今回のパフォーマンス検証結果からは、OLTP 環境での高負荷テスト時には、SQL Server
2000 と SQL Server 2008 では、167.7% の性能差が現れたことを確認することができま
した。この結果は、SQL Server 7.0 から実装されたユーザー モード スケジューラ (UMS)
68
が、SQL Server 2005 で SQL OS としてアーキテクチャが改善されたため、より効率の
良いスレッド スケジューリングが行われるようになったと考えられます。

今回のパフォーマンス検証結果からは、データ パーティションに対する複数パーティショ
ンをまたがったクエリの場合には、SQL Server 2005 と SQL Server 2008 では、51.8%
～71.4% の性能差が現れたことを確認することができました。SQL Server 2008 では、複
数パーティションにまたがるクエリで、パラレル処理（複数 CPU を利用した並列処理）
がサポートされるようになったため、このような顕著な性能差を確認できたと考えられま
す。

今回のパフォーマンス検証結果からは、データベース ミラーリング環境において、SQL
Server 2005 と SQL Server 2008 では、4.4%～42.1% の性能差が現れたことを確認する
ことができました。SQL Server 2008 からは、ミラーリングのログ転送時に、ログを圧縮
する機能が追加されたため、このような顕著な性能差を確認できたと考えられます。

今回のパフォーマンス検証結果からは、SQL Server 2008 からの新機能である「バックア
ップ圧縮」を利用した場合のバックアップ時間は、圧縮なしの場合と比べて 67.6% の性能
差が現れたこと確認できました。また、ファイル サイズは、7.6GB から 2.4GB となり、
圧縮率は 67.9%（3 分の 1 以下のサイズ）となりました。
DTS、Integration Services の移行に関するまとめ

SQL Server 2008 には、SQL Server 2000 の DTS（データ変換サービス）パッケージを
SSIS パッケージへ変換できる「パッケージ移行ウィザード」が用意されているので、基本
的な DTS パッケージを SSIS パッケージへ変換できることを確認できました（ただし、
一部のタスクは変換することができません。変換できないタスクは、アップグレード アド
バイザでチェックすることが可能です）。

SQL Server 2008 には、DTS パッケージを実行するための「DTS 2000 パッケージ実行
タスク」が含まれているので、基本的なパッケージはそのまま実行できることも確認でき
ました。
ただし、「DTS 2000 パッケージ実行タスク」では、一部実行できないタスク（動的プロ
パティ タスクや Analysis Services 処理タスクなど）もあるため、これらに関しては、
Integration Services（SSIS）パッケージとして作成し直す必要があります。したがって、
基本的には SSIS パッケージへの変換または作り直しを実施し、移行期間や移行対象ボリ
ュームによっては、「DTS 2000 パッケージ実行タスク」を使用した暫定対応を検討する
ようにします。

SQL Server 2008 の Integration Services は、SQL Server 2005 の Integration Services
からアーキテクチャがほとんど変更されていないため、容易に移行ができることを確認で
きました。
69
Analysis Services、Reporting Services の移行に関するまとめ

Analysis Services は、SQL Server 2000 と SQL Server 2008 で大きくアーキテクチャが
変更されていますが、「Analysis Services 移行ウィザード」を利用すれば、OLAP キュー
ブを移行できることを確認できました。ただし、移行されたキューブは、SQL Server 2008
へ最適化されているわけではないので、最適化処理を実施しておく必要がありました。

SQL Server 2008 の Analysis Services は、SQL Server 2005 の Analysis Services から
アーキテクチャがほとんど変更されていないため、容易に移行ができることを確認できま
した。

今回のパフォーマンス検証結果からは、移行後の最適化処理を実施した OLAP キューブは、
SQL Server 2000 と比較して、キューブ処理で 46.6% の性能差、キューブ検索（Excel ク
ライアントからのアクセス）では、73.4% の性能差が現れたことを確認することができま
した。

Reporting Services は、内部使用しているデータベースが SQL Server 2000 と SQL
Server 2005、SQL Server 2008 のすべてのバージョンで互換性があるので、容易にアップ
グレードできることを確認できました。
インプレース アップグレードに関するまとめ

クラスタリングの環境において、システムをダウンさせることなく、インプレース アップ
グレードができることを確認しました。

ログ配布の環境において、SQL Server 2000, SQL Server 2005 から共に、フェールオーバ
ーを併用する手順とフェールオーバーを併用しない手順の両方でインプレース アップグ
レードができることを確認しました。

データベース ミラーリングの環境において、ミラー サーバーからアップグレードを行い、
手動でフェールオーバーを行い、もう一方のサーバーのアップグレードを行い、安全にシ
ステムがアップグレードが行われることを確認しました。
70
付録 A ソリューション内にある技術解説（移行手順）
この章では、第 3 章で説明した SQL Server 2008 でのソリューションの技術について、具体的な実装
手順を説明します。以下の操作手順を説明します。
A.1
A.1
SQL Server 2008 アップグレード アドバイザの利用手順
A.2
SQL Server 2000 から SQL Server 2008 への移行（マイグレーション）手順
A.3
SQL Server 2005 から SQL Server 2008 への移行（マイグレーション）手順
SQL Server 2008 アップグレード アドバイザの利用手順
ここでは、SQL Server 2008 アップグレード アドバイザ（以下、アップグレード アドバイ
ザ）の利用手順を説明します。
アップグレード アドバイザのインストール方法
アップグレード アドバイザは、次のように SQL Server 2008 のインストーラ（setup.exe）
からインストールすることが可能です。
71
アップグレード アドバイザは、Windows XP SP3（Service Pack 3）や Windows Vista SP2 な
どのクライアントへインストールして、リモート マシンから移行チェックを行うこともでき
ますが、Reporting Services に関する移行チェックを行う場合は、ローカル マシン（移行元
の SQL Server マシン）へインストールしておく必要があります。
また、アップグレード アドバイザのインストールにあたっては、以下のコンポーネントが必
須になります。

Windows Installer 4.5
ダウンロード URL
http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=5a58b56f-60b6-441295b9-54d056d6f9f4

.NET Framework 2.0
ダウンロード URL
http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=0856EACB-4362-4B
0D-8EDD-AAB15C5E04F5

SQL Server 2000 の DSO（Analysis Services の移行チェックを行う場合に必須）
DSO（Decision Support Objects）のインストール方法は、「A.1.3 Analysis Services
の移行手順」で説明しています。
なお、アップグレード アドバイザは、SQL Server 2008 Feature Pack の一部としても提供さ
れています（次の URL からダウンロードして、インストールすることができます）
。

SQL Server 2008 用 Feature Pack - 2008 年 8 月
http://www.microsoft.com/downloads/details.aspx?FamilyId=C6C3E9EF-BA29-4A43-8D69-A2BED
18FE73C&displaylang=ja
アップグレード アドバイザの利用手順
アップグレード アドバイザを利用する手順は、次のとおりです。
1.
アップグレード アドバイザの起動
アップグレード アドバイザは、次のように［スタート］メニューから起動します。
72
2.
分析ウィザードの起動
アップグレード アドバイザが起動したら、
［アップグレード アドバイザ分析ウィザードの
開始］をクリックして、分析ウィザードを起動します。
3.
分析対象のコンポーネントの選択
［SQL Server コンポーネント］ページでは、分析（移行可否のチェック）を行いたいサー
バーの名前（SQL Server のインスタンス名ではなく、SQL Server がインストールされて
いるマシンの名前）を指定し、分析対象としたいコンポーネントを選択します。
分析対象のサーバー名を入力
（インスタンス名ではない）
分析対象としたい
コンポーネントの選択
データベース エンジン機能を分析したい場合は、
「SQL Server」をチェックし、Analysis
Services を分析したい場合は「Analysis Services」
、SQL Server 2000 の DTS を分析し
たい場合は「データ変換サービス」
、SQL Server 2005 の Integration Services を分析し
たい場合は「Integration Services」をチェックします。また、前述したように、Reporting
73
Services を分析するには、ローカル マシン（移行元の SQL Server マシン）上でアップ
グレード アドバイザを実行する必要があります。
4.
分析対象のデータベースの選択
［接続パラメータ］ページでは、分析を行いたい SQL Server のインスタンス名を選択（既
定のインスタンスの場合は MSSQLSERVER を選択）し、［SQL Server のパラメータ］
ページでは、分析を行いたいデータベースを選択します。
ここで選択したデータベースに対しては、データベース内のオブジェクト（ストアド プロ
シージャやビューなど）が移行にあたって問題がないかどうかがチェックされます。
このページでは、次のように［トレース ファイルを分析する］をチェックして、SQL Server
Profiler で取得したトレース ファイル（拡張子 .trc）を指定することも可能です。
トレース ファイルを指定すれば、トレース内の Transact-SQL ステートメントに対しても
移行にあたって問題がないかどうかをチェックできるようになります。
また、
［SQL バッチ ファイルを分析する］をチェックして、Transact-SQL ステートメン
トを記述したファイル（拡張子 .sql）を指定することも可能です。この場合は、ファイル
内のステートメントに対しても移行チェックを行うことができます。
5.
分析対象のインスタンスの選択
74
分析対象のコンポーネントとして、Reporting Services と Analysis Services を選択して
いる場合は、次の画面が表示され、分析対象としたいインスタンスを選択します。
6.
DTS パッケージの選択
分析対象のコンポーネントとして、データ変換サービス（SQL Server 2000 の DTS）を選
択している場合は、次の画面が表示されます。
SQL Server 2000（msdb）
へ格納されたパッケージを対象
任意の構造化ストレージ
ファイル（.dts）を対象
［サーバーの DTS パッケージを分析する］をチェックした場合は、SQL Server 2000
（msdb データベース）へ格納された DTS パッケージが分析対象になり、
［DTS パッケー
ジ ファイルを分析する］をチェックした場合は、任意の構造化ストレージ ファイル（拡
張子 .dts）を指定して分析対象にすることができます。
7.
分析の実行
［アップグレード アドバイザの設定を確認］ページでは、［実行］ボタンをクリックする
と、分析が実行されます。
75
8.
分析レポートの表示
分析が完了すると、
［レポートの開始］ボタンが表示されるので、これをクリックして、分
析結果を確認することができます。
レポートは、デフォルトでは、
［インスタンスまたはコンポーネント］で「Analysis Services」
が選択され、Analysis Services の分析結果が表示されます。
データベース エンジンの分析結果を表示したい場合は、
「SQL Server」を選択します。
76
レポートでは、次のように「影響を受けるファイルを表示します」をクリックすると、ど
のオブジェクト（ストアド プロシージャやビューなど）によって問題が発生しているのか
や、問題の発生しているトレース ファイル名やバッチ ファイル名を確認することができ
ます。
影響を受けるオブジェクト（ストアド プロ
シージャやビューなど）や、トレース ファ
イル名、バッチ ファイル名を確認可能
また、レポートでは、
「この問題と解決方法についての詳細を参照します」をクリックする
と、アップグレード アドバイザのヘルプが起動して、詳細を確認することができます。
77
このヘルプには、移行に関する問題が一覧されているので、ひと通りの項目を一読してお
くことをお勧めします。
このようにアップグレード アドバイザを利用すると、移行に関する問題を事前にチェック
することができるので、大変便利です。特にトレース ファイルやバッチ ファイルを分析
できる点が便利です。トレース ファイルは、SQL Server Profiler（プロファイラ）で普通
にキャプチャしたものを利用できるので、事前に移行対象のアプリケーションを起動して、
一連の操作を SQL Server Profiler でトレースしておけば、そのアプリケーションが移行
にあたって問題が発生しないかどうかをチェックできるようになります。
78
A.2
SQL Server 2000 から SQL Server 2008 への移行手順
ここでは、SQL Server 2000 から SQL Server 2008 への移行（マイグレーション）手順とし
て、次の流れで説明します。
章項目
詳細項目
A.2.1
1. データベースの移行手順
(1) デタッチ／アタッチによる移行手順
データベース エンジンの移行手順
(2) バックアップ／復元による移行手順
(3) データベース コピー ウィザードでの移行手順
2. クラスタ環境の構築手順
A.2.2
1. パッケージ移行ウィザードによる移行手順
DTS の移行手順
2. DTS 2000 パッケージ実行タスクによる移行手順
A.2.3
1. Analysis Services 移行ウィザードによる移行手順
Analysis Services の移行手順
2. OLAP キューブ処理の移行手順
3. クライアント ツールの変更手順
A.2.4
1. レポート サーバー データベースの移行手順
Reporting Services の移行手順
2. BIDS を利用したレポートの移行手順
3. レポート マネージャによるレポートの移行手順
A.2.1 データベース エンジンの移行手順
まずは、SQL Server 2000 のデータベース エンジンを SQL Server 2008 へ移行する手順と
して、次の 6 つを説明します。
A.2.1.1 データベースの移行手順
A.2.1.2 クラスタ環境の構築手順
A.2.1.1
データベースの移行手順
SQL Server 2000 のデータベースを SQL Server 2008 上へ移行する手順として、次の 3 つ
の方法の具体的な手順を説明します。

デタッチ／アタッチ

バックアップ／復元

データベース コピー ウィザード
この 3 つは、いずれの方法でも、SQL Server 2008 の管理ツールである Management Studio
を利用して、SQL Server 2000 へ接続し、操作を実行することが可能です。
79
それぞれの操作手順は、次のとおりです。
(1) デタッチ／アタッチによるデータベースの移行手順
デタッチ／アタッチによるデータベースの移行は、次のように操作します。
1.
SQL Server 2000 上のデータベースのデタッチ
最初に、移行元となる SQL Server 2000 上のデータベースをデタッチします。デタッチは、
SQL Server 2000 上の Enterprise Manager から操作することも可能ですが、次のように
SQL Server 2008（移行先）上の Management Studio から SQL Server 2000 へ接続し
て、該当データベースを右クリックして、［デタッチ］をクリックしても行うことができま
す。
2.
SQL Server 2000 上のデタッチしたファイルを新規サーバーへコピー
次に、手順 1 でデタッチしたデータベースのデータ ファイル（.mdf／.ndf）およびトラン
ザクション ログ ファイル（.ldf）を新規サーバーへコピーします。この操作は、Windows
エクスプローラ上から行います。
80
3.
コピーしたファイルを SQL Server 2008 へアタッチ
次に、手順 2 でコピーしたファイルを、移行先となる SQL Server 2008 インスタンス上
へアタッチします。アタッチ操作は、SQL Server 2008 の Management Studio から［デ
ータベース］フォルダを右クリックして、［アタッチ］をクリックします。
［データベースのアタッチ］ダイアログでは、次のように［追加］ボタンをクリックして、
コピーしたデータ ファイル（.mdf）を選択します。
以上で、デタッチ／アタッチによるデータベースの移行が完了です。
(2) バックアップ／復元によるデータベースの移行手順
バックアップと復元機能を利用したデータベースの移行手順は、次のとおりです。
1.
SQL Server 2000 のデータベースを完全バックアップ
まずは、SQL Server 2000 上の Enterprise Manager または SQL Server 2008 上の
Management Studio から、移行元となる SQL Server 2000 へ接続し、データベースの完
81
全バックアップを取得します。完全バックアップは、次のように該当データベースを右ク
リックして、
［タスク］メニューの［バックアップ］をクリックして取得できます。
2.
SQL Server 2000 で取得した完全バックアップを新規サーバーへコピー
次に、手順 1 で取得した完全バックアップ ファイルを新規サーバーへコピーします。この
操作は、Windows エクスプローラ上から行います。
3.
SQL Server 2008 インスタンスへバックアップを復元
次に、手順 2 で新規サーバーへコピーしたバックアップ ファイルを SQL Server 2008 上
で復元します。復元は、
［データベース］フォルダを右クリックして、［データベースの復
元］をクリックして行うことができます。
復元するデータベース
の名前を入力
チェック
［デバイスから］をチェックし
てバックアップ ファイルを選択
「データベース xx の復元が正常に完了しました」とダイアログが表示されれば、バック
82
アップ／復元によるデータベースの移行が完了です。
(3) データベース コピー ウィザードによるデータベースの移行手順
データベース コピー ウィザードを利用したデータベースの移行手順は、次のとおりです。
1.
新規サーバーでデータベース コピー ウィザードの起動
最初に、新規サーバー（移行先となる SQL Server 2008）上でデータベース コピー ウィ
ザードを起動します。データベース コピー ウィザードを起動するには、次のように該当
データベースを右クリックして、［タスク］メニューの［データベースのコピー］をクリッ
クします。
2.
転送元へ SQL Server 2000 のデータベースを指定
データベース コピー ウィザードでは、
［転送元サーバーの選択］ページで、転送元となる
SQL Server 2000 のインスタンスを指定します。
83
3.
コピー先へ SQL Server 2008 のインスタンスを指定
［転送先サーバーの選択］ページでは、コピー先となる SQL Server 2008 を指定します。
4.
転送方法の選択
［転送方法の選択］ページでは、転送方法として「デタッチ後、アタッチする方法を使用
する」を選択します（これにより、デタッチ／アタッチによるデータ移行が実施されます）。
5.
移行対象データベースの選択
［データベースの選択］ページでは、対象データベースの「コピー」列をチェックします。
84
6.
転送先データベースの構成
［転送先データベースの構成］ページでは、転送先のデータベースの作成先となるパスや
データベース名の変更を行うことができます（任意）。
7.
ログイン アカウントの転送
［サーバー オブジェクトの選択］ページでは、システム データベース内へ格納される情
報をコピーするかどうかを設定できます（任意）
。
85
8.
共有パスの指定
［転送元のデータベース ファイルの場所］ページでは、次のようにデータベース ファイ
ル（.mdf／.ldf）が格納されているフォルダに対する共有パスを指定し、［パッケージの構
成］ページでは、設定を保存するパッケージの名前を任意に設定します。
9.
実行
［パッケージのスケジュール確認］ページでは、［すぐに実行する］を選択し、［完了］ペ
ージでは［完了］ボタンをクリックすると、次のようにデータベースのコピー（移行）が
開始されます。
コピーが完了すると、すべての［状態］が「成功」と表示されます。
86
A.2.1.2
クラスタ環境の移行手順
次に、SQL Server 2000 上で構築されたクラスタ環境を SQL Server 2008 上へ移行（マイグ
レーション）する手順を説明します。これを行うには、まず SQL Server 2008 上へクラスタ
環境をインストールし、その後、A.2.1.1 で説明したデータベースの移行手順のいずれかを利
用して、データベースを移行します。
なお、クラスタ環境を、移行ではなくアップグレード（インプレース アップグレード）する
方法については、付録 B で説明しています。
SQL Server 2008 へのクラスタ環境のインストール手順は、SQL Server 2005 までの手順と
は異なります。SQL Server 2005 までは、クラスタ ノードを一括でインストールしていまし
たが、SQL Server 2008 からはノードごとにインストールするように変更されました（これ
はローリング アップグレードを実現するための変更です）。
SQL Server 2008 でクラスタ環境をインストールするには、最初のインストール ノードでク
ラスタ リソースを作成し、他のノードへはインストーラからクラスタ リソースへ自らを追加
することによってインストールを行います。
以降では、SQL Server 2008 でのクラスタ構成でのインストール手順について説明します。
(1) 最初のノードへのインストール
最初のノードへインストールする手順は、次のとおりです。
1.
SQL Server 2008 の新規インストール（フェール オーバー クラスタの作成）
最初のノードへ SQL Server 2008 をインストールするには、インストール画面で次のよう
に「SQL Server フェール オーバークラスタの新規インストール」をクリックして、イン
ストール ウィザードを開始します。
87
2.
セットアップ サポート ルール
［セットアップ サポート ルール］ページでは、ノード１のシステムが SQL Server 2008
をインストールするのに必要な条件を満たしているかがチェックされます。チェックの完
了後、次のように［詳細を表示／非表示］ボタンをクリックすることで、詳細結果を確認
することができます。
3.
機能の選択
［機能の選択］ページでは、インストールするコンポーネントおよびインストール場所を
指定します（インストールしたい項目のチェック ボックスをチェックします）。
4.
仮想 SQL Server の使用するネットワークの設定
［インスタンスの構成］ページでは、
［SQL Server のネットワーク名］へ、仮想 SQL Server
88
の使用するネットワーク名を設定します。
5.
必要なディスク領域の確認
［必要なディスク領域］ページでは、内容を確認して、次のページへ進みます。
6.
仮想 SQL Server へ使用するクラスタ グループの設定
［クラスタ リソース グループ］ページでは、仮想 SQL Server をインストールするクラ
スタ グループ名を指定します。
89
7.
仮想 SQL Server クラスタ グループに登録するディスクの設定
SQL Server のクラスタ グループで使用するディスクを指定します。
下欄のクラスタ グループで使用可能なディスクへは、緑の
がマークされているので、
上欄で SQL Server に使用するディスクのチェックボックスをチェックします。
8.
IP アドレスの設定
［クラスタ ネットワークの構成］ページでは、
［IPv4］をチェックし、
［アドレス］へ仮想
SQL Server の使用する IP アドレスを設定します。
90
9.
リモート アカウントの設定
［クラスタのセキュリティ ポリシー］ページでは、クラスタ システムのすべてのノード
に有効な管理者グループを指定します。
［データベース エンジン ドメイン グループ］へは、クラスタ システムのすべてのノー
ドに有効なデータベース エンジンを動作させるためのサービス アカウントが所属するド
メイン グループを指定し、
［SQL Server エージェント ドメイン グループ］へは、クラス
タ システムのすべてのノードに有効な SQL Server エージェントを動作させるためのサ
ービス アカウントが所属するドメイン グループを指定します。
10. サーバーの構成／サービス アカウント
［サーバーの構成］ページの［サービス アカウント］タブでは、SQL Server を実行する
91
サービス アカウントを指定します。
［すべての SQL Server サービスで同じアカウントを使用する］ボタンをクリックした場
合は、SQL Server Agent と SQL Server Database Engine（既定のインスタンス）、SQL
Server Integration Services のすべてのサービスを同一アカウントで実行させることがで
きます。
［アカウント名］へは、実行するユーザーを「ドメイン名¥ユーザー名」の形式で
入力し、
［パスワード］へは上記ユーザーのパスワードを入力します。
なお、サービスごとにアカウントを設定したい場合は、各サービスの［アカウント名］と
［パスワード］をそれぞれ設定します。
フ ル テ キ ス ト 検 索 機 能 を イ ン ス ト ー ル す る 場 合 は 、［ SQL Full-text Filter Daemon
Launcher］サービスの［アカウント名］と［パスワード］をドメイン ユー-ザーへ設定し
ます。
11. 照合順序の変更（必要な場合）
［サーバーの構成］ページの［照合順序］タブでは、SQL Server の照合順序を設定するこ
とができます。照合順序には、移行元の SQL Server 2000 と同じ照合順序を設定するよう
にします。SQL Server 2008 のデフォルトの照合順序は、SQL Server 2000 のときと同様、
「Japanese_CI_AS」です。
照合順序を変更したい場合は、次のように［データベース エンジン］の［カスタマイズ］
ボタンをクリックします。
92
次のように、
［Windows 照合順序指定子と並べ替え順序］をチェックし、照合順序指定子
へ「Japanese」を選択し、
「アクセントを区別する」をチェックした場合が、デフォルトの
「Japanese_CI_AS」です。
12. データベース エンジンの構成／アカウントの準備
［データベース エンジンの構成］ページの［アカウントの準備］タブでは、SQL Server デ
ータベース エンジンのセキュリティ モードと管理者アカウントの設定を行います。
93
セキュリティモードとして、混合モード（SQL Server 認証または Windows 認証）を利
用する場合は、
「混合モード（SQL Server 認証 と Windows 認証）」をチェックします。
混合モードを使用する際は、
［パスワードの入力］および［パスワードの確認入力］へ sa ア
カウント（ビルトインの管理者アカウント）へのパスワードを入力します（推測されにく
い複雑なパスワードを設定するようにします）。
［SQL Server 管理者の設定］では、SQL Server の管理者アカウント（sysadmin ロール
のメンバー）へ設定したいユーザーを追加します。
［現在のユーザーの追加］ボタンをクリ
ックした場合は、現在インストールを実行しているユーザーが管理者アカウントとして追
加されます。
13. データベース エンジンの構成／データディレクトリ
［データベース エンジンの構成］ページの［データ ディレクトリ］タブでは、SQL Server
で使用するファイルの保存場所を設定します。
94
14. クラスタのインストール ルール
［クラスタのインストール ルール］ページでは、ノード 1 のシステムが SQL Server ク
ラスタをインストールするのに必要な条件を満たしているかを調査します。
［詳細を表示／
非表示］ボタンをクリックして、詳細結果を確認することができます
なお、FILESTREAM 修正プログラムで「不合格」となる場合は、Windows Server 2003 に
対して、KB（サポート技術情報）937444 から入手可能な修正プログラムを適用しておく
必要があります。
15. インストールの準備完了
［インストールの準備完了］ページでは、インストールの設定を確認します。
設定を確認後、これで良い場合は、
［インストール］ボタンをクリックします。
インストールの完了後、すべての状態が「成功」と表示されれば、最初のノードへのクラ
95
スタ構成の SQL Server 2008 のインストールが完了です。
(2) 2 番目以降のノードへのインストール
2 番目以降のノードへインストールする手順は、次のとおりです。
1.
SQL Server インストール センター
2 番目以降のノードをクラスタ環境へ追加するには、
［SQL Server インストール センター］
で次のように［SQL Server フェールオーバー クラスタにノードを追加します］をクリッ
クします。
2.
セットアップ サポート ルール
［セットアップ サポート ルール］ページでは、ノード 2 のシステムが SQL Server 2008
をインストールするのに必要な条件を満たしているか調査します。［詳細を表示／非表示］
ボタンをクリックして、詳細結果を確認することができます。
96
3.
続く、
［プロダクト キー］ページ、
［ライセンス条項］ページを過ぎると、
［フェールオー
バー クラスタ ノードの追加］セットアップが開始されます。
4.
セットアップ サポート ルール
［セットアップ サポート ルール］ページでは、ノード 2 のシステムが SQL Server フェ
ール オーバー クラスタを構成するのに必要な条件を満たしているかどうかを調査します。
［詳細を表示／非表示］ボタンをクリックして、詳細結果を確認することができます。
5.
クラスタノードの構成
［クラスタ ノードの構成］ページでは、ノード 2 を追加する仮想 SQL Server を確認し
ます。ノード 1 へインストールした仮想 SQL Server が選択されていることを確認し、
［次
へ］をクリックします。
6.
サービス アカウントの設定
97
［サービス アカウント］ページでは、SQL Server を実行するサービス アカウントのパス
ワードを入力します。
SQL Server Agent、SQL Server（既定のインスタンス）
、SQL Full-text Filter Daemon
Launcher の実行アカウントのパスワードを［パスワード］へ入力します。
7.
ノードの追加ルール
［ノードの追加ルール］ページでは、ノード 2 のシステムが SQL Server クラスタの追加
ノードとしての必要な条件を満たしているかを調査します。
［詳細を表示／非表示］ボタン
をクリックして、詳細結果を確認することができます。
8.
インストールの準備完了
［インストールの準備完了］ページでは、インストールの設定を確認します。
98
設定を確認後、これで良い場合は、
［インストール］ボタンをクリックします。
以上で SQL Server 2008 でのクラスタ環境の構築が完了です。この後、前述のデータベー
スの移行手順（バックアップ／復元、デタッチ／アタッチまたはデータベース コピー ウ
ィザード）にしたがって、SQL Server 2000 のデータベースを SQL Server 2008 へ移行
すれば、クラスタ環境でのデータベース移行が完了します（データベースの移行にあたっ
て、クラスタ環境用の特別な操作は不要です）。
99
A.2.2
DTS（データ変換サービス）の移行手順
次に、SQL Server 2000 上で作成した DTS（データ変換サービス）パッケージを SQL Server
2008 の Integration Services パッケージへ移行する手順として、次の 2 つの方法を説明し
ます。

パッケージ移行ウィザード

DTS 2000 パッケージ実行タスクを使用
(1) パッケージ移行ウィザードによるパッケージの移行手順
パッケージ移行ウィザードを利用して、パッケージを移行する手順は、次のとおりです。
1.
旧バージョンとの互換性コンポーネント（DTS 2000 ランタイム）のインストール
パッケージ移行ウィザードを利用するには、まず「SQL Server 2005 の旧バージョンとの
互換性コンポーネント」をインストールして、
「DTS 2000 ランタイム」をインストールし
ておく必要があります。
SQL Server 2005 の旧バージョンとの互換性コンポーネントは、SQL Server 2008 用の
Feature Pack として、次の URL で提供されています。

SQL Server 2008 用 Feature Pack - 2008 年 8 月
http://www.microsoft.com/downloads/details.aspx?FamilyId=C6C3E9EF-BA29-4A43-8D69-A2BED
18FE73C&displaylang=ja
2.
「SQLServer2005_BC.msi」をダウンロードして、実行すると、次のように DTS 2000 ラ
ンタイムをインストールすることができます。
DTS 2000
ランタイム
100
3.
パッケージ移行ウィザードの起動
DTS 2000 ラインタイムのインストール後は、パッケージ移行ウィザードを起動します。
パッケージ移行ウィザードを起動するには、Management Studio の［管理］フォルダを展
開して、
［レガシ］の［データ変換サービス］を右クリックし、［移行ウィザード］をクリ
ックします。
このウィザードは、SQL Server 2008 の BIDS（Business Intelligence Development
Studio）から起動することも可能です。この場合は、BIDS で Integration Services プロ
ジェクトを新しく作成し、ソリューション エクスプローラの［SSIS パッケージ］フォル
ダを右クリックして、
「DTS 2000 パッケージを移行」をクリックします。
これにより、パッケージの移行ウィザードが起動します。
4.
パッケージの移行元の選択
パッケージの移行ウィザードでは、パッケージの移行元を選択します。移行元には、
「SQL
Server」
（msdb データベース）または「構造化ストレージ ファイル」
（.dts）を選択する
101
ことができます。
ここでは、
「SQL Server」を選択し、移行元の SQL Server 2000 インスタンスの名前を指
定します。
5.
パッケージ ファイルの保存先の指定
［保存場所の選択］ページでは、移行後のパッケージの保存先を「SQL Server」
（msdb デ
ータベース）または「パッケージ ファイル」
（.dtsx）から選択することができます（BIDS
から起動した場合は、保存先を選択することはできず、DTSX ファイル固定になります）。
任意のフォルダ名
を指定
ここでは、
「DTSX ファイル」を選択し、フォルダ名へ任意のフォルダ パスを指定します。
6.
移行元 DTS パッケージの選択
102
次の［パッケージ一覧］ページでは、移行したい DTS パッケージを選択します。
7.
移行中のログ ファイルの指定
［ログ ファイルの指定］ページでは、移行中のログ ファイルの保存場所を指定します（任
意）
。
8.
設定内容の確認
設定内容を確認し、
［完了］ボタンをクリックすると、移行が始まります。
103
9.
移行後は、それぞれのパッケージについて、移行結果が表示されます。
移行できないタスクが含まれている場合には、このように［状態］が「停止」と表示され
ます。この場合は、
［レポート］ボタンをクリックして、［レポート表示］で詳細を確認す
ることができます。
以上で、パッケージの移行が完了です。移行できないタスク（Analysis Services 処理タス
クなど）については、前述のアップグレード アドバイザのヘルプで確認することが可能で
す。
(2) 「DTS 2000 パッケージ実行タスク」によるパッケージの移行手順
次に、
「DTS 2000 パッケージ実行タスク」を利用して、DTS パッケージを移行する手順を説
明します。手順は、次のとおりです。
1.
SQL Server 2000 の Enterprise Manager から DTS パッケージを開く
まずは、SQL Server 2000 の Enterprise Manager を起動して、移行元となる DTS パッ
ケージを開きます。
104
2.
パッケージを「構造化ストレージ ファイル」として保存
パッケージ デザイナが開いたら、「パッケージ」メニューの「名前を付けて保存」をクリ
ックして、構造化ストレージ ファイル（.dts）として保存します。
［DTS パッケージの保存］ダイアログでは、
［場所］を「構造化ストレージ ファイル」へ
変更し、パッケージの保存先を指定します（保存先は、任意のファイル名およびパスを指
定することができます）
。
3.
構造化ストレージ ファイル（.dts）を移行先サーバーへコピー
次に、手順 2 で保存した構造化ストレージ ファイル（.dts）を移行先サーバー上の任意の
場所へコピーします。この操作は、Windows エクスプローラから行います。
105
4.
Integration Services プロジェクトの新規作成
次に、SQL Server 2008 上で BIDS（Business Intelligence Development Studio）を起動
して、Integration Services プロジェクトを新しく作成します。
5.
「DTS 2000 パッケージ実行タスク」の配置
プロジェクトが開いたら、ツール ボックスから「DTS 2000 パッケージ実行タスク」をド
ラッグ&ドロップして、制御フロー内へ配置します。
6.
「DTS 2000 パッケージ実行タスク」の構成
配置した「DTS 2000 パッケージ実行タスク」をダブルクリックして、タスク エディタを
開き、
［Storage Location］を「構造化ストレージ ファイル」へ変更し、
［File］の［...］ボ
タンをクリックして、手順 3 でコピーしたファイルを選択します。
7.
［PackageName］では、
［...］ボタンをクリックして、［パッケージの選択］ダイアログ
から実行したいパッケージを選択します。
106
以上で、
［DTS 2000 パッケージ実行タスク］を使用したパッケージの作成（移行）が完了
です。
A.2.3
Analysis Services の移行手順
次に、SQL Server 2000 上で作成した Analysis Services データベースを SQL Server 2008
上へ移行する手順として、次の 3 つを説明します。

Analysis Services データベースの移行

Analysis Services オブジェクト処理の移行

クライアント ツールの変更
A.2.3.1
Analysis Services データベースの移行手順
SQL Server 2000 の Analysis Services（以下、AS 2000）と SQL Server 2008 の Analysis
Services（以下、AS 2008）では、アーキテクチャが大きく変更されているため、AS 2000 で
取得したデータベースのバックアップ（.cab ファイル）を AS 2008 へ復元することはできま
せん。AS 2000 のデータベースを AS 2008 へ移行するには、
「Analysis Services 移行ウィザ
ード」
（MigrationWizard）を利用しなければなりません。
Analysis Services 移行ウィザードによる OLAP キューブの移行手順
Analysis Services 移行ウィザードを利用して、Analysis Services データベースを移行する手
順は、次のとおりです。
1.
Analysis Services 移行ウィザードの起動
Analysis Services 移行ウィザードを起動するには、移行先サーバー（SQL Server 2008）
上の［スタート］メニューの［ファイル名を指定して実行」から「MigrationWizard」と入
力します。
107
2.
これにより、Analysis Services 移行ウィザードが起動するので、
［次へ］ボタンをクリッ
クします。
3.
移行元と移行先のサーバーの指定
次に、移行元の AS 2000 サーバーと移行先の AS 2008 サーバーを指定します。
移行先へは、スクリプト ファイル（XMLA 形式のスクリプト）を指定することもできます
が、この場合は、ウィザードではスクリプトのみを生成し、それを後から AS 2008 に対し
て実行することで、OLAP キューブを作成（移行）することができます。以降では、直接 AS
2008 サーバーへ指定した場合の手順を説明します。
108
4.
移行元データベースの選択
次に、移行元となるデータベースを選択します。このとき、移行先へ作成するデータベー
スの名前を変更することも可能です。
5.
移行元データベースの検証
次のページでは、移行元データベースの検証が行われます。
6.
検証終了後、「次へ」ボタンをクリックすると、自動的に移行が開始されます。
109
以上で、AS 2000 の Analysis Services データベースの AS 2008 への移行が完了です。
なお、移行後は、データソースに対する接続先が、移行前のまま変更されないので、デー
タソースが新規サーバーの場合は、接続先を変更しておく必要があります。
A.2.3.4
OLAP キューブ処理の実装
AS 2000 と AS 2008 では、Analysis Services データベースの OLAP キューブ処理につい
ても実装が変更されています。変更点は、次のとおりです。

DTS の「Analysis Services 処理タスク」の廃止
前述の「A.2.2.2
DTS パッケージの移行手順」で説明した「パッケージ移行ウィザー
ド」および「DTS 2000 パッケージ実行タスク」では、「Analysis Services 処理タス
ク」の移行を行うことができません。

DSO（Decision Support Objects）が既定ではインストールされない
AS 2008 では、DSO の代わりに AMO（Analysis Management Objects）が管理イン
ターフェースとして提供されています。
したがって、DTS の「Analysis Services 処理タスク」を利用してキューブを処理していた場
合は、Integration Services の「Analysis Services 処理タスク」へ変更するか、AMO を利
用してキューブ処理アプリケーションを作成するようにします。また、DSO を利用してキュ
ーブ処理アプリケーションを作成していた場合は、AMO 利用するようにプログラムを変更す
るか、Integration Services の「Analysis Services 処理タスク」を利用するようにします。
A.2.3.5
クライアント ツールの変更手順
最後に、AS 2008 へ移行した Analysis Services データベースへ、クライアント（Excel 2000、
Excel 2003 および Excel 2007）から参照できるように、クライアントを変更するようにしま
110
す。
(1) Excel 2000／2003 の変更手順
Excel 2000／2003 を変更する手順は、次のとおりです。
1.
Analysis Services 10.0 OLE DB Provider をインストールする
まずは、クライアント マシンへ「Analysis Services 10.0 OLE DB Provider」をインスト
ールしておく必要があります。これは、SQL Server 2008 用の Feature Pack として、次
の URL で提供されています。

SQL Server 2008 用 Feature Pack - 2008 年 8 月
http://www.microsoft.com/downloads/details.aspx?FamilyId=C6C3E9EF-BA29-4A43-8D69-A2BED
18FE73C&displaylang=ja
2.
Microsoft Script Editor を開く
次に、Excel の［ツール］メニューの［マクロ］から Microsoft Script Editor を開きます。
3.
<x:Connection> 要素の変更
Microsoft Script Editor では、<x:Connection> 要素を検索し、次の項目を変更して、保存
します。
項目
変更手順
備考
Provider
MSOLAP.2 を MSOLAP.4 へ書き換える
Data Source
AS 2008 のインスタンス名へ書き換える
111
接続先が変わらない場合（移行元と移行
先のマシン名が同じ場合）は不要
(2) Excel 2007 の変更手順
Excel 2007 を変更する手順は、次のとおりです。
1.
Analysis Services 10.0 OLE DB Provider をインストールする
Excel 2000／2003 の手順と同様、クライアントマシンへ「Analysis Services 10.0 OLE DB
Provider」をインストールしておく必要があります。
2.
接続のプロパティを開く
次に、Excel 2007 のリボンの［データ］タブから［接続］をクリックします。
［ブックの接続］ダイアログでは、使用している接続定義を選択して、［プロパティ］ボタ
ンをクリックします。
3.
接続文字列の変更
［接続のプロパティ］ダイアログが表示されたら、［定義］タブを選択し、［接続文字列］
を次のように変更します。
112
Provider を MSOLAP.2 から MSOLAP.4 へ変更
Data Source を AS 2008 のインスタンスへ変更
項目
変更手順
備考
Provider
MSOLAP.2 を MSOLAP.4 へ書き換える
Data Source
AS 2008 のインスタンス名へ書き換える
以上でクライアント ツールの移行が完了です。
113
接続先が変わらない場合（移行元と移
行先のマシン名が同じ場合）は不要
A.2.4
Reporting Services の移行手順
次に、SQL Server 2000 上で作成した Reporting Services レポートを SQL Server 2008 上
へ移行する方法として、次の 3 つを説明します。

Reporting Services データベースの移行

BIDS（Business Intelligence Development Studio）を利用した配置

レポート マネージャを利用した配置
A.2.4.1
Reporting Services データベースの移行
SQL Server 2000 上の Reporting Services（以下、RS 2000）で作成したレポートや共有デ
ータソースなどを SQL Server 2008 上の Reporting Services（以下、RS 2008）へ移行する
には、Reporting Services データベースを移行するようにします。Reporting Services では、
次の 2 つのデータベース内へ、作成したレポートや共有データソースなどの情報が格納されて
います。
データベース名
格納される情報
ReportServer
レポート定義、データソース、ユーザー、ポリシー、ロール、
レポート スナップショット
ReportServerTempDB
一時データ、セッション情報、キャッシュされたレポート
この 2 つのデータベースは、上位のバージョンの Reporting Services へアップグレードする
ことが可能です。アップグレードにより、レポートと共有データソースを、以前のバージョン
と同じように利用することができます。アップグレードの手順は、次のとおりです。
1.
データベースのバックアップ／復元
まずは、RS 2000 レポート サーバーが利用している次の 2 つのデータベースを、A.2.1.1
のデータベースの移行で説明した移行手順に沿って、SQL Server 2008 上へ移行します。

ReportServer データベース

ReportServerTempDB データベース
データベースの移行は、バックアップ／復元だけでなく、デタッチ／アタッチまたはデー
タベース コピー ウィザードを利用しても行うことが可能です。
2.
暗号化キーのバックアップ
次に、暗号化キーをバックアップします。暗号化キーをバックアップするには、コマンド プ
ロンプトを起動して、次のように「rskeymgmt」コマンドを実行します。
rskeymgmt –e –f "暗号化キーファイルの保存先" –p "復元用パスワード"
3.
Reporting Services 構成マネージャの起動
次に、SQL Server 2008 上で「Reporting Services 構成マネージャ」を起動して、レポー
ト サーバー インスタンスへ接続します。
114
4.
データベース構成ウィザードの実行
Reporting Services 構成マネージャでは、
［データベース］をクリックして、
［レポート サ
ーバー データベース］画面を開きます。
この画面では、
［データベースの変更］ボタンをクリックすることで、データベース構成ウ
ィザードを起動することができます。
5.
既存のデータベースの選択
データベース構成ウィザードが起動したら、
「既存のレポート サーバー データベースを選
択する」をチェックして、次へ進みます。
115
6.
レポート サーバーの指定
次に、移行先となる RS 2008（レポート サーバー）インスタンスの名前と認証方法を指定
します。
7.
レポート サーバー データベースの指定
次に、レポート サーバー データベースを指定します。ここで指定するのは、RS 2000 上
でバックアップしたデータベースを RS 2008 上へ復元したデータベースです。
116
8.
確認
最後に、設定の最終確認を行い、次へ進みます。
9.
［データベース ページ］の確認
完了後、
［データベース］ページで、現在のレポート サーバー データベースへ、RS 2000 か
ら復元した ReportServer データベースが設定されていることを確認します。
117
10. 暗号化キーの復元
次に、
［暗号化キー］ページを開き、
［復元］セクションの［復元］ボタンをクリックして、
手順 2 で取得した暗号化キーを復元します。
以上で、レポート サーバー データベースのアップグレードが完了です。これにより、
Reporting Services データベース内に格納されていた以下の情報が、すべて RS 2008 へ
アップグレードされるようになります。
データベース名
格納される情報
ReportServer
レポート定義、データソース、ユーザー、ポリシー、ロール、
レポート スナップショット
ReportServerTempDB
一時データ、セッション情報、キャッシュされたレポート
A.2.4.2
BIDS（Business Intelligence Development Studio）を利用した配置
RS 2000 で作成したレポートを、BIDS（Business Intelligence Development Studio）を利
用して移行する手順は、次のとおりです。
1.
まず、RS 2000 で作成したレポート ファイルおよび共有データソース ファイルを含むプ
ロジェクト ファイルを移行先の新規サーバー（Reporting Services）上へコピーします。
2.
SQL Server 2008 の BIDS（Business Intelligence Development Studio）を起動して、
手順 1 でコピーしたプロジェクト ファイルを開きます。これにより、
「Visual Studio 変
換ウィザード」が起動します。
3.
次に、レポート ファイルを開き、次のようにデータソースを右クリックして［編集］を
クリックし、データソースのプロパティ画面を開きます。
118
4.
［データソースのプロパティ］ダイアログでは、接続先を新規サーバー（SQL Server 2008
インスタンス）へ変更します。
5.
ソリューション エクスプローラからプロジェクトのプロパティを開きます。
119
6.
［TargetServerURL］を RS 2008 のレポート サーバーの URL へ変更します。
7.
ソリューション エクスプローラから配置を行います。
以上で、RS 2000 のレポートの RS 2008 への移行が完了です。
A.2.4.3
レポート マネージャを利用した配置
RS 2000 で作成したレポートは、レポート サーバーの管理ツールである「レポート マネージ
ャ」を利用して移行することも可能です。手順は、次のとおりです。
1.
2.
RS 2000 で作成したレポート ファイルおよび共有データソース ファイルを含むプロジェ
クト ファイルを Reporting Services サーバー上へコピーします。
レポート マネージャを起動し、
［ファイルのアップロード］をクリックします。
120
3.
［アップロードするファイル］へ手順 1 でコピーしたファイル（.rdl）のパスを指定しま
す。
4.
アップロードしたレポート ファイルへフォーカスし、
［プロパティ］タブをクリックしま
す。
5.
［データソース］ページを開き、接続文字列を新規サーバー（SQL Server 2008 インス
タンス）へ変更します。
121
6.
レポートが共有データソースを使用している場合には、共有データソースとレポートの関
連付けを設定します。
以上で、RS 2000 のレポートの RS 2008 への移行が完了です。
122
A.3
SQL Server 2005 から SQL Server 2008 への移行手順
ここでは、SQL Server 2005 から SQL Server 2008 への移行（マイグレーション）手順とし
て、次の流れで説明します。
章項目
詳細項目
A.3.1
1. データベースの移行手順
データベース エンジンの移行手順
2. データベース ミラーリングの移行手順
3. データ パーティション環境の移行手順
A.3.2
1. BIDS 配置ユーティリティでの移行手順
Integration Services の移行手順
2. パッケージ アップグレード ウィザードでの移行手順
3. dtutil ユーティリティでの移行手順
4. パッケージ（.dtsx）のコピーによる移行手順
A.3.3
1. バックアップ／復元による移行手順
Analysis Services の移行手順
2. XMLA 形式のスクリプト ファイルによる移行手順
3. BIDS での移行手順
4. Analysis Services 配置ウィザードでの移行手順
5. クライアント ツールの変更手順
A.3.4
1. レポート サーバー データベースの移行手順
Reporting Services の移行手順
2. BIDS を利用したレポートの移行手順
3. レポート マネージャを利用したレポートの移行手順
A.3.1 データベース エンジンの移行手順
A.3.1.1
データベースの移行手順
SQL Server 2005 上で作成したデータベースを SQL Server 2008 上へ移行する手順は、
A.2.1 で説明した SQL Server 2000 から SQL Server 2008 への移行手順と同様、次のとお
りです。

方法 1 デタッチ／アタッチでの移行

方法 2 バックアップ／復元での移行

方法 3 データベース コピー ウィザードでの移行
ただし、以下の環境では、方法 1 のデタッチ／アタッチによるデータベース移行が行えないた
め、方法 2 のバックアップ／復元での移行を利用するようにします。

データベース ミラーリング環境

データベース スナップショット作成済み環境
123
A.3.1.2
データベースミラーリング環境の移行手順
ここでは、SQL Server 2005 上で構築したデータベース ミラーリング環境を SQL Server
2008 上へ移行する手順を説明します。
以降の手順の前提条件は、次のとおりです。

移行対象環境はすべて SQL Server 2005 SP1（Service Pack 1）以上のインスタンスで
構成されていること

データベース ミラーリングは、ミラーリング監視サーバー（ウィットネス）を含む自動
フェールオーバー構成であること
移行手順は、次のとおりです。
1.
まずは、移行元の SQL Server 2005 上のデータベース ミラーリングを設定したデータベ
ースを完全バックアップします。
2.
次に、手順 1 でバックアップしたファイルを新規サーバー（SQL Server 2008）上のイン
スタンスへ復元します。
3.
新規サーバー上でデータベース ミラーリングを構成するために必要なエンドポイントを
作成します。
4.
新規サーバーのプリンシパル インスタンス上でデータベースの完全バックアップを取得
します。
124
5.
新規サーバーのミラー インスタンスへ、
手順 4 で取得したバックアップ ファイルを
「NO
RECOVERY」オプションを指定して、復元します。
NO RECOVERY
オプションをチェック
6.
新規サーバー上でミラーリングのセキュリティ構成を利用して、ミラーリング セッショ
ンを開始します。
125
以上で、データベース ミラーリング環境の移行が完了です。
なお、データベース ミラーリングの詳しい設定手順については、SQL Server 2008 自習書
シリーズの「データベース ミラーリング入門」を参考にしてください。
自習書シリーズ「データベース ミラーリング」のダウンロードはこちらから
http://www.microsoft.com/japan/sqlserver/2008/self-learning/default.mspx
126
A.3.1.3
データ パーティション環境の移行手順
ここでは、SQL Server 2005 上で構築したデータ パーティション環境を SQL Server 2008
上へ移行する手順として、デタッチ／アタッチを利用する方法を説明します（バックアップ／
復元でも移行が可能です）
。
移行手順は、次のとおりです。
1.
2.
移行元となるサーバー（SQL Server 2005）上でデータベースをデタッチします。
次に、デタッチしたデータ ファイル（.mdf／.ndf）とトランザクション ログ ファイル
（.ldf）を、新規サーバー（SQL Server 2008）上へコピーします。
127
3.
手順 2 でコピーしたファイルを、新規サーバー上でアタッチします。
4.
アタッチ後、データ パーティションを構成したテーブルを参照して結果を確認します。
以上で、データ パーティション環境の移行が完了です。
128
A.3.2
Integration Services（SSIS）の移行手順
SQL Server 2005 の Integration Services（以下、SSIS 2005）と SQL Server 2008 の
Integration Services（以下、SSIS 2008）は、アーキテクチャがほとんど変更されていないの
で、SSIS 2005 で作成したパッケージは、簡単に SSIS 2008 へ移行することができます。
SSIS 2005 のパッケージを移行する方法には、次の 4 つがあります。

BIDS 配置ユーティリティでの移行手順

パッケージ アップグレード ウィザードによる移行手順

dtutil ユーティリティを利用した移行手順

パッケージ（.dtsx）ファイルのコピーによる移行
(1) BIDS 配置ユーティリティでの移行手順
SQL Server 2005 上で作成した Integration Services パッケージは、SQL Server 2008 の
BIDS（Business Intelligence Development Studio）を利用して、新規サーバー上へ配置する
ことが可能です。配置は、通常のパッケージを配置する手順と同じです。
(2) パッケージ アップグレード ウィザードによる移行手順
SQL Server 2005 上で作成した Integration Services パッケージは、SQL Server 2008 の
Management Studio のパッケージ アップグレード ウィザードを利用して、移行することも
可能です。パッケージ アップグレード ウィザードを利用する手順は、次のとおりです。
1.
2.
移行元の SQL Server 2005 上で作成したパッケージ ファイル（拡張子 .dtsx）を、移行
先となる新規サーバー（SQL Server 2008）上へコピーします。
次 に 、 移行 先の マ シン上 で Management Studio を 起動 し 、 SQL Server 2008 の
Integration Services へ接続します。［格納されたパッケージ］の［File Stream］または
［MSDB］を右クリックして、
［パッケージのアップグレード］をクリックします。
これにより、パッケージ アップグレード ウィザードが起動します。
3.
パッケージ アップグレード ウィザードでは、「パッケージのアップグレード元」を「フ
ァイル システム」へ変更して、手順 1 でパッケージ（.dtsx）を保存したパスを指定しま
す。
129
4.
アップグレードするパッケージと、アップグレード後のパッケージ名を指定します。
5.
アップグレードしたパッケージの保存先を指定します。
130
6.
アップグレード時のオプションを指定します。
「完了」をクリックすると、パッケージのアップグレードが開始されます。以上で、SQL
Server 2005 上で作成したパッケージの SQL Server 2008 への移行が完了です。
(3) dtutil ユーティリティを利用した移行手順
SQL Server 2005 上で作成した Integration Services パッケージは、dtutil ユーティリティ
を利用して移行することも可能です。dtutil ユーティリティを利用する手順については、オン
ライン ブックを参考にしてください。
(4) パッケージ（.dtsx）ファイルのコピーによる移行
SQL Server 2005 上で作成した Integration Services パッケージ ファイル（.dtsx）は、単
純なファイル コピーでも移行が可能です。Windows エクスプローラを利用して、ファイルを
新規サーバー（SQL Server 2008）上へコピーすれば、それを SQL Server 2008 から利用（実
行）することができます。
131
A.3.3
Analysis Services の移行手順
ここでは、SQL Server 2005 上の Analysis Services（以下、AS 2005）で作成した多次元デ
ータベース（OLAP キューブ）を SQL Server 2008 上の Analysis Services（以下、AS 2008）
へ移行する手順を説明します。
SSAS 2005 と SSAS 2008 は、アーキテクチャがほとんど変更されていないので、簡単に移
行することができます。Analysis Services データベースを移行する方法には、次の 4 つの方
法があります。

バックアップ／復元による移行

XMLA 形式のスクリプト ファイル

BIDS（Business Intelligence Development Studio）での配置

Analysis Services 配置ウィザードを利用
(1) バックアップ／復元による移行手順
AS 2005 で取得したバックアップ ファイル（.abf）は、AS 2008 上で復元することが可能で
す。これは次のように操作します。
1.
AS 2005 上で Analysis Services データベースのバックアップを実行します。
2.
手順 1 で取得したバックアップ ファイルを AS 2008 のサーバー上へコピーします。
3.
Management Studio から AS 2008 へ接続し、
［データベース］フォルダを右クリックし
て、
［復元］をクリックします。
132
4.
［データベースの復元］ダイアログでは、復元元の［参照］ボタンをクリックします。
5.
［データベース ファイルの検索］ダイアログでは、手順 2 でコピーしたファイル（.abf）
のパスとファイル名を入力します。
［OK］ボタンをクリックすると、復元を開始されます。
以上で、AS 2005 上の OLAP キューブの AS 2008 への移行が完了です。
133
(2) XMLA 形式のスクリプト ファイルによる移行手順
AS 2005 の OLAP キューブは、XMLA 形式のスクリプトを利用して、AS 2008 上へ移行す
ることも可能です。
XMLA 形式のスクリプトを利用する手順は、次のとおりです。
1.
AS 2005 上で、次のように該当データベースを右クリックして、
［名前を付けてデータベー
スをスクリプト化］の［CREATE］→［ファイル］をクリックして、Analysis Services デ
ータベースの定義をファイルへ保存します。
2.
手順 1 で保存した定義ファイルを AS 2008 サーバー上へコピーします。
3.
Management Studio から AS 2008 へ接続し、
［ファイル］メニューの［開く］から［フ
ァイル］をクリックして、手順 2 でコピーしたファイルを開きます。
4.
実行ボタンをクリックして、XMLA スクリプトを実行します。
134
以上で、AS 2005 上で作成した OLAP キューブとまったく同じ構成の OLAP キューブを
AS 2008 上へ作成することができます。あとは、キューブを処理すれば、同じ移行が完了
です。
(3) BIDS からの配置による移行
AS 2005 の OLAP キューブは、BIDS（Business Intelligence Development Studio）を利用
して、AS 2008 上へ移行することも可能です。
これは、AS 2005 で作成した Analysis Services プロジェクトを、AS 2008 の BIDS で開き、
配置処理を行うだけで完了です。
(4) Analysis Services 配置ウィザードを利用
AS 2005 の OLAP キューブは、Analysis Services 配置ウィザードを利用して、AS 2008 へ
移行することも可能です。
Analysis Services 配置ウィザードを利用する手順は、次のとおりです。
1.
.asdatabase ファイルのコピー
まずは、AS 2005 の Analysis Services プロジェクトで生成されたファイル （拡張
子 .asdatabase）を AS 2008 のサーバー上へコピーします。
2.
Analysis Services 配置ウィザードの起動
次に、
［スタート］メニューの［すべてのプログラム］から［Microsoft SQL Server 2008］
→［Analysis Services］→［配置ウィザード］をクリックして、Analysis Services 配置ウ
ィザードを起動します。
135
3.
Analysis Services 配置ウィザードでは、手順 1 でコピーしたファイル（.asdatabase）を
指定します。
4.
データベースの作成先となる AS 2008 インスタンスを指定します。
5.
パーティションやロール、メンバの配置方法を指定します。
136
6.
データソースへの接続方法等を指定します。
7.
配置ウィザード内で処理を行うかを指定します。
8.
XMLA 形式の配置スクリプトを作成するかどうかを選択します。
137
［次へ］をクリックすると、配置と処理が開始されます。以上で、AS 2005 の OLAP キ
ューブの AS 2008 への移行が完了です。
138
A.3.4
Reporting Services の移行手順
SQL Server 2005 上の Reporting Services（以下、RS 2005）で作成したレポートを SQL
Server 2008 上の Reporting Services（以下、RS 2008）へ移行する手順は、 A.2.4 で説明
した SQL Server 2000 からの移行手順と同様です。
暗号化キーのバックアップ手順（SQL Server 2005 の場合）
RS 2000 では、暗号化キーのバックアップを rskeymgmt ユーティリティを利用して行いま
したが、RS 2005 では、このユーティリティに加えて、GUI ツールでのバックアップがサポ
ートされました。これは、Reporting Services 構成マネージャから行いますが、具体的な手順
は、次のとおりです。
1.
移行元サーバーで Reporting Services 構成マネージャを起動し、インスタンスへ接続しま
す。
2.
［暗号化キー］ページを開き、
［バックアップ］ボタンをクリックします。
3.
［暗号化キーの情報］ダイアログでは、暗号化キーの作成先のパスと複合化のためのパス
ワードを設定します。
139
以上で、暗号化キーのバックアップが完了です。このように RS 2005 では、暗号化キーを
簡単にバックアップできるようになりました。
140
付録 B インプレース アップグレード
ここでは、SQL Server 2000／SQL Server 2005 のデータベース エンジンを SQL Server
2008 へインプレース アップグレードする手順について以下の項目を説明します。
項目
B.1. クラスタ環境のアップグレード手順
B.2. ログ配布環境のアップグレード手順
B.3. データベース ミラーリングのアップグレード手順
なお、各インプレース アップグレード手順の実行前に、必ずアップグレード対象となるデー
タベースの完全バックアップと DBCC CHECKDB コマンドを使用したデータベースの整合
性チェックを実行しておいてください。
141
B.1
クラスタ環境のアップグレード手順
クラスタ環境のアップグレード インストール手順は、SQL Server 2005 までの方法から変更
されています。SQL Server 2005 までは、タスク スケジューラ サービスを使用して、ひと
つのクラスタ ノードからクラスタ環境に参加しているすべてのノードへ一括でインストール
していましたが、SQL Server 2008 ではノードごとにインストールするように変更されまし
た。この結果、ローリング アップグレードが可能となり最小の停止時間でアップグレードす
ることができます。
アップグレード元の環境
クラスタ環境のアップグレード手順では、下表の 2 種類の構成をアップグレード元の環境とし
て使用しましたが、どちらも同様の手順で行えるため、SQL Server 2000 からのアップグレ
ード手順のみを記載しています。
バージョン
コンポーネント
備考
SQL Server 2000
SQL Server 2000 データベース エンジン
Analysis Server 等はインスト
（SP4 適用済み、ビルド番号 8.00.2039）
ールされていない
SQL Server 2005 データベース エンジン
Analysis Server、Integration
SQL Server 2005
Services、Reporting Services
Full Text Search
（SP2 適用済み、ビルド番号 9.0.3042）
142
等はインストールされていな
い
次の図は、アップグレードの検証に使用したクラスタ構成を示しています。
次の画面は、クラスタ アドミニストレータでアップグレード前の環境を表示しています。
NODE1 と NODE2 からなる 2 ノード構成にアクティブ/パッシブで稼働する SQL Server
サービス リソースが稼働しています。初期状態では NODE1 がアクティブで SQL Server
のサービスを提供しています。アップグレードを行うと既存のクラスタ構成がアップグレード
後のシステムに引き継がれることを理解しておきましょう。
143
アップグレード作業表
次の表は、アップグレードのための作業手順を示しています。
手
順
各ノード上で行った作業内容
NODE1
1
2
3
4
5
6
7
8
9
10
NODE2
前提パッケージのイン
ストール
再起動の実施
手 動 によ る NODE2
へのフェールオーバ
ーの実施
前提パッケージのイ
ンストール
再起動の実施
パッシブ ノードから
のアップグレードの
実施
再起動の実施
アクティ
ブ なノ
ード
NODE1
NODE1
NODE2
DB サー
バーの可
用性
(※1)
可
可
可
(※3)
NODE2
ア ク テ ィ ブ ノ ー ドか
らのアップグレードの
実施
再起動の実施
データベース互換性
レベルの設定
DB サーバ
ーのバージ
ョン
(※2)
SQL Server
2000 / 2005
同上
同上
同上
NODE2
NODE2
可
可
同上
同上
NODE2
NODE2
→
NODE1
可
可
(※4)
同上
SQL Server
2008
NODE1
NODE1
可
可
同上
同上
（※1）クラスタ環境で稼働するデータベース エンジン サービスが利用可能か否かを示して
います。
（※2）クラスタ環境で稼働するデータベース エンジン サービスのバージョンです。
（※3）但し、フェールオーバー中はサービスが停止します。
（※4）但し、セットアップにより自動で行われるフェールオーバーとデータベース フォーマ
ットの更新中は、サービスが停止します。
事前準備
アップグレード手順に入る前に、Active Directory ユーザーとコンピュータ ツールを使用し
て、ドメイン コントローラにあらかじめ SQL Server データベース エンジンと SQL Server
エージェント サービス用にドメイン グループ アカウントを作成しておきます。これらのグ
ループアカウントに、既存のインスタンスのサービス アカウントとして使用しているドメイ
ン ユーザー アカウントを登録しておきます。
また、フルテキスト検索サービスを使用する場合、フルテキスト検索サービスのサービス ア
カウントとして使用するドメイン ユーザー アカウントを作成しておきます。
アップグレード作業手順
144
アップグレード作業手順は以下のとおりです。
手順 1．前提パッケージのインストール
SQL Server 2008 のインストール前に、あらかじめ .NET Framework 3.5 SP1 と Windows
インストーラ 4.5 をインストールしておく必要があります。これらのインストールは、コンピ
ュータの再起動を要するため、パッシブ ノード側 (NODE2) からインストール作業を行いま
す。これにより、データベース サービスの停止時間を少なくすることができます。前提パッ
ケージのインストールはインストール DVD の setup.exe を使用するのではなく、各セット
アップ モジュールを直接起動する方法で行います。
① .Net Framework パッケージのインストール
イ ン ス ト ー ル
DVD
の
x86¥redist¥DotNetFrameworks
dotNetFx35setup.exe を起動します。
145
フ ォ ル ダ に あ る
② Windows インストーラ 4.5 のインストール
インストール DVD の x86¥redist¥Windows Installer¥x86 フォルダにある INSTMSI45.exe
をを起動します。
手順 2．再起動の実施
Windows インストーラ 4.5 のインストールの完了ページで [完了] ボタンをクリックすると
再起動します。前提パッケージをインストールしたパッシブ ノード (NODE2) のみを再起動
する必要があります。
手順 3．手動による NODE2 へのフェールオーバーの実施
クラスタ アドミニストレータを使用して SQL Server のクラスタグループを NODE2 へフェ
ールオーバーします。
146
クラスタ アドミニストレータを使用して SQL Server のクラスタグループが NODE2 で稼
働していることを確認します。
手順 4．前提パッケージ (.NET Framework 及び Windows インストーラ) のインストール
現在のパッシブ ノードである NODE1 から行います。作業は「手順 1」と同様のため省略し
ます。
手順 5．再起動の実施
Windows インストーラ 4.5 のインストールの完了ページで[完了]ボタンをクリックすると再
起動します。前提パッケージをインストールしたパッシブ ノード (NODE1) のみを再起動す
る必要があります。
147
手順 6．パッシブ ノードからのアップグレードの実施
① インストール ウィザードの開始
現在のパッシブ ノード (NODE1) から SQL Server のアップグレード インストールを実施
します。
アップグレード インストールを開始するには、SQL Server インストール センターの左側の
リンクで[インストール]を選択し、右側のリンクから「SQL Server 2000 または SQL Server
2005 からのアップグレード」をクリックして、インストール ウィザードを開始します。
② セットアップ サポート ルール
［セットアップ サポート ルール］ページでは、NODE1 のシステムが SQL Server 2008 を
インストールするのに必要な条件を満たしているかがチェックされます。チェックの完了後、
次のように［詳細を表示／非表示］ボタンをクリックすることで、詳細結果を確認することが
できます。確認後、[OK] ボタンをクリックします。
148
③ プロダクト キー
[プロダクト キー] ページでは、適正なプロダクト キーを入力してください。
Enterprise Edition や Standard Edition からのアップグレード インストールで [無償のエ
ディションを指定する] オプションを選択すると、セットアップ中にエラーとなるので注意し
てください。
④ ライセンス条項
[ライセンス条項] ページで ソフトウェア ライセンス条項を確認して [使用許諾契約書に同
意する。] チェックボックスを選択します。
149
⑤ セットアップ サポート ファイル
[セットアップ サポート ファイル] ページで [インストール] ボタンをクリックしセットアッ
プ サポート ファイルのインストールを開始します。
⑥ セットアップ サポート ルール
再び [セットアップ サポート ルール] ページが表示されセットアップ サポート ファイルの
インストールに関する問題がないかチェックを開始します。操作が完了したら [詳細の表示]
ボタンをクリックして ルールの検証結果を確認します。問題がなければ次のステップに進め
ます。
150
⑦ インスタンスの選択
[インスタンスの選択] ページでは、アップグレードするインスタンスを選択します。
⑧ 機能の選択
［機能の選択］ ページでは、アップグレードされるコンポーネントが確認できます。
151
⑨ インスタンスの構成
既存の［SQL Server のネットワーク名］が引き継がれるため［インスタンスの構成］ページ
では、
［SQL Server のネットワーク名］を設定するインターフェイスは表示されません。イ
ンスタンス ID は変更が可能です。
⑩ 必要なディスク領域の確認
［必要なディスク領域］ ページでは、内容を確認して、次のページへ進みます。
152
⑪ クラスタのセキュリティ ポリシー
［クラスタのセキュリティ ポリシー］ ページでは、事前に作成しておいたドメイン グルー
プを指定します。
［データベース エンジン ドメイン グループ］ には、データベース エンジンのためのサー
ビス アカウントが登録されているドメイン グループを指定し、［SQL Server エージェント
ドメイン グループ］ には、SQL Server エージェントのためのサービス アカウントが登録
されているドメイン グループを指定します。この時、グループのドメイン名を NetBIOS 名
で指定するとエラーになりますので注意してください。ドメイン名は、FQDN 形式で指定す
る必要があります。
153
⑫ サーバーの構成
［サーバーの構成］ページの［Service Account］タブでは、フルテキスト検索サービスで使用
するサービス アカウントを指定します。
［サーバーの構成］ページの［Service Account］タブでは、フルテキスト検索サービスで使用
するサービス アカウントを指定した場合、フルテキスト検索サービスが有効化されます。サ
ービス アカウントを指定しない場合は、フルテキスト検索サービスは無効化されます。
また、既存の データベース エンジン サービスと SQL Server エージェント サービスのサー
ビス アカウントは、既存のインスタンスに設定されているアカウントが引き継がれます。
154
⑬ フルテキスト アップグレード
フルテキスト検索サービスが有効化されると既存のカタログのアップグレード オプションを
選択するページが表示されます。
SQL Server 2008 で強化されたワードブレーカを使用する場合、[再構築] オプションを選択す
る必要がありますが、その結果、アップグレード インストールの時間が長くなる場合があり
ます。既定の設定では、既存のカタログをインポートする方法が選択されます。
⑭ エラーと使用状況レポート
[エラーと使用状況レポート] ページでは、今後の SQL Server のリリースの改善に役立てるた
めの情報を Microsoft に送信する場合、チェックボックスを選択し次へ進めます。
155
⑮ アップグレード ルール
［アップグレード ルール］ ページでは、NODE1 のシステムが SQL Server クラスタをア
ップグレードするのに必要な条件を満たしているかを調査します。
［詳細を表示／非表示］ ボ
タンをクリックして、詳細結果を確認することができます
⑯ クラスタ アップグレード レポート
［クラスタ アップグレード レポート］ ページでは、クラスタ構成のアクティブとパッシブ
のノード情報が確認できます。現在、パッシブ ノードからアップグレード作業をしようとし
ていることを確認してください。
156
⑰ アップグレードの準備完了
［アップグレードの準備完了］ ページでは、アップグレード インストールの設定内容を確認
します。
設定を確認後、これで良い場合は、
［アップグレード］ ボタンをクリックします。
⑱ アップグレードの進行状況
アップグレード インストールの完了後、すべての状態が「成功」と表示されれば、NODE1 で
の SQL Server 2008 へのアップグレード インストールが完了します。
157
⑲ クラスタ アップグレード レポート
再び、
［クラスタ アップグレード レポート］ページが表示されます。[SQL バージョン] 列の
情報から、現在、NODE1 は、SQL Server 2008 として構成されていることが分かります。
⑳ 完了
[完了] ページで [閉じる] ボタンをクリックすることで NODE1 でのアップグレード作業は
完了します。なお、インストールに問題が生じている場合は、ここで [概要ログ ファイルの保
存先] のリンクを使用してエラー情報を表示できます。
手順 7．再起動の実施
アップグレード インストールを行った NODE1 (パッシブ ノード) のみを再起動します。
なお、NODE1 のみのアップグレードインストールが完了した段階で、手動フェールオーバー
158
を行うとエラーとなるため、注意してください。クラスタ アドミニストレータを使用して、
NODE1 から NODE2 へのフェールオーバー操作を行った場合、次のメッセージボックスが
表示され、フェールオーバーの実行は拒否されます。
フェールオーバー動作は NODE2 のアップグレード後、正常に行えるようになります。
手順 8．アクティブ ノードからのアップグレードの実施
① インストール ウィザードの開始
ここでは、NODE2 (現在のアクティブ ノード) から SQL Server のアップグレード インス
トールを実施します。
アップグレード インストールを開始するには、手順 6 と同様に「SQL Server 2000 または
SQL Server 2005 からのアップグレード」をクリックして、インストール ウィザードを開始
します。
以降の作業手順は、
「⑮ アップグレード ルール」までは、手順 6 と同様ですので省略します。
159
⑯ クラスタ アップグレード レポート
［クラスタ アップグレード レポート］ページでは、次の内容が表示されます。現在、アクテ
ィブになっている NODE2 のアップグレード インストールを開始しようとしていることが
分かります。
⑰ アップグレードの準備完了
［アップグレードの準備完了］ページでは、アップグレード インストールの設定内容を確認
します。
設定を確認後、これで良い場合は、
［アップグレード］ボタンをクリックします。
160
⑱ アップグレードの進行状況
NODE2 のアップグレード インストールが開始すると自動的にアップグレード済みの
NODE1 へフェールオーバーし、データベース フォーマットが更新されます。この間、サー
ビスが停止していますが、データベース フォーマットの更新処理完了時点に、SQL Server
2008 インスタンスとして構成されている NODE1 がアクティブになります。アップグレード
インストールの完了後、すべての状態が「成功」と表示されれば、NODE2 でのアップグレー
ド インストールが完了します。
⑲ クラスタ アップグレード レポート
再び、
［クラスタ アップグレード レポート］ページが表示されます。現在、両方のノードが
SQL Server 2008 として構成され、NODE1 がアクティブとして稼働していることが分かり
ます。
161
⑳ 完了
[完了] ページで [閉じる] ボタンをクリックすることで NODE2 のアップグレード作業は完
了します。なお、インストールに問題が生じている場合は、ここで [概要ログ ファイルの保存
先] のリンクを使用してエラー情報を表示できます。
手順 9．再起動の実施
NODE2 のみを再起動します。
手順 10．データベース互換性レベルの設定
アップグレード後のデータベースの互換性レベルは、master データベース以外、SQL Server
2000 からのアップグレードでは、すべて 80 (SQL Server 2000 互換)で、SQL Server 2005 か
らのアップグレードでは、すべて 90 (SQL Server 2000 互換)になっています。
SQL Server 2008 の既定の互換性レベルは 100 です。互換性レベルの設定を 100 に設定する
ことで SQL Server 2008 からサポートされる新しい Transact-SQL 構文やデータ型が使用
できるようになります。互換性レベルは、サーバー全体ではなく、データベース単位の指定に
なります。
互換性レベルにより、以前のバージョンの SQL Server との部分的な互換性が提供されるた
め、移行時の暫定的な手段として使用することができます。
SQL Server 2008 での互換性の違いによって既存の SQL Server アプリケーションに影響が
生じる場合、適切に動作するようアプリケーションを変換した後で互換性レベルを 100 に変
更します。この設定により動作を制御することで、バージョン間の動作の違いに対処すること
ができます。以下のステートメントを実行することで互換性レベルを 100 に変更できます。
ALTER DATABASE データベース名
COMPATIBILITY_LEVEL = 100
162
B.2
ログ配布環境のアップグレード手順
ここでは、SQL Server 2000、および SQL Server 2005 のログ配布環境を SQL Server 2008
へインプレース アップグレードする手順について説明します。SQL Server 2000 と SQL
Server 2005 のログ配布では、異なる方法を採用しているため、インプレース アップグレー
ドの手順も異なっています。
163
B.2.1
SQL Server 2000 ログ配布環境からのアップグレード
SQL Server 2000 のログ配布構成を 直接、SQL Server 2008 にインプレース アップグレー
ドすることはできません。SQL Server 2000 ではログ配布の構成にデータベース保守計画ウ
ィザードを使用していましたが、SQL Server 2005 以降ではデータベース保守計画ウィザー
ドは使用しないため、サーバーを SQL Server 2008 にアップグレードした時点で現行のログ
配布機能は使用できなくなり、ログ配布環境の再構成が必要となります。
アップグレード元の環境
2 台のコンピュータを使用して下表の構成で SQL Server 2000 ログ配布環境を作成しました。
コンピュータ名
バージョン
用途
SQL1
SQL Server 2000 (SP4)
プライマリ サーバー
SQL2
SQL Server 2000 (SP4)
セカンダリ サーバー
次の画面は、SQL Server Enterprise Manager でアップグレード前の環境を示しています。
アップグレードの方法
SQL Server 2008 オンライン ブックの「SQL Server 2000 のログ配布構成の SQL Server
2008 への移行 (http://msdn.microsoft.com/ja-jp/library/ms188297(SQL.100).aspx)」で記載
されている手順に基づき、フェールオーバーを併用する方法と併用しない方法の 2 種類のロ
グ配布環境のアップグレード シナリオを検証しました。
① フェールオーバーを併用しない手順
アップグレード作業手順の概要
フェールオーバーを併用せずに SQL Server 2000 のログ配布構成を SQL Server 2008 にア
ップグレードできますが、プライマリ サーバー インスタンスを SQL Server 2008 にアップ
グレードした後、ログ配布を再構成するまでは、ログ配布の同期は行われず、また、プライマ
164
リ サーバー インスタンスのアップグレードの最後のプロセスでインスタンス再起動が実行
され、その間は、プライマリ データベースが使用できなくなります。また、それ以降は、SQL
Server 2000 のバックアップジョブは機能しなくなります。フェールオーバーを併用しない手
順の概要は以下のとおりです。
1. セカンダリ サーバー (SQL2) をアップグレード
2. プライマリ サーバー(SQL1) をアップグレード
3. ログ配布の再構成
次の図はフェールオーバーを併用しない手順でのアップグレードの検証に使用したログ配布
環境を示しています。
アップグレード作業手順表
フェールオーバーを併用しない作業手順は以下のとおりです。
手
順
SQL1
1
SQL2
プライマリ
サーバー
アップグレードの実施
SQL1
2
アップグレードの実施
3
プライマリ サーバーと
セカンダリ サーバーとし
してログ配布再構成
てログ配布再構成
データベースの可用
性
アップグレード中は
使用不可
SQL1
事前準備
アップグレード手順に入る前に、あらかじめ、フルテキスト検索サービスのサービス アカウ
ントとして使用する Windows アカウントを作成しておきます。
アップグレード作業手順
アップグレード作業手順は以下のとおりです。
手順 1．セカンダリ サーバー (SQL2) のアップグレード
① 前提パッケージ (.Net Framework と Windows インストーラ 4.5) のインストール
165
インストール DVD を DVD ドライブにセットすると前提パッケージ (.Net Framework と
Windows インストーラ 4.5) のインストールが開始します。
・.Net Framework のインストール
166
・Windows インストーラ 4.5 のインストール
② 再起動の実施
Windows インストーラ 4.5 のインストールの完了ページで [完了] ボタンをクリックすると
再起動を要求するメッセージボックスが表示されます。前提パッケージをインストールしたセ
カンダリ サーバー (SQL2) のみを再起動します。
167
① インストール ウィザードの開始
再起動後、インストール DVD の Setup.exe を実行します。SQL Server インストール セン
ターが起動するので、左側のリンクで [インストール] を選択し、右側のリンクから「SQL
Server 2000 または SQL Server 2005 からのアップグレード」をクリックして、インストー
ル ウィザードを開始します。
② セットアップ サポート ルール
［セットアップ サポート ルール］ページでは、SQL2 のシステムが SQL Server 2008 をイ
ンストールするのに必要な条件を満たしているかチェックされます。チェックの完了後、次の
ように［詳細を表示／非表示］ボタンをクリックすることで、詳細結果を確認することができ
ます。確認後、[OK] ボタンをクリックします。
168
③ プロダクト キー
[プロダクト キー] ページでは、適正なプロダクト キーを入力してください。
④ ライセンス条項
[ライセンス条項] ページで ソフトウェア ライセンス条項を確認して [使用許諾契約書に同
意する。] チェックボックスを選択します。
169
⑤ セットアップ サポート ファイル
[セットアップ サポート ファイル] ページで [インストール] ボタンをクリックしセットアッ
プ サポート ファイルのインストールを開始します。
⑥ セットアップ サポート ルール
再び [セットアップ サポート ルール] ページが表示されセットアップ サポート ファイルの
インストールに関する問題がないかチェックを開始します。操作が完了したら [詳細の表示]
ボタンをクリックして ルールの検証結果を確認します。問題がなければ次のステップに進め
ます。
170
⑦ インスタンスの選択
[インスタンスの選択] ページでは、アップグレードするインスタンスを選択します。
⑧ 機能の選択
［機能の選択］ ページでは、アップグレードされるコンポーネントが確認できます。
171
⑨ インスタンスの構成
インスタンス ID を確認します。インスタンス ID は、インストール フォルダ名にも使用され
ます。
⑩ 必要なディスク領域の確認
［必要なディスク領域］ ページでは、内容を確認して、次のページへ進みます。
172
⑪ サーバーの構成
［サーバーの構成］ページの［Service Account］タブでは、フルテキスト検索サービスで使用
するサービス アカウントを指定します。
［サーバーの構成］ページの［Service Account］タブでは、フルテキスト検索サービスで使用
するサービス アカウントを指定した場合、フルテキスト検索サービスが有効化されます。サ
ービス アカウントを指定しない場合は、フルテキスト検索サービスは無効化されます。
また、既存の データベース エンジン サービスと SQL Server エージェント サービスのサー
ビス アカウントは、既存のインスタンスに設定されているアカウントが引き継がれます。
173
⑫ フルテキスト アップグレード
フルテキスト検索サービスが有効化されると既存のカタログのアップグレード オプションを
選択するページが表示されます。
SQL Server 2008 で強化されたワードブレーカを使用する場合、[再構築] オプションを選択す
る必要がありますが、その結果、アップグレード インストールの時間が長くなる場合があり
ます。既定の設定では、既存のカタログをインポートする方法が選択されます。
⑬ エラーと使用状況レポート
[エラーと使用状況レポート] ページでは、今後の SQL Server のリリースの改善に役立てるた
めの情報を Microsoft に送信する場合、チェックボックスを選択し次へ進めます。
174
⑭ アップグレード ルール
［アップグレード ルール］ ページではシステムが SQL Server クラスタをアップグレード
するのに必要な条件を満たしているかを調査します。
［詳細を表示／非表示］ ボタンをクリッ
クして、詳細結果を確認することができます
⑮ アップグレードの準備完了
［アップグレードの準備完了］ ページでは、アップグレード インストールの設定内容を確認
します。
設定を確認後、これで良い場合は、
［アップグレード］ ボタンをクリックし、アップグレード
を開始します。アップグレードの最後で、インスタンスが再起動し、それ以降はセカンダリ サ
ーバー (SQL2) 側へのログ転送とログ復元のジョブが停止します。
175
⑯ アップグレードの進行状況
アップグレード インストールの完了後、すべての状態が「成功」と表示されれば、SQL2 で
の SQL Server 2008 へのアップグレード インストールが完了します。
⑰ 完了
[完了] ページで [閉じる] ボタンをクリックすることで SQL2 でのアップグレード作業は完
了します。なお、インストールに問題が生じている場合は、ここで [概要ログ ファイルの保存
先] のリンクを使用してエラー情報を表示できます。
セカンダリ サーバーのデータベース インスタンス アップグレード後、配布データベースは
復元中の状態のままでデータベースは、SQL Server 2000 の形式のままです。
176
⑱ コピー、および復元ジョブの無効化
SQL Server Management Studio を起動し SQL2 に接続し、SQL Server エージェントのコ
ピー ジョブを選択して履歴を表示します。
同様にして、SQL Server エージェントの復元ジョブを選択して履歴を表示します。
この時点では、ログ ファイルをコピー、および復元する SQL Server 2000 ログ配布ジョブ
は sqlmaint.exe の実行でエラーとなり機能していません。
177
SQL Server Management Studio のオブジェクト エクスプローラを使用して、SQL Server
2000 ログ配布構成で使用していたコピー、および復元ジョブを無効化しておきます。
手順 2．プライマリ サーバー (SQL1) のアップグレード
ここでは、プライマリ サーバー (SQL1) から SQL Server のアップグレード インストール
を実施します。
アップグレード インストールを開始するには、手順 1 と同様に前提パッケージをインストー
ルして、再起動後にインストール センターから「SQL Server 2000 または SQL Server 2005
からのアップグレード」をクリックし、インストール ウィザードを開始します。
以降の作業手順は、手順 1 と同様ですので省略します。この作業中もログ配布の同期は停止し
ています。
また、アップグレード インストール完了後は、SQL Server エージェントのバックアップ ジ
ョブも機能しなくなります。
178
SQL Server Management Studio のオブジェクト エクスプローラを使用して、SQL Server
2000 ログ配布構成で使用していたデータベース保守計画のトランザクション ログ バックア
ップ ジョブを無効化しておきます。
179
手順 3．ログ配布の再構成
① プライマリ データベースの設定
SQL Server Management Studio のオブジェクト エクスプローラで SQL1 に接続し、オブ
ジェクト エクスプローラのツリーの [データベース] ノードの下で SQL Server 2000 ログ
配布を構成していたデータベースを右クリックして、表示されるメニューから [タスク] – [ト
ランザクション ログの配布] をクリックします。
再びプライマリ データベースとして構成するために[トランザクション ログの配布] ページ
の [ログ配布構成のプライマリ データベースとして有効にする] チェックボックスを選択し
ます。
② バックアップの設定
180
次に [トランザクション ログの配布] ページで [バックアップの設定] ボタンをクリックしま
す。[トランザクション ログのバックアップの設定] が表示されるので [バックアップ フォル
ダのネットワーク パス] テキストボックスに SQL Server 2000 ログ配布で使用していたバ
ックアップ フォルダの UNC パスを設定します。また、このページの [スケジュール] ボタン
を使用して トランザクション ログ バックアップの実行間隔を指定できます。
③ セカンダリ データベースの設定
[トランザクション ログの配布] ページの [セカンダリ データベース] で [追加] ボタンをク
リックします。[セカンダリ データベースの設定] が開くので、[接続] をクリックしてセカン
ダリサーバーに接続します。
今までログ配布で使用してきたデータベースを使用して再構成を行うには、[セカンダリ デー
タベースの初期化] タブの [いいえ、セカンダリ データベースは初期かされています] オプシ
ョンが選択されている必要があります。
181
④ コピージョブの設定
[セカンダリ データベースの設定] で [ファイルのコピー] タブを選択します。[ファイルのコ
ピー先フォルダ] テキストボックスに SQL Server 2000 ログ配布で使用していたコピー先の
フォルダの UNC パスを設定します。また、このページの [スケジュール] ボタンを使用して ト
ランザクション ログ バックアップをセカンダリサーバーに転送する時間間隔を指定できま
す。
⑤ 復元ジョブの設定
[セカンダリ データベースの設定] で [トランザクション ログの復元] タブをクリックして、
[バックアップ復元時のデータベース状態]で、復元方法を指定できます。また、このページの
[スケジュール] ボタンを使用して トランザクション ログ バックアップをセカンダリサーバ
ーに復元する時間間隔を指定できます。
⑥ 監視サーバーの設定
必要に応じて監視サーバーを登録して [OK] ボタンをクリックすると再構成が開始されます。
182
ログ配布の再構成後、セカンダリ サーバー インスタンスへのログ配布を開始した時点でセカ
ンダリ データベースは SQL Server 2008 のデータベース形式にアップグレードされます。
ログ配布の再構成では、SQL Server 2000 のログ配布構成で使用したのと同一のバックアッ
プ共有を指定することが重要です。これにより、SQL Server 2008 でログ配布を有効にした
ときに、セカンダリ データベースに未適用のログ バックアップを含むファイルが転送され、
すべて正しい順序で適用されます。
183
② フェールオーバーを併用する手順
アップグレード作業手順の概要
フェールオーバーを併用しない移行を行うと、セカンダリ サーバーへのフェールオーバーが
不要なので簡単ですが、プライマリ サーバーをアップグレードする間、データベースを使用
できなくなります。フェールオーバーを併用した場合、ログ配布構成の各サーバーをアップグ
レードする間もデータベースの可用性を維持することができます。
フェールオーバーを併用する手順の概要は以下のとおりです。
1. セカンダリ サーバー (SQL2) をアップグレード
2. SQL1 から SQL2 への手動フェールオーバー
3. フェールオーバー後のセカンダリ サーバー (SQL1) をアップグレード
4. ログ配布の再構成
次の図はフェールオーバーを併用する手順でのアップグレードの検証に使用したログ配布環
境を示しています。
アップグレード作業手順表
フェールオーバーを併用する作業手順は以下のとおりです。
SQL2
プライマリ
サーバー
1
アップグレードの実施
SQL1
2
SQL2 への手動フェール
SQL1 → SQL2
手順
SQL1
オーバー
データベースの可用
性
フェールオーバー中は利
用不可
3
アップグレードの実施
SQL2
4
セカンダリとしてログ
プライマリとしてログ配
配布再構成
布再構成
184
SQL2
手順 1．セカンダリ サーバー (SQL2) のアップグレード
まず、セカンダリ サーバー (SQL2) から SQL Server のアップグレード インストールを実
施します。
アップグレード インストールを開始するには、
「B.2.1 ①フェールオーバーを併用しない手順」
の手順 1 と同様に前提パッケージをインストールして、再起動後にインストール センターか
ら「SQL Server 2000 または SQL Server 2005 からのアップグレード」をクリックし、イン
ストール ウィザードを開始します。
以降の作業手順は、
「B.2.1 ①フェールオーバーを併用しない手順」の手順 1 と同様ですので
省略します。アップグレード インストール完了後は、SQL Server Management Studio のオ
ブジェクト エクスプローラで SQL2 に接続して、SQL Server 2000 ログ配布構成で使用して
いたコピー、および復元ジョブを無効化します。
185
手順 2．SQL1 から SQL2 への手動フェールオーバー
① トランザクション ログ バックアップの適用範囲を確認
SQL2 で SQL Server Management Studio のクエリエディタを使用し、以下のステートメン
トを実行します。
SELECT * FROM msdb.dbo.log_shipping_plans_databases
msdb.dbo.log_shipping_plans_databases システム テーブルの last_file_loaded 列の情報か
ら最後にセカンダリ データベースに適用されたトランザクション ログ バックアップのファ
イル名を確認します。
② バックアップジョブの無効化
SQL Server Management Studio のオブジェクト エクスプローラで SQL1 に接続し SQL
Server 2000 ログ配布構成で使用していたデータベース保守計画のトランザクション ログ
バックアップ ジョブを無効化します。また、これ以降はフェールオーバーが完了するまで、
プライマリ データベースに対する更新は停止させる必要があります。
③ 未適用のトランザクション ログを適用する
msdb.dbo.log_shipping_plans_databases システム テーブルの last_file_loaded 列で示され
たトランザクション ログのバックアップ ファイルがセカンダリサーバーに適用された最後
のログです。last_file_loaded 列のファイル以降に作成されたログ バックアップ ファイルを
セ カ ン ダ リ サ ー バ ー にコ ピ ー し 、 ク エ リ エ ディ タ で SQL2 に接 続 して 以 下 の よ うな
RESTORE LOG ステートメントを作成し、順次、未適用のログバックアップを適用します。
RESTORE LOG pubs
FROM DISK = 'C:\LogShipShare\ReceiveLog\pubs_tlog_200810031520.TRN'
WITH NORECOVERY
RESTORE LOG pubs
FROM DISK = 'C:\LogShipShare\ReceiveLog\pubs_tlog_200810031525.TRN'
WITH NORECOVERY
186
RESTORE LOG pubs
FROM DISK = 'C:\LogShipShare\ReceiveLog\pubs_tlog_200810031530.TRN'
WITH NORECOVERY
RESTORE LOG pubs
FROM DISK = 'C:\LogShipShare\ReceiveLog\pubs_tlog_200810031535.TRN'
WITH NORECOVERY
④ 末尾のトランザクション ログをバックアップする
クエリ アナライザで SQL1 に接続して以下の BACKUP LOG ステートメントを作成し、末尾
のトランザクション ログをバックアップします。
BACKUP LOG pubs
TO DISK = 'C:\LogShipShare\SendLog\pubs_tlog_TailLOG.TRN'
WITH NORECOVERY
このステートメントの WITH 句の指定により SQL1 のデータベースはオフラインになります。
⑤ 末尾のトランザクション ログをセカンダリ データベースに適用して復旧する
作成された末尾のログ バックアップ ファイル (pubs_tlog_TailLOG.TRN) をセカンダリサ
ーバーにコピーし、クエリ エディタで SQL2 に接続して以下の RESTORE LOG ステートメ
ントを作成し、末尾のログバックアップを適用します。
RESTORE LOG pubs
FROM DISK = 'C:\LogShipShare\ReceiveLog\pubs_tlog_TailLOG.TRN'
WITH RECOVERY
このステートメントの WITH 句の指定により SQL1 のデータベースは、アップグレードされた
後にオンラインになります。メッセージ ウィンドウには、以下のメッセージが返ります。
データベース 'pubs' の 0 ページ、ファイル 1 のファイル 'pubs' を処理しました。
データベース 'pubs' の 0 ページ、ファイル 1 のファイル 'pubs_log' を処理しました。
データベース 'pubs' をバージョン 539 から現在のバージョン 655 に変換しています。
データーベース 'pubs' で、バージョン 539 からバージョン 551 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 551 からバージョン 552 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 552 からバージョン 611 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 611 からバージョン 621 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 621 からバージョン 622 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 622 からバージョン 625 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 625 からバージョン 626 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 626 からバージョン 627 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 627 からバージョン 628 へのアップグレード手順が実行されています。
187
データーベース 'pubs' で、バージョン 628 からバージョン 629 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 629 からバージョン 630 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 630 からバージョン 631 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 631 からバージョン 632 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 632 からバージョン 633 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 633 からバージョン 634 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 634 からバージョン 635 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 635 からバージョン 636 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 636 からバージョン 637 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 637 からバージョン 638 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 638 からバージョン 639 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 639 からバージョン 640 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 640 からバージョン 641 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 641 からバージョン 642 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 642 からバージョン 643 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 643 からバージョン 644 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 644 からバージョン 645 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 645 からバージョン 646 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 646 からバージョン 647 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 647 からバージョン 648 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 648 からバージョン 649 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 649 からバージョン 650 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 650 からバージョン 651 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 651 からバージョン 652 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 652 からバージョン 653 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 653 からバージョン 654 へのアップグレード手順が実行されています。
データーベース 'pubs' で、バージョン 654 からバージョン 655 へのアップグレード手順が実行されています。
RESTORE LOG により 0 ページが 0.009 秒間で正常に処理されました (0.000 MB/秒)。
この操作の結果、SQL2 はプライマリ サーバーとして稼働します。
手順 3．フェールオーバー後のセカンダリ サーバー (SQL1) のアップグレード
フェールオーバー後のセカンダリ サーバー (SQL1) で SQL Server のアップグレード イン
ストールを実施します。
アップグレード インストールを開始するには、
「B.2.1 ①フェールオーバーを併用しない手順」
の手順 1 と同様に前提パッケージをインストールして、再起動後にインストール センターか
ら「SQL Server 2000 または SQL Server 2005 からのアップグレード」をクリックし、イン
ストール ウィザードを開始します。
188
以降の作業手順は、
「B.2.1 ①フェールオーバーを併用しない手順」の手順 1 と同様ですので
省略します。この作業の間も SQL2 に置かれたプライマリ データベースへのアクセスは可能
です。
手順 4．ログ配布の再構成
① プライマリ データベースの設定
SQL Server Management Studio のオブジェクト エクスプローラで SQL2 に接続し、オブ
ジェクト エクスプローラのツリーの [データベース] ノードの下で SQL Server 2000 ログ
配布を構成していたデータベースを右クリックして、表示されるメニューから [タスク] – [ト
ランザクション ログの配布] をクリックします。
プライマリ データベースとして構成するために [トランザクション ログの配布] ページの
[ログ配布構成のプライマリ データベースとして有効にする] チェックボックスを選択します。
189
② バックアップの設定
次に [トランザクション ログの配布] ページで [バックアップの設定] ボタンをクリックしま
す。[トランザクション ログのバックアップの設定] が表示されるので [バックアップ フォル
ダのネットワーク パス] テキストボックスにバックアップ フォルダ用の UNC パスを設定
します。また、このページの [スケジュール] ボタンを使用して トランザクション ログ バッ
クアップの実行間隔を指定できます。
③ セカンダリ データベースの設定
[トランザクション ログの配布] ページの [セカンダリ データベース] で [追加] ボタンをク
リックします。[セカンダリ データベースの設定] が開くので、[接続] をクリックしてセカン
ダリサーバーに接続します。
190
今までログ配布で使用してきたデータベースを使用して再構成を行うには、[セカンダリ デー
タベースの初期化] タブの [いいえ、セカンダリ データベースは初期かされています] オプシ
ョンが選択されている必要があります。
④ コピージョブの設定
[セカンダリ データベースの設定] で [ファイルのコピー] タブを選択します。[ファイルのコ
ピー先フォルダ] テキストボックスにコピー先のフォルダの UNC パスを設定します。また、
このページの [スケジュール] ボタンを使用して トランザクション ログ バックアップをセ
カンダリサーバーに転送する時間間隔を指定できます。
⑤ 復元ジョブの設定
[セカンダリ データベースの設定] で [トランザクション ログの復元] タブをクリックして、
[バックアップ復元時のデータベース状態]で、復元方法を指定できます。また、このページの
[スケジュール] ボタンを使用して トランザクション ログ バックアップをセカンダリサーバ
ーに復元する時間間隔を指定できます。
191
192
⑥ 監視サーバーの設定
必要に応じて監視サーバーを登録して [OK] ボタンをクリックすると再構成が開始されます。
ログ配布の再構成後、セカンダリ サーバー インスタンスへのログ配布を開始した時点でセカ
ンダリ データベースは SQL Server 2008 のデータベース形式にアップグレードされます。
193
B.2.2
SQL Server 2005 ログ配布環境からのアップグレード
SQL Server 2005 から SQL Server 2008 にアップグレードする際には、ログ配布構成を保持
することができます。ここでは、ログ配布構成のアップグレードの手順としてフェールオーバ
ーを併用する場合と併用しない場合の 2 種類のシナリオについて説明します。
アップグレード元の環境
2 台のコンピュータを使用して下表の構成で SQL Server 2005 ログ配布環境を作成しました。
コンピュータ名
バージョン
用途
SQL1
SQL Server 2005 (SP2)
プライマリ サーバー
SQL2
SQL Server 2005 (SP2)
セカンダリ サーバー
次の画面は、SQL Server Enterprise Manager でアップグレード前の環境を示しています。
アップグレードの方法
SQL Server 2008 オンライン ブックの「SQL Server 2005 のログ配布構成の SQL Server
2008 への移行 (http://msdn.microsoft.com/ja-jp/library/cc645954.aspx)」で記載されている
手順に基づき、フェールオーバーを併用する方法と併用しない方法の 2 種類のログ配布環境
のアップグレード シナリオを検証しました。
194
① フェールオーバーを併用しない手順の概要
この手順は、フェールオーバーを使用するシナリオより作業が単純ですが、停止時間が長くな
ります。プライマリ サーバー インスタンスに対するアップグレードが行われるため、その間
データベースは使用できなくなります。フェールオーバーを併用しない手順の概要は以下のと
おりです。
1. セカンダリ サーバー (SQL2) をアップグレード
2. プライマリ サーバー (SQL1) をアップグレード
次の図はフェールオーバーを併用しない手順でのアップグレードの検証に使用したログ配布
環境を示しています。
アップグレード作業手順表
フェールオーバーを併用しない作業手順は以下のとおりです。
手
順
SQL1
1
2
SQL2
プライマ
リ
サーバー
アップグレードの実施
SQL1
データベース
の可用性
SQL1
アップグレードの実施
アップグレー
ド中は使用不
可
アップグレードが完了すると、引き続きログ配布は機能し、通常の運用が可能となります。
手順 1．セカンダリ サーバー (SQL2) のアップグレード
まず、セカンダリ サーバー (SQL2) から SQL Server のアップグレード インストールを実
施します。
アップグレード インストールを開始するには、
「B.2.1 ①フェールオーバーを併用しない手順」
の手順 1 と同様に前提パッケージをインストールして、再起動後にインストール センターか
ら「SQL Server 2000 または SQL Server 2005 からのアップグレード」をクリックし、イン
ストール ウィザードを開始します。
195
以降の作業手順は、
「B.2.1 ①フェールオーバーを併用しない手順」の手順 1 と同様ですので
省略します。アップグレード インストール完了後 SQL2 の SQL Server 2005 ログ配布構成で
使用していたコピー、および復元ジョブを無効化する必要はありません。
手順 2．プライマリ サーバー (SQL1) のアップグレード
プライマリ サーバー (SQL1) で SQL Server のアップグレード インストールを実施します。
アップグレード インストールを開始するには、
「B.2.1 ①フェールオーバーを併用しない手順」
の手順 1 と同様に前提パッケージをインストールして、再起動後にインストール センターか
ら「SQL Server 2000 または SQL Server 2005 からのアップグレード」をクリックし、イン
ストール ウィザードを開始します。
以降の作業手順は、
「B.2.1 ①フェールオーバーを併用しない手順」の手順 1 と同様ですので
省略します。アップグレード インストール完了後 SQL1 の SQL Server 2005 ログ配布構成で
使用していたバックアップ ジョブを無効化する必要はありません。
この方法は、プライマリ サーバーのアップグレード中、データベースは使用できませんが、
アップグレードが完了すると、引き続きログ配布は機能し、通常の運用が可能となります。
196
② フェールオーバーを併用する手順の概要
この手順では、停止時間を最小限に抑えることができます。セカンダリ サーバー インスタン
スへの制御されたフェールオーバーを利用することでインスタンスをアップグレードする間、
データベースを使用することができます。
フェールオーバーを併用する手順の概要は以下のとおりです。
1. セカンダリ サーバー (SQL2) をアップグレード
2. プライマリ サーバー (SQL1) でログ末尾のバックアップを行う
3. セカンダリ サーバー (SQL2) に未適用のログとログ末尾のバックアップを適用してフ
ェールオーバーする
4. フェールオーバー後のセカンダリ サーバー (SQL1) でアップグレードを実施
5. フェールオーバー後のプライマリ サーバー (SQL2) でログ末尾のバックアップを行う
6. SQL1 にログ末尾のバックアップを適用してフェールオーバーする
次の図はフェールオーバーを併用する手順でのアップグレードの検証に使用したログ配布環
境を示しています。
アップグレード作業手順表
フェールオーバーを併用する作業手順は以下のとおりです。
手
順
SQL1
1
2
SQL2
プライマリ
サーバー
データベース
の可用性
アップグレードの実施
SQL1
可
SQL1
ログ末尾のバッ
ログ末尾のバックアップ
を行う
クアップ後、デ
ータベースはオ
フラインとなる
3
未 適用の ログフ ァイルと
SQL1
ロ グ末尾 のバッ クアップ
SQL2
197
→
フェールオーバ
ー中は利用不可
を適用し、フェールオーバ
ーする
(データベースのバージョ
ン がアッ プグレ ードされ
る)
4
アップグレードの実施
5
ロ グ末尾 のバッ クアップ
SQL2
可
SQL2
ログ末尾のバッ
を行う
クアップ後、デ
ータベースはオ
フラインとなる
6
ログ末尾のバックアップ
SQL2
を適用し、フェールオーバ
SQL1
→
フェールオーバ
ー中は利用不可
ーする
(データベースのバージョ
ンがアップグレードされ
る)
手順 1．セカンダリ サーバー (SQL2) のアップグレード
まず、セカンダリ サーバー (SQL2) から SQL Server のアップグレード インストールを実
施します。
アップグレード インストールを開始するには、
「B.2.1 ①フェールオーバーを併用しない手順」
の手順 1 と同様に前提パッケージをインストールして、再起動後にインストール センターか
ら「SQL Server 2000 または SQL Server 2005 からのアップグレード」をクリックし、イン
ストール ウィザードを開始します。
以降の作業手順は、
「B.2.1 ①フェールオーバーを併用しない手順」の手順 1 と同様ですので
省略します。アップグレード インストール完了後 SQL2 の SQL Server 2005 ログ配布構成で
使用していたコピー、および復元ジョブを無効化する必要はありません。
198
手順 2． プライマリ サーバー (SQL1) でログ末尾のバックアップを行う
クエリ エディタで SQL1 に接続して以下の BACKUP LOG ステートメントを作成し、末尾の
トランザクション ログをバックアップします。バックアップ先としてログ転送用のフォルダ以
外を使用します。
BACKUP LOG pubs
TO DISK = 'C:\LogBackup\pubs_tlog_TailLOG.TRN'
WITH NORECOVERY
このステートメントの WITH 句の指定により SQL1 のデータベースはオフラインになります。
手順 3．セカンダリ サーバー (SQL2) に未適用のログとログ末尾のバックアップを適用して
フェールオーバーする
SQL2 で SQL Server Management Studio のクエリエディタを使用し、以下のステートメン
トを実行します。
EXEC sp_help_log_shipping_monitor
last_resotred_file 列の情報から最後にセカンダリ データベースに適用されたトランザクシ
ョン ログ バックアップのファイル名を確認します。上の画面の場合、last_copied_file 列と
last_restoed_file 列の情報を比較して last_copied_file 列に示されているファイルは、未だセ
カンダリ データベースに適用されていないことが分かります。
残されているトランザクション ログ バックアップの適用はセカンダリサーバー側の SQL
Server エージェントの「LSCopy_プライマリサーバー名＿DB 名」
、および「LSRestore_プラ
イマリサーバー名＿DB 名」という名前のジョブを右クリックして [ステップでジョブを開始]
を選択して手動で実行することで行えます。
199
EXEC sp_help_log_shipping_monitor の実行結果ですべてのログ バックアップが適用された
ことを確認します。
次に作成した末尾のログ バックアップ ファイル (pubs_tlog_TailLOG.TRN) をセカンダリ
サーバー (SQL2) にコピーし、クエリ エディタで SQL2 に接続して以下の RESTORE LOG
ステートメントを作成し、末尾のログバックアップを適用します。
RESTORE LOG pubs
FROM DISK = 'C:\LogBackup\pubs_tlog_TailLOG.TRN'
WITH RECOVERY
このステートメントの WITH 句の指定により SQL2 のデータベースは、アップグレードされた
後にオンラインになります。この操作の結果、SQL2 はプライマリ サーバーとして稼働します。
手順 4．フェールオーバー後のセカンダリ サーバー (SQL1) でアップグレードを実施
プライマリ サーバー (SQL1) で SQL Server のアップグレード インストールを実施します。
アップグレード インストールを開始するには、
「B.2.1 ①フェールオーバーを併用しない手順」
の手順 1 と同様に前提パッケージをインストールして、再起動後にインストール センターか
ら「SQL Server 2000 または SQL Server 2005 からのアップグレード」をクリックし、イン
ストール ウィザードを開始します。
200
以降の作業手順は、
「B.2.1 ①フェールオーバーを併用しない手順」の手順 1 と同様ですので
省略します。
手順 5． フェールオーバー後のプライマリ サーバー (SQL2) でログ末尾のバックアップを行
う
クエリ エディタで SQL2 に接続して以下の BACKUP LOG ステートメントを作成し、末尾の
トランザクション ログをバックアップします。バックアップ先としてログ転送用のフォルダ以
外を使用します。
BACKUP LOG pubs
TO DISK = 'C:\LogBackup\pubs_tlog_TailLOG.TRN'
WITH NORECOVERY
このステートメントの WITH 句の指定により SQL2 のデータベースはオフラインになります。
手順 6． SQL1 にログ末尾のバックアップを適用してフェールオーバーする
作成した末尾のログ バックアップ ファイル (pubs_tlog_TailLOG.TRN) をセカンダリサー
バー (SQL1) にコピーし、クエリ エディタで SQL1 に接続して以下の RESTORE LOG ス
テートメントを作成し、末尾のログバックアップを適用します。
RESTORE LOG pubs
FROM DISK = 'C:\LogBackup\pubs_tlog_TailLOG.TRN'
WITH RECOVERY
このステートメントの WITH 句の指定により SQL1 のデータベースは、アップグレードされた
後にオンラインになります。この操作の結果、SQL1 はプライマリ サーバーとして稼働します。
201
注意 手順 2 では末尾のトランザクション ログ適用前に未適用のトランザクション ログをす
べて適用する作業を伴いましたが、セカンダリ サーバーには、バックアップ ジョブ（同様に
プライマリ サーバーではコピー、および復元ジョブ）が存在しないため「未適用のトランザ
クション ログの適用作業」は必要ありません。
202
B.3
データベース ミラーリング環境のアップグレード手順
データベース ミラーリングは、SQL Server 2005 SP1 よりサポートが開始された高速な自動
フェールオーバーをサポートするデータベース単位の高可用性ソリューションです。以降では、
データベース ミラーリング環境を SQL Server 2005 から SQL Server 2008 にアップグレ
ードする手順を説明します。
アップグレード元の環境
下表の 3 台のコンピュータを使用してトランザクションの安全性が「完全(FULL)」で動作す
る SQL Server 2005 データベース ミラーリング環境を作成しました。
コンピュータ名
バージョン
用途
SQL1
SQL Server 2005 (SP2)
プリンシパル サーバー
SQL2
SQL Server 2005 (SP2)
ミラー サーバー
SQL3
SQL Server 2008
ミラーリング監視サーバー
ミラーリング監視サーバーは、あらかじめ SQL Server 2008 にアップグレードしています。
アップグレード作業手順表
SQL Server 2005 データベース ミラーリング環境のアップグレード作業手順は以下のとおり
です。
手順
SQL1
SQL2
プリンシパル
ミラーリング
セッション
1
監視サーバーの削除
SQL1
Synchronized
SQL1
Synchronized
SQL1
Synchronized
(オプション)
2
トランザクションの安
全性を確認
3
4
アップグレードの実施
手動フェールオーバー
SQL1
の実施
SQL2
→
Synchronized
→ Suspended
(SQL2 は SQL
Server 2008 と
して稼働)
4
アップグレードの実施
SQL2
Suspended
6
データベース ミラーリ
SQL2
suspended
→
Synchronized
ング セッションを再開
(SET
PARTNER
RESUME 実 行
後にステータス
203
が変更される)
7
SQL2
監視サーバーの追加
アップグレード作業手順
アップグレード作業手順は以下のとおりです。
手順 1. 監視サーバーの削除 (オプション)
以下のステートメントによりミラーリング監視 サーバーをミラーリング セッションから削
除します。
ALTER DATABASE データベース名
SET WITNESS OFF
手順 2. トランザクションの安全性を確認
デ ー タ ベ ー ス ミ ラ ー リ ン グ モ ニ タ か 、 sys.database_mirroring カ タ ロ グ ビ ュ ー の
mirroring_safety_level 列および mirroring_safety_level_desc 列で現在のトランザクション
の安全性を確認します。本手順書では、「トランザクションの安全性」 が 「完全 (FULL)」
である必要がります。それ以外に設定されている場合は、以下のステートメントを実行して「完
全(FULL)」に変更します。
ALTER DATABASE データベース名
SET PARTNER SAFETY FULL
この同期動作モードは移行の手順の手動フェールオーバーを行うための前提条件となります。
手順 3. SQL2 のアップグレードの実施
手順 1 を行わなかった場合、アップグレード インストール後、ミラーリング監視サーバーは
SQL Server のセットアップ プロセスにより削除されます。
アップグレード インストール中にシステムデータベース(master、msdb、model)やデータベ
ース ミラーリング構成になっていないユーザーデータベース等は、アップグレードされます
が、この時点では、データベース ミラーリング構成のデータベースはアップグレードされて
いません。
手順 4. 手動フェールオーバーの実施
フェールオーバー実行後、SQL2 側のデータベース ミラーリング構成のデータベースがアッ
プグレードされます。このフェールオーバー完了後、ミラーリング セッションの状態は
「SUSPEND」になります。
204
手順 5. SQL1 のアップグレードの実施
アップグレード インストール中にシステムデータベース(master、msdb、model)やデータベ
ース ミラーリング構成になっていないユーザーデータベース等は、アップグレードされます。
手順 6. データベース ミラーリング セッションを再開
以下のステートメントによりミラーリング セッションを再開します。
ALTER DATABASE データベース名
SET PARTNER RESUME
手順 7. 監視サーバーの追加
以下のステートメントによりミラーリング セッションにミラーリング監視サーバーを追加し
ます。
ALTER DATABASE データベース名
SET WITNESS = ‘TCP://監視サーバーのアドレス:ポート番号’
「トランザクションの安全性」 が 「完全(FULL)」に設定されたミラーリング セッションに
ミラーリング監視サーバーを追加することで、自動フェールオーバー機能が使用できます。
以上
205