sql server 2012 自習書シリーズ 新機能編 no.2
TRANSCRIPT
SQL Server 2012 自習書シリーズ 新機能編 No.2
SQL Server AlwaysOn による可用性の向上
Published: 2011年 9月 30日 改訂版： 2012年 8月 31日
有限会社エスキューエル・クオリティ
この文章に含まれる情報は、公表の日付の時点での Microsoft Corporation の考え方を表しています。市場の変化に応える必要
があるため、Microsoft は記載されている内容を約束しているわけではありません。この文書の内容は印刷後も正しいとは保障で
きません。この文章は情報の提供のみを目的としています。
Microsoft、SQL Server、Visual Studio、Windows、Windows XP、Windows Server、Windows Vistaは Microsoft Corporation
の米国およびその他の国における登録商標です。
その他、記載されている会社名および製品名は、各社の商標または登録商標です。
© Copyright 2012 Microsoft Corporation. All rights reserved.
目次
SSTTEEPP 11.. SSQQLL SSeerrvveerr AAllwwaayyssOOnn のの概概要要 ................................................................................ 4
1.1 SQL Server 2012 の概要 ......................................................................................... 5 1.2 SQL Server AlwaysOn による可用性の向上／DR の実現 ................................................ 6
SSTTEEPP 22.. SSQQLL SSeerrvveerr AAllwwaayyssOOnn 可可用用性性ググルルーーププにによよるる可可用用性性のの向向上上 ........................................ 11
2.1 AlwaysOn 可用性グループの概要 .............................................................................. 12 2.2 可用性グループを利用するための前提条件 .................................................................... 14 2.3 可用性グループの設定方法 ........................................................................................ 17 2.4 リスナー（仮想サーバー名）の確認／接続 .................................................................... 39 2.5 読み取り可能セカンダリ／セカンダリでのバックアップ .................................................. 42 2.6 アプリケーション（ADO.NET）からの接続確認 ............................................................ 51 2.7 手動フェールオーバーによる動作確認 ......................................................................... 57 2.8 非同期モードの場合の手動フェールオーバー ................................................................. 65 2.9 障害のシミュレーション 1： 自動フェールオーバーの場合 .............................................. 76 2.10 障害のシミュレーション 2： 2台のサーバーが障害発生した場合 ................................... 81 2.11 複数サブネットの場合の構成例（災害復旧用途） ........................................................ 92 2.12 包含データベース によるログインに依存しない DB ユーザー ....................................... 99 2.13 可用性グループの削除 ........................................................................................ 114
SSTTEEPP 33.. SSQQLL SSeerrvveerr AAllwwaayyssOOnn フフェェーールルオオーーババーー ククララススタターー イインンススタタンンスス .......................... 116
3.1 AlwaysOn フェールオーバー クラスター インスタンス（WSFC）.................................. 117 3.2 Windows Server Core へのインストールがサポート ................................................... 118
SSTTEEPP 11.. SSQQLL SSeerrvveerr AAllwwaayyssOOnn のの概概要要
この STEP では、SQL Server の最新バージョンである SQL Server 2012 で提供される SQL Server AlwaysOn 機能の概要を説明します。
この STEP では、次のことを学習します。
SQL Server 2012 の概要
SQL Server AlwaysOn による可用性の向上／DR の実現
・可用性グループ（Availability Group） ・包含データベース（CDB：Contained Database） ・フェールオーバー クラスター インスタンス（FCI） ・Windows Server Core へのインストール
1.1 SQL Server 2012 の概要
SQL Server 2012 の概要
SQL Server の最新バージョンである SQL Server 2012 には、非常に多くの新機能が提供されています。その主なものは、次のとおりです。
SQL Server AlwaysOn による可用性の向上（本自習書で詳しく説明）
列ストア インデックスによる飛躍的な性能向上（新機能編 No.3で詳しく説明）
DWH 関連の強化（新機能編 No.3で詳しく説明）
DQS（Data Quality Services）によるデータ品質の向上や、BI 分析関数の提供など
開発生産性の向上（新機能編 No.1で概要説明）
新しい Transact-SQL 関数や、SQL Server Data Tools（SSDT）の提供など
ビッグデータ対応のインメモリ BI（新機能編 No.4 で概要を説明）
インメモリのカラム ベース エンジン「xVelocity」による、ビッグデータ対応の高速 BI 機能（Analysis Services テーブル モデル：Tabular Model）
BI 関連の強化（新機能編 No.4 と No.5 で詳しく説明）
Power View による容易なデータ分析レポート作成や、Reporting Services のデータ警告機能、PowerPivot のバージョンアップなど
これらの中でも、一番の目玉機能は、この自習書で説明する「SQL Server AlwaysOn による可用性の向上」です。ステップ バイ ステップ形式で画面ショット満載で詳しく説明しますので、ぜひ試しながら読み進めていただければと思います。
そのほかの新機能については、本自習書シリーズの新機能編「No.1 新機能ダイジェスト」や、「No.3 DWH 関連の新機能」、「No.4 BI 新機能ダイジェスト」、「No.5 Power View」で詳しく説明していますので、こちらもぜひご覧いただければと思います。
SQL Server 2012 評価版（Evaluation）のダウンロード
SQL Server 2012 には、6 ヶ月間限定で利用できる評価版もあります。これは、「SQL Server 2012 Evaluation」と呼ばれ、Enterprise エディションとまったく同じ機能を備えています。SQL Server 2012 Evaluation は、以下の URLからダウンロードすることができます。
SQL Server 2012 Evaluation http://www.microsoft.com/ja-jp/download/details.aspx?id=29066
1.2 SQL Server AlwaysOn による可用性の向上／DR の実現
SQL Server AlwaysOn による可用性の向上／DR の実現
SQL Server 2012 で提供される目玉の新機能は、新たな SQL Server AlwaysOn テクノロジーとして提供される「AlwaysOn 可用性グループ」と「AlwaysOn フェールオーバー クラスター インスタンス」、「Windows Server Core のサポート」です。
AlwaysOn は、「いつでも利用できる」ことを目指したテクノロジーで、いわゆる「高可用性」（High Availability）および「ビジネス継続性」（Business Continuity）を実現するための機能のブランド名です。これまでのバージョンでは、WSFC（Windows Server フェールオーバー クラスタリング）や DBM（データベース ミラーリング）、ログ配布、レプリケーション機能などが提供されていました。そして、これらのテクノロジーを利用して、稼働率 99.999%（ファイブ ナイン＝年間ダウンタイム約 5.3分以内）を達成／実現している企業もすでに存在しています。
弊社のお客様でも、可用性を向上させるために、「WSFCと DBMの組み合わせ」や「WSFCとログ配布の組み合わせ」で年間ダウンタイム 0（1年間無障害・無停止）を実現しているお客様がいらっしゃいます。また、求める可用性レベルが低くても良いという場合には「WSFC のみ」や「DBM のみ」で運用されているお客様もいらっしゃいます。昨今では、万が一の災害に備えるべく、DR（Disaster Recovery：災害復旧）へのニーズも高まっています（従来のバージョンでは、「DBM 非同期モード」や「ログ配布」機能を利用することで DR を実現できます）。
しかし、これらの機能は、すべて別々のテクノロジーとして提供されていたため、組み合わせて利用するためには設定が面倒であったり、組み合わせならではの設定のコツが必要だったりもしました。また、柔軟な設定が行えない部分や、DR 構成時の復旧手順が複雑（これに伴うダウンタイムの増加）などの課題もありました。コスト面でも、WSFC では共有ストレージ（エントリ クラスでも数百万円～）が必須であったこと、DBM での自動フェールオーバー構成時には監視サーバーを別途用意する必要があるなど、余計なコストがかかっていました。そこで、これらの課題を解決するべく登場したのが、今回の SQL Server 2012 で提供された「AlwaysOn 可用性グループ」（Availability Group）です。
AlwaysOn 可用性グループ（Availability Group）の概要
AlwaysOn 可用性グループ（Availability Group）は、従来の WSFC（Windows Server フェールオーバー クラスタリング）とデータベース ミラーリング機能の良いところどりをしたような機能で、容易な設定で可用性を向上させることができます。以下の画面は、可用性グループの設定ウィザードを利用して、4台のセカンダリ（複製データを保持するサーバー）を設定しているときの様子です。
自動フェールオーバー（自動的に切り替わるサーバー）の指定や、DR（災害復旧）用途の非同期モードの設定などを簡単に行うことができます。
AlwaysOn 可用性グループでは、内部的にデータベース ミラーリングと同じようなテクノロジーを利用して、データベースの複製（レプリカ）を作成しています（最大 4 つの複製＝セカンダリを作成することが可能です）。
クライアントからは、リスナーと呼ばれる仮想サーバー名を介してアクセスするので、どのサーバーが処理しているかは意識する必要はありません。フェールオーバー（プライマリとセカンダリの役割変更）があったとしても、クライアントのアプリケーションを修正する必要はなく、同じサーバー名で透過的にアクセスすることが可能です。
フェールオーバーにかかる時間は、わずか 10～20秒程度であり、WSFC の場合の 30秒～数分かかるのに比べて大幅にダウンタイムを短縮することもできます。
AlwaysOn 可用性グループには、次の利点もあります。
ウィザードによる容易な設定およびダッシュボードによる容易な監視が可能
セカンダリを遠隔地へ配置した DR（災害復旧）構成が可能。災害からの復旧時にも、
アプリケーションを修正することなく同じサーバー名（リスナー）でアクセス可能なため、ダウンタイム（停止時間）を大きく短縮可能
セカンダリに対して読み取りアクセスが可能（レポーティング ツールのような読み取り中心のアプリケーションが、プライマリへ負荷をかけることなく、読み取り操作が可能）
セカンダリからバックアップを取得可能（プライマリへ負荷をかけることなく、バックアップを取得することが可能）
データ転送時の圧縮と暗号化が可能（データベース複製時の転送データは自動圧縮されるためパフォーマンス良く複製することが可能。暗号化によるセキュリティ強化も可能）
自動ページ修復機能（万一プライマリ上のデータベース ページが破損した場合には、セカンダリ上の正常なページを利用して、自動修復が可能）
柔軟なフェールオーバー ポリシー（フェールオーバーを発生させる障害のレベルを 5段階で調整可能）
共有ストレージが不要な分、コスト削減が可能（可用性グループでは、それぞれのノードがローカル ディスク内にデータベースの複製を保持するため、共有ストレージが不要。通常、WSFC を構成する場合は、エントリー クラスの共有ストレージで数百万円、ミドル クラスだと一千万前後、その分のコスト削減が可能）。また、DBM のように監視サーバーを別途用意する必要がないため、その分のコスト削減も可能
包含データベース（Contained Database）機能により、ログイン アカウントや照合順序に依存しないデータベースが作成可能になり、障害時のダウンタイム（停止時間）を短縮可能（従来のバージョンでは、障害によるフェールオーバー発生後は、ログイン アカウントとデータベース ユーザーとのマッピングの修復が必要）。
ダッシュボードで現在の状態を容易に把握できる
このように、AlwaysOn 可用性グループには多くの利点があり、従来のバージョンの DBM（データベース ミラーリング）機能ではサポートされなかった複数セカンダリ（最大 4 台まで構成可能。DBM では 1台まで）や、セカンダリに対する読み取り操作／バックアップ操作が可能なアクティブ セカンダリが実装されています（DBM の場合はスナップショット作成時点での過去データの読み取りのみがサポートされるのに対して、可用性グループではリアルタイムでの読み取り操作が可能）。
また、従来のバージョンだと複数のテクノロジーを組み合わせないと実現できなかった構成（ローカル環境での高可用性と、遠隔地サーバーによる DR 構成を実現するには「WSFC と DBM 非同期モード」あるいは「WSFC とログ配布」、「DBM 同期とログ配布」などの組み合わせが必要だったもの）を、可用性グループ だけで実現できるようになりました。障害からの復旧時にも、アプリケーションを修正する必要がないため（同じサーバー名でアクセスできるため）、ダウンタイム（停止時間）を大きく短縮することが可能です。
AlwaysOn フェールオーバー クラスター インスタンス（FCI）の新機能
AlwaysOn フェールオーバー クラスター インスタンス（FCI）は、WSFC（Windows Server フェールオーバー クラスタリング）のリソースとしてインストールした SQL Server インスタンス（SQL Server クラスター）のことを指します。SQL Server 2012 では、従来のバージョンの SQL Server クラスターと比べて、次の機能が強化されています。
SMB 接続（共有フォルダー）へのデータベース配置が可能に。SQL Server 2012 からは、共有ストレージが必須ではなくなり、データベースのインストール先としてネットワーク上の共有フォルダーを選択可能
tempdb データベースをローカル ディスクへ配置可能。ボトルネックになりやすい
tempdb データベースをローカル ディスクへ配置できることで、SSD などより高速な内蔵ストレージへ配置して性能向上を実現可能
複数サイト（複数サブネット）フェールオーバー クラスタリングのサポート（従来のバージョンではサブネットをまたがったクラスタリングは構成不可。SQL Server 2012 からはサブネットをまたがった構成が可能に）
柔軟なフェールオーバー ポリシー（フェールオーバーを発生させる障害のレベルを 5段
共有フォルダーをデータベースのインストール先として指定可能に
tempdb データベースをローカル ディスクへ配置可能に
階で調整可能。障害検知をより詳細に行うことが可能）
このように、SQL Server 2012 では WSFC が強化されて柔軟な構成をとれるようになりました。これらは、可用性の向上に繋がるだけでなく、性能向上にも役立つものです。
Windows Server Core による計画停止時間の短縮
SQL Server 2012 からは、Windows Server Core へのインストールがサポートされるようになりました。Server Core は、GUI を持たない、コマンドベースでの操作で管理する Windows Server の構成です。以下の画面は、Server Core 上へ SQL Server 2012 をインストールしているときの様子です（コマンドラインから setup.exe を実行しています）。
Server Core では、GUI が不要であるため、必要最小限の機能のみしかインストールされません。これにより、よりセキュアな運用が可能になり、また、修正プログラムの適用回数を大きく削減できるというメリットが得られます。Server Core の場合は、修正プログラムの数を 50～60％程度削減できると言われており、その分 OS を再起動する回数を減らすことができます（計画停止時間を大きく短縮することが可能です）。
このように、SQL Server 2012 では、可用性を高めるための機能強化が数多く行われています。
以降では、これらの AlwaysOn テクノロジーを簡単に試せるように、ステップ バイ ステップ形式で画面ショット満載で説明しますので、ぜひ試しながら読み進めてください。
Server Core へ SQL Server 2012をインストールしているところ
SSTTEEPP 22.. SSQQLL SSeerrvveerr AAllwwaayyssOOnn 可可用用性性ググルルーーププにによよるる可可用用性性のの向向上上
この STEP では、SQL Server AlwaysOn の新たなテクノロジーとして提供される「AlwaysOn 可用性グループ」（Availability Group）について、詳しく説明します。
この STEP では、次のことを学習します。
可用性グループの概要
可用性グループを利用するための前提条件
リスナー（仮想サーバー名）の作成
読み取り可能セカンダリ
手動フェールオーバーによる動作確認
障害のシミュレーション（自動フェールオーバーの確認）
2台のサーバーが障害発生時の復旧手順（DR：災害復旧想定）
複数サブネットでの可用性グループ構成
包含データベースを利用したログインに依存しない DB ユーザー
2.1 AlwaysOn 可用性グループの概要
AlwaysOn 可用性グループの概要
まずは、AlwaysOn 可用性グループ（以下、可用性グループ）の概要を説明します。可用性グループ（Availability Group）は、前述したように、DBM（データベース ミラーリング）と WSFC（Windows フェールオーバー クラスタリング）の良いところどりをしたような機能です。データベース複製の基本的な仕組みの部分は、DBM と良く似ているので、DBM を利用したことのある方にはお馴染みのキーワードが多く出てきます。
同期モードと非同期モード（データベースの複製モード）
可用性グループでのデータベースの複製は、DBM の場合と同様に、「同期モード」と「非同期モード」のどちらかを選択することができます。同期モードの場合は、次のように動作します。
DBM の場合と同様、可用性グループは、トランザクション ログ（更新履歴）をベースとしたテクノロジーで、プライマリはログの情報を圧縮してセカンダリへ転送し、セカンダリはログを受け取ったことをプライマリへ伝えます。プライマリがこれを受け取って、はじめて処理が完了（トランザクションが完了）になります。このようにセカンダリへのログの転送が完了するのを待っているので（同期をとっているので）、この動作は「同期モード」と呼ばれています。なお、同期モードでは、障害が発生したときにプライマリとセカンダリの役割を自動的に入れ替える「自動フェールオーバー」を設定することも可能です。
これに対して、セカンダリがログを受け取ったことを確認せずに、処理を完了とするのが「非同期モード」（パフォーマンスを重視したモード）です。このモードは、遠隔地へのデータベースの複製時に利用できるので、DR（災害復旧）用途として利用することができます。
データベース ミラーリング機能との比較
可用性グループは、データベース ミラーリング機能と多くの共通点があり、考え方や基本的な操作方法は同じですが、大きな違いもあります。これらをまとめると、次のようになります。
一番の大きな違いは、データベース ミラーリングでは、セカンダリの台数が 1台に制限される点です。これでは、ローカルの可用性の確保に「同期モードのデータベース ミラーリング」機能を採用した場合、DR（災害復旧）対策には別のテクノロジー（ログ配布など）を利用しなければなりません。また、DR 対策として「非同期モードのデータベース ミラーリング」を採用した場合には、今度はローカルの可用性確保のために別のテクノロジー（WSFC による SQL Server クラスターなど）を利用しなければなりません。
これに対して、可用性グループでは、セカンダリを 4 台まで追加することができるので、ローカルの可用性の確保を同期モードのセカンダリで行いつつ、DR 対策に非同期モードのセカンダリを配置する、といったことを簡単に行うことができます。
また、可用性グループでは、セカンダリに対する読み取り操作をリアルタイムに行える点も大きな違いです（データベース ミラーリングではデータベース スナップショット作成時点での過去のデータの参照のみ）。セカンダリに対しては、バックアップ（完全バックアップやログ バックアップ）を実行することもできるので、本番環境（マスター機）へ負荷をかけることなく、バックアップの取得も可能です。
コスト面でも 可用性グループでは、監視サーバー（ウィットネス）が不要な分だけコスト削減が可能です（DBM では、自動フェールオーバー構成時に監視サーバーが必須になります）。
機能 可用性グループ DBM 備考
セカンダリの台数 4台まで 1台まで 可用性グループでは、同期／非同期の組み合わせが可能。DBM では同期のみ、または 非同期のみ の構成しかとれない
自動フェールオーバー構成に監視サーバーが必要かどうか 不要 必要 DBM では、自動フェールオーバー構成時には、監視サーバー
（ウィットネス）が必須
仮想サーバー名によるアプリケーションからの透過的アクセス ○ △
可用性グループでは、同じサーバー名で透過的にアクセス可能。DBM では Failover Partner 句へセカンダリ名を指定することでアクセス可能
セカンダリへの読み取りアクセス ○ △可用性グループではリアルタイムでの読み取りアクセスが可能。DBM では、データベース スナップショット機能を利用することで、スナップショット作成時点での過去のデータを参照可能
セカンダリへの透過的な読み取りアクセス ○ ×可用性グループでは、読み取りを行いたいサーバー名を指定することなく、通常と同じサーバー名で透過的に読み取りアクセスも可能
セカンダリでのバックアップ実行 ○ × DBM では、セカンダリ側でのバックアップ不可
DR（災害復旧）用途 ○ △可用性グループでは、非同期モードを利用して DR 対策が可能。DBM でも、非同期モードで DR 対策が可能だが、ローカルの可用性向上には、WSFC など別のテクノロジーを組み合わせて利用する必要がある
柔軟なフェールオーバー ポリシー ○ × 可用性グループでは、後述の FailureConditionLevelを設定することで 5段階で障害発生レベルを柔軟に調整することが可能
転送データの圧縮／暗号化 ○ ○
自動ページ修復 ○ ○
高速フェールオーバーの実現 ○ ○ どちらも WSFC（SQL Server クラスター）よりも高速なフェールオーバーを実現可能
共有ストレージの必要性 不要 不要
Standard エディションでの利用 × △ 可用性グループを利用するには Enterprise エディションが必須。DBM は Standard エディションでは同期モードのみが利用可能
2.2 可用性グループを利用するための前提条件
可用性グループを利用するための前提条件
可用性グループを利用するための前提条件は、次のとおりです（全部で 13点）。
1. 可用性グループへ参加させる各サーバーは、Windows Server 2008 R2 の SP1（Service Pack 1）を適用していること
2. 可用性グループへ参加させる各サーバーは、可用性グループの構成に応じた Windows の修正プログラムを適用していること（詳細は後述）
3. 可用性グループへ参加させる各サーバーは、同じ Active Directory ドメインへ参加していること
可用性グループは、WSFC（Windows Server フェールオーバー クラスター）の機能を利用しているため、各サーバーは同じ Active Directory ドメインへ参加している必要があります。また、可用性グループは、ドメイン コントローラーではサポートされていないため、各サーバーはメンバー サーバーである必要があります。
4. 可用性グループへ参加させる各サーバーは、WSFC（Windows Server フェールオーバー クラスター）のノードであること
可用性グループでは、各ノードの障害検知とリスナー（仮想サーバー名）機能を実現するために、WSFC のリソース機能を利用しているため、可用性グループを構成するメンバーは、必ず WSFC のノード（WSFC の管理ツールであるフェールオーバー クラスター マネージャー上で「ノード」として認識されているサーバー）である必要があります。
同じ Active Directory ドメインへ参加していること
WSFC のノードであること
WSFC のノードとして設定するには、次のように「サーバー マネージャー」ツールで「機能の追加」から「フェールオーバー クラスタリング」を追加します。
5. WSFC の各ノードには、通常の SQL Server のインストールと同様、それぞれのローカル ドライブへインストールした SQL Server インスタンス、またはフェールオーバー クラスター インスタンス（FCI）としてインストールした SQL Server（SQL Server クラスター）が必要（どちらの場合も SQL Server 2012 Enterprise エディションが必須）
可用性グループを構成するには、SQL Server クラスターが必須ではないことがポイントです。通常、SQL Server クラスターを構成するには高価な共有ストレージが必須になりますが、可
1
2
ローカル ドライブへ SQL Server をインストール
フェールオーバー クラスターインスタンス（SQL Server クラスター）としてインストールする場合はこちらをクリック
用性グループでは、SQL Server クラスターが必須ではないため、共有ストレージは不要です（その分のコスト削減が可能です）。
可用性グループを構成するノードには、通常の SQL Server の場合と同様、それぞれのローカル ドライブへ SQL Server をインストールします。ただし、可用性グループのメンバーにできるのは、異なるマシン上で動作している単独の SQL Server インスタンスまたは SQL Server クラスターのみであり、同じマシン（同じノード）内の、複数の名前付きインスタンスを同じ 可用性グループ 内のメンバーにすることはできません。
したがって、3 台構成の可用性グループを検証する場合にも、最低 3 台のマシン（または Hyper-V などでの仮想マシンが最低 3台）が必要になります。従来のバージョンのデータベース ミラーリングやログ配布機能などは、同一マシン内の複数インスタンスで検証することができましたが、可用性グループでは複数マシンが必須になります。
6. 可用性グループを構成する各 SQL Server のインスタンスは、サーバー レベルの照合順序を統一しておくこと（同じ照合順序を利用していること）
7. SQL Server のサービス アカウントをドメイン ユーザーへ設定して、すべてのノードで同じアカウントを利用していること
8. データベースを格納するフォルダーに対して、SQL Server のサービス アカウントへ NTFS アクセス許可（変更権限）を付与しておくこと
9. データベースを格納するフォルダーを、すべてのサーバー上に同じパスで作成しておくこと（可用性グループ設定ウィザードで初期同期を行う場合に必須）
10. バックアップ データを保管するための共有フォルダーを作成しておき、SQL Server のサービス アカウントに対して共有アクセス許可と NTFS アクセス許可（変更権限）を付与しておくこと（可用性グループ設定ウィザードで初期同期を行う場合に必須）
11. 対象データベースの復旧モデルが「完全」であること
12. 対象データベースの完全バックアップを最低 1回取得していること
13. SQL Server 構成マネージャー ツールを利用して、AlwaysOn 可用性グループを有効化しておくこと（詳細は後述）
以上が 可用性グループを設定するための前提条件です。次の Step では、実際に可用性グループを設定しながら、上記の設定方法についても説明します。
2.3 可用性グループの設定方法
可用性グループの設定方法
この Step では、次の構成で可用性グループを設定します。
SERVER1、SERVER2、SERVER3 の 3台で可用性グループを構成します（SERVER1 をプライマリとして、SERVER2 は同期モードのセカンダリ、SERVER3 は非同期モードのセカンダリとして作成します）。すべてのサーバーは同じ Active Directory ドメイン（example.com）へ参加させ、WSFC（Windows Server フェールオーバー クラスター）のノードとして設定しています。各ノードには、それぞれのローカル ドライブへ SQL Server 2012 Enterprise エディションのデータベース エンジンをインストールしています（SQL Server クラスターとしてはインストールしていません）。
データベースを格納するためのフォルダーは「C:\AGtest」という名前で各ノード上に作成し、初期同期に利用される共有フォルダーは「C:\AGtemp」という名前で SERVER1 上に作成しています。以降では、前述の前提条件も確認しながら、実際に可用性グループを設定してみましょう。
前提条件の確認
1. まずは、可用性グループを構成する各サーバー（SERVER1、SERVER2、SERVER3）の前提条件を確認しておきます。
・Windows Server 2008 R2 の SP1（Service Pack 1）を適用していること ・同じ Active Directory ドメイン（ここでは example.com）へ参加していること ・WSFC（Windows Server フェールオーバー クラスター）のノードであること
2. 次に、SQL Server のサービス アカウントを Active Directory ドメイン ユーザーへ設定して、すべてのノードで同じアカウントを利用していることを確認／設定します。
SQL Server 2012 では、 インストール時の既定のサービス アカウントが「NT Service\MSSQLSERVER」に設定されているので、このアカウントを利用している場合は、可用性グループを構成できません。
サービス アカウントを確認／変更するには、次のように「SQL Server 構成マージャー」ツールを利用して、SQL Server サービスのプロパティを開いて、［ログオン］タブから行います。
［このアカウント］を選択して、［参照］ボタンをクリックすれば、任意のドメイン ユーザーを選択することができます（画面は sqlservice という名前のユーザーを選択）。［パスワード］には、そのユーザーへ設定したパスワードを入力して、［OK］ボタンをクリックします。以上でサービス アカウントの変更が完了です（SQL Server サービスを再起動することで、変更したアカウントが有効化されます）。
以上の操作を、可用性グループを構成する全てのサーバー上（SERVER1、SERVER2、SERVER3）で行います。可用性グループでは、全てのサーバー上で同一の Active Directory ドメイン ユーザーを利用している必要があります。
3. 次に、データベースを格納するフォルダーに対して、SQL Server のサービス アカウントへ NTFS アクセス許可（変更権限）を付与します。これを設定するには、Windows エクスプローラーから次のように操作します。
2
1 4
5
ここでは、「C:\AGtest」という名前のフォルダーのプロパティを開いて、［セキュリティ］タブでサービス アカウント（画面は sqlservice）を追加して、このアカウントに対して変更権限を付与しています。後述の手順で、このフォルダーに対してデータベース（.mdf／.ldf ファイル）を作成します。
4. 次に、データベースを格納するフォルダーを、すべてのサーバー上に同じパスで作成しておきます。
可用性グループを構成するには、すべてのサーバー上で、同じパスのフォルダーを作成しておく必要があります（ここでは C:\AGtest フォルダーを SERVER1 と SERVER2、SERVER3 上に作成）。これを行う理由は、後述の可用性グループ設定ウィザードでは、内部的にバックアップと復元機能を利用して初期同期（初回のデータベース複製）を行っているため、同じパスのフォルダーがないと、復元に失敗してしまうためです。なお、初期同期を手動で行う場合には、この作業は不要です。
5. 次に、バックアップ データを保管するための共有フォルダーを作成しておき、SQL Server のサービス アカウントに対して共有アクセス許可と NTFS アクセス許可（変更権限）を付与しておきます。共有フォルダーを作成するには、次のようにフォルダーのプロパティを開いて、［共有］タブから行います。
1
2
3
サービス アカウントへ変更権限を付与
1
2
3
この共有フォルダーは、設定ウィザードでの初期同期の際に利用されます。
6. 次に、可用性グループを設定するためのデータベースを作成します。［スタート］メニューから Management Studio を起動して、プライマリとして設定するサーバー（SERVER1）へ接続します。
7. 接続後、ツールバーの［新しいクエリ］ボタンをクリックして、クエリ エディターを起動して、次のようにデータベースを作成するステートメント（CREATE DATBASE）を記述／実行します。
-- データベース「AGTestDB」の作成
CREATE DATABASE AGTestDB
ON PRIMARY ( NAME = 'AGTestDB', FILENAME = 'C:\AGtest\AGTestDB.mdf' )
LOG ON ( NAME = 'AGTestDB_log', FILENAME = 'C:\AGtest\AGTestDB.ldf' )
go
-- テーブル「t1」の作成
USE AGTestDB
CREATE TABLE t1 (a int)
INSERT INTO t1 VALUES(1)
SELECT * FROM t1
go
4
5
6
サービス アカウントへ変更権限を付与
1
1
2
プライマリとして設定するサーバー（Server1）へ接続
このステートメントでは、AGTestDB という名前でデータベースを作成し、データ ファイル（.mdf）とログ ファイル（.ldf）は「C:\AGtest」フォルダーへ格納しています。データベースの作成後は、その中へ「t1」という名前のテーブルを作成して、データを 1件（1）を INSERT しています。
8. 次に、対象データベースの復旧モデルが「完全」であることを確認します。
復旧モデルを確認／変更するには、次のようにデータベース（AGTestDB）のプロパテを開いて、［オプション］ページの［復旧モデル］から行います。
1
データベースを作成するステートメントを記述
3
2
1
32
9. 次に、対象データベースの完全バックアップを実行します。次のように BACKUP DATABASE ステートメントを記述して、完全バックアップを実行します。
-- DB 完全バックアップを実行
BACKUP DATABASE AGTestDB
TO DISK='C:\AGtemp\AGTestDB.bak'
可用性グループを設定するには、事前に最低 1 回の完全バックアップを実行しておく必要があります。
10. 次に、SQL Server 構成マネージャー ツールを利用して、AlwaysOn 可用性グループを有効化します。
AlwaysOn 可用性グループを有効化するには、次のように「SQL Server サービス」のプロパティを開いて、［AlwaysOn 高可用性］タブで「AlwaysOn 可用性グループを有効にする」をチェックします。
なお、WSFC（Windows Server フェールオーバー クラスター）のノードでない場合には、このオプションはグレーアウトされていて、設定することができません。
2
1 3
4
5
6
設定後は、SQL Server サービスを再起動する必要があります。再起動を行うには、次のように「SQL Server サービス」を右クリックして、［再起動］をクリックします。
この設定は、可用性グループを構成する全てのサーバー上（SERVER1、SERVER2、SERVER3）で行っておく必要があります。
構成に応じた修正プログラムの適用
可用性グループに対しては、いくかの Windows の修正プログラムが提供されています。詳しくは、オンライン ブックの以下の場所に記載されていますが、ここでは代表的なものを紹介します。
AlwaysOn 可用性グループの前提条件、制限事項、および推奨事項 http://msdn.microsoft.com/ja-jp/library/ff878487
KB 2494036（http://support.microsoft.com/kb/2494036） クォーラムの投票権（Vote）を持たないノード（NodeWeight=0 へ設定したノード）を作成できるようにする修正プログラム。DR（Disaster Recovery：災害復旧）目的のリモート サイトへ配置したノードに対して投票権を与えないようにするときに利用（詳しくは Step 2.11 の複数サブネットでの構成例のところで説明）
1
1
KB 2616514（http://support.microsoft.com/kb/2616514） クラスター ノード間での不要なレジストリ通知を送信するのを防ぐための修正プログラム
KB 2531907（http://support.microsoft.com/kb/2531907） クラスターの構成テスト時に、WSFC クラスター内の一部のノードから利用できないディスクに対して誤って SCSI Device Vital Product Data（VPD）ストレージ テストを実行し、不合格になってしまった場合に対処するための修正プログラム
KB 2687741（http://support.microsoft.com/kb/2687741） ローカル レプリカへのフェールオーバーのパフォーマンスを向上させるための修正プログラム
KB 976097（http://support.microsoft.com/kb/976097） 可用性グループと SQL Server クラスター（FCI：フェールオーバー クラスター インスタンス）を組み合わせて利用する場合に、一部の WSFC ノードでしか利用できない非対称ストレージ共有ディスクを「フェールオーバー クラスター マネージャー」ツールから使用できるようにする修正プログラム（執筆時点では Windows Server 2008 R2 用のファイルは未提供）
KB 980915（http://support.microsoft.com/kb/980915） IPsec を利用している環境で、接続の遅延が発生する可能性を防ぐための修正プログラム
KB 2578113（http://support.microsoft.com/kb/2578113） IPv6 を利用している環境で、IP アドレスの WSFC フェールオーバーに 30秒かかってしまう問題に対処するための修正プログラム
KB 2582281（http://support.microsoft.com/kb/2582281） WSFC クラスターとアプリケーション間にルーターがない場合に、フェールオーバーが遅くなる問題に対処するための修正プログラム（執筆時点では Windows Server 2008 R2 用のファイルは未提供）
以上で、前提条件の確認／設定が完了です。
可用性グループの設定（新しい可用性グループ ウィザードの実行）
次に、可用性グループを作成します（ウィザードが用意されているので、簡単に作成することができます）。ここでは、SERVER1 をプライマリとして設定し、SERVER2 は同期モードのセカンダリ、SERVER3 は非同期モードのセカンダリとして、複製データベース（レプリカ）を作成するように設定します。
1. 可用性グループ（可用性グループ）を作成するには、次のように Management Studio で［AlwaysOn 高可用性］フォルダーを右クリックして、［新しい可用性グループ ウィザード］をクリックします。
これにより、［新しい可用性グループ］ウィザードが起動するので、［次へ］ボタンをクリックします。
2. 次の［可用性グループ名の指定］ページでは、［可用性グループ名］へ任意の名前を入力（AG1 など）して、［次へ］ボタンをクリックします。
1
2
3. 次の［データベースの選択］ページでは、対象としたいデータベースを選択（前の手順で作成した AGTestDB を選択）して、［次へ］ボタンをクリックします。
4. 次の［レプリカの指定］ページでは、［レプリカの追加］ボタンをクリックして、追加したい
1
2
2
1
セカンダリへ接続します。セカンダリは、1 つずつ追加する必要があるので、まずは「SERVER2」を追加します。
5. 追加後、もう一度［レプリカの追加］ボタンをクリックして、「SERVER3」を追加します。
2
3
1
セカンダリへ設定したいSQL Server の名前を指定
SERVER2 と入力
2
3
1
SERVER3 と入力
6. 次に、SERVER1 と SERVER2 の［自動フェールオーバー］をチェックします。
これにより、［同期コミット］も自動的にチェックされて、SERVER1 と SERVER2 を自動フェールオーバーが可能な同期モードへ設定することができます。SERVER3 に関しては、［同期コミット］のチェックを外しておくことで、非同期モードへ設定することができます。
Note： 自動フェールオーバーへ設定できるセカンダリは 1台まで、同期モードは 2台まで
可用性グループでは、「自動フェールオーバー」（同期モード）へ設定できるセカンダリの台数は 1台まで、同期モードへ設定できるセカンダリの台数は 2台まで（1台を自動フェールオーバー、もう 1台を手動フェールオーバーに設定するか、2台とも手動フェールオーバーへ設定）という制限があります。また、セカンダリの台数は全部で 4台までという制限があるので、セカンダリが 4台の場合は、2台までが同期モードへ設定でき、残りの 2台は非同期モードへ設定することになります。次の画面は、4台のセカンダリを追加している場合の設定例です。
自動フェールオーバーに設定したレプリカ
同期モードに設定したセカンダリ非同期モード
に設定したセカンダリ
1
セカンダリへのアクセスを許可する設定
【 制限 】・同期モードへ設定できるセカンダリは 2台まで・自動フェールオーバーへ設定できるセカンダリは 1台まで
５台のノードで可用性グループを構成。
4台のセカンダリ 非同期モード（高パフォーマンス）に設定したセカンダリ
自動フェールオーバーに設定したセカンダリ
同期モードに設定したセカンダリ
7. 次に、［読み取り可能なセカンダリ］で「はい」を選択します。
これで、セカンダリに対しても読み取りアクセスができるようになります。
8. 次に、［エンドポイント］タブを開きます。
このタブでは、可用性グループの内部的な通信で利用されるエンドポイントの設定を確認／変更することができます。既定では、hadr_endpoint という名前のエンドポイントが TCP 5022 ポート番号を利用するように作成され、暗号化がオンに設定されています。
セカンダリへのアクセスを許可する設定
1
既定で暗号化がオンに設定される
SQL Server のサービスアカウントが内部的に利
用される
データベース ミラーリングと同様、既定で 5022 ポートを利用したエンドポイントが作成される
エンドポイントの名前はhadr_endpoint へ設定される
1
9. 次に、［リスナー］タブを開きます。このタブでは、リスナーを作成することができます（リスナーは、仮想サーバー名／仮想 IP アドレスになるもので、クライアントからの接続時に利用されるサーバー名（SQL Server の名前）になります）。
［可用性グループ リスナーの作成］を選択して、［リスナーの DNS 名］へ任意の名前（AG1_Listener など）、［ポート］へは任意のポート番号（SQL Server の既定のポート番号は 1433）、［ネットワーク モード］で「静的 IP」を選択して、［追加］ボタンをクリックします。
10. ［IP アドレスの追加］ダイアログが表示されたら、任意の静的な IP アドレス（画面は 192.168.1.112）を入力して、［OK］ボタンをクリックします。
［レプリカの指定］ページへ戻ったら、［次へ］ボタンをクリックして、次のページへ進みます。
11. 次の［最初のデータの同期を選択］ページでは、「完全」を選択して、［すべてのレプリカからアクセス可能な共有ネットワーク場所を指定］で［参照］ボタンをクリックし、事前に作成した共有フォルダー（\\SERVER1\AGtemp）を選択して、［OK］ボタンをクリックします。
3
2
1
1
2
［すべてのレプリカからアクセス可能な共有ネットワーク場所を指定］に、選択した共有フォルダーへのパス（\\SERVER1\AGtemp）が入力されたことを確認して、［次へ］ボタンをクリックします。
12. 次の［検証］ページでは、可用性グループを構成できるかどうかの検証が行われます。
2
1
4
3
2
1
すべての［結果］が「成功」と表示されていることを確認して、［次へ］ボタンをクリックします。
Note： データベースを格納するフォルダーを作成していない場合のエラー
データベースを格納するフォルダーを、プライマリ上と全く同じパスで、セカンダリ上に作成していない場合は、次のように検証エラーが発生します。
前述したように、初期同期（初回のデータベース複製時）には、内部的にバックアップと復元機能が利用されているため、プライマリとセカンダリ上で同じパスのフォルダーがない場合には、復元が失敗してしまうため、事前に検証エラーを発生してくれています。
13. 次の［概要］ページでは、内容を確認して、［完了］ボタンをクリックします。
1
これにより、可用性グループの構築が始まります。
14. すべての構築が完了すると、次のように結果が表示されます。
すべての［結果］が「成功」となっている場合は、可用性グループの構築が成功です。
Note： 「WSFC クォーラム投票の構成を検証しています」で警告が表示される場合
3台以上のノードで可用性グループを構成する場合に、3台目以降のノードに投票権がある場合（NodeWeight が
1
1
1 に設定されている場合。既定値は 1）は、次のように「WSFC クォーラム投票の構成を検証しています」で警告が表示されます。
DR（Disaster Recovery：災害復旧）を考慮しない、ローカル環境のみの可用性グループ（同じサブネット内で可用性グループ）の構成で、3台または 5台のノード（奇数のノード数）で、WSFC のクォーラム設定が「ノード マジョリティ」の場合には、この警告を無視して大丈夫です。
DR を考慮したリモート サイトへ別ノードを配置する場合（複数サブネットで可用性グループを構成する場合）には、リモート サイトへ配置したノードのクォーラムの投票権を取っておく（NodeWeight を 0 へ設定する）ことを推奨します。こうすることで、リモート サイトのノードの障害が、プライマリ サイト（メインのノードを配置している場所）へ影響を与えることを防ぐことができます。NodeWeight を 0 へ設定するには、前出の Windows の修正プログラム「KB 2494036」を適用しておく必要があります（NodeWeight の設定方法は、「Step 2.11 複数サブネットの場合の構成例」で説明します）。また、3台のノードでこの構成を構築する場合（ローカルが 2台、リモートが 1台）の場合には、リモート ノードの投票権を 0 にすることで、ローカルの 2個の投票権のみとなってしまい、これでは障害対策にならない（1台のノードの障害でクラスターが停止してしまう）ので、クォーラム構成を「ノードおよびファイル共有マジョリティ」へ変更するなどの対処も必要になります（これについても Step 2.11 で説明します）。
Note： スクリプト生成機能。CREATE AVAILABILITY GROUP ステートメント
ウィザードの［概要］ページでは、次のように右下の［スクリプト］ボタンをクリックして、ウィザードで設定し
た項目をスクリプト化することも可能です。
15. 可用性グループの構築が完了したら、［オブジェクト エクスプローラー］の［可用性グループ］を展開して、作成した 可用性グループ（AG1）が表示されることを確認します。
1
可用性グループを設定するためのCREATE AVAILABILITY GROUP
ステートメントが生成される
16. 次に、［表示］メニューの［オブジェクト エクスプローラーの詳細］をクリックして、「オブジェクト エクスプローラーの詳細」ウィンドウを表示します。
17. 次に、オブジェクト エクスプローラーで［可用性レプリカ］フォルダーをクリックします。これにより、次のようにセカンダリとの接続状態や同期の状態（同期済みかどうかなど）を確認することができます。
18. 次に、作成した 可用性グループ（AG1）を右クリックして、［プロパティ］をクリックします。
Server1 がプライマリServer2 がセカンダリServer3 もセカンダリ
可用性グループを設定したデータベース
AGTestDB
作成した可用性グループ
作成したリスナー
1
セカンダリとの接続状態接続が正常なら ”接続済み”
と表示される
セカンダリとの同期の状態非同期モードは ”同期中”同期モードは ”同期済み”
と表示される
1
このダイアログでは、同期モードや自動フェールオーバーの設定などを確認／変更することが可能です。
ダッシュボードで監視
可用性グループでは、ダッシュボード機能が提供されているので、現在の状態をグラフィカルに監視することも可能です。
1. ダッシュボードを利用するには、作成した 可用性グループ（AG1）を右クリックして、［ダッシュボードの表示］をクリックします。
2. ダッシュボードは、次のように表示されます。
1
同期モードと非同期モードの変更
自動フェールオーバーかどうかの変更
セカンダリへの読み取りアクセスを可能にするか
どうかの変更
1
可用性グループに問題がある場合には、次のように［問題点］にリンクが表示されて、詳細を確認することができます。
ダッシュボードで現在の状態を容易に把握できる
2.4 リスナー（仮想サーバー名）の確認／接続
リスナー（仮想サーバー名）の確認
リスナーは、仮想サーバー名／仮想 IP アドレスになるもので、クライアントからの接続時に利用されるサーバー名（SQL Server の名前）になります。
1. 作成されたリスナーを確認するには、次のように［可用性グループ リスナー］フォルダーを展開します。
2. リスナーは、内部的には、WSFC のリソース（ネットワーク名および IP アドレス リソース）として登録されます。これを確認するには、次のように WSFC の管理ツールである「フェールオーバー クラスター マネージャー」を起動して、［サービスとアプリケーション］を展開します。
作成されたリスナー
リスナーの利用するポート暗号
作成されたリスナー
可用性グループの名前
現在の所有者
リスナーを利用して接続
次に、作成したリスナー（AG1_Listener）を利用して、SQL Server への接続を試みてみましょう。
1. オブジェクト エクスプローラーで、次のように［接続］メニューの［データベース エンジン］をクリックして、リスナーの名前を入力し、［接続］ボタンをクリックします。
何の問題もなく接続できることを確認できます。
2. 次に、データベースを展開して、テーブルなどを参照できることを確認しておきましょう。
3. 次に、オブジェクト エクスプローラーでリスナー名を右クリックして、［プロパティ］をクリックし、サーバー プロパティを表示してみます。
作成したリスナーの名前を入力
1
2
3
AGTestDB データベース内の t1 テーブル
［名前］には、実際のプライマリの名前（SERVER1）が表示されていることを確認できます。
4. 次に、リスナー名を右クリックして［新しいクエリ］をクリックし、「SELECT @@SERVERNAME」を実行すると、プライマリの名前が返ってくることを確認します。
1
2
1
クエリを記述2
3
Server1 が処理していることが分かる
2.5 読み取り可能セカンダリ／セカンダリでのバックアップ
読み取り可能セカンダリ
可用性グループでは、セカンダリに対しても読み取り操作を行うことが可能です。それでは、これも試してみましょう。
1. まずは、オブジェクト エクスプローラーの［接続］メニューから［データベース エンジン］をクリックして、セカンダリ（SERVER2）へ接続します。
2. 接続後、ツールバーの［新しいクエリ］ボタンをクリックして、t1 テーブルに対する SELECT ステートメントを実行し、正しくデータが複製されていることを確認しておきましょう。
USE AGTestDB
SELECT * FROM t1
3. 次に、リスナー（SERVER1）へ接続して、プライマリ側へデータを 2 件 INSERT してみ
1
2
3
セカンダリへ接続
1
AGTestDB データベース内のt1 テーブルのデータを参照
3
2
ましょう。
USE AGTestDB
INSERT INTO t1 VALUES(2)
INSERT INTO t1 VALUES(3)
SELECT * FROM t1
4. データの追加が完了したら、再度セカンダリ（SERVER2）へ接続して、データを確認します。
プライマリ側で追加したデータが、すぐにセカンダリ側でも読み取りできることを確認できます。
このように、可用性グループでは、セカンダリに対するリアルタイムでの読み取りアクセスができる点が大きなメリットです。以前のバージョンのデータベース ミラーリング機能では、セカンダリに対してはデータベース スナップショットを作成しないとアクセスすることができず、リアルタイムで現在のデータを参照することができませんでした（スナップショット作成時点での古いデータしか参照できませんでした）。
リスナーへ接続
1
t1 テーブルへデータを 2件追加
3
2
セカンダリへ接続
1
プライマリ側で追加されたデータを参照できることを確認
3
2
セカンダリ側でのデータベース バックアップの取得
可用性グループでは、セカンダリ側でバックアップを実行することも可能です。これも試してみましょう。
1. まずは完全バックアップを実行してみましょう、これを行うには、セカンダリ（SERVER2）へ接続して、次のように BACKUP DATABASE ステートメントで COPY_ONLY オプションを利用します（バックアップ先に指定している「C:\temp」フォルダーは、皆さんの環境に合わせて任意のパスへ変更して実行してください）。
BACKUP DATABASE AGTestDB
TO DISk = 'C:\temp\AGTestDB_full.bak'
WITH COPY_ONLY
このように、可用性グループでは、セカンダリに対してもバックアップを実行することができるので、テスト環境などを作成する際に大変便利です（本番環境と同じ環境を作成するのに、本番環境＝プライマリ サーバーへの負荷をかけることなく行うことができるようになります）。
Note： Management Studio からバックアップを実行する場合
Management Studio からバックアップを実行する場合は、次のように該当データベースを右クリックして、［タスク］メニューの［バックアップ］をクリックします。
［データベースのバックアップ］ダイアログが表示されたら、次のように「コピーのみのバックアップ」をチェッ
2 セカンダリへ接続
1
クすることで、セカンダリ上でもバックアップを取得することができます。
Note： COPY_ONLY を付けない場合
セカンダリに対しての完全バックアップでは、COPY_ONLY オプションが必須になります。これを付けない場合は以下のエラーが発生します。
2. 次に、セカンダリに対して、BACKUP LOG ステートメントを実行して、ログ バックアップを取得してみましょう。
BACKUP LOG AGTestDB
TO DISk = 'C:\temp\AGTestDB_log1.trn'
1
2
4
3
このように可用性グループでは、セカンダリに対してログ バックアップを実行することも可能です。
3. 次に、もう一度ログ バックアップを実行しておきましょう。
BACKUP LOG AGTestDB
TO DISk = 'C:\temp\AGTestDB_log2.trn'
テスト環境などへのリストア
次に、セカンダリで取得したバックアップを別のマシンへリストアしてみましょう。
1. リストアを行うには、次のようにオブジェクト エクスプローラーで［データベース］フォルダーを右クリックして、［データベースの復元］をクリックします。
［データベースの復元］ダイアログが表示されたら、［デバイス］を選択して、［...］ボタンをクリックします。［バックアップ デバイスの選択］ダイアログでは、［追加］ボタンをクリックします。
2. ［バックアップ ファイルの検索］ダイアログが表示されたら、次のように「C:\temp」フォルダーを選択して、3 つのバックアップ ファイルをすべて選択し、［OK］ボタンをクリックします。
1
2 3
4
［バックアップ デバイスの選択］ダイアログへ戻ったら、［OK］ボタンをクリックします。
3. ［データベースの復元］ダイアログへ戻ると、どのバックアップを戻せば最新の状態へ復元できるのかを提示してくれます（これは SQL Server 2012 からの新機能です）。
次に、［転送先］の［データベース名］を任意のデータベース名（AGTestDB2 など）へ変更します（ここでの手順では、復元先となる別のマシンを用意せずに、SERVER2 上にデータベースを復元しようとしているので、違う名前のデータベースとして復元します）。変更後は、［タイムライン］ボタンをクリックします。
4. これにより、［バックアップのタイムライン］ダイアログが表示されて、どの時点までのデータを復元するのかをグラフィカルに設定することができます（この GUI ツールも SQL Server 2012 からの新機能です）。
C:¥temp フォルダー内のすべてのバックアップ ファイルを選択
2
1
3
↓
4
どのバックアップ ファイルを戻せば最新の状態になるか
を指示してくれる
転送先（復元先）となるデータベース名を変更する
2
1
3
ここでは［キャンセル］ボタンをクリックして、ダイアログを閉じます。
5. ［データベースの復元］ダイアログへ戻ったら、［ファイル］ページをクリックします。
［復元先］のファイル名を「AGTestDB2.mdf」と「AGTestDB2.ldf」へ変更します（既存の AGTestDB データベースと同じファイル名にならないように変更します）。
6. 次に、［オプション］ページをクリックします。
1
何時の時点まで戻したいかをグラフィカルに設定できる
1
2
［ログ末尾のバックアップ］セクションの［復元の前にログ末尾のバックアップを実行する］のチェックを外して、［OK］ボタンをクリックします。
これで復元が始まり、数秒すると［データベース "AGTestDB2" の復元に成功しました］と表示されれば、復元が完了です。
7. 最後に復元が完了したことをオブジェクト エクスプローラーや SELECT ステートメントを実行して確認しておきましょう。
このように、可用性グループでは、セカンダリに対しても完全バックアップやログ バックアップを実行できるようになったので、テスト環境や開発環境などを作成する場合に大変便利です（本番環境と同じ環境を作成するのに、本番環境＝プライマリ サーバーへの負荷をかけることなく実施することができます）。また、SQL Server 2012 からは、バックアップ ファイ
1
2
3
4
復元されたデータベース内の t1 テーブル
t1 テーブルの中身を参照
ルからの復元時のユーザー インターフェースが非常に使いやすくなった点もうれしいところです。
SERVER3（非同期モード セカンダリ）での読み取り操作
ここまでは SERVER2 への読み取り操作とバックアップについて確認しましたが、次にもう 1台のセカンダリである SERVER3（非同期モードへ設定したセカンダリ）に対しても読み取り操作を実行してみましょう。
1. オブジェクト エクスプローラーの［接続］メニューから［データベース エンジン］をクリックして、SERVER3 へ接続します。
2. 接続後、ツールバーの［新しいクエリ］ボタンをクリックして、t1 テーブルに対する SELECT ステートメントを実行し、正しくデータが複製されていることを確認しておきましょう。
このように、非同期モードの SERVER3 に対しても、SERVER2 と同じように読み取りアクセスが可能です。バックアップについても、同様に完全バックアップやログ バックアップを実行することが可能です。
1
2
3
SERVER3へ接続
1
AGTestDB データベース内のt1 テーブルのデータを参照
3
2
2.6 アプリケーション（ADO.NET）からの接続確認
アプリケーション（ADO.NET）からの接続確認
次に、VB や C# などのアプリケーションから ADO.NET を利用して、可用性グループへ接続する方法を試してみましょう。とはいっても、通常の SQL Server へ接続する場合と同様、接続文字列を次のように記述するだけで接続できます。
"Data Source=リスナー名;" _
& "Initial Catalog=データベース名;" _
& "Integrated Security=SSPI" ' Windows 認証で接続する場合
Data Source 句でリスナー名（仮想サーバー名）を指定するだけで、可用性グループへ接続することができます。また、自動フェールオーバーや手動フェールオーバーが発生しても、どのサーバーが処理しているかを意識することもなく、透過的に接続することが可能です。
Let's Try
それでは、これを試してみましょう。ここでは、Visual Studio 2010 の Visual Basic 10.0 から ADO.NET 4.0 を利用して、「AGTestDB」データベースへ接続してみましょう（Visual Studio 2005 や 2008、2012 でも同様の手順で試すことができます）。
次のようにボタン（Button1）をクリックすると、SQL Server へ接続して、「t1」テーブルのデータを取得し、リスト ボックス（ListBox1）へ結果を表示するようにします。
1. まずは、［スタート］メニューから Visual Studio 2010 を起動します。
2. 起動後、［スタート］ページの［新しいプロジェクト］をクリックして、新しいプロジェクトを作成します。
Button1
ListBox1
［新しいプロジェクト］ダイアログが表示されたら、［インストールされたテンプレート］から［Visual Basic］を選択して、「Windows フォーム アプリケーション」を選択します。［名前］には、任意の名前（WindowsApplication１ など）を入力して、［OK］ボタンをクリックします。
3. 次に、ツールボックスから［Button］と［ListBox］をドラッグ＆ドロップして、フォーム上へ配置します。
配置後、ボタン（Button1）をダブル クリックして、コード エディターを開きます。
4. コード エディターでは、コードの先頭へ以下を記述します。
Imports System.Data.SqlClient
2
3
5
4
1
6
1
貼り付けた後、Button1 を
ダブル クリック
3
2
5. 次に、ボタン（Button1）の Click イベント ハンドラーへ次のように記述して、「AGTestDB」データベースへ接続し、「t1」テーブルのデータを取得します（コード入力が面倒な方は、サンプル スクリプト内の完成版のファイル（WindowsApplication1 フォルダー内の ADONET_code.txt ファイル）を開いてください。
Private Sub Button1_Click(..)
ListBox1.Items.Clear()
Dim cnstr As String
cnstr = "Data Source=AG1_Listener;" _
& "Initial Catalog=AGTestDB;" _
& "Integrated Security=SSPI"
Using cn As New SqlConnection(cnstr)
Using cmd As New SqlCommand()
cmd.Connection = cn
Try
cn.Open()
cmd.CommandText = "SELECT @@SERVERNAME"
MessageBox.Show(cmd.ExecuteScalar())
cmd.CommandText = "SELECT * FROM t1" Using dr As SqlDataReader = cmd.ExecuteReader()
While dr.Read
ListBox1.Items.Add( dr("a") )
End While
End Using
Catch ex As Exception
Debug.Print(ex.Message)
Finally
cn.Close()
End Try
End Using
End Using
End Sub
Data Source 句へはリスナー名（AG1_Listener）、Initial Catalog 句へはデータベース名（AGTestDB）を指定します。このコードでは、まず cmd.CommandText で指定した「SELECT @@SERVERNAME」を実行して、どのサーバーが処理したかをメッセージ ボックス（MessageBox.Show）で返し、次の cmd.CommandText で指定した「SELECT * FROM t1」ステートメントで取得した t1 テーブルのデータをリストボックス（ListBox1）へ表示します。
6. コードを記述後、［デバッグ］メニューから［デバッグ開始］をクリックして、実行します。
コードの先頭へ記述
ボタンをクリックすると、処理したサーバーの名前（SERVER1）がメッセージ ボックスで表示されて、「t1」テーブルのデータ 3件（1、2、3）がリストボックスへ表示されることを確認できます。
7. 正しくデータを取得できたことを確認したら、アプリケーションを終了して、デバッグを停止します。
このように可用性グループでは、リスナー名を利用して接続することで、どのサーバーが処理したのかを意識することなく、アプリケーションを作成することができます。このアプリケーションは、フェールオーバーが実行された後（セカンダリがプライマリへ切り替わった後）でも正しく動作します。次の Step では、手動フェールオーバーを試すので、この動作を確認することができます。
Note： 読み取り可能セカンダリへの自動ルーティング（ApplicationIntent=ReadOnly）
SQL Server Native Client 11.0（SQL Server 2012 で提供される SQL Server Native Client）からは、リスナー名を指定したときに、読み取り可能セカンダリへ自動的に転送（ルーティング）してくれる機能が提供されています（読み取り操作に関しても、どのセカンダリが処理するかを意識することなく、透過的にアクセスすることが可能です）。これは、接続文字列を次のように記述します。
"Data Source=リスナー名;" _
& "Initial Catalog=データベース名;" _ & "Integrated Security=SSPI;" _
& "ApplicationIntent=ReadOnly;" _
このように Data Source 句にはリスナー名を指定し（セカンダリのサーバー名を指定するのではなく、リスナー名を指定できます）、ApplicationIntent=ReadOnly（読み取り専用指定）を付けることで、可用性グループ内の読み取り可能セカンダリへ自動的に接続しにいってくれます（自動ルーティングしてくれます）。
実際の実行結果は、次のとおりです。
1
2
SERVER1 が処理したことが分かる
3t1 テーブルのデータ（3件）が表示される
4
現在のプライマリは SERVER1 ですが、ApplicationIntent=ReadOnly を付けたことで、セカンダリ（SERVER2）へアクセスしにいってくれることを確認できます。
■ ルーティングの設定（READ_ONLY_ROUTING_URL、READ_ONLY_ROUTING_LIST）
ApplicationIntent=ReadOnly を利用してセカンダリへ自動ルーティングするには、可用性グループ 側の設定も必要になります。これは、ALTER AVAILABILITY GROUP ステートメントを利用して、次のように READ_ONLY_ ROUTING_URL と READ_ONLY_ROUTING_LIST を設定します。
USE master
-- セカンダリに対して READ_ONLY_ROUTING_URL を設定
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'SERVER2'
WITH
( SECONDARY_ROLE
( READ_ONLY_ROUTING_URL = 'TCP://SERVER2:1433' ) )
go
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'SERVER3'
WITH
( SECONDARY_ROLE
( READ_ONLY_ROUTING_URL = 'TCP://SERVER3:1433' ) )
go
-- プライマリに対して READ_ONLY_ROUTING_LIST を設定
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'SERVER1'
WITH
( PRIMARY_ROLE
( READ_ONLY_ROUTING_LIST = ('SERVER2', 'SERVER3') ) )
go
セカンダリ（SERVER2 と SERVER3）に対しては、READ_ONLY_ROUTING_URL を自分自身への URL パスへ設定し（SERVER2 なら TCP://SERVER2:1433）、プライマリ（SERVER1）へは READ_ONLY_ROUTING_LIST（読み取り専用ルーティング リスト）へ自動ルーティングさせたいセカンダリ名をカンマ区切りで指定（ここでは
接続文字列へApplicationIntent=ReadOnly を追加
1
2
3
SERVER2（セカンダリ）が処理したことが分かる
4t1 テーブルのデータ（3件）が表示される
5
SERVER2 と SERVER3 を指定）します。このように設定することで、ApplicationIntent=ReadOnly（読み取り専用）が設定されたアプリケーションが、ルーティング リストに登録されているセカンダリへアクセスしにいくようになります。
このように、可用性グループでは、読み取り操作に関しても、アプリケーションから透過的に（どのサーバーがセカンダリであるかを意識することなく）アクセスすることが可能です。
Note： 読み取り可能セカンダリでの遅延
読み取り可能セカンダリでは、データベース複製時のロック待ちを防ぐために（複製によるデータ更新時のロックによって、読み取り操作がブロックされないようにするために）、内部的にスナップショット機能を利用して、セカンダリへの読み取り操作を実現しています。このため、読み取りを行ったときのデータは、遅延が発生する（完全な最新データではない）可能性もあります。また、スナップショットによるオーバーヘッドも数%発生します。
2.7 手動フェールオーバーによる動作確認
手動フェールオーバーによる動作確認
次に、手動フェールオーバーを実行して、プライマリとセカンダリの役割を変更してみましょう。
1. 手動フェールオーバーを実行するには、まずセカンダリ（SERVER2）へ接続します。
2. 次に、［可用性グループ］フォルダーの可用性グループ名（AG1）を右クリックして、［フェールオーバー］をクリックします。
3. これにより、［可用性グループのフェールオーバー］ウィザードが起動するので、［次へ］ボタンをクリックします。
4. 次の［新しい プライマリ レプリカの選択］ページでは、SERVER2 を選択して、［次へ］ボ
SERVER2へ接続
1可用性グループ名（AG1）を右クリックして［フェールオー
バー］をクリック
2
1
タンをクリックします。
5. 次の［概要］ページでは、内容を確認して、［完了］ボタンをクリックします。
これでフェールオーバーが開始され、フェールオーバーの実行中は、次のように［進行状況］ページが表示されます。
2
1
1
6. フェールオーバーが完了すると、次のように［結果］ページが表示されます。
これで手動フェールオーバーが完了です。フェールオーバーにかかる時間は、実行されているトランザクション量にもよりますが、10～20秒程度で完了します。WSFC（Windows Server フェールオーバー クラスター）を利用した SQL Server クラスターでは、30秒～1分程度の時間がフェールオーバーにかかるので、可用性グループのほうがダウンタイム（障害発生時
1
の停止時間）を大幅に短縮することができます（これは、可用性グループの大きなメリットです）。
7. フェールオーバーが完了したら、フェールオーバーが成功したことをオブジェクト エクスプローラーから確認しておきましょう。
8. また、フェールオーバー クラスター マネージャーからもリソースの所有者が新しいプライマリ（SERVER2）へ変更されていることを確認しておきましょう。
9. 次に、オブジェクト エクスプローラーでリスナー名で接続して、サーバーのプロパティを表示します。
役割が入れ替わっていることを確認
「現在の所有者」が変更されていることを確認
［名前］には、新しいプライマリのサーバー名（SERVER2）が表示されていることを確認できます。
10. 次に、リスナーへ接続して、「SELECT @@SERVERNAME」を実行して、処理しているサーバー名が SERVER2 と表示されることを確認しておきましょう。
SELECT @@SERVERNAME
11. 次に、リスナーに対して INSERT ステートメントを実行して、データが追加できることを確認します。
USE AGTestDB
INSERT INTO t1 VALUES(4)
SELECT * FROM t1
1
2
リスナーを右クリック
1
SELECT @@SERVERNAMEを実行してサーバー名を確認
3
2
SERVER2 が処理していることが分かる
12. 次に、前の Step で Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。
接続文字列では、Data Source 句へリスナー名（AG1_Listener）を指定しているので、フェールオーバー後でも、どちらのサーバーが処理しているかを意識することなく、何の問題もなくアプリケーションを実行できていることを確認できます。
13. 次に、SQL Server ログを参照して、フェールオーバーが実行された際に記録されるメッセージを確認してみましょう。オブジェクト エクスプローラーで［管理］フォルダーの［SQL Server ログ］フォルダーを展開して、現在のログをダブル クリックします。
1
2
SERVER2 が処理したことが分かる
3追加したデータ（4）も表示されていることを確認
4
1
ログが表示されたら、「The availability group database "AGTestDB" is changing roles from "PRIMARY" to "RESOLVING" ～」や「～ changing roles from "RESOLVING" to "SECONDARY" ～」というメッセージを確認できます。これがロール変更（プライマリからセカンダリへの役割変更）に関するエントリです。
SQL で手動フェールオーバー（ALTER AVAILABILITY GROUP ステートメント）
次に、SQL ステートメントを利用して、手動フェールオーバーを実行してみましょう。
1. SQL ステートメントで手動フェールオーバーを実行するには、セカンダリ（現在は SERVER1 がセカンダリ）へ接続して、ALTER AVAILABILITY GROUP ステートメントを次のように実行します（データベース ミラーリング機能の場合と同様、手動フェールオーバーは、セカンダリからのみ実行することができます）。
USE master
ALTER AVAILABILITY GROUP AG1 FAILOVER
AG1 の部分は、可用性グループ 名を指定し、セカンダリに接続してから実行することに注意してください。
2. コマンドが正常に完了したら、オブジェクト エクスプローラーを最新の情報に更新して、役割が変更されたことを確認しておきましょう。
3. 次に、Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。
↓
1
フェールオーバー前はSERVER2 がプライマリ
フェールオーバー後はSERVER1 がプライマリ
1
2
SERVER1 が処理したことが分かる
3t1 テーブルのデータ（4件）が表示される
4
2.8 非同期モードの場合の手動フェールオーバー
非同期モードの場合の手動フェールオーバー
セカンダリが非同期モードの場合に手動フェールオーバーを実行するには、次の 2 つの方法があります。
1. 非同期モードを同期モードへ変更してから手動フェールオーバーを実行する
2. FORCE_FAILOVER_ALLOW_DATA_LOSS を指定して強制フェールオーバーを実行する。ただし、役割を元に戻すには RESUME を指定したデータベース再開がそれぞれのサーバー上で必要になる
非同期モードを同期モードへ変更する方法
非同期モードを同期モードへ変更する場合は、次のように［可用性レプリカ］フォルダー内のセカンダリを右クリックして、［プロパティ］をクリックし、［可用性モード］を［同期コミット］へ変更するだけです。ただし、この手順はプライマリ（SERVER1）へ接続して、プライマリ上から実行することに注意してください。
SQL ステートメントを利用して、非同期モードを同期モードへ変更する場合は、次のように ALTER AVAILABILITY GROUP ステートメントを実行します。
USE master
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'SERVER3'
WITH ( AVAILABILITY_MODE = SYNCHRONOUS_COMMIT )
AG1 は 可用性グループ 名、SERVER3 は同期モードを変更したいセカンダリの名前、AVAILABILITY_MODE で SYNCHRONOUS_COMMIT と指定することで同期モードへ変更することができます。非同期モードへ戻したい場合は、ASYNCHRONOUS_COMMIT と指定します。
プライマリへ接続
1
2
3
同期モードへ変更した後は、前の Step で試した SERVER2 と同じ状態になるので、手動でのフェールオーバーを全く同じように試すことができます。試した後は、非同期モードへ戻すようにします。
FORCE_FAILOVER_ALLOW_DATA_LOSS を指定した強制フェールオーバー
次に、非同期モードの場合の手動フェールオーバーの方法の 2つ目を説明します。この方法では、FORCE_FAILOVER_ALLOW_DATA_LOSS を指定した強制フェールオーバーを実行するのですが、実行後の復旧手順（役割を元に戻す手順）が少し複雑になります。しかし、この手順は、実際に障害が発生した場合の復旧手順とほとんど同じなので覚えておくことをお勧めします。
それでは、これも試してみましょう。
1. まずは、SERVER3 が非同期モードへ設定されていることを確認します。
2. 次に、SERVER3 へ接続して、前の Step ど同様の手動フェールオーバーを実行してみます。
USE master
ALTER AVAILABILITY GROUP AG1 FAILOVER
プライマリへ接続
1
2
3
SERVER3へ接続
1
非同期モードでは、手動フェールオーバーを実行す
るとエラーとなる
結果はエラーとなり、非同期モードでは、手動フェールオーバーが実行できないことを確認できます。
3. 次に、FORCE_FAILOVER_ALLOW_DATA_LOSS を指定して、フェールオーバーを実行します（このオプションを指定したフェールオーバーは "強制フェールオーバー" と呼ばれます）。
USE master
ALTER AVAILABILITY GROUP AG1 FORCE_FAILOVER_ALLOW_DATA_LOSS
今度は正常に終了します（約 10秒くらいで完了します）。Step 2 の冒頭で説明したように、非同期モードでは、データを失う可能性がある（同期がとれていない可能性がある）ので、ALLOW_DATA_LOSS（データ損失を受け入れ）、FORCE（強制的に）FAILOVER を実行する、というオプションになっています。データベース ミラーリング機能で非同期モードを利用したことがある方にとってはお馴染みのオプションです。
Note： GUI での強制フェールオーバー
オブジェクト エクスプローラーで強制フェールオーバーを実行するには、手動フェールオーバーのときと同様、次のように可用性グループ名（AG1）を右クリックして、［フェールオーバー］をクリックします。、
SERVER3へ接続
1
強制フェールオーバーを実行
強制フェールオーバーなので、データ損失の可能性があると表示さ
れる
SERVER3 の NodeWeight を 0（投票権をなし）へ設定している場合は、クォーラム投票の構成で警告が表示される
（SERVER3 がプライマリになった後に、投票権を持っていないことで、障害発生に対応できない、という主旨の警告）
4. 強制フェールオーバーが完了した後は、オブジェクト エクスプローラーを最新の情報に更新して、SERVER3 がプライマリに変更されていることを確認します。
5. 次に、SERVER3 またはリスナー（AG1_Listener）へ接続して、INSERT ステートメントを実行して、データを 1件追加してみましょう。
USE AGTestDB
INSERT INTO t1 VALUES(5)
SELECT * FROM t1
正しくデータを追加できることから、SERVER3 がプライマリとして正常に動作していることを確認できます。
6. 次に、フェールオーバー クラスター マネージャーを起動して、リソースの所有者がSERVER3 へ変更されていることを確認しておきましょう。
↓
1
SERVER3 がプライマリになったことを確認
「現在の所有者」がSERVER3 に変更されていることを確認
7. 次に、Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。
8. 次に、オブジェクト エクスプローラーで［可用性レプリカ］フォルダーをクリックして、［オブジェクト エクスプローラーの詳細］を表示します。
ツールバーの［最新の情報に更新］ボタンをクリックすると、新しいセカンダリとなった SERVER1 や SERVER2 の［同期状態］が「同期されていません」と表示されることを確認できます。このように表示される場合は、その名のとおり、同期がとれいない状態なので、プライマリへ追加したデータ（さきほど追加した 5）は、セカンダリへは複製されていません。
強制フェールオーバーは、後述の 2 台のサーバーが障害発生した場合など、緊急時に使用するためのオプションなので、これを実行した後は、同期が自動停止するようになっています。同期を再開（RESUME）するには、明示的な操作が必要になります。
1
2
SERVER3 が処理したことが分かる
3追加したデータ（5）も表示されていることを確認
4
同期されていませんとなっていることを確認
3［最新の情報に更新］ボタンをクリック
2
1
同期の再開（RESUME）
1. 次に、SERVER1（元プライマリ、現在はセカンダリ）へ接続して、オブジェクト エクスプローラーを最新の情報に更新します。
［可用性データベース］フォルダーを展開すると、AGTestDB データベースのアイコンが「白」に変わっていることを確認できます。これは、「同期されていない」状態を表すアイコンです。
2. 同期を再開するには、ALTER DATABASE ステートメントを次のように実行して、RESUME オプションを指定します。
USE master
ALTER DATABASE AGTestDB SET HADR RESUME
Note： GUI で RESUME を実行する場合
GUI 操作で RESUME を実行したい場合は、次のように［可用性データベース］フォルダーの AGTestDB データベースを右クリックして、［データ移動の再開］をクリックします。
アイコンが「白」へ変わっていることを確認
↓
1
SERVER1へ接続
1
RESUMEを実行
3
2
2
1
3. RESUME の実行が完了したら、オブジェクト エクスプローラーを最新の情報に更新して、アイコンが正常な状態を表す「緑」に変わっていることを確認しましょう。
4. 次に、SERVER1 へ接続して、SELECT ステートメントを実行し、現在のプライマリ（SERVER3）側で追加したデータ（5）が複製されていることを確認しておきましょう。
このように、FORCE～オプションで強制フェールオーバーを実行した場合には、同期を再開するために RESUME の実行が必要になります。
5. 次に、SERVER2 についても同様に、RESUME を実行します。
アイコンが「緑」へ変わっていることを確認
↓
1
SERVER1へ接続
1
現在のプライマリ（SERVER3）側で追加したデータ（5）を確認できる
2
SERVER2へ接続
1
RESUMEを実行
3
2
6. RESUME が完了したら、SERVER3 の［オブジェクト エクスプローラーの詳細］で最新の情報に更新して、［同期状態］が「同期中」へ変更されていることを確認します。
役割を元へ戻す（SERVER1 をプライマリへ）
1. 次に、SERVER1 をプライマリへ戻します。この場合も（SERVER3 が非同期モードへ設定されているため）、FORCE～ オプションを利用した強制フェールオーバーを実行する必要があります。
USE master
ALTER AVAILABILITY GROUP AG1 FORCE_FAILOVER_ALLOW_DATA_LOSS
2. 強制フェールオーバーが完了したら、SERVER1 で［オブジェクト エクスプローラーの詳細］を最新の情報に更新します。
SERVER3へ接続
1
2
同期中 に変更されていることを確認
3
SERVER1へ接続
1
強制フェールオーバーを実行
3
2
強制フェールオーバーを実行したので、また「同期されていません」と表示されていることを確認できます。
3. 同期を再開するために、SERVER2 および SERVER3 に対して、RESUME を実行します。
4. RESUME が完了したら、SERVER1 で［オブジェクト エクスプローラーの詳細］を最新の情報に更新します。
同期されていませんと表示されることを確認
4［最新の情報に更新］ボタンをクリック
3SERVER1へ接続
12
SERVER2へ接続
1
RESUMEを実行
3
2
SERVER3へ接続
1
RESUMEを実行
3
2
SERVER2 は「同期済み」、SERVER3 は「同期中」と表示されて、この Step を始める前の状態へ戻ったことを確認します。
以上のように、非同期モードのセカンダリの場合には、強制フェールオーバーと RESUME を利用することで、役割変更を行うことができます。この手順は、後述の Step の障害発生時の復旧手順でも利用できるので、覚えておくことをお勧めします。
また、非同期モードでの単純な手動フェールオーバーのみを試す場合は、この Step の冒頭で説明した「いったん同期モードへ変更してから手動フェールオーバーを実行する」ことで、簡単に役割変更を試すこともできます。
これらの手順は、データベース ミラーリング機能を利用する場合もほとんど同じなので（可用性グループ機能は、データベース ミラーリングの場合と同じように操作できるものが多くあるので）、データベース ミラーリング機能を利用する場合にも、考え方や用語、基本的な操作方法などが役立ちます。
次の Step では、障害発生をシミュレートして、障害からの復旧手順を説明します。
SERVER1へ接続
1
2
SERVER2 は同期済み、SERVER3 は同期中
に変更されていることを確認
3
2.9 障害のシミュレーション 1： 自動フェールオーバーの場合
障害のシミュレーション 1： 自動フェールオーバーの場合
ここでは、プライマリ（SERVER1）に障害が発生した場合の動作を確認してみましょう。プライマリに障害が発生した場合は、次のように自動フェールオーバーが行われて、セカンダリ（SERVER2）がプライマリへ自動的に切り替わってくれます。
Let's Try
それでは、これを試してみましょう。
1. まずは、プライマリ側（SERVER1）へ接続して、データを 1件追加しておきます。
-- プライマリ側でデータの追加
USE AGTestDB
INSERT INTO t1 VALUES(6)
SELECT * FROM t1
2. 続いて、SHUTDOWN ステートメントを次のように実行して、プライマリを強制停止します。
-- プライマリを強制停止
SHUTDOWN WITH NOWAIT
セカンダリセカンダリ
セカンダリ
正常な状態
プライマリ
同期
非同期
SERVER1
SERVER2
SERVER3
プライマリに障害発生！
プライマリ
SERVER1
セカンダリ
SERVER2
SERVER3
プライマリ自動フェールオーバー
SERVER1へ接続
1
データを 1件追加3
2
サービスが停止されると、自動フェールオーバーが内部実行されます（自動フェールオーバーにかかる時間は 10秒程度です）。
自動フェールオーバーの確認
1. 次に、自動フェールオーバーが実行されたことを確認するために、オブジェクト エクスプローラーで元セカンダリ側（SERVER2）を最新の情報に更新して、可用性グループの状態を確認します。
SERVER2 がプライマリへ変更されていることから、自動フェールオーバーが正常に完了したことを確認できます。また、元プライマリ（SERVER1）は、［接続状態］が「接続解除」、［同期状態］が「同期されていません」と表示されていることも確認できます（障害が発生して接続できていない場合には、このように表示されます）。
2. 次に、SERVER2（現在のプライマリ）へ接続して、「t1」テーブルの中身を確認します。
USE AGTestDB
SELECT * FROM t1
SERVER1 は 接続解除、同期されていませんと表示されることを確認
4［最新の情報に更新］ボタンをクリック
2SERVER2へ接続
1
SERVER2 が プライマリに変更されることを確認
3
元のプライマリ（SERVER1）側で追加したデータ「6」が反映されていることを確認できます。
3. 次に、Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。
アプリケーションは、リスナー（AG1_Listener）で接続しているので、フェールオーバー後でも、どちらのサーバーが処理しているかを意識することなく、何の問題もなくアプリケーションを実行できることを確認できます。
このように、可用性グループでは、プライマリに障害が発生した場合には、自動的にフェールオーバーが実行されるので、ダウンタイム（停止時間）はわずか 10秒程度です（フェールオーバーにかかる時間は、実行されているトランザクション量によっても変化します）。
SERVER2へ接続
1
データを確認3
2
最後に追加されたデータ（6）が複製されていることを確認
1
2
SERVER2 が処理したことが分かる
3追加したデータ（6）も表示されていることを確認
4
元プライマリの起動
次に、元プライマリ（SERVER1）のサービスを開始した場合の動作を確認してみましょう。元プライマリを起動すると、次のようにセカンダリとして動作するようになります。
それでは、これを試してみましょう。
1. オブジェクト エクスプローラーで、元プライマリ（SERVER1）を右クリックして［開始］をクリックします。
「サービスを開始しますか」と尋ねられるので、［はい］をクリックして、サービスを開始します。
2. サービスが開始されたら、オブジェクト エクスプローラーを最新の情報に更新して、可用性グループの状態を確認してみましょう。
元プライマリがセカンダリとして、復帰していることを確認できます。
セカンダリ
セカンダリ セカンダリ
現在の状態
プライマリ
同期
非同期
SERVER1
SERVER2
SERVER3
プライマリの復帰！
プライマリ
SERVER1
セカンダリ
SERVER2
SERVER3
プライマリ
プライマリ
1
2
↓
↓
［最新の情報に更新］ボタンをクリック
2SERVER1へ接続
1
SERVER1 が セカンダリに変更されることを確認
3セカンダリからはプライマリ
は不明と表示される
4
Note： 可用性グループでの障害検知（FailureConditionLevel）
データベース ミラーリングでは、DBM PING と呼ばれる通信パケットを利用して障害検知が行われていますが、可用性グループでは、WSFC（Windows Server フェールオーバー クラスター）のリソース機能を利用して障害検知が行われています。可用性グループを作成すると、可用性グループ名と同じ名前のリソースが次のように作成されています（フェールオーバー クラスター マネージャー ツールから確認できます）。
このリソースの［プロパティ］タブを開くと、次のように「FailureConditionLevel」というプロパティがあり、この値を変更することで、どのような障害を SQL Server の障害と見なすのかを 5段階で設定することが可能です。
既定値は「3」に設定されて、この場合は SQL Server の致命的な内部エラー（重大な書き込み違反など）が発生した場合に障害と見なすようになっています。
FailureConditionLevel の詳細については、オンライン ブックの以下の場所が参考になります。
可用性グループの自動フェールオーバーのための柔軟なフェールオーバー ポリシー http://msdn.microsoft.com/ja-jp/library/hh710061.aspx
FailureConditionLevel は、次のように ALTER AVAILABILITY GROUP ステートメントを利用して変更することもできます。
ALTER AVAILABILITY GROUP 可用性グループ名
SET (FAILURE_CONDITION_LEVEL = 3)
2.10 障害のシミュレーション 2： 2台のサーバーが障害発生した場合
障害のシミュレーション 2： 2台のサーバーが障害発生した場合
次に、可用性グループを構成する ３台の SQL Server のうち、2台（SERVER1、SERVER2）に障害が発生した場合の動作を確認してみましょう。
Let's Try
それでは、これを試してみましょう。ここでは、まず現在のプライマリ（SERVER2）を停止して、自動フェールオーバーされるのを待ち、その後新しいプライマリとなった SERVER1 を停止してみましょう。
1. まずは、現在のプライマリ（SERVER2）をシャットダウンして、OS を停止します（Hyper-V などの仮想環境で試している場合は、仮想マシンの［停止］（電源オフ）をクリックして、より現実に近い障害をシミュレートしてみてください）。
2. プライマリがシャットダウンされることにより、自動フェールオーバーが発生し（10～20秒でフェールオーバーが完了）、セカンダリ（SERVER1）がプライマリへ切り替わることを確認できます。自動フェールオーバーが発生したことを確認するには、オブジェクト エクスプ
セカンダリ
セカンダリ
現在の状態
プライマリ
同期
非同期
SERVER1
SERVER2
SERVER3
1
ローラーを最新の情報に更新します。
SERVER1 がプライマリへ変更されて、SERVER2 との［接続状態］が「接続解除」、［同期状態］が「同期されていません」と表示されていることを確認できます。
3. 次に、フェールオーバー クラスター マネージャーを起動して、リソースの所有者が SERVER1 へ変更されていることを確認します。
4. 次に、［ノード］をクリックすると、SERVER2 が停止状態になっていることを確認できます。
5. 次に、Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。
［最新の情報に更新］ボタンをクリック
2SERVER1へ接続
1
SERVER1 がプライマリに変更されることを確認
3 SERVER2 が 接続解除、同期されていません と表示される
4
「現在の所有者」がSERVER1 に変更されていることを確認
SERVER2 が停止状態になっていることを確認
1
2
6. 次に、SERVER1 へ接続して、データを 1件追加しておきます。
-- データの追加
USE AGTestDB
INSERT INTO t1 VALUES(7)
SELECT * FROM t1
2台目のサーバー（SERVER1）の停止
1. 次に、SERVER1 をシャットダウンして、OS を停止します（Hyper-V などの仮想環境で試している場合は、仮想マシンの［停止］（電源オフ）をクリックして、より現実に近い障害をシミュレートしてみてください）。
1
2
SERVER1 が処理したことが分かる
3t1 テーブルのデータを確認（6件）
4
SERVER1へ接続
1
データを 1件追加3
2
SERVER1 がシャットダウンされることにより、残りは非同期モードへ設定したセカンダリ（SERVER3）のみになります。
2. シャットダウン後、SERVER3 で Management Studio を起動して、［可用性グループ］フォルダーを確認します。
SERVER3 は「解決中」と表示されて、正常に動作していないことを確認できます。
3. 次に、フェールオーバー クラスター マネージャーを起動します。
クラスター内のノードが表示されず、クラスター全体が停止していることを確認できます。今
1
「解決中」と表示されて、正常に動作していないこと
が分かる
クラスター内のノードが表示されず、クラスターが正常に動作していないことを確認できる
回は SERVER1、SERVER2、SERVER3 の 3台でクラスターを構成しているので、クォーラムを既定値の「ノード マジョリティ」へ設定しています。この設定の場合、3台中 2台のノードが停止したときに、クラスターとしての機能を停止する、という動作をとります。したがって、現在 SERVER1 と SERVER2 の 2 台が停止しているので、全体として停止された状態になっています。
クラスター サービスの起動（forcequorum オプション）
1. この状態で、クラスターを起動するには、forcequorum または fixquorumオプションを利用してククラスター サービスを起動します。このオプションを利用すると、現在のクォーラムに問題があったとしてもクラスター サービスを起動することができます。
これを行うには、まずコマンド プロンプトを起動します。
2. 次に、net start コマンドを利用して、forcequorum オプションを利用してクラスター サービス（clussvc）を起動します。
net start clussvc /forcequorum
なお、サービスが開始されずに、「要求したサービスは既に開始されています」というエラーが表示される場合は、いったん net stop コマンドを利用してクラスター サービス（clussvc）を停止してから（net stop clussvc と入力／実行して、サービスを停止してから）、上記のコマンドを再実行してみてください。
1
強制フェールオーバーの実行
クラスター サービスが開始されたら、次は強制フェールオーバー（FORCE～ オプション）を実行します。
1. 強制フェールオーバーを実行するには、Management Studio で SERVER3 へ接続し、次の よ う に FORCE_FAILOVER_ALLOW_DATA_LOSS を 指 定 し て 、 ALTER AVAILABILITY GROUP ステートメントを実行します。
USE master
ALTER AVAILABILITY GROUP AG1 FORCE_FAILOVER_ALLOW_DATA_LOSS
このステートメントは、約 10 秒程度で完了します。これが完了すると、クライアント アプリケーションからアクセスできるようになるので、障害発生時のダウンタイム（停止時間）は、障害検知から、クラスター サービスの開始、強制フェールオーバーの実行完了まで、と非常に短い時間で済みます。
ただし、前述したように、非同期モードでは、データを失う可能性がある（同期がとれていない可能性がある）ので、実際の障害発生時には、ネットワーク障害などによるデータ転送遅延なども起こりえるため、最新のデータであるかどうかは、手動でデータを確認していく必要が
「要求したサービスは既に開始されています」と表示される場合
net stop コマンドでサービスを停止
SERVER3へ接続
1
強制フェールオーバーを実行
2
あります。
2. 次に、オブジェクト エクスプローラーを最新の情報に更新します。
SERVER3 がプライマリとして正常に動作していることを確認できます。
3. 次に、フェールオーバー クラスター マネージャーで、リソースの所有者が SERVER3 へ変更されていることを確認します。
4. 次に、Visual Studio 2010 で作成した Windows アプリケーションを実行して、正しく結果が取得できることを確認します。
［最新の情報に更新］ボタンをクリック
2SERVER3へ接続
1
SERVER3 がプライマリに変更されていることを確認
3
「現在の所有者」がSERVER3 に変更されていることを確認
最後に追加したデータ（7）も正しく取得できていることを確認できます。このように、可用性グループでは、障害が発生しても、アプリケーションを変更することなく、アプリケーションからはどのサーバーが処理しているかを意識することなく、透過的にアクセスすることが可能です。
以上で、2台のサーバーに障害が発生した場合のシミュレーションが完了です。従来のバージョンでは、3台以上で高可用性を実現する場合には、「WSFC と DBM の組み合わせ」や「WSFC とログ配布の組み合わせ」などを利用する必要がありましたが、SQL Server 2012 からは可用性グループのみで 3 台以上の高可用性を簡単に実現できます。また、障害時のダウンタイムも大幅に短縮できます。可用性グループではリスナー機能が提供されたことで、アプリケーションを修正する必要がないからです。また、障害検知に WSFC のリソース機能を利用しているので、迅速な障害検知も可能です。
可用性グループは、コスト面でのメリットもあります。従来の WSFC による SQL Server クラスターでは、共有ストレージ（エントリ クラスでも数百万円～）が必須であったり、DBM での自動フェールオーバー構成時には、監視サーバー（ウィットネス）を別途用意する必要があったりしましたが、可用性グループではこれらは不要です。
可用性グループは、性能面では、データ転送のオーバーヘッドがありますが、ローカルのストレージ（筐体内の HDD や SSD）を利用できることで、共有ストレージよりも性能の良いストレージを選択できるメリットがあるので、書き込みよりも読み取り操作の多いシステムの場合には、逆に性能面でのメリットにもなります。
SERVER1 と SERVER2 が復旧した場合
障害発生後に、SERVER1 や SERVER2 が何の問題もなく復旧できる場合は、現在の可用性グループ（SERVER3 がプライマリ）へ簡単に参加させることができます。これは、前の Step で
1
2
SERVER3 が処理したことが分かる
3追加したデータ（7）も表示されていることを確認
4
試した RESUME オプションで同期の再開を行うだけで完了します。これも試してみましょう。
1. まずは、SERVER1 を起動します。
2. SERVER1 が起動したら、Management Studio を起動して、［可用性グループ］フォルダーを確認します。
［可用性データベース］フォルダーを展開すると、AGTestDB データベースのアイコンが白くなっていて、同期が行われていないことを確認できます。
3. 次に、SERVER1 へ接続して、RESUME を実行します。
USE master
ALTER DATABASE AGTestDB SET HADR RESUME
4. 実行が完了したら、オブジェクト エクスプローラーを最新の情報に更新します。
アイコンが「白」になっていることを確認
同期されていません と表示されてていることを確認
SERVER1へ接続
1
RESUMEを実行
3
2
データベースが「緑」のアイコンに変わって、同期が再開されたことを確認できます。
5. 次に、SELECT ステートメントを実行して、t1 テーブルのデータが複製されていることを確認します。
6. 次に、フェールオーバー クラスター マネージャーを起動して、ノードの状態を確認します。
SERVER1 が「稼働中」と表示されて、クラスターのノードとしても正常に動作していることを確認できます。
7. 次に、SERVER2 を起動します。
8. SERVER2 に対しても、SERVER1 に対して行った RESUME を実行するだけで、
接続済み、同期中に変更されたことを確認
［最新の情報に更新］ボタンをクリック
1
「緑」のアイコンに変更されたことを確認
2
3
SELECTを実行
2
1
SERVER1 が稼働中と表示されていることを確認
SERVER3 をプライマリとした可用性グループのメンバーにすることができます。また、同期モードを変更したり、別のノードを可用性グループへ追加したりすることも簡単に行えるので、SERVER3 をプライマリとした新しい可用性グループを構成していくことも簡単です。
なお、SERVER1 をプライマリとした元の構成（一番最初の構成）へ戻したい場合でも、前の Step の手順（FORCE～ での強制フェールオーバーと RESUME での同期の再開）を全く同じように操作するだけで元に戻すことができます。この場合の手順は、次のとおりです。
-- SERVER1 で強制フェールオーバー実行
USE master
ALTER AVAILABILITY GROUP AG1 FORCE_FAILOVER_ALLOW_DATA_LOSS
-- SERVER3 で RESUME の実行
USE master
ALTER DATABASE AGTestDB SET HADR RESUME
-- SERVER2 で RESUME の実行
USE master
ALTER DATABASE AGTestDB SET HADR RESUME
2.11 複数サブネットの場合の構成例（災害復旧用途）
複数サブネットの場合の構成例（災害復旧用途）
可用性グループは、サブネットをまたがっても構成することができるので、DR（Disaster Recovery:災害復旧）用途として、遠隔地へセカンダリを配置することもできます。ここでは、次の図ように 192.168.1 のサブネット（東京）と 172.16 のサブネット（大阪）がある場合の構成方法を説明します。
WSFC（Windows Server フェールオーバー クラスター）では、異なるサブネットのノードが存在する場合には、クラスター作成時の「クラスター作成」ウィザードで、次のようにサブネットごとに IP アドレスを設定することができます。
セカンダリセカンダリ
192.168.1 のサブネット（東京）
同期
非同期
SERVER1
SERVER2SERVER3
172.16 のサブネット（大阪）
プライマリ192.168.1.102
192.168.1.101
172.16.1.3
DR（災害復旧）のための遠隔地サイト
複数のサブネットに対してそれぞれ IP アドレスを設定することができる
2つの IP アドレスが登録されて、どちらかがオンラインになる
サブネットをまたがって作成あされたクラスター
複数サブネットの場合は、クラスター名（画面は CLUSTER001）に対して、2 つの IP アドレスが登録されて、どちらか一方がオンラインになるように設定されます。これは、クラスター名のプロパティを開いて、次のように［依存関係］タブから確認することができます。
OR 条件で 2 つの IP アドレスが登録されることで、どちらかの IP アドレスに依存するクラスター名が作成されることで、サブネットをまたがってフェールオーバーが発生しても、クライアントからは同じクラスター名でアクセスできるようになります。
このように構成されたクラスターの状態で可用性グループを作成すれば、サブネットをまたがって 可用性グループを構成することができます。作成手順は、前の Step で説明したものとほとんど同じで、違いはリスナー（仮想サーバー名／仮想 IP アドレス）を作成するところだけです。
［新しい可用性グループ］ウィザードの［レプリカの指定］ページの［リスナー］タブで、［リス
2つの IP アドレスが登録されて、OR に設定される＝どちらかがオン
ラインになる
2つの IP アドレスを追加
ナー DNS 名］へ任意のリスナー名（AG1_Listener など）を入力、［ポート］へ任意のポート番号（1433 など）、［ネットワーク モード］で「静的 IP」を選択して、［追加］ボタンをクリックし、2つの IP アドレスを追加します（画面は 192.168.1.122 と 172.16.1.122 を追加）。
このようにリスナーには、複数の IP アドレスを登録することができます。
このように作成したリスナーは、フェールオーバー クラスター マネージャーからは、次のように確認できます。。
OR 条件で 2 つの IP アドレスが登録されることで、どちらかに依存するリスナー名（画面は AG1_Listener）が作成されます。192.168.1 のサブネットに属する SERVER1 または SERVER2 がプライマリの場合には、192.168.1.122 がオンライン、172.16 のサブネットに属する SERVER3 がプライマリになった場合には、172.16.1.122 がオンラインになり、それに依存するリスナー名が利用可能になります。これにより、サブネットをまたがったフェールオーバーが発生した場合でも、クライアントからは同じリスナー名でアクセスすることができます。
以上で、複数サブネットでの可用性グループの構成が完了です。ほかの手順（手動フェールオーバーや強制フェールオーバー、RESUME、障害から復旧手順など）は、これまでの Step で説明したものとまったく同じ手順です。
作成したリスナー
2つの IP アドレスが登録されて、OR に設定される＝どちらかがオン
ラインになる
2つの IP アドレスが登録されて、どちらかがオンラインになる
MultiSubnetFailover=True の追加
複数サブネット構成の場合、.NET Framework で作成するクライアント アプリケーションには、接続文字列へ「MultiSubnetFailover=True」を追加しておく必要があります（追加することで迅速なフェールオーバーが可能になります）。
MultiSubnetFailover=True は、SQL Server Native Client 11.0（SQL Server 2012 で提供される SQL Server Native Client）から利用できるようになったオプションです。
DR 目的のリモート サイトのノードには投票権を与えない（NodeWeight=0）
DR（災害復旧）目的の場合は、リモート サイトの WSFC クラスター ノードには投票権（Vote）を与えない（NodeWeight を 0 へ設定する）ようにします。こうすることで、リモート サイトのノードの障害が、プライマリ サイト（メインのノードを配置している場所）へ影響を与えることを防ぐことができます。
NodeWeight を 0 へ設定するには、Windows の修正プログラム「KB 2494036」を適用しておく必要があります。
接続文字列にMultiSubnetFailover=True
を追加する
1
現在の NodeWeight 設定を確認するには（既定では全てのノードが 1に設定される）、次のように Cluster コマンドを利用します。
CLUSTER クラスター名 node /status /properties
NodeWeight を 0 へ設定するには、次のように Cluster コマンドを利用します。
CLUSTER クラスター名 node ノード名 /prop NodeWeight=0
設定内容を確認するには、前述のコマンドを再度実行します。
SERVER1 の NodeWeightが 1 に設定されている
SERVER2 の NodeWeightが 1 に設定されている
SERVER3 の NodeWeightを 0 へ変更
なお、Management Studio を利用して、「dm_hadr_cluster_members」ビューを参照しても、NodeWeight の設定を確認することができます。
SELECT member_name, member_state_desc, number_of_quorum_votes
FROM sys.dm_hadr_cluster_members
ローカル ノードが 2台の場合は「ノードおよびファイル共有マジョリティ」
3台のノードで DR を構成する場合（ローカル サイトが 2台、リモート サイトが 1台）の場合には、リモート サイトのノードの NodeWeight を 0 にする（投票権を削除する）ことで、ローカル サイトは 2個の投票権のみとなってしまい、これでは障害対策にならない（1台のノードの障害でクラスターが停止してしまう）ので、クォーラム構成を「ノード マジョリティ」から「ノードおよびファイル共有マジョリティ」へ変更するなどの対処も必要になります。
SERVER3 の NodeWeightが 0 へ変更されたことを確認
SERVER3 の NodeWeightが 0 へ変更されていることを
確認できる
セカンダリ セカンダリ
192.168.1 のサブネット（東京）
SERVER1 SERVER2 SERVER3
172.16 のサブネット（大阪）
プライマリ
DR（災害復旧）のための遠隔地サイト
投票権有りNodeWeight=1
投票権有りNodeWeight=1
投票権なしNodeWeight=0
3台構成で、投票権が 2個だと、1台のノードが障害発生で、クラスターが停止状態となってしまう投票権 2個
クォーラム構成が「ノード マジョリティ」の場合
なお、ファイル共有マジョリティの代わりに、ローカル サイトへノードをもう 1台追加して、「ノード マジョリティ」で構成することでも障害対策が可能です。クォーラム構成については、オンライン ブックの以下の場所も参考になります。
WSFC クォーラム モードと投票の構成 (SQL Server) http://msdn.microsoft.com/ja-jp/library/hh270280.aspx
その他の参考資料
実際に、複数サブネット構成を構築する際には、以下のドキュメントも一読しておくことをお勧めします。
AlwaysOn 可用性グループの前提条件、制限事項、および推奨事項（HostRecordTTL を設定する (60秒を推奨) など） http://msdn.microsoft.com/ja-jp/library/ff878487
Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx
Requirements and Recommendations for a Multi-Site Failover Cluster http://technet.microsoft.com/en-us/library/dd197575(WS.10).aspx
セカンダリ セカンダリ
192.168.1 のサブネット（東京）
SERVER1 SERVER2 SERVER3
172.16 のサブネット（大阪）
プライマリ
DR（災害復旧）のための遠隔地サイト
投票権有りNodeWeight=1
投票権有りNodeWeight=1
投票権なしNodeWeight=0
投票権が 3個になるので、SERVER1 または SERVER2に障害が発生してもクラスター停止とはならない投票権 3個
共有フォルダー投票権有り
クォーラム構成を「ノードおよびファイル共有マジョリティ」へ変更した場合
1
2
2.12 包含データベースによるログインに依存しない DB ユーザー
包含データベースによるログインに依存しない DB ユーザー
包含データベース（包含データベース）は、SQL Server 2012 から提供された新機能で、ログイン アカウントや照合順序に依存しないデータベースを作成できる機能です。これを利用すれば、ログイン アカウントとは完全に独立したデータベース（DB）ユーザーを作成できるようになるので、可用性グループでも役立ちます。
包含データベースを利用しない場合の DB ユーザーの問題
ここでは、まず包含データベースを利用しなかった場合にどういった問題が発生するのかを試してみましょう。今回作成した AGTestDB データベースは、包含データベースを利用していないので、これで試します。
1. まずは、SQL Server 認証用のログイン アカウントを作成するので、SQL Server の認証モードを混合モードへ設定します。認証モードを設定するには、次のように Management Studio でサーバー名を右クリックして［プロパティ］をクリックします。
［サーバーのプロパティ］ダイアログが表示されたら、［セキュリティ］ページを開いて、「SQL Server 認証モードと Windows 認証モード」をチェックして、［OK］ボタンをクリックします。ダイアログを閉じたら、SQL Server を再起動することで、変更が有効になります。
この操作は、SERVER1、SERVER2、SERVER3 で行ってください。
2. 次に、プライマリ（SERVER1）へ接続して、ログイン アカウントとデータベース ユーザー
2
3
4
1
を作成します。ログイン アカウントを作成するには、次のように［セキュリティ］フォルダーの［ログイン］フォルダーを右クリックして、「新しいログイン」をクリックします。
［ログイン - 新規作成］ダイアログが表示されたら、ログイン名に「testlogin1」など任意の名前を入力して、「SQL Server 認証」を選択、［パスワード］と［パスワードの確認入力］に「P@ssword」など任意のパスワードを設定します。
3. 次に、［ユーザー マッピング］ページを開いて、「AGTestDB」データベースをチェックして、このログイン アカウントにマッピングされたデータベース ユーザーを作成します。
1
2
3
1 2
3
4
次に、「db_datareader」ロールをチェックして、［OK］ボタンをクリックします。これでデータベースに対する読み取り操作が可能になります。
4. 次に、AGTestDB データベースを展開して、［セキュリティ］フォルダーの［ユーザー］フォルダーを展開すると、testlogin1 ユーザーが作成されていることを確認できます。
このユーザーのプロパティを開くと、［ログイン名］に testlogin1 ログイン アカウントが表示されて、ログイン アカウントにマッピングされたユーザーであることを確認できます。
5. 次に、ツールバーの［データベース エンジン クエリ］ボタンをクリックして、testlogin1 ログイン アカウントで接続します。
［認証］で「SQL Server 認証」を選択、［ログイン］に「testlogin1」、パスワードに設定したパスワードを入力して、［接続］ボタンをクリックします。
ログインとマッピングされている
AGTestDBを展開
1
3
testlogin1 ユーザーが作成されていることを確認
2
4
1
2
3
「SQL Server 認証」を選択
testlogin1 で接続
6. 接続完了後、次のように SELECT ステートメントを実行して、t1 テーブルのデータが参照できることを確認します。
7. 次に、SERVER2（セカンダリ）へ接続して、AGTestDB データベースを展開し、［セキュリティ］フォルダーの［ユーザー］フォルダーを展開すると、testlogin1 ユーザーが作成されている（複製されている）ことを確認できます
しかし、ユーザーのプロパティを開くと、［ログイン名］が表示されない、マッピングの切れたユーザーとなっていることを確認できます。
8. 次に、ツールバーの［データベース エンジン クエリ］ボタンをクリックして、testlogin1 ログイン アカウントで SERVER2 への接続を試みます。
testlogin1 としてログインしていることを確認
1
t1 テーブルのデータを参照
2
ログインとマッピングされていない状態
AGTestDBを展開
2
4
testlogin1 ユーザーが複製されていることを確認
3
5
SERVER2に接続
1
6
しかし、結果はエラーとなります。
SERVER2 には、ログイン アカウントを作成していないため、ログインすることができません。
9. 次に、SERVER2 へログイン アカウントを作成します。
［ログイン名］に「testlogin1」と入力して、「SQL Server 認証」を選択し、任意のパスワードを設定します。
1
2
3
SERVER2 へ接続
1
2
3
10. 次に、［ユーザー マッピング］ページを開いて、「AGTestDB」データベースをチェックして、［OK］ボタンをクリックします。
しかし、AGTestDB データベースは、セカンダリに設定されているデータベースなので、読み取り専用として設定されているので、データベースを更新できない主旨のエラーが返ります。
11. 次に、［AGTestDB］データベースのチェックを外して、［OK］ボタンをクリックします。
今度は、「testlogin1 は既に存在します」というエラーが発生します。これは、先ほどのエラーになったときに、ログイン アカウントの作成については成功している（データベース ユーザーの作成は失敗している）ために発生しています。
12. 次に、作成されたログイン アカウント（testlogin1）を確認します。
1 2
3
4
データベースが読み取り専用のため更新できないという
エラーが発生
5
2
3
1
既に存在しますとエラーとなる
13. 次に、もう一度、testlogin1 ログイン アカウントで SERVER2 への接続を試みます。
今度は接続できます。
14. 接続後、USE ステートメントを実行して、AGTestDB データベースへ接続します。
結果は、エラーとなります。これは、SERVER2 上に作成した「testlogin1」ログイン アカウントと AGTestDB データベース内のデータベース ユーザー「testlogin1」のマッピングが切れているために発生しています。これでは、せっかく読み取り可能なセカンダリを作成していても、ユーザーがデータベースへ接続できないことになってしまいます。
testlogin1 ログインが作成されたことを確認
1
2
3
SERVER2 へ接続
testlogin1 としてログインしていることを確認
1
データベースへ接続
2
15. マッピングの切れたユーザーは、次のように sp_change_users_login ストアド プロシージャを実行して確認することができます（このステートメントは、Administrator としてログインした状態で実行してください）。
16. マッピングの切れたユーザーは、Update_One を指定して sp_change_users_login ストアド プロシージャを実行することで、再マッピングする（マッピングを修復する）ことができるのですが、これも次のようにエラーとなります。
セカンダリ データベースは、読み取り専用に設定されるため、マッピング情報の更新（データベース内部のデータ更新）は許可されないのです。
したがって、このステートメントが実行できるのは、セカンダリがプライマリに役割変更されたときだけです。これでは、障害発生時に、（このステートメントが実行されるまで）ユーザーがログインできないことになってしまいます（ダウンタイムが長くなってしまいます）。また、このステートメントを実行しても、内部的な SID を新しいもの（SERVER2 側で作成したログイン アカウントの SecurityID）へ置き換えるだけなので、逆の役割変更があった場合（次に SERVER1 が再びプライマリになった場合）には、再度マッピングが切れたユーザー（SERVER1 上のログイン アカウントの SID と SERVER2 上の同じログイン アカウントの SID が異なるので、再度マッピングが切れる）が発生することにもなります。
したがって、sp_change_users_login ストアド プロシージャによるマッピング更新は、最良の解決策とは言えません。これを解決するための方法が、次の 2つです。
KB（Knowledge Base）918992 で提供される「sp_help_revlogin」ストアド プロシージャを利用して、同じ SID／同じパスワードのログイン アカウントをすべてのサーバー上で作成する。この KB は、以下の URL で提供されている http://support.microsoft.com/kb/918992/ja
Administrator としてログインしていることを確認
2
1
sp_change_users_loginを実行
3
ログインとのマッピングが切れたDB ユーザーをリストアップしてくれる
sp_change_users_loginを実行
1
SQL Server 2012 から提供された新機能「包含データベース」を利用して、ログイン アカウントに依存しないデータベース ユーザーを作成する
包含データベースを利用したログインに依存しない DB ユーザー
包含データベース（Contained Database）機能を利用すると、ログイン アカウントに依存しない（マッピングが不要な）データベース ユーザーを作成することができます（独立したデータベース ユーザーをデータベース内に含められることから Contained と名付けられています）。このようにデータベース ユーザーが独立していれば、可用性グループでの役割変更時にも問題なくそのユーザーを利用することができ、またデータベースの移行時（ハードウェア リプレイス時のデータベース移行時や、別のサーバーへデータベースを移動したい場合、開発機から本番機へデータベースを移動したい場合など）にも役立ちます。
それでは、包含データベースを利用して、可用性グループを構成してみましょう。
1. 包含データベースを利用するには、まずは sp_configure を利用して、SQL Server の構成オプションで Contained Database Authentication（包含データベース認証）を有効化（1へ設定）します。これは次のように実行します。
EXEC sp_configure 'contained database authentication', 1
RECONFIGURE
このオプションは、可用性グループを構成するすべてのサーバー上で実行しておく必要があるので SERVER2 および SERVER3 でも実行しておきます。
SERVER1へ接続
1
sp_configureを実行
2
SERVER2へ接続
1
sp_configureを実行
2
2. 次に、AGTestDB データベースを包含データベースへ設定します。包含データベースへ設定するには、次のようにデータベースのプロパティを開いて、［オプション］ページから［コンテインメントの種類］で「部分」を選択します。
Note： ［コンテインメントの種類］の「完全」？
SQL Server 2012 では、［コンテインメントの種類］は「部分」と「なし」のみが選択できますが、SQL Server 2012 の次のバージョンでは、「完全」が提供されて、さまざまなサーバー オブジェクトに関してもデータベース内に包含したものが作成できるようになる予定です（SQL Server 2012 では、ログイン アカウントと照合順序のみが包含できるため、完全ではなく、部分的な包含という位置付けになっています）。
Note： ALTER DATABASE ステートメントで包含データベースを設定する場合
GUI 操作ではなく、ALTER DATABASE ステートメントで包含データベースを設定する場合には、次のように SET オプションで CONTAINMENT=PARTIAL を指定して実行します。
USE master
go
ALTER DATABASE AGTestDB
SET CONTAINMENT = PARTIAL
WITH NO_WAIT
go
SERVER3へ接続
1
sp_configureを実行
2
SERVER1へ接続
1
2
3
4
5
3. 次に、データベース内にユーザーを作成します。AGTestDB データベースを展開して、［セキュリティ］フォルダーの［ユーザー］を右クリックして、［新しいユーザー］をクリックします。
［データベース ユーザー - 新期］ダイアログが表示されたら、［ユーザーの種類］で「パスワードを持つユーザー」を選択して、［ユーザー名］に「testuser1」、［パスワード］と［パスワードの確認入力］に任意のパスワード（P@ssword など）を設定します。
4. 次に、［メンバーシップ］ページを開いて、「db_datareader」ロールをチェックして、［OK］ボタンをクリックします。これで、データベース内のオブジェクトに対する読み取り操作が行えるようになります。
これで、データベースの中に包含されたデータベース ユーザーの作成が完了です。
2
AGTestDBデータベースを展開
1
3
1
2
3
Note： SQL ステートメントで 包含データベース 内に DB ユーザーを作成する場合
SQL ステートメントを利用して、包含データベース 内にデータベース ユーザーを作成する場合には、次のように CREATE USER ステートメントを実行します。
USE AGTestDB
go
CREATE USER testuser1
WITH PASSWORD = 'P@ssword'
WITH PASSWORD でパスワードを設定することで、データベースの中に包含されたデータベース ユーザーを作成することができます。
5. 次に、作成したユーザー（testuser1）で SERVER1 へ接続します。
［認証］で「SQL Server 認証」を選択、［ログイン］に「testuser1」、［パスワード］に設定したパスワード（P@ssword）を入力して［オプション］ボタンをクリックします。
6. 次のように［接続プロパティ］タブが表示されたら、［データベースへの接続］へ「AGTestDB」と入力して［接続］ボタンをクリックします。
1
2
3
1
2
3
これで、testuser1 ユーザーとして AGTestDB データベースへ接続することができます。
7. 接続完了後、t1 テーブルのデータを参照します。
ステータス バーには、接続しているユーザーと接続先のデータベース名が表示されるので、これで正しく接続できたことを確認できます。
8. 次に、SERVER2 に対して、testuser1 で接続します。
［サーバー名］に「SERVER2」、［認証］で「SQL Server 認証」を選択、［ログイン］に「testuser1」、［パスワード］に設定したパスワード（P@ssword）を入力して［オプション］ボタンをクリックします。
9. ［接続プロパティ］タブが表示されたら、［データベースへの接続］へ「AGTestDB」と入力して［接続］ボタンをクリックします。
testuser1 として接続していることを確認
1
t1 テーブルのデータを参照
3
AGTestDB データベースへ接続していることを確認
2
1
2
3
10. 接続完了後、t1 テーブルのデータを参照します。
何の問題もなくデータが参照できることを確認できます。
このように 包含データベースを利用すれば、データベース ユーザーがデータベース内に包含されるので、マッピングの切れたユーザーが発生することはありません。
tempdb データベースの照合順序に依存しない一時テーブルの作成
包含データベースは、tempdb の照合順序に依存しない一時テーブルの作成ができることも大きなメリットです。従来のバージョンでは、CREATE TABLE ステートメントを利用して作成した一時テーブルの照合順序は tempdb の照合順序を継承するため、データベース移行時に、移行元と移行先で tempdb の照合順序が異なる場合に、照合順序の不一致が発生するという問題がありました。
この問題は、次のように 包含データベースではない通常のデータベースを作成することで確認することができます。
1
2
3
testuser1 として接続していることを確認
1
t1 テーブルのデータを参照
3
AGTestDB データベースへ接続していることを確認
2
-- 包含データベースではない通常のデータベースを照合順序 Japanese_CS_AS で作成
CREATE DATABASE testDB
COLLATE Japanese_CS_AS
go
-- テーブル t1 の作成
USE testDB
CREATE TABLE t1 ( a varchar(100) )
INSERT INTO t1 VALUES('aaa')
SELECT * FROM t1
-- 一時テーブル #t2 の作成
CREATE TABLE #t2 ( a varchar(100) )
INSERT INTO #t2 VALUES('aaa')
SELECT * FROM #t2
このステートメントでは、通常のデータベースを照合順序 Japanese_CS_AS で作成しているので、t1 テーブルの文字列データ型の列は、Japanese_CS_AS として作成されます。一方、tempdb の照合順序は Japanese_CI_AS（既定値）へ設定しているので、一時テーブル ＃t２ の文字列データ型の列は Japanese_CI_AS として作成されます。このように異なる照合順序の列がある場合に、この列を JOIN キーとして利用すると、次のようにエラーが発生してしまいます。
このように、包含データベース ではない通常のデータベースの場合には、移行元と移行先での tempdb の照合順序に注意する必要がありました。これに対して包含データベースでは、tempdb の照合順序に依存しない一時テーブルの作成が可能です。一時テーブルの照合順序は、包含データベース に設定された照合順序を継承するようになっているため、移行元と移行先で tempdb の照合順序が異なっている場合でも、データベースを問題なく動作させることが可能です。
このように、SQL Server 2012 では、包含データベースが提供されたことによって、データベースの移行（バックアップ／リストアやデタッチ／アタッチによるデータベース移動）が非常に簡単に行えるようになりました。これにより、ハードウェア リプレイス時のデータベース移行時や、別のサーバーへデータベースを移動したい場合、開発機から本番機へデータベースを移動したい場合などで大変役立ちます。
また、可用性グループを構成する場合にも、包含データベースを利用することで、データベース ユーザーを何の問題もなく利用できるようになるので、大変便利です。
2.13 可用性グループの削除
可用性グループの削除
この手順は、可用性グループをテストしていた環境をきれいに元に戻したい場合に参考にしてください。
1. 可用性グループを削除するには、削除したい可用性グループを右クリックして、［削除］をクリックします。
［オブジェクトの削除］ダイアログが表示されたら、［OK］ボタンをクリックします。以上で削除が完了です。
2. ただし、可用性グループを削除しても、データベースは削除されないため、データベースを削除したい場合は、個別に削除するようにします。
1
2
1
エンドポイントの削除
可用性グループでは、サーバー間の内部的な通信に、エンドポイントを利用していて、これは自動では削除されません。
1. まずは、endpoints カタログ ビューを参照して、作成されているエンドポイントを確認します。
-- 既存のエンドポイントの確認
SELECT * FROM sys.endpoints
既定では、「Hadr_endpoint」という名前で作成されています。
2. エンドポイントを削除したい場合は、次のように DROP ENDPOINT ステートメントを実行します。
-- エンドポイントの削除
DROP ENDPOINT Hadr_endpoint
以上で 可用性グループ環境のクリーンアップが完了です。
可用性グループで内部利用されるエンドポイント
既定では「Hadr_endpoint」
SSTTEEPP 33.. SSQQLL SSeerrvveerr AAllwwaayyssOOnn フフェェーールルオオーーババーー ククララススタターー イインンススタタンンスス
この STEP では、「SQL Server AlwaysOn フェールオーバー クラスター インスタンス」（SQL Server クラスター）で提供される新機能と「Windows Server Core へのインストール方法」について説明します。
この STEP では、次のことを学習します。
SQL Server クラスターの新機能
Windows Server Core へのインストール
3.1 AlwaysOn フェールオーバー クラスター インスタンス（FCI）
AlwaysOn フェールオーバー クラスター インスタンス（FCI）
AlwaysOn フェールオーバー クラスター インスタンス（FCI）は、WSFC（Windows Server フェールオーバー クラスタリング）のリソースとしてインストールした SQL Server インスタンス（SQL Server クラスター）のことを指します。
SQL Server 2012 では、従来のバージョンの SQL Server クラスターと比べて、次の機能が強化されています。
SMB 接続（共有フォルダー）へのデータベース配置が可能に。SQL Server 2012 からは、共有ストレージが必須ではなくなり、データベースのインストール先としてネットワーク上の共有フォルダーを選択可能
tempdb データベースをローカル ディスクへ配置可能。ボトルネックになりやすい
tempdb データベースをローカル ディスクへ配置できることで、SSD などより高速な内蔵ストレージへ配置して性能向上を実現可能
柔軟なフェールオーバー ポリシー（フェールオーバーを発生させる障害のレベルを 5段階で調整可能。障害検知をより詳細に行うことが可能）
複数サイト（複数サブネット）フェールオーバー クラスタリングのサポート（従来のバージョンではサブネットをまたがったクラスタリングは構成不可。SQL Server 2012 からはサブネットをまたがった構成が可能に）
前の Step での 可用性グループの複数サブネットでの構成例と同じように、SQL Server のクラスター名に対しては、複数の IP アドレスを設定することができる（OR 条件でどちらかをオンラインにできる）ので、サブネットをまたがった SQL Server クラスターを構成することができます。
このように、SQL Server 2012 では WSFC が強化されて柔軟な構成をとれるようになりました。これらは、可用性の向上に繋がるだけでなく、性能向上にも役立つものです。
共有フォルダーをデータベースのインストール先として指定可能に
tempdb データベースをローカル ディスクへ配置可能に
3.2 Windows Server Core へのインストールがサポート
Windows Server Core へのインストールがサポート
SQL Server 2012 からは、Windows Server Core へのインストールがサポートされるようになりました。Server Core では、必要最小限の機能のみしかインストールされないため、よりセキュアな運用が可能になります。また、修正プログラムの適用回数を削減できる（OS の再起動を伴う計画停止時間を大きく短縮できる）というメリットも得られます。
対応している Server Core は、Windows Server 2012 または Windows Server 2008 R2 に SP1 を適用した Server Core です。
SQL Server 2012 を Server Core へインストールするには、SQL Server 2012 のインストーラー（Setup.exe）をコマンドラインから実行するだけです。たとえば、データベース エンジンのみをインストールしたい場合は、次のように Setup.exe を実行するだけで、SQL Server 2012 をインストールすることができます（画面は Windows Server 2008 R2 SP1）。
Setup.exe
/qs
/ACTION=Install
/FEATURES=SQLEngine
/INSTANCENAME=MSSQLSERVER
/SQLSVCACCOUNT=".\sqlservice"
/SQLSVCPASSWORD="P@ssword"
/AGTSVCACCOUNT=".\sqlservice"
/AGTSVCPASSWORD="P@ssword"
/SQLSYSADMINACCOUNTS=".\Administrator"
/IACCEPTSQLSERVERLICENSETERMS
/qs は無人インストール オプションとしてお馴染みのオプション、/ACTION=insall でインス
SQL Server の管理者アカウントの指定
使用許諾契約書への同意
SQL Server Agent サービスのサービス アカウント名とパスワード
SQL Server サービスのサービス アカウント名とパスワード
SQL Server のインスタンス名
データベース エンジンのインストール
トール、/FEATURES でインストールしたい機能を指定（SQLEngine の場合はデータベース エンジン）、/INSTANCENAME へ SQL Server のインスタンス名、/SQLSVCACCOUNT へ SQL Server サービスのサービス アカウント名、/SQLSVCPASSWORD へそのアカウントのパスワード、同様に /AGTSVCACCOUNT と /AGTSVCPASSWORD には SQL Server Agent サービスのサービス アカウント名とパスワード、/SQLSYSADMINACCOUNTS で SQL Server の管理者として設定したいアカウントを指定、/IACCEPTSQLSERVERLICENSETERMS でライセンス条項へ同意したことを意味するオプションになっています。
その他のインストール オプションや、他の機能のインストール方法については、SQL Server 2012 のオンライン ブックの以下の場所を参考にしてみてください。
Server Core への SQL Server 2012 のインストール http://msdn.microsoft.com/ja-jp/library/hh231669
また、上記ページにも記載されていますが、Server Core へインストール可能な SQL Server の機能は、次のとおりです。
Server Core では、データベース エンジンやレプリケーション、フルテキスト検索、Integration Services、Analysis Services のインストールがサポートされています。
機能 サポートデータベース エンジン サービス ◯レプリケーション機能 ◯フルテキスト検索 ◯Integration Services サーバー ◯Analysis Services ◯Reporting Services ×Distributed Replay Controller ×Distributed Replay Client ×Microsoft Sync Framework ×マスター データ サービス（MDS） ×Data Quality Services（DQS） ×
おわりに
最後までこの自習書を試された皆さま、いかがでしたでしょうか？ SQL Server 2012 で提供さ
れる AlwaysOn テクノロジー（可用性グループや SQL Server クラスター、Server Core へ
のインストールなど）によって、より柔軟かつ容易な高可用性システムが構築できることを確認し
ていただけたのではないでしょうか。
この自習書は、「SQL Server AlwaysOn」の新機能に絞ったものでしたが、SQL Server 2012 で
はどんな新機能が提供されているのか？ということを知りたい方は、本自習書シリーズの新機能編
「No.1 新機能ダイジェスト」で説明していますので、ぜひこちらもご覧いただければと思います。
http://www.microsoft.com/ja-jp/sqlserver/2012/technology/self-learning.aspx
また、オンライン ブック（SQL Server のヘルプ）にも詳細手順が記載されているので、こちら
もご覧いただければと思います。
SQL Server 2012 オンライン ブックの URL
http://msdn.microsoft.com/ja-jp/library/ms130214.aspx
執筆者プロフィール
有限会社エスキューエル・クオリティ（http://www.sqlquality.com/） SQLQuality（エスキューエル・クオリティ）は、日本で唯一の SQL Server 専門の独立系コンサルティング会社です。過去のバージョンから最新バージョンまでの SQL Server を知りつくし、多数の実績と豊富な経験を持つ、OS や .NET にも詳しい SQL Server の専門家（キャリア 17年以上）がすべての案件に対応します。人気メニューの「パフォーマンス チューニング サービス」は、100％の成果を上げ、過去すべてのお客様環境で驚異的な性能向上を実現。チューニング スキルは世界トップレベルを自負、検索エンジンでは（英語情報を含めて）ヒットしないノウハウを多数保持。ここ数年は BI／DWHシステム構築支援のご依頼が多い。
主なコンサルティング実績 大手映像制作会社の BI システム構築支援（会計／業務システムにおける予実管理／原価管理など） 大手流通系の DWH／BI システム構築支援（POS データ／在庫データ分析） 大規模テラバイト級データ ウェアハウスの物理・論理設計支援および運用管理設計支援
大手アミューズメント企業の BI システム構築支援（人事システムにおける人材パフォーマンス管理） 外資系医療メーカーの Analysis Services による「販売分析」システムの構築支援（売上／顧客データ分析） 9 TB データベースの物理・論理設計支援（パーティショニング対応など） ハードウェア リプレイス時のハードウェア選定（最適なサーバー、ストレージの選定）、高可用性環境の構築 SQL Server 2000（32ビット）から SQL Server 2008（x64）への移行／アップグレード支援 複数台の SQL Server の Hyper-V 仮想環境への移行支援（サーバー統合支援） 2時間かかっていた日中バッチ実行時間を、わずか 5分へ短縮（95.8％ の性能向上） ピーク時の CPU 利用率 100% のシステムを、わずか 10% にまで軽減し、大幅性能向上 平均 185.3ms かかっていた処理を、わずか 39.2ms へ短縮（78.8％ の性能向上） Java 環境（Tomcat、Seasar2、S2Dao）の SQL Server パフォーマンス チューニング etc
コンサルティング時の作業例（パフォーマンス チューニングの場合） アプリケーション コード（VB、C#、Java、ASP、VBScript、VBA）の解析／改修支援 ストアド プロシージャ／ユーザー定義関数／トリガー（Transact-SQL）の解析／改修支援 インデックス チューニング／SQL チューニング／ロック処理の見直し 現状のハードウェアで将来のアクセス増にどこまで耐えられるかを測定する高負荷テストの実施 IIS ログの解析／アプリケーション ログ（log4net／log4j）の解析 ボトルネック ハードウェアの発見／ボトルネック SQL の発見／ボトルネック アプリケーションの発見 SQL Server の構成オプション／データベース設定の分析／使用状況（CPU, メモリ, ディスク, Wait）解析 定期メンテナンス支援（インデックスの再構築／断片化解消のタイミングや断片化の事前防止策など）etc
松本美穂（まつもと・みほ） 有限会社エスキューエル・クオリティ 代表取締役 Microsoft MVP for SQL Server（2004年 4月～） 経産省認定データベース スペシャリスト／MCDBA／MCSD for .NET／MCITP Database Administrator SQL Serverの日本における最初のバージョンである「SQL Server 4.21a」から SQL Serverに携わり、現在、SQL Server を中心とするコンサルティングを行っている。得意分野はパフォーマンス チューニングと Reporting Services。コンサルティング業務の傍ら、講演や執筆も行い、マイクロソフト主催の最大イベント Tech・Ed などでスピーカーとしても活躍中。SE や ITPro としての経験はもちろん、記名／無記名含めて多くの執筆実績も持ち、様々な角度から SQL Server に携わってきている。著書の『SQL Server 2000でいってみよう』と『ASP.NETでいってみよう』（いずれも翔泳社刊）は、トップ セラー（前者は 28,500部、後者は 16,500部発行）。近刊に『SQL Server 2012の教科書』（ソシム刊）がある。
松本崇博（まつもと・たかひろ） 有限会社エスキューエル・クオリティ 取締役 Microsoft MVP for SQL Server（2004年 4月～） 経産省認定データベース スペシャリスト／MCDBA／MCSD for .NET／MCITP Database Administrator SQL Server の BI システムとパフォーマンス チューニングを得意とするコンサルタント。過去には、約 3,000本のストアド プロシージャのチューニングや、テラバイト級データベースの論理・物理設計、運用管理設計、高可用性設計、BI・DWH システム設計支援などを行う。アプリケーション開発（ASP／ASP.NET、C#、VB 6.0、Java、Access VBA など）やシステム管理者（IT Pro）経験もあり、SQL Server だけでなく、アプリケーションや OS、Web サーバーを絡めた、総合的なコンサルティングが行えるのが強み。Analysis Servicesと Excelによる BIシステムも得意とする。マイクロソフト認定トレーナー時代の 1998年度には、Microsoft CPLSトレーナー アワード（Trainer of the Year）を受賞。