今回は Denali の AWE についてまとめていきたいと思います。

32bit の Denali でも AWE を設定することができます。

DBCC MEMORYSTATUS で Memory Manager を確認すると AWE Allocated によるメモリ割り当てがされていることが確認できます。

それでは、どれくらいのメモリが割り当てられるかを試してみたいと思います。
# /3GB スイッチは無効にしてあります。

このグラフの情報は AWE を有効にしている状態で取得をしているのですが、メモリが 1.4GB 程度で頭打ちになっています。

AWE について SQL Server 2008 R2 の BOL で確認をしてみました。
awe enabled オプション

この機能は、Microsoft SQL Server の次のバージョンで削除されます。
新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションはできるだけ早く修正してください

 

SQL Server 2008 R2 の段階で、AWE は次バージョンで削除されることになっています。
# SQL Server 2008 ではこの記載はありませんでしたので、2008 R2 になって明記されたものになります。

SQL Server で実行されているクエリのトレースを取得できるツール、SQL Server Prolifer には [Deprecation] というイベント カテゴリが用意されており、このカテゴリに含まれるイベント クラスを取得すると実行されている SQL が次バージョンでサポートされるかを確認することができます。
Deprecation イベント カテゴリ

それでは、SQL Server 2008 R2 で [awe enabled] を有効にするクエリを実行してイベントを取得してみたいと思います。

[sp_configure] で [awe enabled] を設定しようとすると、[Deprecation Announcement] イベントが発生しているのが確認できます。
メッセージンは以下の内容が表示されています。

sp_configure ‘awe enabled’ は、今後のバージョンの SQL Server では削除される予定です。 新しい開発作業ではこの機能の使用を避け、現在この機能を使用しているアプリケーションでは変更を検討してください。

SQL Server Plofiler からも、[awe enabled] に関しては削除対象となっていることが確認できます。

それでは、Denali で [awe enabled] を設定するとイベントが発生するかを確認してみたいと思います。

sp_configure ‘awe enabled’ will be removed in a future version of SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use it.

Denali でも 、[Deprecation Announcement] が発生しています。
sp_configure で awe enabled は設定ができているので、構文が使用できるかどうかで見るとこのイベントの発生で正常だと思います。

ただし、メモリが使えるかというと簡単に試したところ、通常のユーザーモードの空間内のメモリしか使えていないようですね…。
/3GB スイッチに関しては想定通りの動きとなり、2GB 以上のメモリ空間の利用が可能となります。

現在は CTP 版なので設定できているのかもしれませんが、SQL Server 2008 R2 の BOL に削除されていると記載されている以上、Denali で AWE が使えると思えるのは危険な気がしますね。

検証した感じでは、32bit の Denali のメモリ割り当ては以下のようになりそうです。

ここまでの投稿で、メモリの情報を取得しながら AWE の動作を簡単に確認してきました。
次の投稿では、AWE 有効時のメモリの使用状況の取得についてまとめたいと思います。

Tech・Ed Europe 2010 のセッション資料が Tech・Ed Online で公開されています。
Tech・Ed Online

Denali リリース後に開催された (といっても本当に直ぐ後ですが) Tech・Ed となり、Denali に関連するセッションがいくつかあったようです。

気づいた範囲になりますが Denali が含まれるセッションをまとめてみました。
# 一文は入っているだけのセッションもありますが。

BIN204:Offering PowerPivot as a Service – Best Practices from Microsoft IT
BIN206:A-to-Z of Master Data Services in Microsoft SQL Server 2008 R2
BIN308:Finally: Data Lineage in Business Intelligence Projects with SQL Server Metadata Toolkit 2008
BIN310:Analysis with Microsoft PowerPivot
DAT222:Microsoft SQL Server Code Name "Denali" Overview
DAT303:SQL Server “Denali” High Availability:The next generation high availability solution
DAT342:SQL Server Performance Series – Part 3 – Query and Index Tuning
# DAT340～342 は Perfomance Series になっており Denali ではありませんがおすすめのセッションです。

DAT222 / DAT303 は Denali とセッション名についているようにフォーカスして情報が公開されています。
# DAT222 は PPTX の提供がないので動画を途中までしか見て入れませんが。

Tech・Ed Europe 2010 のセッション資料のダウンロード先やセッション一覧は以下の URL にテキストベースにはなりますが、簡単にまとめたファイルを作ってみましたので、興味のある方はご利用いただければと思います。
Tech Ed 2010 Europe

Denali の HADR の構築はできましたので、今回はフェールオーバーについてまとめてみたいと思います。

■HADR 用のクラスターグループについて

HADR は WSFC が必須の構成となります。
HADR を構築するとクラスターグループとして Availability Group として設定したグループ名が作成されます。

このクラスターグループにはリソースが一つ含まれています。

このリソースですが、[SQL Server Availability Group] というリソースで作成されています。

リソースの所有者が [Primary] として設定されているサーバーになるようですね。

このグループですが、WSFC の管理コンソールからはグループを移動させることはできないようになっているようです。

 

■SSMS で Primary サーバーを切り替え

WSFC のグループは WSFC の管理コンソールからは切り替えることができません。
Primary サーバーを切り替える (フェールオーバーさせる) 場合は、SSMS から操作をする必要があります。

Primary サーバーの切り替えですが、現在 [Primary] サーバーとなっているサーバーの接続からは変更することができません。

• DENALI-01 : Primary
• DENALI-02 : Secondary

となっている場合、DELALI-01 の接続では、サーバーの切り替えをするためのメニューは表示されません。

DENALI-02 に接続し、Secondary で右クリックをするとメニューが少し変わります。

SSMS で Secondary のサーバーに接続をして、Secondary のサーバーを右クリックすると [Force Failover] が表示されます。
[Force Failover] を使用することで Primary と Secondary を切り替えることができます。

CTP1 の Release Notes には以下の記載があります。

The SQL Server Code-Named “Denali” CTP1 release of "HADR" is a preview and does not support the following features:

• Synchronous data movement (synchronous-commit availability mode).

• Manual failover and automatic failover.

  The only supported form is forced failover, which allows data loss and suspends the secondary databases.

• Log compression.

• Automatic page repair.

• The ALTER AVAILABILITY GROUP Transact-SQL statement does not support changing the configuration of the availability group such as changing read-only access to an availability replica, adding or removing an availability database, and adding or removing a secondary availability replica. For information about what this Transact-SQL statement supports, see ALTER AVAILABILITY GROUP (Transact-SQL) in Books Online.

 

現状は マニュアル / 自動フェールオーバーは実装されていないようです。
そのため、Primary / Secondary を切り替えるためには強制フェールオーバーをする必要があります。
# Primary のサービスを停止しても Secondary には切り替わりません。

それでは、[Force Failover] を実行して Primary と Secondary を切り替えてみたいと思います。
DEHALI-02 に接続し、[HADR Group] → [Availability Replicas] を展開して、[DENALI-02] を右クリックし、[Force Failover] をクリックします。
# Secondary の接続でないと [Force Failover] が表示されません。

[OK] をクリックして、フェールオーバーを実施します。

H
ADR の強制フェールオーバーは以上で完了です。

強制フェールオーバー前は以下の状態となっていました。

[DENALI-01]

[DENALI-02]

 

強制フェールオーバーを実施すると以下の状態となります。

強制フェールオーバー前は [Primary] であった、[DENALI-01] が [Secondary] になっているのが確認できます。
強制フェールオーバーを実施した影響だと思うのですが、[Synchronization State] が [Synchronized] から [Not Synchronizing] に変わっています。

データベースの状態も [Online] から [Suspended] に変わっています。

[DENALI-01]

[DENALI-02]

強制フェールオーバーを実施した場合は、自動で [Online] にはならないため手動で HADR による同期を再開する必要があります。

 

同期を再開するためには、[Secondary] に接続をして [Resume Data Movement] を実行する必要があります。

[OK] をクリックして、HADR によるデータ同期を再開します。

Resume をすることでデータ同期が再開されます。

 

自動フェールオーバーや自動ページ修復が実装されるとミラーリングと変わらない利用が出来そうなので期待大ですね。

次の CTP で検証できるようになっているとうれしいですね～。

Denali では高可用性の構成として、

• レプリケーション
  トランザクションログをディストリビュータに配信し、その内容をサブスクライバに適用することでデータの同期を行います。
  
  # ディストリビュータはパブリッシャと兼用する場合が多いかもしれないですね。
• ログ配布
  トランザクションログのバックアップを共有ディレクトリに取得し、配布先で取得されたログバックアップをリストアすることでデータの同期を行います。
  
• ミラーリング
  プリンシパル / ミラー間でミラーリング用のエンドポイント (接続点) を介してデータの同期を行います。
  ウイットネスサーバーを用意することで障害発生時にプリンシパルとミラーを切り替えることが可能です。
  
• クラスタリング
  共有ディスクにデータベースを配置し、SQL Server のサービスはどちらかのノードで実行する構成になります。
  データベースは共有ディスク一か所なのでデータの同期は行われません。
  

 

のほかに、HADR (high-availability and disaster recovery) という構成が追加されています。
"HADR" Overview (SQL Server)
SQL Server Code-Named "Denali" CTP1 Release Notes の[3.7 High Availability and Disaster Recovery ("HADR")] にも情報が記載されています。

HADR は共有ディスクを使用しないで SQL Server の高可用性環境を作成できる構成になります。

特徴としてはプライマリとセカンダリのサーバーだけで同期をとることができ、サーバー間のデータ同期にはミラーリングと同様にエンドポイントが使用されている点になります。
パッと見はレプリケーションと変わらなそうですが、HADR はデータベース全体を同期の対象とすることが可能です。
# レプリケーションは同期をとるテーブルを選択する必要があったはずです。
レプリケーションは SQL Server Agent は使用してデータの同期が行われますが HADR では SQL Server Agent は不要です。
また、セカンダリデータベースは常に読み取りデータベースとして使用することができるように設定が可能です。

クライアントからの接続はミラーリングと同じような設定ができるようなのですがここはまだ検証ができていません。
"HADR" Overview (SQL Server) に[Client Connections] にこのあたりの記載がされています。
Connecting Clients to a Database Mirroring Session (SQL Server) へのリンクがあるので、ミラーリングと同じように Server / Failover_Partner を使用して自動的なフェールオーバーはできそうなのですが。

CTP1 では

This CTP supports only a single, asynchronous secondary replica.

となっているため、シングルのセカンダリ環境となります。
# GUI 上は複数サーバー設定できそうなのですが、具体的に何サーバー設定できるかが記載されているドキュメントが見つかっていないのですよね…。

HADR はクラスタリングの技術が使用されているため、WSFC が必須となります。

HADR で必要となる要件に関してはこちらの技術情報に記載がされています。
"HADR" Prerequisites and Restrictions
前提となるデータベースの設定条件に関してもこちらの技術情報に記載がされています。

ただし、SQL Server のインスタンスに関してはクラスタインスタンスとする必要はなくローカルインスタンス間でデータの同期を行うことが可能です。

この HADR の構築方法をまとめてみたいと思います。

今回の環境は前回の投稿で作成したクラスタ環境に、ローカルの既定のインスタンスを作成した環境で実施しています。
また、SQL Server のサービスアカウントはドメインユーザーを指定しています。

両サーバーでローカルアカウントを使用して、ミラーアカウントを作成、エンドポイントで証明書を使用する等を行えばドメインユーザーでなくてもデータ連携ができるかもしれませんが今回は簡単な構築の検証のためドメインユーザーを使用しています。
# WSFC なのでドメイン参加は必須ですのでドメインユーザーを使用するのはそれほど敷居が高くないと思います。

 

■HADR の有効化

 

最初の作業として HADR を使用するインスタンスで、HADR を有効化する必要があります。
HADR の有効化は [SQL Server Configuration Manager] から行います。

 

Configuration Manager で対象のインスタンスの SQL Server サービスのプロパティを開くと、[SQL HADR] というタブが表示されます。
このタブの [Enable SQL HADR service] を有効にすることで、対象のインスタンスで HADR を使用することが可能になります。

[Enable SQL HADR service] を両サーバーのインスタンスで有効にして、サービスを再起動します。

 

TCP/IP 接続の有効化

Denali CTP1 の初期状態では、[Shared Memory] のみが有効になった状態になっています。

HADR では TCP/IP でインスタンス間を接続する必要がありますので、TCP/IP を有効にしておきます。
# データの同期はエンドポイントを介して行われますが HADR 設定時に TCP/IP でインスタンスに接続ができる必要があります。


設定を有効にするため、SQL Server のサービスを再起動します。

 

■ファイアウォールの設定

 

HADR はインスタンス間の接続と、エンドポイントの接続ができる必要がありますので、必要となるポートを許可するファイアウォールのルールを設定します。

今回は既定のインスタンスを使用していますので、インスタンス間の接続は [TCP 1433] が必要になります。
エンドポイントでは既定ではミラーリングと同じ [TCP 5022] が使用されますので、この 2 種類のポートを許可するルールを作成します。

netsh advfirewall firewall add rule name="HADR" dir=in protocol=TCP localport=1433,5022 action=allow

 

■HADR の設定

HADR の設定は SQL Server Management Studio (SSMS) から実施します。

今回は、HADR_TEST というデータベースを使用て HADR を設定してみたいと思います。
# 復旧モデルは [完全] に設定しておく必要があります。

最初の作業としては [Availability Group]  を作成します。
HADR はこのグループに属しているデータベースの冗長化を行います。

1. [Management] から、[Availability Groups] を右クリックして、[New Availability Group] をクリックします。
   
2. [Next] をクリックします。
   
3. Availability Group の名称を入力して、[Next] をクリックします。
   
4. HADR で冗長化を行うデータベースを選択する画面が表示されるのですが、データベースを作成した直後の状態だと以下のように対象のデータベースとして選択することができません。
   
   [Show user databases not meeting requirements.] を有効にすると理由が表示されます。
   
   HADR を構成するためには、バックアップを取得しておく必要があります。
   一度もバックアップを取得したことがないデータベースは HADR の対象とすることができません。

   バックアップを取得していると HADR の対象とすることができます。
   対象のデータベースを選択して、[Next] をクリックします。
   

5. HADR に含める SQL Server のインスタンスを設定します。
   デフォルトでは、HADR を設定しようとしたインスタンスが Primary に設定されています。
   
   [Add] をクリックしてインスタンスの追加を行います。
   インスタンスの接続ダイアログが表示されますので HADR に含めるインスタンスに接続を行います。
   
6. インスタンスに接続をすると HADR の対象として追加がされます。
   
   初期の状態では、[Read Mode in Secondary Role] は [Disallow Connections] となっています。
   今回は、Secondary は読み取り専用として使用したいため、[Allow All Connections] に設定を行います。
   
   この設定ですが以下の技術情報の [Read-only Access Behavior] に記載があります。
   Read-Only Access to Secondary Availability Replicas
   READ_CONNECTIONS_ONLY と ALL_CONNECTIONS の違いはこれから勉強しないといけないなと思っています…。
7. [Endpoints] に関しては自動で作成がされます。
   [Next] をクリックして次の画面に遷移します。
   
8. [Finish] をクリックして、Availability Group を作成します。
   [Script] をクリックすることで、Availability Group の設定を行うためのスクリプトを作成することも可能です。
   
9. [Start Data Synchronization] をクリックして Secondaly サーバーとデータの初期同期を行います。
   
10. データの初期同期ですが、バックアップ / リストアを使用して行われます。
    
    バックアップ/リストアは共有ディレクトリ経由で行われますので、共有ディレクトリを作成する必要があります。
    今回は、[Share] という [Everyone:フルコントロール] の共有を作成しています。
    
    注意点としては、Secondary のサーバーにデータベースが存在しているとバックアップ / リストアが実施できない点になります。
    Secondary 側にデータベースが存在していると以下のようなエラーになります。
    
    正常に同期が完了すると以下の画面になります。
    
11. [Close] をクリックして完了します。
    

以上で HADR の設定は完了です。
今回は SSMS で GUI を使って実行しましたが、クエリベースで実行する場合は以下の技術情報が参考になります。
Example: Setting Up an Availability Group Using Windows Authentication (Transact-SQL)

[Availability Groups] の下に設定が追加されていることが確認できます。

設定ついては [Object Explorer Details] からも確認をすることができます。

HADR の設定は特に難しい箇所はなく設定が出来ると思います。
現状は非同期の更新となっていますが、技術情報で以下のように記載されているように、かなり短い間隔で同期はされているように思えます。

Asynchronous-commit mode enables the primary replica to run with minimum transaction latency

 

細かな使い方に関しては別の投稿でまとめていきたいと思います。

Denali で 2 ノードクラスターを構築する手順をまとめてみたいと思います。

WSFC は構築をしてあり、MSDTC のリソースは作成済みです。

■1 ノード目のインストール

事前準備は終わっていますのでセットアップを起動してクラスターのインストールを行います。
Denali のクラスターのインストールは一台ずつ実施をします。
まずは最初のノードのインストールから。

1. セットアップを起動すると .NET Framework 3.5 のインストールを確認されますので、[OK] をクリックしてインストールを行います。
   # .NET Framework 4.0 も合わせてインストールがされるようです。
   
2. [Installation] から [New SQL Server failover Cluster installation] をクリックします。
   
3. [OK] をクリックします。
   
4. [Next] をクリックします。
   CTP1 では、Enterprise Evaluation を使用してクラスターを構築します。
   
5. [I accept the license terms.] を有効にして、[Next] をクリックします。
   
6. [Install] をクリックします。
   
7. セットアップルールの検証が開始されます。問題が無ければ [Next] をクリックします。
   以下の画面では、[Microsoft Cluster Serivce (MSCS) Cluste rverification warnings] が発生しています。
   この警告ですが、WSFC のクラスタの検証レポートで警告が発生していたために発生しています。
   
   

   私がインストールする場合、インストール時にログオンしているドメインアカウントには最低限の権限 (Domain Users) しか与えていないので、コンピューターアカウントの作成に関してのチェックで警告となります。
   
   インストール時にログオンしているユーザーにはコンピューターアカウント作成のための権限は委任していませんが、初期状態の 10 台までの作成で対応ができますので、警告は無視ししています。

   クラスターの検証レポートが以下の状態であれば、SQL Server のインストール検証では警告は発生しません。
   

   また、SQL Server で使用するディスクに関してもインストーラーを実行するノードに移動をしておきます。
   
   [使用可能記憶域] に属している状態ではインストールには使えませんので注意が必要です。
   
   インストーラーを実行しているノードで使用可能な共有ディスクがない場合はエラーになります。
   
   

8. インストールする機能を選択し、[Next] をクリックします。
   今回は、SQL Server のデータベースエンジン関連に必要な最低限の機能をインストールしています。
   
9. インスタンスの情報を入力して、[Next] をクリックします。
   今回は名前付きインスタンスを使用しています。
   
10. [Next] をクリックします。
    
11. SQL Server クラスターのグループ名を設定し、[Next] をクリックします。
    グループ名はコンボボックスになっているのでグループ名を変更することが可能です。
    
    共有ディスクが [使用可能記憶域] に属している場合は、[Next] をクリックすることができませんので一度ほかのグループに移動をしておく必要があります。
    
12. チェックボックスで使用するディスクを選択し、[Next] をクリックします。
    
13. ネットワークを設定して [Next] をクリックします。
    今回は、DHCP のままでインストールをしてみたいと思います。
    
14. クラスターで使用するセキュリティ設定を選択して、[Next] をクリックします。
    今回は、[User service SIDs] を選択しています。
    
15. サービスアカウントと照合順序を設定して、[Next] をクリックします。
    
    
16. セキュリティ設定、データディレクトリ、FILESTREAM の設定をして、[Next] をクリックします。
    
    
    
17. エラー報告をして [Next] をクリックします。
    
18. [Next] をクリックします。
    
19. [Install] をクリックしてインストールを開始します。
    
    
20. [Close] をクリックしてインストールを完了します。
    

これで 1 ノード目のインストールは完了です。

 

■2 ノード目のインストール

 

続いて 2 ノード目のインストールを行います。

1. 2 ノード目でセットアップを実行します。
2. [OK] をクリックします。
   
3. [Installation] から、[Add node to a SQL Server failover cluster] をクリックします。
   
4. [OK] をクリックします。
   
5. [Next] をクリックします。
   
6. [I accept the license terms.] を有効にして、[Next] をクリックします。
   
7. [Install] をクリックします。
   
8. [Next] をクリックします。
   
9. ノードを追加するインスタンスを選択して、[Next] をクリックします。
   
10. [Next] をクリックします。
    
11. サービスアカウントのパスワードを入力して、[Next] をクリックします。
    
12. [Next] をクリックします。
    
13. [Next] をクリックします。
    
14. [Install] をクリックして、インストールを開始します。
    
    
15. [Close] をクリックしてインストールを完了します。
    

以上でクラスターのインストールは完了です。

クラスターインスタンスのインストールは今までのバージョンと変わらないですね。

Denali では高可用性構成として [HADR] という構成があります。

この構成に関しては次の投稿でまとめてみたいと思います。