sql server 2008 徹底検証シリーズdownload.microsoft.com/download/f/1/0/f10bc023-9396-4d67...5...

SQL Server 2008 徹底検証シリーズ

データベースサーバー統合実践ガイド

Published．2008 年 10 月 31 日

3

© 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

4

はじめに

このホワイトペーパーは、SQL Server 2008 早期実証プロジェクト「CQI」（Center of Quality

Innovation）の成果物です。

CQI は、マイクロソフトと日本ヒューレット・パッカード株式会社、日本ユニシス株式会社、

日本電気株式会社の 3 社と共同で実施し、実際のユーザーに対する SI（System Integration）

プロジェクトを想定した「RFP」（Request for Proposal：提案依頼書）に基づいた「機能動作

検証」や「パフォーマンス検証」を行ったプロジェクトです。

このプロジェクトでは、次の 4 つのシナリオを実施しています。

サーバー統合シナリオ

日本ヒューレット・パッカード株式会社様との共同検証プロジェクト。複数の SQL

Server を 1 台の 64 ビットサーバーへ集約するメリット・運用管理方法などに関する検

証を実施

コンプライアンスシナリオ

マイクロソフトによる検証プロジェクト。内部統制や日本版 SOX 法、情報漏えい対策で

求められるコンプライアンスに対応するためのガイドライン提示を目的とし、日本版SOX

法への対応に必要となる機能の実装方法の確立やシステムに与える影響の計測などを実

施

DWH（データウェアハウス）シナリオ

日本電気株式会社様との共同検証プロジェクト。SQL Server 2008 の大規模データウェ

アハウス環境における実装方法の検証を実施

移行／アップグレードシナリオ

日本ユニシス株式会社様との共同検証プロジェクト。SQL Server 2000 および 2005 か

CQI

(Center of Quality Innovation)

実際の System Integration

プロジェクトを想定

検証内容

• SQL Server 2008 早期実証

／検証プロジェクト

• 提案依頼書（RFP）

• 機能動作検証

• パフォーマンス検証

•コンプライアンス•サーバー統合

•移行/アップグレード•データウェアハウス

日本電気

株式会社

日本ユニシ

ス株式会社

マイクロソ

フト

日本ヒュー

レット・

パッカード

株式会社

5

ら、SQL Server 2008 への移行や互換性に関する検証を実施

サーバー統合シナリオ実施の背景

32-bit 環境で稼働している 4 つのデータベースサーバーを、1 台の 64-bit サーバーへ集約

（コンソリデーション）するにあたって、どういった手法があるのか、それぞれの手法のメリ

ット／デメリットは何なのか、性能の差はあるのか、このシナリオでは、分散されたデータベ

ースサーバー環境を SQL Server 2008 へ統合するための実践ガイドを作成することを目的

としました。

データベースサーバー統合に関連する SQL Server の各機能や性能測定の結果を解説しなが

ら各手法のメリットとデメリットを解説しています。

実証プロジェクトの成果（サーバー統合シナリオ）

詳しくは、文書内へ記述していますが、この実証プロジェクトをとおして、次のことを確認す

ることができました。

データベースサーバー統合にあたっては、SQL Server 2008 からの新機能である「リソー

スガバナ」と「パフォーマンスデータコレクション」「ポリシーベースの管理」が役

立つことを確認することができました。

シングルインスタンスでのサーバー統合では、「リソースガバナ」によるリソース調整

を行うことで、パフォーマンスを向上させることができることを確認できました。

マルチインスタンスでのサーバー統合では、「CPU アフィニティ」と「Max Server

Memory」パラメータによるリソース調整を行うことで、パフォーマンスを向上させること

ができることを確認できました。

ハードウェアパーティションモデルでは、OS と SQL Server の修正プログラムのレベ

ルをパーティションごとに変更できるメリットがあります。

シングルインスタンスとマルチインスタンスモデルでの性能比較は、決定的な差が現れ

なかったため、両モデルの比較は、運用管理面でのメリット／デメリットやライセンス面

などを含めて総合的に判断することが重要です。

修正プログラムの適用や、定期メンテナンス処理、システム監視などの運用管理操作は、

インスタンスの数分実行する必要があります。したがって、シングルインスタンスモデ

ルでは、運用管理操作が 1 回だけで済むため、運用管理面でメリットがあります。

障害対策面では、シングルインスタンスモデルでは、SQL Server のインスタンス障害が

他のデータベースへも影響があるのに対して、マルチインスタンスモデルでは、SQL

Server のインスタンス障害は他のインスタンス（データベース）には影響を与えません。

6

目次

はじめに .................................................................................................................................. 4

目次 .......................................................................................................................................... 6

第 1 章現状のシステムまたはビジネスの問題点 .................................................................. 7

1.1 現状のシステム 7

1.2 現状の問題点 7

第 2 章 RFP（Request for Proposal：提案依頼書） ............................................................ 8

2.1 RFP（提案依頼書）の内容 8

第 3 章 RFP に対する SQL Server 2008 のソリューション ............................................ 10

3.1 サーバー統合（コンソリデーション）の手法 10

3.2 運用サービス要件に対するソリューション 12

3.3 RFP 要件に対するソリューションのまとめ 24

第 4 章ソリューション作成時の挙動およびパフォーマンス .............................................. 27

4.1 検証環境 27

4.2 検証パターン 27

4.2 検証結果 29

第 5 章まとめ ....................................................................................................................... 34

付録 A ソリューション内にある技術解説 ............................................................................ 35

A.1 リソースガバナ（インスタンス内でのリソース調整） 35

A.2 マルチインスタンスでのインスタンス間のリソース調整 41

A.3 リソースの監視（パフォーマンスデータコレクション） 44

A.4 構成管理（ポリシーベースの管理による集中管理） 48

A.5 バックアップ／復元 52

A.6 データベース運用の技術解説 59

A.6.1 管理タスクの自動化（Agent ジョブ機能） 59

A.6.2 DBCC CHECKDB コマンドによる一貫性チェック 60

A.6.3 オンラインでのインデックスの再構築／再編成 62

A.6.4 データコレクションによる定期的なデータ収集 65

A.7 ユーザー管理 67

7

第 1 章現状のシステムまたはビジネスの問題点

1.1 現状のシステム

ある架空のユーザー企業「X 社」では、現在 SQL Server 2005 で動作している業務システム

（OLTP 系の処理）を 4 台の 32-bit サーバーで運用しています。

1.2 現状の問題点

現在、X 社では、以下の問題点を抱えており、これらの問題点を解決するために新システムの

導入を予定しています。

(1) 運用コストの増大

修正プログラムの適用や日々の運用／定期メンテナンスコストの増大

(2) ハードウェアの監視、管理が煩雑である

(3) ハードウェアリソースの有効活用ができていない

不要になったシステムのハードウェアリソースを有効活用できていない

突発的なアクセス増大に対する柔軟な対応ができていない（夜間や月末だけアクセスが

増えるなどの計画的なアクセス増大への対応）

(4) 資産管理面での困難さ

サーバー数が多く、資産管理が大変である

将来の増強に対し、柔軟に対応したい（今後もデータベースシステムが増える予定だが

新たにサーバーを増強したくない）

予算を削減したい

SQL Server 2005Microsoft




処理内容・昼間： OLTP 系処理・夜間：バッチ系処理、メンテナンス作業

4台のサーバー構成・ HP ProLiant DL385

・ 32-bit サーバー／Windows Server 2003／SQL Server 2005 SP2

8

第 2 章 RFP（Request for Proposal：提案依頼書）

2.1 RFP（提案依頼書）の内容

X 社から依頼を受けた「RFP」（提案依頼書）の内容は、次のとおりです。

概要

業務システムのコンソリデーション

4 台の 32-bit サーバーを 1 台の 64-bit サーバーへ統合

目的

新システムの目的は、次のとおりです。

安定的、効率的、かつ安全で高品質なシステム運用の実施

システム運用コストの削減

顧客への 24 時間 365 日の情報提供によるサービス向上

提案依頼内容

複数台で運用している業務システムを１台のサーバーに集約（コンソリデーション）を行う。

サーバー統合（コンソリデーション）の方式は、複数提案していただく

各方式でのパフォーマンス検証を行い、その結果は、サーバー集約前と同等またはそれ

以上とする

各方式の運用サービス要件における長所／短所を明確に示していただく

システム要件

サーバープラットフォームは、64-bit 機を使用する。

運用サービス要件

運用サービス要件は、次のとおり。

日常オペレーション

運用項目内容要件

サービス開始、終了 24 時間 365 日運用夜間バッチは、0:00 ~ 6:00

システム監視

(ジョブ監視、セキュ

リティ監視、資源監

視、ログ監視含む)

システム動作異常監視（OS および

SQL Server の監視）簡素化したい。監視を統合したい

リソース動的配分 CPU 使用率、メモリ使用率、ディスク

使用率等

常に。

夜間バッチ処理は、リソースの配分比

率を高くする

バックアップ、運用

管理毎日（正副保管）取得

対象は、全ユーザーデータベースとす

る。システムデータベースについて

9

は、週次でバックアップする

データベース運用

・DBCC によるデータベースのチェック

・統計情報取得

・オンラインでのインデックス再構築

・インデックスのチューニング

構成管理パラメータ設定集中管理したい。

柔軟性を持たせたい

修正プログラム適用 Windows OS の修正プログラム適用

SQL Server の修正プログラム適用修正プログラム運用を簡素化したい

ハードウェアの構成

変更最小限の停止で柔軟に対応できること

障害対応

運用項目内容備考

インスタンス障害

・アプリケーションソフトウェアの異常

発生時の一時切り分け

・リカバリ処理、再起動／再処理等

・SQL Server のみを対象

・台数分の監視が必要

・システムダウン時の影響を極小化

したい（⇔ メンテナンスの簡素化）

システム異常

・ハードウェア／システムソフトウェア／

ネットワーク異常発生時の一次切り分け

・ベンダーへの連絡、協力、立会、確認

・システムダウン

・ハードウェアと OS システムダ

ウン時の影響を極小化したい

運用管理

運用項目内容備考

ユーザー管理変更発生時にオペレーション・Windows 統合認証を使用すること

・データベースのアクセス権限を厳重に行うこと

移行

・アプリケーションの変更の作業の軽減

・インスタンス分の環境設定

・ユーザーの管理

対象外

以下の内容は、対象外とする

仮想化

以下のサービスについては、サーバー統合を行わない

Analysis Services、Integration Services、Reporting Services

10

第 3 章 RFP に対する SQL Server 2008 のソリューション

この章では、X 社からの RFP（提案依頼書）に対する SQL Server 2008 でのソリューション（具体

的な解決策）を説明します。

3.1 サーバー統合（コンソリデーション）の手法

RFP にあるサーバー統合（コンソリデーション）に対するソリューションには、次の 3 つの

方式があります。

ハードウェアパーティションモデル

シングルインスタンスモデル

マルチインスタンスモデル

それぞれの特徴は、次のとおりです。

(1) ハードウェアパーティションモデル

ハードウェア（H/W）パーティションモデルは、ハードウェアのパーティション技術（HP

nPartitions など）を使用して、ハードウェアレベルで電気的にパーティションを分離する方

法です。このモデルでは、次のように、1つのパーティション内に 1つの OS（Windows Server）、

1 つの SQL Server インスタンス、1 つのデータベースを保持する構成をとります。

このモデルのメリットは、次のとおりです。

他の OS やデータベース障害の影響を受けない

物理的配置を含めて、管理の集中化が可能

パーティションごとにメンテナンス／チューニングが可能

サーバー統合後サーバー統合前分散したDB 環境

HWパーティション#1

サーバー統合

Windows OS

SQL ServerWindows OS

SQL Server


Windows OS

SQL Server


Windows OS

SQL Server


Windows OS

SQL Server

Windows OS

SQL Server

Windows OS

SQL Server

Windows OS

SQL Server

DB

DB

DB

DB

サーバーをハードウェアパーティションで複数に分割

複数のハードウェアパーティション上に、OSを配置

複数の OS 上にSQL Server を配置

複数の SQL Server

上に DB を配置

HWパーティション： 4

Windows OS ： 4

SQL Server ： 4

DB 4つに対して

DB

DB

DB

DB

11

一方、デメリットは、次のとおりです。

リソースの再配分時に OS の再起動が必要

(2) シングルインスタンスモデル

シングルインスタンスモデルは、1 つの SQL Server インスタンス内へ複数のデータベース

を保持するモデルです。次のように 1 つのハードウェアパーティション内へ、1 つの OS

（Windows Server）、1 つの SQL Server インスタンス、複数のデータベースを保持する構成

をとります。


OS および SQL Server を 1 つ構築するだけで良い

修正プログラムの適用回数の削減

サーバーライセンス費用の削減


OS／インスタンス障害は、すべてのデータベースへ影響

(3) マルチインスタンスモデル

マルチインスタンスモデルは、複数の SQL Server インスタンス内へ複数のデータベース

を保持するモデルです。次のように 1 つの OS（Windows Server）へ、複数の SQL Server イ

ンスタンス、それぞれのインスタンスごとにデータベースを保持する構成をとります。

サーバー統合後サーバー統合前分散したDB 環境


サーバー統合

Windows OS

SQL Server

Windows OS

SQL Server

DB

Windows OS

SQL Server

DB

Windows OS

SQL Server

DB

Windows OS

SQL Server

DB

サーバーにハードウェアパーティションを１つだけ構築

ハードウェアパーティション上に、OS を１つ配置

OS 上に SQL Server

を１つだけ配置

SQL Server 上に DB

を配置


Windows OS ： 1

SQL Server ： 1

DB 4つに対して

DB

DB

DB

DB

12


インスタンスごとにリソースの割り当てが可能

インスタンス単位でのメンテナンス／チューニングが可能

フェールオーバークラスタの Active／Active 構成が可能

SQL Server 2008 では、スタンドアロン構成で 50、クラスタ構成で 25 までの構成（イ

ンスタンス）が可能。Workgroup Edition では、コンピュータあたり最大 16 個のイン

スタンスがサポートされる


OS 障害は、すべてのデータベースへ影響

インスタンスの管理対象が増える

3.2 運用サービス要件に対するソリューション

それぞれの 3 つのサーバー統合モデルについて、運用サービス要件ごとのソリューションは、

次のようになります。

3.2.1 日常オペレーション要件に対するソリューション

サービス開始、終了

サービス開始と終了に関する RFP の要件は、「24 時間 365 日の運用」です。これに対するソ

リューションは、次のとおりです。

サーバー統合モデル RFP 対応度、優位性

(◎/ ○/ △/ ×）実現手法

共通 ◎ フェールオーバークラスタによる 24時間 365日運用の実現を行う。た

だし、統合モデルによって、留意点がある

サーバー統合前分散したDB 環境


サーバー統合後

サーバー統合

Windows OS

SQL Server

SQL Server

SQL Server

SQL Server

Windows OS

SQL Server

DB

Windows OS

SQL Server

DB

Windows OS

SQL Server

DB

Windows OS

SQL Server

DB

サーバ^にハードウェアパーティションを１つだけ構築

ハードウェアパーティション上に、OS を１つ配置

OS 上に複数の SQL

Server を配置


上に DB を配置


Windows OS ： 1

SQL Server ： 4

DB 4つに対して

サーバーにハードウェアパーティションを１つだけ構築


上に DB を配置

DB

DB

DB

DB

13

ハードウェアパーテ

ィションモデル ◎

各パーティションは、セル単位で電気的に区切られているので、障害発生

時に他のセルの SQL Server およびデータベースへ影響を与えない

シングルインスタン

スモデル ○

障害発生時には、SQL Server インスタンス全体がフェールオーバーして

しまうので、インスタンス内の全データベースが影響を受けてしまう

マルチインスタンス

モデル ○ 障害発生時には、個別のデータベースのみがフェールオーバーする

24 時間 365 日の運用は、フェールオーバークラスタ（MSCS: Microsoft Cluster Service）を

利用することで実現可能です。ただし、それぞれのモデルごとに動作の違いがあります。

ハードウェアパーティションモデルでは、各パーティションは、セル単位で電気的に区切ら

れているので、障害発生時に他のセルの SQL Server およびデータベースへの影響はありま

せん。

これに対して、シングルインスタンスモデルでは、障害発生時には、SQL Server インスタ

ンス全体がフェールオーバーしてしまうので、インスタンス内のすべてのデータベースが影響

を受けてしまいます。

マルチインスタンスモデルでは、障害発生時には、個別のデータベースのみがフェールオー

バーするので、ほかのインスタンスへの影響はありません。

システム監視（ジョブ監視、セキュリティ監視、資源監視、ログ監視含む）

システム監視に関する RFP の要件は、次のとおりです。

システム動作異常監視（OS および SQL Server の監視）を簡素化すること

これに対するソリューションは、次のとおりです。


(◎/ ○/ △/ ×）実現手法

共通

監視対象の数がモデルによって変化

ハードウェアパー

ティションモデル △

OS : 4

SQL Server : 4

シングルインスタ

ンスモデル ◎

OS : 1

SQL Server : 1

マルチインスタン

スモデル ○

OS : 1

SQL Server : 4

監視対象の数は、インストールした OS の数と SQL Server のインスタンス数によって異な

ります。

ハードウェアパーティションモデルでは、パーティションごとに OS と SQL Server をイ

ンストールするので、OS が 4 つ、SQL Server も 4 つと、監視対象が最も多くなります。

これに対して、シングルインスタンスモデルでは、OS が 1 つ、SQL Server が 1 つと、

監視対象を最も尐なくすることができます。マルチインスタンスモデルでは、OS は 1 つで

すが、SQL Server はインスタンスの数分だけ、監視対象が増えることになります。

14

リソース動的配分

リソース動的配分に関する RFP の要件は、「CPU 使用率」や「メモリ使用率」、「ディスク使

用率」等のリソースに対して、以下の要件を満たすことです。

常に監視を行い、リソースを動的に調整すること

夜間バッチ処理は、リソースの配分比率を高くすること



(◎/ ○/ △/ ×）実現手法

共通 ◎ ・リソースガバナでリソースの調整を行う

・リソース監視には、パフォーマンスデータコレクションを使用



パーティション間のリソース調整は、ハードウェア固定の割り付けによる

ので、SQL Server からの設定は不可能


ンスモデル ◎

インスタンス内のリソース調整は、リソースガバナを使用して、CPU と

メモリリソースの調整が可能


スモデル ○

インスタンス間のリソース調整

・CPU は、Affinity Mask の構成変更による設定が可能

・メモリは、Max Server Memory / Min Server Memory による設定

が可能

インスタンス内のリソース調整は、シングルインスタンスモデルと同

様、リソースガバナを使用して、CPU とメモリリソースの調整が可能

ハードウェアパーティションモデルでは、リソースの割り付けがパーティションごとに固定

になるため、動的なリソース調整を行うことができません。

これに対して、シングル／マルチインスタンスモデルでは、インスタンス内のリソース調整

には、SQL Server 2008 からの新機能である「リソースガバナ」を利用できます。リソース

ガバナでは、CPU およびメモリ使用率をワークロード単位で調整することが可能です。リソ

ースガバナによるリソース調整は、SQL Server を停止することなく、動的に設定すること

ができるため、日中の OLTP 処理と夜間のバッチ処理で、リソースの配分比率を変更するこ

とも容易に実現できます。

次の画面は、リソースガバナを利用して、CPU 使用率を制限しているときの様子です。

ワークロード B は、CPU を 30％しか利用できないように制限

ワークロード A は、CPU を 70％利用している

15

マルチインスタンスモデルモデルでのインスタンスをまたがった（インスタンス間の）リ

ソース調整は、「CPU アフィニティ」と「Max／Min Server Memory」パラメータを利用す

ることで可能です。このパラメータにより、各インスタンスが利用する CPU やメモリ使用量

を調整することが可能です。また、このパラメータは、リソースガバナと同様、SQL Server

を停止することなく、動的に設定変更することができます。

このようにリソースガバナおよび設定パラメータ（CPU アフィニティと Max／Min Server

Memory）を利用することで、不要になったシステムのハードウェアリソースの有効活用や、

夜間や月末だけアクセスが増えるなどの計画的なアクセス増大への対応も可能になります。

RFP の要件にある「リソースの監視」は、SQL Server 2008 からの新機能である「パフォー

マンスデータコレクション」を利用することで可能です。

次のレポートは、パフォーマンスデータコレクション機能を利用して、リソースの監視をし

ている様子です。

パフォーマンスデータコレクションを利用すると、CPU 利用率やメモリ使用量などを過去

にさかのぼってグラフィカルに監視することが可能です。

また、レポートでは、グラフ内をクリックすると、その詳細を参照することも可能です。

「CPU 使用率」グラフのクリックにより、各 CPU コアごとの CPU 利用率を参照可能

「ディスク I/O の使用量」グラフのクリックにより、各ドライブごとの応答時間やキュー（ディスク待ち）の長さを参照可能

16

構成管理

構成管理に関する RFP の要件は、次のとおりです。

パラメータ設定を集中管理したい

パラメータ設定の柔軟性を持たせてほしい



(◎/ ○/ △/ ×）実現手法

共通 ◎ ポリシーベースの管理を使用したサーバーの管理


ティションモデル ◎ ポリシーベースの管理／パーティション間での設定


ンスモデル ◎ ポリシーベースの管理


スモデル ◎ ポリシーベースの管理／マルチインスタンス間での設定

パラメータ設定は、SQL Server 2008 からの新機能である「ポリシーベースの管理」を利用

することで、複数のインスタンスを集中管理することが可能です。

次の画面は、ポリシーベースの管理機能を利用して、複数の SQL Server インスタンスの

CPU アフィニティ設定をチェックしているところです。

このように、ポリシーベースの管理機能を利用すれば、複数の SQL Server インスタンスに

対するパラメータ設定を集中管理することが可能です。

複数のサーバーのパラメータ設定を集中管理可能

17

バックアップ、運用管理

バックアップ、運用管理に関する RFP の要件は、次のとおりです。

全ユーザーデータベースのバックアップを毎日（正副保管）取得すること

システムデータベースのバックアップを週次で取得すること



(◎/ ○/ △/ ×）実現手法

共通 ◎

・BACKUP ステートメントを使用

・ユーザーデータベースに関しては、対象数に比例する

・システムデータベースのバックアップは、インスタンス数に比例する


ティションモデル ○ パーティション数分、システムデータベースのバックアップが必要


ンスモデル ◎ システムデータベースのバックアップは、１回のみ


スモデル ○ インスタンスの数分のシステムデータベースのバックアップが必要

バックアップは、通常の SQL Server に対するバックアップと同様、BACKUP ステートメン

トを利用して、オンラインで（SQL Server を停止することなく）実行可能です。

ユーザーデータベースのバックアップ回数は、バックアップ対象のデータベース数に比例し

ます（今回のシナリオでは、すべてのモデルで 4 回＝ 4 つのデータベース）。

システムデータベース（master や msdb、model など）のバックアップ回数は、インスタ

ンス数に比例するため、ハードウェアパーティション／マルチインスタンスモデルでは、4

回分のシステムデータベースのバックアップが必要になるのに対して、シングルインスタン

スモデルでは、1 回で済みます。

データベース運用

データベース運用に関する RFP の要件は、次のとおりです。

DBCC によるデータベースの一貫性チェック

オンラインでのインデックス再構築／再編成

インデックスのチューニング

統計情報取得（クエリ統計やインデックス断片化情報などの取得）

対象は、システムデータベースと全ユーザーデータベースとする。



(◎/ ○/ △/ ×）実現手法

共通 ◎

オンラインでのインデックス再構築と DBCC によるデータベースのチ

ェックは、夜間バッチ中に行うか、または、昼間の O LTP 処理の尐ない

時間に行うかを監視しながら見極める。その際も、リソースガバナでリ

ソース調整を行う。

18

統計情報は、データコレクションで定期的に取得する


ティションモデル ○ 実行回数は、データベースの数分行う


ンスモデル ○ 同上


スモデル ○ 同上

オンラインでのインデックス再構築と DBCC によるデータベースの一貫性チェックは、夜間

バッチ中に行うか、または昼間の OLTP 処理の尐ない時間に行うかを監視しながら見極める

ようにします。実行の際には、リソースガバナでリソース調整を行うことが可能です。

統計情報（クエリ統計やインデックス断片化情報など）は、SQL Server 2008 からの新機能

である「データコレクション」機能によって定期的に取得することが可能です。

修正プログラム運用

修正プログラム運用に関する RFP の要件は、次のとおりです。

Windows OS に対する修正プログラムの適用を簡素化すること

SQL Server に対する修正プログラムの適用を簡素化すること



(◎/ ○/ △/ ×）実現手法

共通

Windows OS の修正プログラム適用回数＝ OS の数

SQL Server の修正プログラム適用回数 = SQL Server のインスタンス数



Windows OS の修正プログラム適用回数＝4 (OS の数)

SQL Server の修正プログラム適用回数= 4 (SQL Server インスタンス数)

パーティションごとに、OS と SQL Server の修正プログラムレベルを

変更することが可能である。


ンスモデル ◎




スモデル △



インスタンスごとに、SQL Server の修正プログラムレベルを変更するこ

とが可能である。

修正プログラムの適用回数は、OS および SQL Server のインスタンス数によって異なります。

ハードウェアパーティションモデルでは、OS が 4 回、SQL Server も 4 回と、適用回数

が最も多くなります。

これに対して、シングルインスタンスモデルでは、OS が 1 回、SQL Server が 1 回と、

最も尐なくすることができます。

マルチインスタンスモデルでは、OS は 1 回ですが、SQL Server はインスタンスの数分だ

19

け、適用回数が増えることになります。

なお、ハードウェアパーティションモデルでは、パーティションごとに、OS と SQL Server

の修正プログラムレベルを変更することが可能です。

ハードウェアの構成変更

ハードウェアの構成変更に関する RFP の要件は、次のとおりです。。

最小限の停止で柔軟に対応できること



(◎/ ○/ △/ ×）実現手法

共通


ティションモデル ◎ 他のパーティションに依存しないので、自由に作業が可能である


ンスモデル △

他のシステムに依存してしまう。必要に応じて、フェールオーバークラ

スタで冗長化を行うことで可能となる


スモデル △

他のシステムに依存してしまう。必要に応じて、フェールオーバークラ

スタで冗長化を行うことで可能となる

インスタンス間で、SQL Server の修正プログラムレベルを変更すること

が可能である

ハードウェアの構成変更は、ハードウェアパーティションモデルが優位です。このモデルで

は、他のパーティションに依存せずに、ハードウェアの構成変更を自由に作業が可能です。

20

3.2.2 障害対応要件に対するソリューション

インスタンス障害

インスタンス障害に関する RFP の要件は、次のとおりです。

アプリケーションソフトウェアの異常発生時の一時切り分け

リカバリ処理、再起動／再処理等

対象は、SQL Server のみとし、システムダウン時の影響を極小化したい（メンテナン

スの簡素化）



(◎/ ○/ △/ ×）実現手法

共通

監視は、Management Studio から一元管理が可能である


ティションモデル ◎

SQL Server のインスタンス障害時は、他のパーティションに影響を与え

ない


ンスモデル ○

SQL Server のインスタンス障害時には、すべてのデータベースが影響を

受けてしまう


スモデル ○

SQL Server のインスタンス障害時は、他のインスタンスに影響を与えな

い

監視は、SQL Server Management Studio ツールを利用して一元管理が可能です。ハードウ

ェアパーティション／マルチインスタンスモデルでは、SQL Server のインスタンス障害

は、他のデータベースへ影響を与えませんが、シングルインスタンスモデルでは、SQL Server

インスタンスの障害が、すべてのデータベースへ影響を与えてしまいます。

なお、フェールオーバークラスタを構成することによって、SQL Server インスタンスの障

害時に、迅速な障害復旧が可能になります。フェールオーバークラスタを構成した場合の各

モデルの動作の違いについては、前述の「24 時間 265 日運用」の項を参照してください。

システム異常

システム異常に関する RFP の要件は、次のとおりです。

ハードウェア／システムソフトウェア／ネットワーク異常発生時の一次切り分け

対象は、ハードウェアと OS を含み、システムダウン時の影響を極小化したい



(◎/ ○/ △/ ×）実現手法

共通


ティションモデル ◎

システムダウン時の影響を極小化するためには、ハードウェアパーティ

ションを使用して、他のパーティションに影響を与えない構築を行う


ンスモデル △

ハードウェアまたは OS レベルでシステムダウンが発生した場合は、他

のシステムへの影響が回避できない

21


スモデル △

ハードウェアまたは OS レベルでシステムダウンが発生した場合は、他

のシステムへの影響が回避できない

ハードウェアパーティションモデルでは、OS レベルでのシステムダウン時にも、他のデ

ータベースへの影響はありませんが、シングル／マルチインスタンスモデルでは、OS レベ

ルのシステムダウンは、すべてのデータベースが影響を受けてしまいます。

なお、フェールオーバークラスタを構成している場合は、OS レベルでのシステムダウンが

発生した場合にも、迅速な障害復旧が可能になります。

3.2.3 運用管理要件に対するソリューション

ユーザー管理

ユーザー管理に関する RFP の要件は、次のとおりです。

変更発生時にオペレーション

Windows 統合認証を使用すること

データベースに対するアクセス権限を厳重に設定すること



(◎/ ○/ △/ ×）実現手法

共通 ◎

・Windows 統合認証でセットアップを行う

・セットアップの設定画面

・データベースに対するアクセス権限

・ユーザー名の登録

・ログインアカウントの登録

・ロールの設定

・データベースオブジェクトに対する権限の設定

・スクリプトでの設定

・Management Studio での設定


ティションモデル ◎ データベースオブジェクトに対する権限設定を厳重に行う


ンスモデル ◎

データベースオブジェクトに対する権限設定を厳重に行う。インスタン

スレベルの管理者アカウントに対しては、特に厳重に行っておくことが

重要となる


スモデル ◎ データベースオブジェクトに対する権限設定を厳重に行う

SQL Server では、Windows 統合認証を利用することで、ユーザーを一元管理できるように

なります。また、ログインアカウント／データベースユーザーおよびオブジェクト権限をし

っかりと管理しておくことで、データベースに対するアクセス権限を厳重に行うことが可能で

す。

シングルインスタンスモデルでは、インスタンスレベルの管理者アカウントが、すべての

データベースを管理可能になるため、特に厳重に設定を行っておくことが重要です。

22

移行（マイグレーション）

移行に関する RFP の要件は、次のとおりです。

アプリケーションの変更作業の軽減

インスタンス分の環境設定（照合順序）

ユーザーの管理

移行時の「アプリケーションの変更作業の軽減」に対するソリューションは、次のとおりです。


(◎/ ○/ △/ ×）実現手法

共通

統合により、インスタンス名の変更を要する場合があり、アプリケーショ

ンから接続する接続文字列（Connection String）の変更を行う


ティションモデル ◎ 変更なし


ンスモデル ○

統合元のインスタンス名に依存する。統合元と統合先のインスタンス名が

同じ場合、変更しなくても良い


スモデル ○

統合元のインスタンス名に依存する。統合元と統合先のインスタンス名が

同じ場合、変更しなくても良い

サーバー統合によって、インスタンス名の変更が発生する場合は、アプリケーションから接続

する接続文字列（Connection String）の変更を行う必要があります。

移行時の「インスタンスごとの環境設定（照合順序）」に対するソリューションは、次のとお

りです。


(◎/ ○/ △/ ×）実現手法

共通

統合した場合、インスタンス内の照合順序を考慮する必要がある


ティションモデル ◎ 照合順序の影響はない


ンスモデル △

統合元の照合順序が統合先のインスタンスの照合順序と違う場合には、検

索結果が異なる可能性がある。また、TempDB や SQLCLR などがイン

スタンスレベルの照合順序の影響を受ける


スモデル ◎ 照合順序の影響はない

ハードウェアパーティション／マルチインスタンスモデルでは、照合順序の影響はありま

せんが、シングルインスタンスモデルでは、移行元と移行先で照合順序が違う場合に注意す

る必要があります。照合順序が違う場合は、検索結果が異なる可能性があり、また TempDB

／SQLCLR などがインスタンスレベルの照合順序の影響を受けることになるので、照合順序

を統一しておくようにします。

23

移行時の「ユーザーの管理」に対するソリューションは、次のとおりです。


(◎/ ○/ △/ ×）実現手法

共通 ◎ Windows 統合認証を使用して、一元管理を行う


ティションモデル ◎ 同上


ンスモデル ◎ 同上


スモデル ◎ 同上

24

3.3 RFP 要件に対するソリューションのまとめ

以上、RFP 要件に対するソリューションをまとめると、次のようになります。

日常オペレーション

RFP 要件モデル

実現手法

サービス開始、

終了

(24時間 365日

の運用)

共通 ◎ フェールオーバークラスタによる 24時間 365日運用の実現を行う。ただし、統合モ

デルによって、留意点がある

(1) ◎ 各パーティションは、セル単位で電気的に区切られているので、障害発生時に他のセ

ルの SQL Server およびデータベースへ影響を与えない

(2) ○ 障害発生時には、SQL Server インスタンス全体がフェールオーバーしてしまうので、

インスタンス内の全データベースが影響を受けてしまう

(3) ○ 障害発生時には、個別の DB のみがフェールオーバーする

システム監視

(OS および

SQL Server の

監視)

共通

監視対象の数がモデルによって変化

(1) △ OS : 4、SQL Server : 4

(2) ◎ OS : 1、SQL Server : 1

(3) ○ OS : 1、SQL Server : 4

リソース動的

配分

共通 ◎ ・リソースガバナでリソースの調整を行う

・リソース監視には、パフォーマンスデータコレクションを使用

(1) △ パーティション間のリソース調整は、ハードウェア固定の割り付けによるので、SQL

Server からの設定は不可能

(2) ◎ インスタンス内のリソース調整は、リソースガバナを使用して、CPU とメモリリ

ソースの調整が可能

(3) ○

インスタンス間のリソース調整

・CPU は、CPU Affinity Mask の構成変更で設定可能

・メモリは、MAX Server Memory / Min Server Memory で設定可能

インスタンス内のリソース調整は、シングルインスタンスモデルと同様

構成管理

(パラメータ設

定の集中管理)

共通 ◎ ポリシーベースの管理を使用したサーバーの管理

(1) ◎ ポリシーベースの管理／パーティション間での設定

(2) ◎ ポリシーベースの管理

(3) ◎ ポリシーベースの管理／マルチインスタンス間での設定

バックアップ

共通 ◎

・BACKUP ステートメントを使用

・ユーザーデータベースに関しては、対象数に比例する

・システムデータベースのバックアップは、インスタンスの数に比例する

(1) ○ パーティション数分、システムデータベースのバックアップが必要

(2) ◎ システムデータベースのバックアップは、１回のみ

(3) ○ インスタンスの数分のシステムデータベースのバックアップが必要

データベース

運用管理

共通 ◎

オンラインでのインデックス再構築と DBCC によるデータベースのチェックは、夜

間バッチ中に行うか、もしくは、昼間の O LTP 処理の尐ない時間に行うかを監視し

ながら見極める。その際も、リソースガバナでリソース調整を行う。

統計情報は、データコレクションで定期的に取得する

(1) ○ 実行回数は、データベースの数分行う

(2) ○ 同上

(3) ○ 同上

修正プログラ

ム適用共通

Windows OS の修正プログラム適用回数＝ OS の数

SQL Server の修正プログラム適用回数 = SQL Server のインスタンス数

25

(1) △



パーティションごとに、OS と SQL Server の修正プログラムレベルを変更するこ

とが可能である。

(2) ◎ Windows OS の修正プログラム適用回数＝1 (OS の数)


(3) △



インスタンスごとに、SQL Server の修正プログラムレベルを変更することが可能で

ある。

ハードウェア

の構成変更

共通

(1) ◎ 他のパーティションに依存しないので、自由に作業が可能である

(2) △ 他のシステムに依存してしまう。必要に応じて、フェールオーバークラスタで冗長化

を行うことで可能となる

(3) △

他のシステムに依存してしまう。必要に応じて、フェールオーバークラスタで冗長化

を行うことで可能となる

インスタンス間で、SQL Server の修正プログラムレベルを変更することが可能であ

る

(1) ハードウェアパーティションモデル、(2) シングルインスタンスモデル、(3) マルチインスタンスモデル

障害対応要件に対するソリューションのまとめ

RFP 要件モデル

実現手法

SQL Server の

インスタンス

障害

共通

監視は、Management Studio から一元管理が可能である

(1) ◎ SQL Server のインスタンス障害時は、他のパーティションに影響を与えない

(2) ○ SQL Server のインスタンス障害時には、すべてのデータベースが影響を受けてしま

う

(3) ○ SQL Server のインスタンス障害時は、他のインスタンスに影響を与えない

システム異常

共通

(1) ◎ システムダウン時の影響を極小化するためには、ハードウェアパーティションを使

用して、他のパーティションに影響を与えない構築を行う

(2) △ ハードウェアまたは OS レベルでシステムダウンが発生した場合は、他のシステム

への影響が回避できない

(3) △ ハードウェアまたは OS レベルでシステムダウンが発生した場合は、他のシステム

への影響が回避できない


運用管理要件に対するソリューションのまとめ

RFP 要件モデル

実現手法

ユーザー管理共通 ◎

・Windows 統合認証でセットアップを行う

・セットアップの設定画面

・データベースに対するアクセス権限

・ユーザー名の登録

・ログインアカウントの登録

・ロールの設定

・データベースオブジェクトに対する権限の設定

・スクリプトでの設定

・Management Studio での設定

(1) ◎ データベースオブジェクトに対する権限設定を厳重に行う

26

(2) ◎ データベースオブジェクトに対する権限設定を厳重に行う。インスタンスレベルの

管理者アカウントに対しては、特に厳重に行っておくことが重要となる

(3) ◎ データベースオブジェクトに対する権限設定を厳重に行う

移行

アプリケーシ

ョンの変更作

業の権限

共通

統合により、インスタンス名の変更を要する場合があり、アプリケーションから接続

する接続文字列（Connection String）の変更を行う

(1) ◎ 変更なし

(2) ○ 統合元のインスタンス名に依存する。統合元と統合先のインスタンス名が同じ場合、

変更しなくても良い

(3) ○ 統合元のインスタンス名に依存する。統合元と統合先のインスタンス名が同じ場合、

変更しなくても良い

移行

インスタンス

ごとの環境設

定（照合順序）

共通

統合した場合、インスタンス内の照合順序を考慮する必要がある

(1) ◎ 照合順序の影響はない

(2) △

統合元の照合順序が統合先のインスタンスの照合順序と違う場合には、検索結果が異

なる可能性がある。また、TempDB や SQLCLR などがインスタンスレベルの照合

順序の影響を受ける

(3) ◎ 照合順序の影響はない

移行

ユーザー管理

共通 ◎ Windows 統合認証を使用して、一元管理を行う

(1) ◎ 同上

(2) ◎ 同上

(3) ◎ 同上


27

第 4 章ソリューション作成時の挙動およびパフォーマンス

この章では、ソリューション作成時の挙動およびシステムへの影響（特にパフォーマンスへの影響）を

測定した結果について説明します。

4.1 検証環境

検証環境は、次のとおりです。

4.2 検証パターン

検証パターンは、次のとおりです。

HP Integrity

rx 8640 ServerItanium 1.6GHz 16CPU 32Core64GB Memory

Windows Server 2008

SQL Server 2008

DB Server

HP StorageWorks

EVA 4400 146GB x 48(7TB)

DB Storage

HP ProLiant

DL585 G2Opteron 2.81GHz 4CPU 8Core32GB Memory

Windows Server 2003

Management Server

4Gb x 4

4Gb x 4HP StorageWorks

SAN Switch 4/16

項目

サーバーHP Integrity rx864016 CPU 32 Core（Itanium2 1.6GHz） 64 GB Memory

ストレージHP StorageWorks EVA 4400146GB * 48（7TB）

SAN スイッチ HP StorageWorks SAN Switch 4/16

OS Windows Server 2008 IA64

データベース SQL Server 2008 Enterprise Edition

サーバー統合モデル処理内容デフォルト設定リソース調整

シングルインスタンスモデルOLTP ● ●

バッチ ● ●

マルチインスタンスモデルOLTP ● ●

バッチ ● ●

28

シングルインスタンスモデルでの検証

シングルインスタンスモデルでは、1 台のサーバーへ、1 つの SQL Server 2008 インスタ

ンスのみをインストールし、データベースを 4 つ作成します。リソース調整を行わないデフォ

ルト設定のパターンと、リソースガバナを使用してリソース調整を行ったパターン（各デー

タベースへの CPU 利用率を 25% へ制限）で検証を行いました。

マルチインスタンスモデルでの検証

マルチインスタンスモデルでは、1 台のサーバーへ、4 つの SQL Server 2008 インスタン

スをインストールし、インスタンスごとに 1 つのデータベースを作成します。リソース調整を

行わないデフォルト設定のパターンと、CPU Affinity Mask および Max Server Memory を

使用してリソース調整を行ったパターン（各データベースへの CPU コア数を 8、最大使用メ

モリを 16GB へ制限）で検証を行いました。

OLTP／Batch テスト

OLTP テストは、4 つの DB（DB1～DB4）に対して、現行システムのピーク時の高負荷状態

をシミュレートしたものを、継続して 30 分間実行できるように作成してあります。

Batch テストは、4 つの DB（DB1～DB4）に対して、現行システムの日中バッチを再現した

ものになっています。

パフォーマンス計測方法

パフォーマンスの計測方法は、次のとおりです。

各検証パターンごとに、OLTP および Batch テストを 4 回ずつ実行

1 回の実行につき、10～ 20 分程度の計測時間に調整

すべての実行でパフォーマンスログの取得を行う

DB 1

サーバー 32 コア, 64 GB メモリ

インスタンス

DB 2

DB 3 DB 4

DB 1


インスタンス

DB 2

DB 3 DB 4

CPU 25%

CPU 25%

CPU 25%

CPU 25%

シングルインスタンス（デフォルト設定）シングルインスタンス（リソース調整）

DB 1


インスタンス 1

DB 2


DB 3


DB 4


DB 1


DB 2

DB 3 DB 4

CPU 8コア

メモリ 16GB

CPU 8コア

メモリ 16GB

CPU 8コア

メモリ 16GB

CPU 8コア

メモリ 16GB

マルチインスタンス（デフォルト設定）マルチインスタンス（リソース調整）

インスタンス 1 インスタンス 2

インスタンス 3 インスタンス 4

29

4.2 検証結果

以降では、パフォーマンス測定の結果を、次の流れで説明します。

4.2.1 シングルインスタンス（デフォルト設定、OLTP／Batch テスト）

4.2.2 シングルインスタンス（リソース調整 OLTP／Batch テスト）

4.2.3 マルチインスタンス（デフォルト設定 OLTP／Batch テスト）

4.2.4 マルチインスタンス（リソース調整 OLTP／Batch テスト）

4.2.1 シングルインスタンス（デフォルト設定、OLTP／Batch テスト）

シングルインスタンス環境で、リソース調整を行っていないデフォルト設定の場合に、OLTP

および Batch テストをそれぞれ 4 回実行した結果は、次のとおりです。

結果は、1 回目の DB1 に対する結果を 100 とした場合の相対値で示しています。

OLTP テストの結果は、1 秒あたりのトランザクション数を相対値で示し（数が多いほうが優

秀）、Batch テストの結果は、実行時間を相対値で示しています（時間が短いほうが優秀）。

結果は、OLTP、Batch テストともにバラツキが出て、データベース（DB1～DB4）および実

行回数（1 回目～4 回目）ごとに結果が変わりました。これは、それぞれの実行時に獲得でき

たリソース（特にメモリ）によって、結果に差が出たと考えられます。

100.0 101.5 90.6 98.2

99.6 107.797.3

102.8

77.9 71.172.7

88.4

76.3 73.979.5

84.6

0

50

100

150

200

250

300

350

400

1回目 2回目 3回目 4回目

シングルデフォルト OLTP

DB4

DB3

DB2

DB1

100.0 97.3 97.1 94.9

100.5 95.9 97.1 93.2

89.1 85.5 76.7 84.7

99.397.3 96.8 98.0

0

50

100

150

200

250

300

350

400

450


シングルデフォルト Batch

DB4

DB3

DB2

DB1

30

4.2.2 シングルインスタンス（リソース調整、OLTP／Batch テスト）

シングルインスタンス環境で、リソースガバナによってリソース調整（それぞれの CPU 利

用率を 25% へ制限）を行った場合の OLTP および Batch テストをそれぞれ 4 回実行した

結果と、リソース調整を行わなかった場合（デフォルト設定）の結果を比較すると、次のよう

になります。

結果は、デフォルト設定の 1 回目の DB1 に対する結果を 100 とした場合の相対値で示して

います。

OLTP テストでは、デフォルト設定（リソース調整を行わない場合）は、結果が安定しないの

に対して、リソース調整を行った場合（それぞれの DB の CPU 利用率を 25% へ制限）に

は、結果が安定し、かつパフォーマンスが向上していることを確認できます。

一方、Batch テストでは、OLTP のような効果は見られず、結果にはバラツキが出て、パフ

ォーマンスも安定しない結果となりました。今回のリソース調整は、CPU 利用率に対しての

100.0 101.5 90.6 98.2 101.0 100.8 104.7 104.1

99.6 107.797.3

102.8 103.1 105.2 103.8 103.9

77.9 71.172.7

88.4106.0 107.5 106.7 105.6

76.3 73.979.5

84.6

106.8 102.5 106.0 104.4

0

50

100

150

200

250

300

350

400

450

1回目 2回目 3回目 4回目 1回目 2回目 3回目 4回目

デフォルト設定リソース調整

シングルデフォルト設定 vs. リソース調整（OLTP）

DB4

DB3

DB2

DB1

100.0 97.3 97.1 94.9 96.6 97.1 90.3 93.9

100.5 95.9 97.1 93.2 99.5 108.396.1 95.7

89.1 85.5 76.7 84.7 79.888.9

85.5 72.6

99.397.3 96.8 98.0 93.4

107.8

95.7 101.9

0

50

100

150

200

250

300

350

400

450



シングルデフォルト設定 vs. リソース調整（Batch）

DB4

DB3

DB2

DB1

31

み行っており、Batch テストの特性が CPU リソースを大量に消費するものではなかったた

めと考えられます。

4.2.3 マルチインスタンス（デフォルト設定、OLTP／Batch テスト）

マルチインスタンス環境で、リソース調整を行っていないデフォルト設定の場合に、OLTP お

よび Batch テストをそれぞれ 4 回実行した結果は、次のとおりです。

結果は、1 回目の DB1 に対する結果を 100 とした場合の相対値で示しています。

シングルインスタンスでの結果と同様、OLTP テストの結果は、1 秒あたりのトランザクシ

ョン数を相対値で示し（数が多いほうが優秀）、Batch テストの結果は、実行時間を相対値で

示しています（時間が短いほうが優秀）。

OLTP、Batch テストともにシングルインスタンス環境の場合のようなバラツキは見られず、

安定した結果となりました。安定した理由は、今回の検証は、4 つの負荷テストを同時に実行

しており、インスタンスごとにリソースがうまく配分されたことによるものと考えられます。

4.2.4 マルチインスタンス（リソース調整、OLTP／Batch テスト）

マルチインスタンス環境で、CPU Affinity Mask および Max Server Memory によってリソ

ース調整を行った場合の OLTP および Batch テストをそれぞれ 4 回実行した結果は、次の

とおりです。

100.0 101.3 101.3 101.0

102.0 101.9 100.6 102.2

106.6 109.0 107.6 108.5

105.8 107.4 107.5 106.2

0

50

100

150

200

250

300

350

400

450


マルチデフォルト OLTP

DB4

DB3

DB2

DB1

100.0 110.8 113.0 111.8

97.5106.6 107.0 107.2

93.0100.8 100.0 98.6

94.4

109.9 111.6 109.3

0

50

100

150

200

250

300

350

400

450

500


マルチデフォルト Batch

DB4

DB3

DB2

DB1

32

結果は、デフォルト設定の 1 回目の DB1 に対する結果を 100 とした場合の相対値で示して

います。

OLTP テストでは、デフォルト設定（リソース調整を行わない場合）と比べて、リソース調整

を行った場合（それぞれの DB が利用できる CPU を 8 コア、メモリを 16GB へ制限した

場合）のほうが、パフォーマンスが良い結果となりました。

一方、Batch テストでは、OLTP のような効果は見られませんでした。

以上、シングルインスタンス／マルチインスタンスのどちらの結果も、リソース調整を行っ

たほうが良好な結果を示したため、多数のワークロードが同時実行される環境では、リソース

調整を行うことが非常に重要であることを確認することができました。

パフォーマンス分析結果の詳細ホワイトペーパー

100.0 101.3 101.3 101.0 107.9 112.3 109.7 108.3

102.0 101.9 100.6 102.2 111.0 113.9 114.2 112.5

106.6 109.0 107.6 108.5113.4 117.3 118.6 116.6

105.8 107.4 107.5 106.2114.0

117.4 116.9 114.1

0

50

100

150

200

250

300

350

400

450

500



マルチデフォルト設定 vs. リソース調整（OLTP）

DB4

DB3

DB2

DB1

100.0 110.8 113.0 111.8 111.6 106.8 110.8 111.6

97.5106.6 107.0 107.2 106.2 105.4 105.4 106.0

93.0100.8 100.0 98.6 101.2 97.5 96.9 98.6

94.4

109.9 111.6 109.3 108.9 111.4 110.4 109.7

0

50

100

150

200

250

300

350

400

450

500



マルチデフォルト設定 vs. リソース調整（Batch）

DB4

DB3

DB2

DB1

33

今回のパフォーマンス検証結果に関する詳細は、別途ホワイトペーパー「SQL Server 2008 デ

ータベースサーバー統合共同検証ホワイトペーパー（性能解説編）」が公開されます。

URL: http://www.microsoft.com/japan/sql/partners/default.mspx

このホワイトペーパーでは、以上の結果に「ミックストランザクション」（OLTP と Batch の

混在テスト）の結果を加え、さらに SQL Server の「NUMA アーキテクチャ」や「内部リソ

ースの動作」など性能に関して詳細解説を行っています。

http://www.microsoft.com/japan/sql/partners/default.mspx

34

第 5 章まとめ

この実証プロジェクトをとおして、次のことを確認することができました。

シングルインスタンスでのサーバー統合では、「リソースガバナ」によるリソース調整

を行うことで、パフォーマンスを向上させることができることを確認できました。

マルチインスタンスでのサーバー統合では、「CPU アフィニティ」と「Max Server

Memory」パラメータによるリソース調整を行うことで、パフォーマンスを向上させること

ができることを確認できました。

ハードウェアパーティションモデルでは、OS と SQL Server の修正プログラムのレベ

ルをパーティションごとに変更できるメリットがあります。

シングルインスタンスとマルチインスタンスモデルでの性能比較は、決定的な差が現れ

なかったため、両モデルの比較は、運用管理面でのメリット／デメリットやライセンス面

などを含めて総合的に判断することが重要です。

修正プログラムの適用や、定期メンテナンス処理、システム監視などの運用管理操作は、

インスタンスの数分実行する必要があります。したがって、シングルインスタンスモデ

ルでは、運用管理操作が 1 回だけで済むため、運用管理面でのメリットがあります。

障害対策面では、シングルインスタンスモデルでは、SQL Server のインスタンス障害が

他のデータベースへも影響があるのに対して、マルチインスタンスモデルでは、SQL

Server のインスタンス障害は他のインスタンス（データベース）には影響を与えません。

データベースサーバー統合にあたっては、SQL Server 2008 からの新機能である「リソ

ースガバナ」と「パフォーマンスデータコレクション」、「ポリシーベースの管理」

が役立つことを確認することができました。

以上

35

付録 A ソリューション内にある技術解説

この章では、第 3 章で説明した SQL Server 2008 でのソリューションの技術について、具体的な実装

手順を詳しく解説します。以下の操作手順を説明します。

A.1 リソースガバナ（インスタンス内でのリソース調整）

A.2 マルチインスタンスでのインスタンス間のリソース調整

A.3 リソースの監視（パフォーマンスデータコレクション）

A.4 構成管理（ポリシーベースの管理）

A.5 バックアップ／復元

A.6 データベース管理

A.7 ユーザーの管理

A.1 リソースガバナ（インスタンス内でのリソース調整）

サーバー統合によるサーバーの集約化は、分散していたクライアントアクセスが集中化する

ことになるため、次のことを引き起こす可能性があります。

マルチプロセス化するワークロード

膨大なリソースを消費するプロセスによるシステムパフォーマンスの务化

高優先度なプロセスに影響を受ける低優先度なプロセス

複雑化するシステムリソース管理

このような状況に対処するための機能が「リソースガバナ」（Resource Governor）です。リ

ソースガバナは、SQL Server 2008 からの新機能で、ワークロードに対する CPU 利用率や

メモリ使用量などのリソースの調整（governor）を行うことができます。

以前のバージョンの SQL Server 2005 では、次のようにワークロードを識別することができ

ず、また、リソースプールも 1 つであったため、リソースの調整を行うことができませんで

した。

ワークロード

メモリ、CPU、スレッド、…

リソース

Backupタスク

OLTP 処理

バッチ処理

非定型レポート

管理タスク

SQL Server 2005 では、1 つのリソースプール。

データベースエンジンは、ワークロードの違いを判別できない

Adminワークロード

Adminリソース

Backupタスク

バッチ処理

非定型レポート

管理タスク

SQL Server 2005

OLTPワークロード

バッチ／レポートワークロード

アプリケーションリソース

Min Memory 10%Max Memory 20%

Max CPU 20%

Max CPU 90%

SQL Server 2008 では、複数のリソースプール。CPU とメモリリソースの使用率を調整可能

優先度 High

OLTP 処理

36

これに対して、SQL Server 2008 からは、ワークロードを識別および複数のリソースプール

を保持できるようになったので、リソースの調整が行えるようになりました。

リソースガバナでは、次のことを実現することができます。

個別のワークロードごとにリソース制限と優先順位付けが可能に

ユーザー、アプリケーション、データベースに基づくワークロード定義

リソースを大量消費するタスクの制御が可能

ミッションクリティカルなプロセスを低優先度プロセスから分離可能

定期的に実行される保守タスクからの影響を最小化可能

このように、リソースガバナは、サーバー統合によるアクセス数の増加に対処するために、

重要な機能となっています。

ただし、リソースガバナには、次の制約もあります。

データベースエンジンのみが対象（Analysis Services、Integration Services、Reporting

Services は対象外）

シングルインスタンスのみが対象（複数のインスタンス間でのリソース調整およびロー

ドバランシングは対象外）

リソースコントロールの対象は、CPU と Memory のみ

リソースガバナは、シングルインスタンスのみが対象（インスタンス内でのリソース調整の

みが可能）で、インスタンスをまたがったリソース調整を行うことはできません。したがって、

マルチインスタンスによるサーバー統合の際は、次の項で説明する CPU アフィニティや

Max Server Memory パラメータなどを利用して、インスタンス間のリソース調整を行うよう

にします。

分類子関数によるワークロードのルーティング

リソースガバナでは、ユーザー定義の「分類子関数」（Classification Function）を利用して、

ワークロードをリソースプールへルーティングすることができます。

分類子関数による

ワークロードの判別

リソースプール

ワークロード

User1

User2

User3

Adminワークロード

OLTPワークロード

バッチ／レポートワークロード

Adminリソース

アプリケーションリソース

Min Memory 10%Max Memory 20%

Max CPU 20%

Max CPU 90%

分類子関数により、ユーザーをワークロードへルーティング

・「User1」は、「OLTP ワークロード」へ

・「User2」は、「Admin ワークロード」へ

・「User3」は、「バッチ／レポートワークロード」へ

37

分類子関数は、通常のユーザー定義関数と同様の構文で作成でき、master データベース内へ

格納するようにします。分類子関数では、次の関数を利用して、ワークロードを識別すること

ができます。

HOST_NAME()

APP_NAME()

SUSER_NAME()

SUSER_SNAME()

IS_SRVROLEMEMBER()

IS_MEMBER()

分類子関数の作成例

USE master

go

CREATE FUNCTION cf1() RETURNS SYSNAME

WITH SCHEMABINDING

AS

BEGIN

-- SUSER_NAME 関数を利用して、ユーザーごとにワークロードをルーティング

DECLARE @grp_name AS SYSNAME

IF (SUSER_NAME() = 'SQL\Administrator')

SET @grp_name = 'groupAdmin'

IF (SUSER_NAME() = 'SQL\batchUser')

SET @grp_name = 'groupBatch'

RETURN @grp_name

END

リソースガバナの設定手順

リソースガバナは、次の手順で設定します。

1. リソースプールの作成

2. リソースプール内へワークロードグループの作成

3. 分類子関数の作成と設定、リソースガバナの有効化

リソースプールの作成

分類子関数の指定

ワークロードグループの作成

38

ワークロードグループに対するリソース調整

ワークロードグループに対しては、次の 7 つの設定値を構成することが可能です。

単一の要求に対する相対的な優先度

要求数の制限

単一の要求に対する最大 CPU 時間（sec）

単一の要求に対する最大メモリサイズ

単一の要求に対するタイムアウト時間（sec）

並列度数（MAXDOP）

リソースプールの指定

ワークロードグループの設定画面

リソースプールに対するリソース調整

リソースプールに対しては、次の 4 つの設定値を構成することが可能です。

CPU 使用率に対する最大値／最小値

メモリ使用率に対する最大値／最小値

リソースプールの設定画面

39

実効値の計算

リソースプールへ設定可能な最大値／最小値の実効値は、次のように計算されます。

Internal、Default、Pool 1、Pool 2 で構成している場合

min(x, y) は、x と y の値で小さい方をとります。

この例に対して、Pool 3 リソースプールを追加した場合の実効値は、次のようになります。

リソースガバナの構成と状態確認

リソースガバナの構成と状態確認は、以下のシステムカタログビューおよび動的管理ビュ

ーを利用して行うことも可能です。

分類ビュー説明

システム

カタログ

resource_governor_configuration リソースガバナに格納されている分類関数の情報を表示

resource_governor_workload_groups ワークロードグループの構成を表示

プール名最小値

(%) 最大値

(%)最大値の実効値(%)

共有可能な比率(%)

説明

Internal 0 100 100 0 Internal プールは固定

default 0 100 30 30

最大値の実効値 (%) の計算式min(100, 100-(20+50)) = 30

共有可能な比率 (%) の計算式最大値の実効値 (%) – 最小値 (%) = 30

Pool 1 20 100 50 30

最大値の実効値 (%) の計算式min(100, 100-50) = 50

共有可能な比率 (%) の計算式最大値の実効値 (%) – 最小値(%) = 30

Pool 2 50 70 70 20

最大値の実効値 (%) の計算式min(70, 100-20) = 70


プール名最小値

(%) 最大値

(%)最大値の実効値(%)

共有可能な比率(%)

説明

internal 0 100 100 0 Internal プールは固定

default 0 100 25 25

最大値の実効値 (%) の計算式min(100, 100-(20+50+5)) = 25

共有可能な比率 (% )の計算式最大値の実効値 (%) – 最小値 (%) = 25

Pool 1 20 100 45 25

最大値の実効値 (%) の計算式min(100, 100-(50+5)) = 45


Pool 2 50 70 70 20

最大値の実効値 (%) の計算式min(70, 100-(20+5)) = 70


Pool 3 5 100 30 25

最大値の実効値 (%) の計算式min(100, 100-(20+50)) = 30


40

ビュー resource_governor_resource_pools リソースプールの構成を表示

動的管理

ビュー

dm_resource_governor_configuration リソースガバナに格納されている分類関数の状態を表示

dm_resource_governor_workload_groups メモリにロードされたワークロードグループの構成と状態

を表示

dm_resource_governor_resource_pools メモリにロードされたリソースプールの構成と状態を表示

なお、リソースガバナの具体的な利用手順については、SQL Server 2008 自習書シリーズの

「SQL Server 2008 の新機能をイチ早く試してみよう」を参考にしてください。

自習書シリーズ「新機能をイチ早く試してみよう」のダウンロードはこちらから

http://www.microsoft.com/japan/sqlserver/2008/self-learning/default.mspx


41

A.2 マルチインスタンスでのインスタンス間のリソース調整

マルチインスタンスモデルによるサーバー統合を実施する場合は、インスタンス間のリソー

ス調整は、CPU アフィニティや Max Server Memory パラメータを利用します。

CPU アフィニティ（Affinity Mask、Affinity64 Mask）

CPU アフィニティは、SQL Server インスタンスが使用する CPU コアを制御するためのパ

ラメータです。デフォルトでは、SQL Server インスタンスは、すべての CPU コアを利用す

るように設定されていますが、

「CPU アフィニティ」（Affinity Mask パラメータ）を設定することで、特定の CPU コアの

みを使用するように制限することができます。

CPU アフィニティ（Affinity Mask パラメータ）は、次のように設定します。

EXEC sp_configure 'Show Advanced Options', 1

RECONFIGURE

EXEC sp_configure 'Affinity Mask', 値

RECONFIGURE

値は、有効化したい CPU コアを次のように指定します。

したがって、CPU 0～4 の 4 つのコアのみを利用させたい場合は、次のように実行します。

EXEC sp_configure 'Affinity Mask', 15

RECONFIGURE

このステートメントの実行後は、SQL Server を再起動することなく、設定が有効になります

（Affinity Mask パラメータは、動的変更が可能です）。

なお、Management Studio のサーバープロパティを利用して、CPU アフィニティを設定す

ることも可能です。これは、次のように操作します。

10 進値 2 進ビットマスク有効化するCPU コア

1 00000001 0

3 00000011 0 と 1

7 00000111 0、1、2

15 00001111 0、1、2、3

31 00011111 0、1、2、3、4

63 00111111 0、1、2、3、4、5

127 01111111 0、1、2、3、4、5、6

255 11111111 0、1、2、3、4、5、6、7

42

Affinity64 Mask

CPU コアが 32 個よりも多い場合には、「Affinity64 Mask」パラメータを利用します。この

場合は、Affinity Mask パラメータを利用して 32 個のプロセッサコアに対する CPU アフ

ィニティを設定して、残りのプロセッサコアに対して、Affinity64 Mask パラメータを利用

するようにします。

Max Server Memory（メモリ制限）

Max Server Memory は、SQL Server インスタンスが使用する動的メモリの最大サイズを制

御するためのパラメータです。デフォルトでは、各インスタンスは、物理メモリがなくなるま

で、メモリを獲得しようとするため、マルチインスタンスで運用している場合には、メモリ

競合を回避するために、各インスタンスが使用するメモリ量を制限しておくことが重要です。

Max Server Memory は、次のように設定します。

EXEC sp_configure 'Show Advanced Options', 1

RECONFIGURE

EXEC sp_configure 'Max Server Memory', 16384 -- 16GB へ制限する場合

RECONFIGURE

Max Server Memory は、Affinity Mask パラメータと同様、動的変更に対応しているので、

ステートメントの実行後は、SQL Server を再起動することなく、設定が有効になります。

なお、Management Studio のサーバープロパティを利用して、Max Server Memory を設定

することも可能です。これは、次のように操作します。

43

以上のように、マルチインスタンスモデルでのサーバー統合を実施する場合には、インスタ

ンス間のリソース調整に CPU アフィニティと Max Server Memory を利用するようにしま

す。

44

A.3 リソースの監視（パフォーマンスデータコレクション）

サーバー統合後のリソース監視に役立つのが SQL Server 2008 からの新機能である「パフォ

ーマンスデータコレクション」です。

パフォーマンスデータコレクションは、グラフィカルなパフォーマンス監視が行える機能で、

Management Studio のレポートとして実装されています。

パフォーマンスデータコレクションで提供されるレポートは、次の 3 つで、いずれのレポー

トも過去のデータまでさかのぼって監視することができます。

それぞれのレポートは、システムデータコレクション（組み込みのデータコレクション）

と連動しています（データコレクション機能については後述します）。システムデータコレ

クションでは、主に次の情報が定期収集されています。

レポート名対応するシステムデータコレクション説明

ディスク使用量の概要ディスク使用量データとログの使用量の推移を表示

クエリ統計の履歴クエリ統計クエリの統計情報（CPU実行時間の多いクエリや、実行時間の長いクエリ）などを表示

サーバーの利用状況の履歴サーバーの利用状況メモリやCPU、ディスク、Wait Stats（各種の待ちに関する情報）などの使用状況を表示

コレクションセット名主な収集している内容収集頻度保持期間

ディスク使用量・database_files

・DBCC SQLPERF (LOGSPACE)

・partitions、allocation_units

6時間ごと 730日

サーバーの利用状況

・主要なパフォーマンスカウンタ・dm_os_wait_stats

・dm_os_latch_stats

・dm_os_schedulers

・dm_os_process_memory

・dm_os_memory_nodes / clerks

・dm_os_sys_memory / info

・dm_io_virtual_file_stats

60秒ごと

アップロードは 15分ごと

14日

クエリ統計

・dm_exec_sessions とdm_exec_requests、dm_os_tasks

dm_os_waiting_tasks の JOIN

10秒ごと

アップロードは 15分ごと 14日

・dm_exec_query_stats

・dm_exec_text_query_plan15分ごと(アップロード時)

45

レポート例

パフォーマンスデータコレクションで提供されるレポートを参照するには、次のように、［管

理］フォルダの［データコレクション］を右クリックして、［レポート］メニューの［管理デ

ータウェアハウス］をクリックします。

レポートの種類には、前述の「ディスク使用量の概要」、「クエリ統計の履歴」、「サーバー利用

状況の履歴」の 3 種類があります。

ディスク使用量の概要レポート

ディスク使用量の概要レポートでは、データベースファイル（.mdf／.ndf）の使用量の推移や

その内訳、トランザクションログファイル（.ldf）の使用量の推移などを確認することが可

能です。

クエリ統計の履歴レポート

クエリ統計の履歴レポートでは、次のように実行時間（Duration）の長いクエリや、CPU 利

用時間の長いクエリ Top 10 を参照することが可能です。

グラフをクリックすると、詳細レポートを表示可能

46

クエリの詳細画面では、次のように「リソース待ちに関する情報」や「グラフィカル実行プラ

ン」を確認することも可能です（収集されている場合のみ）。

「実行時間」をクリックすると実行時間の長いクエリ

の順に表示が可能

クエリをクリックすると詳細レポートを表示可能

「このクエリに関するサンプリングされた待機を表示」のクリックにより、

リソース待ちに関する詳細を表示可能

リソース待ちに関する詳細情報

「グラフィカルな実行プランの表示」のクリックにより、実行プランを確認できる場合もある (収集されている場合)。収集されていない場合はエラーとなる

不足しているインデックス（Missing Index）に関する情報を確認できる場合もある

グラフィカル実行プラン

47

サーバーの利用状況の履歴レポート

サーバーの利用状況の履歴レポートでは、CPU 利用率やメモリ使用量、ディスク（I/O）の使

用量、SQL Server の動作状況（Wait Stats や各種パフォーマンスカウンタの状況）などを

表示することができます。また、各グラフをクリックすると、その詳細を表示できるようにな

っていて、たとえば、次のように CPU 使用率のグラフをクリックすると、その詳細（各 CPU

コアごとの CPU 使用率など）を確認することが可能です。

サーバーの利用状況の履歴レポートでは、「User Connections」や「Batch Request/sec」、

「Logins/sec」、「Compilation/sec」といった、SQL Server 関連の各種パフォーマンスカウ

ンタの状況なども確認することが可能です。

このように、パフォーマンスデータコレクション機能を利用すると、リソースの使用状況を

過去にさかのぼって参照することができるので、パフォーマンスチューニング時のボトルネ

ックの発見や、トラブルシューティング時のトラブル原因の究明に大変役立ちます。

なお、パフォーマンスデータコレクションの具体的な利用手順については、SQL Server 2008

自習書シリーズの「監視ツールの基本操作」を参考にしてください。


「CPU 使用率」グラフのクリックにより、各 CPU コアごとの CPU 利用率を参照可能

「ディスク I/O の使用量」グラフのクリックにより、各ドライブごとの応答時間やキュー（ディスク待ち）の長さを参照可能


48

A.4 構成管理（ポリシーベースの管理による集中管理）

サーバーの構成管理は、SQL Server 2008 からの新機能である「ポリシーベースの管理」を

利用することで、容易に行うことが可能です。ポリシーベースの管理機能は、Windows Server

の Active Directory 環境におけるグループポリシー機能と同じように、管理者が設定したポ

リシーを利用して、複数の SQL Server を集中管理できる機能です。この機能は、SQL Server

2008 だけでなく、SQL Server 2000／2005 を対象にすることもできるので、企業内のすべて

の SQL Server を集中管理するための目的として利用することができます。

ポリシーベースの管理機能によって作成したポリシーは、そのポリシーを強制（設定値を強

制）したり、定期的なチェックとレポートを作成したりすることも可能です。

ポリシーの作成手順

ポリシーベースの管理では、次の手順でポリシーを作成します。

1. ファセットの選択

2. ファセットをもとに条件（コンディション）の作成

3. 条件をもとにポリシーの作成

手順 1：ファセットの選択

ポリシーを作成するために最初の手順は、どういったファセットが存在するのかを確認する作

業です。ファセットは、管理対象の動作や特性をモデル化した論理プロパティで、74 種類用意

されています。

次の画面は、サーバーの環境設定パラメータに対応した「Server Configuration」ファセット

のプロパティ一覧です。

リソースガバナの設定値Minimum Cpu Percentage = 90

サーバー設定パラメータAffinity Mask = 15

Max Server Memory = 16GB

ポリシー 1

ポリシー 2

ポリシーにより、複数の SQL Server

を集中管理可能

49

このファセットには、4-2 で説明した Affinity Mask や Max Server Memory など、環境設

定パラメータ（sp_configure で設定できる値）に関するプロパティが用意されています。

次の画面は、4-1 で説明したリソースガバナのワークロードグループ設定に対応した

「Workload Group」ファセットです。

次の画面は、リソースプールの設定に対応した「Resource Pool」ファセットです。

Server Configurationファセットのプロパティ一覧

ファセットの一覧

Affinity Mask

Inportance プロパティワークロードの優先度設定

MaxCpuPercentage プロパティCPU 利用率の最大値の設定

50

手順 2：条件の作成

ポリシーを作成するための次の作業は、ファセットのプロパティに対する「条件」（チェック

したい設定値の条件）の作成です。たとえば、Server Configuration ファセットをもとに、

Affinity Mask の設定値をチェックする条件を作成したい場合は、次のように操作します。

手順 3：ポリシーの作成

条件を作成した後は、条件をもとにポリシーを作成します。これは次のように操作します。

このようにポリシーを作成することで、条件を満たしているかどうかをチェックできるように

なります。

ポリシーの実行（評価）

実際のポリシーの評価は、次のように実行できます。

ファセットの一覧から「Server Configuration」

ファセットの選択

プロパティの一覧から@AffinityMask プロパティを選択

作成した条件を選択

51

ポリシーに違反している場合は、が表示されます。また、［適用］ボタンがクリックできる

ようになり、これをクリックすると、ポリシーを満たすように値を強制変更することが可能で

す。

ポリシーおよび条件のスクリプト生成

GUI ベースで作成したポリシーと条件は、次のようにスクリプト生成することができるので、

開発機から本番機へポリシーの設定を反映させる場合などに便利です。

なお、ポリシーベースの管理の具体的な利用手順については、SQL Server 2008 自習書シリ

ーズの「セキュリティ」を参考にしてください。

自習書シリーズ「セキュリティ」のダウンロードはこちらから


ポリシーに違反している場合はが表示される

「適用」をクリックすると、ポリシー値を強制適用することも可能


52

A.5 バックアップ／復元

ここでは、バックアップと復元について、以下の項目を説明します。サーバー統合後のオンラ

インバックアップと復元は、通常の SQL Server に対するバックアップ／復元操作と同様、

BACKUP および RESTORE ステートメントを利用して実行することが可能です。

A.5.1 BACKUP ステートメントによるオンラインバックアップ

A.5.2 バックアップ圧縮

A.5.3 オンラインバックアップの種類

A.5.4 システムデータベースのバックアップ

A.5.5 RESTORE ステートメントによるリストア

A.5.6 システムデータベースのリストア

A.5.1 BACKUP ステートメントによるオンラインバックアップ

BACKUP DATABASE ステートメントの構文は、次のとおりです。

BACKUP DATABASE データベース名

TO { DISK | TAPE } = 'パス' [ WITH オプション ]

ハードディスクへバックアップする場合は「TO DISK=」に続けて、バックアップ先のファ

イルパスを記述し、テープドライブへバックアップする場合は「TO TAPE=」に続けて、テ

ープへのパスを記述します。WITH で指定できる代表的なオプションは、次のとおりです。

Tips：ファイル名へ日付／時刻を入れる方法

バックアップファイル名には、バックアップを実行したときの日付と時刻を入れておくよう

にすると、管理がしやすくなり、リストアの際にも、どのバックアップを戻せば良いのかが一

目瞭然になります。これは、次のように実行します。

DECLARE @d datetime = GETDATE()

DECLARE @d1 char(8) = CONVERT(char(8), @d, 112)

DECLARE @d2 char(6) = REPLACE( CONVERT(char(8), @d, 108), ':', '' )

DECLARE @fName varchar(30) = 'C:\' + @d1 + @d2 + '.bak'

BACKUP DATABASE sampleDB

TO DISK = @fName

オプション説明

NAME バックアップセットの名前

DESCRIPTION バックアップセットの説明

FORMAT バックアップファイルをフォーマット

NOINITバックアップファイルを初期化せずに、同じファイル内へ追加でバックアップセットを作成

DIFFERENTIAL 差分バックアップ

53

これにより、現在時刻が「2008 年 5 月 3 日 18 時 08 分 46 秒」なら「C:¥20080503180846

.bak」というファイル名にすることができます。CONVERT 関数を利用して、日付と時刻を

文字列へ変換している部分の、第 3 引数へ指定した「112」や「108」については、オンライン

ブックの Transact-SQL リファレンスの「CAST および CONVERT」を参考にしてください。

「112」は yymmdd 形式、「108」は hh:mm:ss 形式の結果を返します（間のコロン : は

REPLACE 関数で取り除いています）。

A.5.2 バックアップ圧縮（COMPRESSION オプション）

バックアップ圧縮は、SQL Server 2008 から提供された新機能で、バックアップデータを圧

縮できる機能です。圧縮することによって、バックアップおよびリストア時のデバイス（テー

プ装置やディスクなどのバックアップ先デバイス）への書き込み／読み取り量（I/O）を減ら

すことができるので、パフォーマンスを向上させることができます。

圧縮は、デバイスへの書き込みと CPU 利用率のトレードオフになりますが、オフピーク時

など CPU リソースが十分に余っている時間帯では、バックアップ圧縮が多いに役立ちます。

また、バックアップ実行時の CPU 利用率は、前述のリソースガバナ機能を利用して、調整

することも可能なので、バックアップ操作が他のワークロードへ与える影響を最小化すること

ができます。

バックアップ圧縮を実行するための構文は、次のとおりです。

BACKUP DATABASE sampleDB

TO { DISK | TAPE } = 'パス'

WITH COMPRESSION

通常の BACKUP ステートメントへ COMPRESSION オプションを指定するだけで、バック

オンラインバックアップ

バックアップ圧縮

バックアップ圧縮のほうが書き込む量が減るので

パフォーマンスが向上する

サイズを縮小

バックアップ先

54

アップ圧縮を実行することができます。

A.5.3 オンラインバックアップの種類

SQL Server のオンラインバックアップには、次の 3 種類があります。

完全バックアップ（フルバックアップ）

差分バックアップ

ログバックアップ（トランザクションログバックアップ）

完全バックアップは、データベース全体を丸ごとバックアップし、差分バックアップは、前回

の完全バックアップ以降の差分のみ、ログバックアップは、前回のログバックアップ以降の

差分（増分）のみをバックアップできます。ログバックアップと差分バックアップは、バッ

クアップ／リストア時間を短縮するための機能です。

ログバックアップ

ログバックアップは、前回のログバックアップ以降の増分情報のみをバックアップできるの

で、次のようなイメージになります。

リストア時は、完全バックアップをリストアした後に、その後のすべてのログバックアップ

をリストアすることで、最新の状態まで復元することができます。

ログバックアップには、トランザクションログ内の不要になった領域を切り捨ててくれる効

果もあるので、トランザクションログの肥大化を防止する目的としても重要な役割を果たし

ます。


差分バックアップは、前回の完全バックアップ以降の差分情報のみをバックアップできるので、

次のようなイメージになります。

前回のログバックアップ以降の増分のみ

完全バックアップ




前回の完全バックアップ以降の差分をすべて

完全バックアップ




55

差分バックアップでは、実行のたびに、完全バックアップ以降の差分情報をすべてバックアッ

プしていくので（増分のみではないので）、ログバックアップよりもバックアップ時間がかか

ります。

この反面、差分バックアップでは、リストア時間をログバックアップよりも短縮することが

できます。完全バックアップと最後の差分バックアップのみをリストアすれば良いからです。

このように、差分バックアップとログバックアップには、一長一短があるので、次のように

組み合わせて利用することで、それぞれの長所を活かせるようになります。

ログ／差分を組み合わせたバックアップ計画

ログバックアップと差分バックアップは、次のように組み合わせて利用することができます。

このように組み合わせると、バックアップ時間もリストア時間も短縮できるようになります。

たとえば、日中のトランザクションが多く発生する時間帯は、バックアップ時間が短くて済む

ログバックアップのみを実行し、1 日の終わりなどに差分バックアップを取得、そして 1 週

間に 1 回完全バックアップを取得、という形で運用しておけば、バックアップ時間を短縮する

ことが可能です。

また、リストア時には、完全バックアップと差分バックアップを復元した後に、差分バックア

ップ以降のログバックアップのみを復元するだけで済むので、リストア時間を短縮すること

もできます。

4.5.4 システムデータベースのバックアップ

システムデータベース（master や msdb、model など）には、SQL Server の動作に関わる

内部的な情報が格納されているため、システムデータベースのバックアップを定期的に取得

しておくことも重要です。

システムデータベースの役割は、次のとおりです。

master データベース

master は、SQL Server の設定パラメータ（CPU アフィニティや Max Server Memory な

どの設定）、ログインアカウント、固定サーバーロール、作成したデータベースの名前とフ

ァイルパス、リンクサーバーの設定、ユーザー定義のエラーメッセージなどが格納されてい

るデータベースです。

完全と差分とログの組み合わせ

ログ差分バックアップ

ログバックアップ完全バックアップ

ログログ


ログ

56

msdb データベース

msdb は、後述の SQL Server Agent サービスの機能であるジョブや警告、オペレータ、レプ

リケーションの設定などが格納されているデータベースです。また、Integration Services

（SSIS）のローカルパッケージも格納されます。

model データベース

model は、データベースを作成する際のテンプレートとして利用されるデータベースです。

tempdb データベース

tempdb は、一時的な領域として利用されるデータベースです。並べ替え（ソート）やハッシ

ュ処理、一時テーブル、テーブル変数などの格納場所として利用されます。

distribution データベース

distribution は、レプリケーション機能を使用している場合に利用されるデータベースです。

システムデータベースのバックアップのタイミング

システムデータベースをバックアップするタイミングは、それぞれのデータベースへ格納さ

れる情報（master データベースなら、設定パラメータやログインアカウント、リンクサー

バーの設定など）を変更した後、または 1 日に 1 回など定期的に実行するようにします。

システムデータベースのバックアップ方法は、通常のデータベースと同様、BACKUP ステー

トメントを使用します。

次の画面は、master データベースをバックアップしている様子です。

なお、tempdb データベースは、SQL Server の起動時に、model データベースをもとに毎回

再構築されているので、バックアップを取得する必要はありません。

A.5.5 RESTORE ステートメントによるリストア

オンラインバックアップからのリストア（復元）は、「RESTORE DATABASE」ステートメ

ントを利用します。構文は、次のとおりです。

RESTORE DATABASE データベース名

FROM { DISK | TAPE } = 'ファイルパス' [ WITH オプション ]

57

BACKUP ステートメントとの違いは、「TO」の部分が「FROM」へ変わるだけです。また、

WITH で指定できる代表的なオプションは次のとおりです。

A.5.6 システムデータベースの復元

システムデータベースの復元は、通常のデータベースと同様、RESTORE ステートメントを

使用します。ただし、master データベースの復元には、後述の追加の手順が必要になること

と、次の順番で復元する必要があることに注意してください。

システムデータベースは、まず master をリストアしてから、ほかのデータベースを復元す

るようにします。また、msdb と distribution データベースを復元するまでは、SQL Server

Agent サービスなど、SQL Server 関連の他のサービスをすべて停止しておくようにします。

model データベースの復元後は、SQL Server サービスを再起動して、SQL Server 関連の他

のサービスを起動します。以上で、システムデータベースの復元が完了です。tempdb デー

タベースは、自動的に再構築されるので、復元は不要です。

master データベースのリストア手順

master データベースのリストアは、次の手順で実行する必要があります。

1. まず、SQL Server 構成マネージャから、SQL Server サービスを停止します。

2. 次に、コマンドプロンプトを起動して、SQL Server をシングルユーザーモードで起

動します。シングルユーザーモードで起動するには、次のようにコマンドを入力します。

cd C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn

sqlservr -m

cd コマンドで SQL Server 2008 をインストールした Binn フォルダへ移動し、SQL Server サービスの実体である sqlservr.exe を -m オプションを付けて実行することで、シングルユーザーモードで起動することができます。

オプション説明

REPLACE 既存のデータベースを上書きして復元

MOVE ～ TO 復元先のファイルパスを変更

FILE 復元するバックアップセットの番号を指定。デフォルトは 1

RECOVERY複数のバックアップセットを復元する場合に、最後のバックアップセットを復元する際に指定するオプション

NORECOVERY複数のバックアップセットを復元する場合に、途中のバックアップセットを復元する際に指定するオプション

1•master データベース

2•msdb データベース（復元前に Agent サービスを停止しておくこと）

3•distibution データベース（レプリケーションを利用している場合）

4•model データベース

システムデータベースの復元順序

58

なお、名前付きインスタンスとして、SQL Server 2008 をインストールしている場合は、フォルダパスの「MSSQL10.MSSQLSERVER」を「MSSQL10.インスタンス名」へ変更する必要があります。

3. 次に、もう 1 つコマンドプロンプトを起動して、sqlcmd ユーティリティから、

RESTORE ステートメントを実行して、master データベースを復元します。

sqlcmd

RESTORE DATABASE master

FROM DISK = 'バックアップファイルへのパス'

go

4. 復元が成功した場合には、手順 2 でコマンドプロンプトから起動した SQL Server がシ

ャットダウン（停止）しています。

5. SQL Server 構成マネージャから、SQL Server サービスを開始します。

以上で、master データベースの復元が完了です。

なお、SQL Server におけるバックアップと復元の具体的な操作手順については、SQL Server

2008 自習書シリーズの「バックアップと復元」を参考にしてください。


：

SQL Server が正常起動した場合は、最後の行が点滅している


59

A.6 データベース運用の技術解説

ここでは、データベース運用に関して、次の項目を説明します。

A.6.1 管理タスクの自動化（Agent ジョブ機能）

A.6.2 DBCC CHECKDB コマンドによる一貫性チェック

A.6.3 インデックスの再構築／再編成

A.6.4 データコレクションによる定期的なデータ収集

A.6.1 管理タスクの自動化（Agent ジョブ機能）

バックアップや DBCC コマンドによるデータベースの一貫性チェック、インデックスの再構

築など、定期メンテナンスタスクを自動化するには、SQL Server Agent サービスの「ジョ

ブ」機能（スケジュール実行機能）を利用します。

ジョブは、Management Studio から次のように作成することが可能です。

ジョブ機能では、次のように任意のスケジュール設定が可能です。

定期実行したいステートメントを記述

任意のスケジュール設定が可能

60

A.6.2 DBCC CHECKDB コマンドによる一貫性チェック

データベースの一貫性チェックは、DBCC CHECKDB コマンドによって実行することができ

ます。このコマンドにより、次の内容をチェックできます。

システムテーブル間の整合性

ディスク領域の割り当て構造の整合性

インデックスとデータページのリンク

インデックスのソート順

テキストポインタの一貫性

ページオフセットの正当性

ページデータの正当性

クリティカルシステムテーブルの低レベルチェック

データパリティチェック

行オーバーフローポインタの整合性

Service Broker 内部オブジェクトの整合性

インデックス付きビューと XML インデックスのチェック

破損ページと CHECKSUM エラー

DBCC CHECKDB コマンドの実行方法

DBCC CHECKDB コマンドは、次のように使用します。

USE <データベース名>

DBCC CHECKDB

このコマンドを SQL Server Agent ジョブとして登録しておけば、定期的に実行することがで

きます。

DBCC CHECKDB コマンドを利用時のポイント

DBCC CHECKDB コマンドを利用する際のポイントは、次のとおりです。

61

DBCC CHECKALLOC、DBCC CHECKTABLE、DBCC CHECKCATALOG コマンド

の実行を含んでいるので、重複して実行する必要はない

ESTIMATE_ONLY オプションにより、内部的な tempdb 使用量の見積りが可能

PHYSICAL_ONLY の検討

物理構造のチェックのみに限定して、高速実行が可能

TABLOCK オプションの検討

通常は、内部的にデータベーススナップショットを利用するが、TABLOCK オプショ

ンを指定することで、使わずに高速実行が可能に。ただし、同時ワークロードがある場

合は、それらのワークロードの実行がブロックされることに注意する必要がある

REPAIR オプションによる修復は最終手段と考え、まずは、バックアップからの修復を

検討すること

62

A.6.3 オンラインでのインデックスの再構築／再編成

RFP 要件にある「オンラインでのインデックスの再構築または再編成」は、ALTER INDEX ス

テートメントを実行することで実現可能です。

インデックスのオンライン再構築（ONLINE REBUILD）

インデックスのオンライン再構築は、SQL Server 2005 から提供された機能で、Enterprise

Edition でのみ利用可能です。オンライン再構築を利用すると、インデックスの再構築にもユ

ーザーがデータへアクセスすることが可能になります（通常のオフライン再構築の場合は、再

構築中はユーザーアクセスがブロックされます）。

オンライン再構築を実行するには、次のように記述します。

ALTER INDEX インデックス名

ON テーブル

REBUILD

WITH ONLINE = ON

インデックスの再編成（REORGANIZE）

インデックスの再編成は、SQL Server 2000 までは、DBCC INDEXDEFRAG（デフラグ）

コマンドとして提供されていた機能です。インデックスの再編成でも、オンライン再構築の場

合と同様、再編成の実行中にもユーザーがデータへアクセスすることが可能です。

インデックスの再編成を実行するには、次のように記述します。

ALTER INDEX インデックス名

ON テーブル

REORGANIZE

再編成と再構築の違いは、再編成がリーフページの断片化のみを解消する点と、ロック中の

ページをスキップする点です。ただし、断片化の度合いがひどい場合には、再構築（REBUILD）

よりも実行時間のかかってしまうことに注意する必要があります。

インデックスの再構築／再編成にかかる時間

再構築または再編成にかかる時間は、インデックスが使用するページ数（ディスク容量）が大

きければそれだけ時間がかかります。また、断片化の度合いがひどい場合は、再編成

（REORGANIZE）は、再構築（REBUILD）よりも実行時間のかかってしまいます。

使用するページ数が大きくなるのは、行サイズが大きいインデックスで、クラスタ化インデッ

クス、カバリングインデックス、INCLUDE インデックスなどです。特にクラスタ化インデ

ックスは、実際のデータそのものを格納しているので、再構築／再編成には非常に時間がかか

ることに注意が必要です。

63

再構築／再編成の使い分けの指針

再編成は、断片化の度合いがひどい場合には、実行時間が長くなってしまうので、おおまかな

指針としては、断片化の割合が 30％未満なら再編成（REORGANIZE）、それ以上なら再構

築（REBUILD）を実行するようにします。

なお、再構築と再編成の内部動作の違いは、次のようになります。

インデックスの再編成では、同じ領域を再利用して、それぞれのページを比較して並び替えを

行うことで、断片化を解消するのに対して、インデックスの再構築では、新しい領域へインデ

ックスを再作成します。このような内部動作の違いがあるので、再編成は断片化の割合が大き

い場合には、非常に時間がかかるようになっています。

断片化の調査： dm_db_index_physical_stats

インデックスの断片化の度合いを調べるには、dm_db_index_physical_stats 動的管理関数を

利用します（この関数は、SQL Server 2000 までの DBCC SHOWCONTIG コマンドに相当

するものです）。構文は、次のとおりです。

SELECT * FROM sys.dm_db_index_physical_stats

(データベースID, テーブルID, インデックスID, パーティション番号, 'スキャンモード')

1 2 3 4 5 6 7 8

9 10 11 12 13 14 15 16

17 181 14 3 4 9 12 7 6

5 10 11 8 13 15 2 20

17 16 19 18

1 2 3 4 5 6 7 8

9 10 11 12 13 14 15 16

17 18

別オブジェクトが使用



空き領域

空き領域

空き領域

空き領域




空き領域

空き領域




空き領域

空き領域

空き領域

64

この関数の出力結果のうち、主なものは次のとおりです。

断片化の割合は、avg_fragmentation_in_percent 列で確認することができます。関数の第 5

引数で指定するスキャンモードには、次の 3 種類があります。

LIMITED モードを使用すると、最も高速に断片化を調査することが可能です。

断片化調査の定期実行

断片化の調査を定期実行して、その結果を保持しておくには、次の項で説明する「データコ

レクション」機能が役立ちます。

主な結果列説明スキャンモードがLIMITED の場合

index_id インデックス ID ○

index_depth インデックスの階層数 ○

index_level インデックスのレベル ○

avg_fragmentation_in_percent 断片化の割合（％） ○

fragment_count 断片化しているページ数 ○

page_count ページ数 ○

avg_page_space_used_in_percent ページ内をデータで占める割合の平均 NULL

record_count レコード数 NULL

avg_record_size_in_bytes 平均レコードサイズ NULL

モードスピード説明

LIMITED 最速断片化の割合のみを判別。SQL Server2000の DBCC SHOWCONTIG コマンドでのWITH FASTに相当するモード

SAMPLED 高速

LIMITED モードのスキャンに加えて、一部のリーフページの読み取りを行う。10,000 ページ以上のインデックスでは、1% と 2% のサンプリング（サンプル抽出）した結果を比較し、その結果に差がある場合は、10% のサンプリングを行い、その結果を返す。差がない場合は2% の結果を返す

DETAILED 低速 100% のデータ（すべてのリーフ）を対象に、すべての情報を取得

65

A.6.4 データコレクションによる定期的なデータ収集

インデックスの断片化の状況や、各サーバーの統計情報を定期収集するには、SQL Server 2008

からの新機能である「データコレクション」機能が役立ちます。

データコレクション機能では、任意の Transact-SQL ステートメントや、パフォーマンスカ

ウンタ、トレースデータを定期的に収集することが可能です。前述のパフォーマンスデータ

コレクションは、組み込みのデータコレクション（システムデータコレクション）によっ

て自動収集されたデータをもとにレポートを表示する機能です。

データコレクションの設定

データコレクションを利用するには、次のように「管理データウェアハウス構成ウィザード」

を実行して、管理データウェアハウスをセットアップします。

管理データウェアハウスをセットアップした後は、次の 3 種類のコレクタ型を利用して、コ

レクションセットとコレクションアイテムを作成します。

T-SQL Query Collector の利用例

T-SQL Query Collector は、次のように利用します。

-- 6時間ごとに実行するために、CollectorSchedule_Every_6h の uid を取得

USE msdb

DECLARE @schedule_uid uniqueidentifier

SELECT @schedule_uid =

(SELECT schedule_uid

FROM sysschedules_localserver_view

WHERE name=N'CollectorSchedule_Every_6h')

コレクタ型説明

TSQLQueryCollector 型任意の Transact-SQL ステートメントから収集可能

PerformanceCountersCollector 型任意のパフォーマンスカウンタから収集可能

SqlTraceCollector 型任意のトレース／デフォルトトレースから収集可能

66

-- コレクションセットの作成

DECLARE @collection_set_id int

EXEC dbo.sp_syscollector_create_collection_set

@name = N'DCtest1',

@schedule_uid = @schedule_uid, -- 収集・アップロードスケジュール（6hごと）

@collection_mode = 1, -- キャッシュモードをオフ

@days_until_expiration = 30, -- 収集データの保持期間

@description = N'テスト',

@collection_set_id = @collection_set_id output

-- 定期的に実行したい T-SQL を <Query> 要素の <Value> 要素へ記述

DECLARE @params XML

SELECT @params = CONVERT(XML,

N'<ns:TSQLQueryCollector xmlns:ns="DataCollectorType">

<Query>

<Value> 実行したい T-SQL ステートメント </Value>

<OutputTable> データの格納先となるテーブル名 </OutputTable>

</Query>

</ns:TSQLQueryCollector>')

-- コレクションアイテムの作成

DECLARE @collection_item_id int

EXEC dbo.sp_syscollector_create_collection_item

@collection_set_id = @collection_set_id,

@collector_type_uid = N'302E93D1-3424-4BE7-AA8E-84813ECF2419', -- TSQL Query Collector の UID

@name = 'DMVtest1',

@frequency = 30, -- クエリ実行頻度（キャッシュモードがオフの場合は無視される）

@parameters = @params, -- 上で定義した実行したいT-SQL の定義

@collection_item_id = @collection_item_id output;

このようにデータコレクション機能を利用すると、任意の Transact-SQL ステートメント

を定期実行して、データを収集することができるので、インデックスの断片化状況を収集した

り、パフォーマンスチューニング時に大変役立ちます。

なお、データコレクション機能の具体的な利用手順については、SQL Server 2008 自習書シ

リーズの「監視ツールの基本操作」を参考にしてください。

自習書シリーズ「監視ツールの基本操作」のダウンロードはこちらから



67

A.7 ユーザー管理

ユーザー管理に関する RFP の要件は、「Windows 統合認証を使用して、データベースに対す

るアクセス権限を厳重に行うこと」です。

SQL Server では、Windows 統合認証を利用することで、ユーザーを一元管理することが可

能です。Windows 統合認証を利用するには、SQL Server 2008 のセットアップ時に、次のよ

うに指定します。

認証モードで「Windows 認証モード」を選択すれば、Windows 統合認証のみが許可されるモ

ードで SQL Server を運用することができます。

セットアップ後に、あとから認証モードを変更したい場合は、次のように操作します。

68

データベースに対するアクセス権限を厳重に行う

データベースに対するアクセス権限を厳重に行うには、次の 3 つのセキュリティチェックを理

解しておく必要があります。

ログインアカウントの作成は、次のように行えます。

Windows 認証をチェックして、Windows ユーザーまたはグループを指定すれば、そのユーザーま

たはグループ内の全てのユーザーが SQL Server へログインできるようになります。

ログインアカウントは、「CREATE LOGIN」ステートメントを使用して作成することもでき

ます。構文は、次のとおりです。

-- Windows 認証用のログインアカウントの作成

CREATE LOGIN ログイン名 FROM WINDOWS

ログイン名には、Windows ユーザーまたはグループを指定します。

第 1 のチェックSQL Server への接続（ログイン認証）第 2 のチェック

データベースへの接続

第 3 のチェックオブジェクトの操作

第１のチェックの通過には「ログインアカウントの作成」第２のチェックの通過には「データベースユーザーの登録」第３のチェックの通過には「オブジェクト権限の付与」

テーブル

データベース

1 2

3

一般ユーザーがオブジェクトを操作するための 3つのセキュリティチェック

69

データベースユーザーの作成

データベースユーザーの作成は、次のように行えます。

ログイン名には、データベースユーザーとマッピングさせたいログインアカウントを指定します。

データベースユーザーは、「CREATE USER」ステートメントを使用して作成することもで

きます。構文は、次のとおりです。

USE データベース名

CREATE USER ユーザー名 FOR LOGIN ログイン名 [ WITH オプション ]

データベース内のオブジェクトに対する権限の設定

データベース内のオブジェクトに対する権限の設定は、次のように行えます。

70

オブジェクト権限をステートメントで設定したい場合には、「GRANT」、「DENY」、「REVOKE」

ステートメントを次のように使用します。

-- 権限を「許可」したい場合は、GRANT ステートメントを使用

GRANT 権限 ON オブジェクト名 TO ユーザー名またはロール名

-- 権限を「拒否」したい場合は、DENY ステートメントを使用

DENY 権限 ON オブジェクト名 TO ユーザー名またはロール名

-- 権限を「取り消し」たい場合は、REVOKE ステートメントを使用

REVOKE 権限 ON オブジェクト名 FROM ユーザー名またはロール名

データベースロールによるデータベースユーザーのグループ化

オブジェクト権限は、データベースロールを作成すると、管理がしやすくなります。データ

ベースロールは、データベースユーザーをグループ化するための機能で、次のように作成で

きます。

データベースロールの作成とメンバーの追加をステートメントから行うには、次のように

「CREATE ROLE」ステートメントと「sp_addrolemember」システムストアドプロシージ

ャを利用します。

USE データベース名

CREATE ROLE ロール名

EXEC sp_addrolemember N'ロール名', N'ユーザー名'

以上のように、ログインアカウント／データベースユーザーおよびオブジェクト権限をしっ

かりと管理しておくことで、データベースに対するアクセス権限を厳重に行うことが可能です。

なお、ユーザー管理の具体的な操作手順については、SQL Server 2008 自習書シリーズの「ロ

グイン認証とオブジェクト権限」を参考にしてください。


以上


sql server 2008 徹底検証シリーズdownload.microsoft.com/download/f/1/0/f10bc023-9396-4d67...5...

Documents