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] という構成があります。

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

今日は、CodePlex で提供されている [SQL Live Monitor] と [Performance Analysis of Logs (PAL) Tool] を使用した、SQL Server のモニタリングとレポーティングについてまとめてみたいと思います。

■SQL Live Monitor

SQL Live Monitor を使用すると、SQL Server の現状の稼働状況を確認することができます。

[SQL Server] の欄に情報を取得する SQL Server 名 (既定のインスタンスの場合はサーバー名、名前付きインスタンスの場合はサーバー名インスタンス名) を入力して、[Start] をクリックすることで情報が取得できます。

パフォーマンスチューニングをするにあたって、いくつかの項目は手動で情報を取得する必要がありますが現状の状態を把握するのにはとても便利なツールだと思います。
データキャッシュ / プロシージャキャッシュのメモリ使用状況は Page Life Expectancy といった定番の情報をリアルタイムに見やすく確認することが可能です。
Cache Hit Ratio 系は SQL Server のサービスが最後に起動してからの情報なのであまり参考にならない可能性がありますが…。
矢印でデータの流れがわかるようになっており、[>->->] であれば、左の項目から右の項目に、[<-<-<-] であれば右の項目から左の項目に対してデータが流れていることになります。

たとえば、[Checkpoints/Sec] ですが、チェックポイントが発生するとダーティーページがデータファイルに対してフラッシュされます。
そのため、[SQL Memory] から [Disk Storage] に対してデータが流れることになります。この矢印の方向を理解しておくと SQL Server のデータの流れが分かるかと思います。

 

情報はパフォーマンスモニタから取得されており、以下のような項目を取得し、画面に表示を行っています。

DiskIdleTime = LogicalDisk% Idle Time AvgDiskReadSec = LogicalDiskAvg. Disk sec/Read AvgDiskWriteSec = LogicalDiskAvg. Disk sec/Write AvgDiskQueueLength = LogicalDiskAvg. Disk Queue Length DiskReadBytesSec = LogicalDiskDisk Read Bytes/sec DiskWriteBytesSec = LogicalDiskDisk Write Bytes/sec TransactionsSec = DatabasesTransactions/sec LogFlushes = DatabasesLog Flushes/sec TempDBSize = DatabasesData File(s) Size (KB)tempdb TempDBLogSize = DatabasesLog File(s) Size (KB)tempdb TempLogSpaceUsed = DatabasesLog File(s) Used Size (KB)tempdb CPUPercent = Processor% Processor Time CompilesSec = SQL StatisticsSQL Compilations/sec RecompilesSec = SQL StatisticsSQL Re-Compilations/sec BatchesSec = SQL StatisticsBatch Requests/sec TargetMemory = Memory ManagerTarget Server Memory (KB) TotalMemory = Memory ManagerTotal Server Memory (KB) ConnectionMemory = Memory ManagerConnection Memory (KB) MemGrantsPending = Memory ManagerMemory Grants Pending BufferCacheSize = Buffer ManagerDatabase pages BufferCacheHitRatio = Buffer ManagerBuffer cache hit ratio UserPageLookups = Buffer ManagerPage lookups/sec PageLife = Buffer ManagerPage life expectancy LazyWrites = Buffer ManagerLazy writes/sec ReadAheads = Buffer ManagerReadahead pages/sec Checkpoints = Buffer ManagerCheckpoint pages/sec DiskReads = Buffer ManagerPage reads/sec DiskWrites = Buffer ManagerPage writes/sec StolePages = Buffer ManagerStolen pages LocksPerSecond = LocksLock Requests/sec LockWaits = LocksLock Waits/sec_Total AvgLockWaitTime = LocksAverage Wait Time (ms)_Total UserConnections = General StatisticsUser Connections LoginsSec = General StatisticsLogins/sec TempObjectCreate = General StatisticsTemp Tables Creation Rate TempObjectDestroy = General StatisticsTemp Tables For Destruction TempActiveTables = General StatisticsActive Temp Tables ProcedureCacheSize = Plan CacheCache PagesSQL Plans ProcedureCacheHitRatio = Plan CacheCache Hit RatioSQL Plans MemPagesSec = MemoryPages/sec FreePTEs = MemoryFree System Page Table Entries PagedPool = MemoryPool Paged Bytes NonPagedPool = MemoryPool Nonpaged Bytes AvailableSystemRam = MemoryAvailable MBytes ProcQueueLength = SystemProcessor Queue Length WorkTables = Access MethodsWorktables Created/sec WorkFiles = Access MethodsWorkfiles Created/sec FullScans = Access MethodsFull Scans/sec msdtc = Exec StatisticsDistributed QueryExecs in progress

手動でパフォーマンス監視をしたいときはこの項目をベースに必要となる項目を追加していくと楽かもしれないですね。

 

Live Monitor でリンクになっている箇所は情報をブレークダウンすることができます。

[User Connections]

[Total]

[Locks / sec]

[Avg Waits]

[Latch Stats]

[Current Memory]

[Plan Cache]

[Expensive Queries]

[Detailed TempDB Views]

 

SQL Live Monitor は現在の使用状況を確認するだけでなく、ログを取得する機能を持っています。
[Option] ボタンを押すことで、ログ取得の設定をすることが可能です。

デフォルトではログ取得は有効になっていないのですが、
[Log Data for offline analysis (CSV)]
[Log Blocked Process Details (CSV)]
[Log Data for PAL Analysis]
を有効にすることで、ログを取得することが可能になります。ログですが、SQL Live Monitor を実行したフォルダに取得されます。
# Blocked Process はうまく取得できなかったのですが…。

 

[PAL Analysis] は PAL Tool で解析をするための取得データになり、このデータはパフォーマンスモニタを使用して取得されています。
設定を有効にすると、[mscounters] というユーザー定義のデータコレクタ セットが作成され、このコレクタ セットで PAL Tool で解析するためのパフォーマンス情報が取得されます。

この PAL Tool 用のデータですが以下の情報が取得されています。

Network Interface(*)Bytes Total/sec Network Interface(*)Current Bandwidth Network Interface(*)Output Queue Length SystemProcessor Queue Length Processor(*)% Processor Time Processor(*)% Privileged Time Processor(_Total)% Processor Time Processor(_Total)% Privileged Time Processor(*)% Interrupt Time PhysicalDisk(*)% Idle Time PhysicalDisk(*)Avg. Disk sec/Read PhysicalDisk(*)Avg. Disk sec/Write LogicalDisk(*)% Idle Time LogicalDisk(*)Avg. Disk sec/Read LogicalDisk(*)Avg. Disk sec/Write LogicalDisk(C:)Free Megabytes LogicalDisk(*)Disk Transfers/sec MemoryFree System Page Table Entries MemoryPool Nonpaged Bytes MemoryPool Paged Bytes MemoryAvailable MBytes MemoryPages/sec SystemContext Switches/sec Process(*)Private Bytes Process(*)Handle Count Process(*)Thread Count Process(*)% Processor Time Process(*)Virtual Bytes Process(*)Working Set MemorySystem Cache Resident Bytes MemoryPages Input/sec Paging File(*)% Usage Paging File(*)% Usage Peak Process(sqlservr)% Privileged Time Process(sqlservr)% Processor Time Process(*)IO Data Operations/sec Process(*)IO Other Operations/sec SQL StatisticsBatch Requests/sec Access MethodsForwarded Records/sec Access MethodsFreeSpace Scans/sec Access MethodsFull Scans/sec Access MethodsIndex Searches/sec Access MethodsPage Splits/sec Access MethodsScan Point Revalidations/sec Access MethodsWorkfiles Created/sec Access MethodsWorktables Created/sec Buffer ManagerBuffer cache hit ratio Buffer ManagerLazy writes/sec Buffer ManagerCheckpoint pages/sec Buffer ManagerFree pages Buffer ManagerPage life expectancy Buffer ManagerPage lookups/sec Buffer ManagerPage reads/sec Buffer ManagerPage writes/sec General StatisticsLogins/sec General StatisticsLogouts/sec General StatisticsUser Connections LatchesLatch Waits/sec LatchesTotal Latch Wait Time (ms) Memory ManagerMemory Grants Pending Memory ManagerTarget Server Memory (KB) Memory ManagerTarget Server Memory(KB) Memory ManagerTotal Server Memory (KB) Memory ManagerTotal Server Memory( KB) SQL StatisticsSQL Compilations/sec SQL StatisticsSQL Re-Compilations/sec Locks(_Total)Lock Requests/sec Locks(_Total)Lock Waits/sec Locks(_Total)Lock Wait Time (ms) Locks(_Total)Lock Timeouts (timeout > 0)/sec Locks(_Total)Number of Deadlocks/sec

このログを使用して PAL Tool でレポートを作成することが可能となります。

 

■Performance Analysis of Logs (PAL) Tool

 

PAL Tool はパフォーマンスモニタで取得した情報を解析しレポートを作成することができるツールになります。
# PowerShell 2.0 と .NET Framework 3.5 の Chart Control が必要になります。
Live Monitor では、PAL Tool の [Microsoft SQL Server 2005/2008] のテンプレートに合わせた情報を取得していますので、取得したデータをすぐに PAL Tool にかけてレポートを作成することが可能です。

こちらが PAL Tool を起動した画面になります。

レポートの作り方は簡単で、[Counter Log] から Live Monitor で取得したパフォーマンスモニタのログデータを選択し、

[Threshold File] から、[SQL Server 2005/2008] をテンプレートとして設定をし、

[Execute] から [Finish] をクリックすることでレポートを作成することが可能です。

そうすると裏で PowerShell が実行されレポートが作成されます。

PAL Tool の実行が完了するとこのようなレポートが生成されます。
# デフォルトだと PAL Tool を実行したユーザーの [ドキュメントPAL Reports] に出力されます。

CPU の使用率の警告やメモリの空きの警告など基本的な情報を出力してくれるほかに SQL Server 固有のレポートが生成されます。
たとえば、Page Life Expectancy は 300 以上を推移しているのが良好な状態というのが定番になっていますが、そのレポートに関しても作成がされています。
# 300 を超えていない場合は赤くなって警告のレポートが作成されます。

こちらは CPU の使用率のグラフになるのですが、80%～100% は注意が必要な範囲 (Critical) なので赤くなっているのが確認できます。
以下のグラフでは瞬間的に Clitical の領域に達していることが確認できます。

ただし、別のグラフ (Processor の Queue) では Warning / Critical には達していませんので瞬間的な CPU の負荷であって、CPU のスペックの限界までは達していない (処理能力には余裕がある) 状態であると考察することができます。

Live Monitor で取得したデータを基に SQL Server の状態と、サーバーの基本的な状態をレポートとして確認をできますので、複数のグラフを見比べサーバーの状態を確認することが可能となります。

パフォーマンス チューニングではベースラインとして現状を確認することが重要になりますので、これらのツールを組み合わせると一からベースライン情報の取得を考えなくてもよいので楽になるかと思います。

グラフをどう読み解いていくかが難しいところではあるのですが、最初の一歩としては Warning / Critical となっている箇所を注視して、他のグラフと重ね合わせていくとよいのかな～と。

本日 [Microsoft SQL Server code-named ‘Denali’ CTP1] の提供が開始されました。

Code Name Denali ですが、次期 SQL Server の CTP 版になります。
# SQL Server 2011 になるのかなと。

SSMS が VIsutal Studio 2010 ベース (.NET Framework 4.0 もインストールされます) に変更されています。

SSMS が刷新され、レポートが Word 形式でもエクスポートできるようになりました。

PDF のレポートに関してもフォントが埋め込まれるようになったみたいですね。

Availability Groups という機能が増えているようなのですが、これは WSFC の必要があるようですね。

日本語の照合順序に関しては、[Japanese_XJIS_100] が最新のようですね。

 

まだ、ヘルプが見れないので新規にどのような機能が入ったのかは調べられていないのですがクラスタに関しては今週中に構築してみたいと思います。

本日 [Microsoft SQL Server code-named ‘Denali’ CTP1] の提供が開始されました。

Code Name Denali ですが、次期 SQL Server の CTP 版になります。
# SQL Server 2011 になるのかなと。

SSMS が VIsutal Studio 2010 ベース (.NET Framework 4.0 もインストールされます) に変更されています。

SSMS が刷新され、レポートが Word 形式でもエクスポートできるようになりました。

PDF のレポートに関してもフォントが埋め込まれるようになったみたいですね。

Availability Groups という機能が増えているようなのですが、これは WSFC の必要があるようですね。

日本語の照合順序に関しては、[Japanese_XJIS_100] が最新のようですね。

 

まだ、ヘルプが見れないので新規にどのような機能が入ったのかは調べられていないのですがクラスタに関しては今週中に構築してみたいと思います。

SQL Server の管理をするために使用する SQL Server Management Studio (SSMS) ですが、サーバーにはインストールをしているケースが多いと思いますが、保守用のクライアントには入っていないことがあるかもしれないです。

そんな時に便利なのが RemoteApp。

正確に言うと以下の更新プログラムをインストールすることで使用できるようになる、アプリケーションのコンソールリダイレクト機能を使用します。
# Windows 7 / 2008 / 2008 R2 は更新プログラムをインストールしないでも使用できます。

RemoteApp? を有効にするための WindowsR XP SP3 用の更新プログラム
RemoteApp? を有効にするための WindowsR Vista SP1 以降用の更新プログラム

残念ながら Windows Server 2003 用はないのですよね…。
これが使用できるのは、Windows XP SP3 / Windows Vista SP1 以降 / Windows 7 / Windows Server 2008 / Windows Server 2008 R2 上で実行されているプログラムをクライアントで使用したいときに限定がされます。

 

XP / Vista の初期で使用されている、RDP 6.x 系でも使用できます。
最新の RDP 7.0 を使用したい場合は以下の更新プログラムをインストールします。
Windows XP 用の更新プログラム (KB969084)
Windows Vista 用の更新プログラム (KB969084)

 

有効にするための方法はいろいろとあるのですが一番単純なのは、起動したいアプリケーションがインストールされているサーバー (今回は SQL Server をインストールしているサーバー) で以下のレジストリを 1 にすることだと思います。
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTsAppAllowList]
[fDisabledAllowList] (REG_DWORD)

デフォルトは [0] になっていますのでこれを [1] に変更します。
# 再起動は不要です。

これでサーバーで起動できるアプリケーションをリモートデスクトップ経由でリダイレクトできるようになります。
サーバーのアプリケーションを利用したい端末で以下の内容を記載した [.rdp] という拡張子のファイルを作成します。
IP アドレスを記載している部分は接続したいサーバーの IP アドレスに変更してください。
# 最後の行は改行されてしまっていますが一行で記載します。

full address:s:192.168.0.1 server port:i:3389 remoteapplicationmode:i:1 remoteapplicationname:s:SQL Server Management Studio remoteapplicationprogram:s:C:Program Files (x86)Microsoft SQL Server100ToolsBinnVSShellCommon7IDESsms.exe

リモートデスクトップを使用していますので、サーバー側でリモートデスクトップを有効にする必要もあります。
# 3389 はリモートデスクトップのポートですので。

上の画像では、NLA (ネットワーク レベル認証) で設定をしていますが、NLA でない設定でも問題はありません。

 

後は作成した RDP ファイルを実行して、リモートデスクトップ接続をすれば RemoteApp で SSMS を起動することが可能です。

SSMS が起動してきているのですが、[(リモート)] となっているのが確認できます。
これはリモートデスクトップ経由でアプリケーションが実行されていることになります。

タスクマネージャーから確認をしても同様に (リモート) となっています。

 

リモートデスクトップで接続ができる環境にインストールされているプログラムを透過的に利用したい場合は結構便利だと思います。

私は、XP の環境で Hyper-V マネージャーを使用したい場合にもこの方法を使用して使っていたりします。
# UAC が働くので、一度ダイアログが表示されてしまいますが。

先日、
@IT などを運営されている
アイティメディア株式会社様
の会議スペースをお借りして開催された、SQL Server の勉強会に参加をしてきました。

その勉強会の中で SQL Server の [Resource] データベースについて質問を受けたので、このデータベースについて少し書いてみたいと思います。

Resource データベースに関しては、Books Online で以下のように記載されています。

Resource データベースは、読み取り専用のデータベースで、SQL Server に含まれるすべてのシステム オブジェクトがこれに格納されます。 SQL Server システム オブジェクト (sys.objects など) は、物理的には Resource データベースに保存されていますが、論理的にはすべてのデータベースの sys スキーマ内にあるように扱われます。 Resource データベースには、ユーザーのデータやユーザーのメタデータは保持されません。

各データベースのシステムビューやシステムストアドプロシージャーなどで使用されている、[sys.xxxx] 関連の情報は [Resource] データベースの内容を透過的に参照している形になります。
# Resource データベースは SSMS (SQL Server Management Studio) には表示されません。

普段何気なく使用している、[sys.master_files] のようなシステムビューですが、これは [ビュー] と名前がついている用に実体ではなく、実表を参照しているものになります。

ではこの実体はどこに格納されているかというと実体は [master] データベースに保存されています。
試しに [sys.master_files] のビュー定義を確認してみたいと思います。
確認するためには、[SELECT OBJECT_DEFINITION(OBJECT_ID(‘sys.master_files’))] というように OBJECT_DEFINITION を使います。

CREATE VIEW sys.master_files AS   SELECT     database_id  = f.dbid,     file_id   = f.fileid,     file_guid   = f.fileguid,     type   = f.filetype,     type_desc  = ft.name,     data_space_id  = f.grpid,     name    = f.lname,     physical_name  = f.pname,     state   =         convert(tinyint,             case f.filestate  — Map enum EMDFileState to AvailablityStates                          when 0 then 0 when 10 then 0 — ONLINE                        when 4 then 7 — DEFUNCT                        when 5 then 3                 when 9 then 3 — RECOVERY_PENDING                        when 7 then 1                 when 8 then 1                 when 11 then 1 — RESTORING                        when 12 then 4 — SUSPECT                    else 6 end), — OFFLINE        state_desc  = st.name,     f.size,     max_size    = f.maxsize,     f.growth,     is_media_read_only  = sysconv(bit, f.status & 8),  — FIL_READONLY_MEDIA     is_read_only    = sysconv(bit, f.status & 16), — FIL_READONLY     is_sparse    = sysconv(bit, f.status & 256), — FIL_SPARSE_FILE     is_percent_growth  = sysconv(bit, f.status & 32), — FIL_PERCENT_GROWTH     is_name_reserved  = sysconv(bit, case f.filestate when 3 then 1 else 0 end), — x_efs_DroppedReusePending     create_lsn   = GetNumericLsn(f.createlsn),     drop_lsn    = GetNumericLsn(f.droplsn),     read_only_lsn   = GetNumericLsn(f.readonlylsn),     read_write_lsn  = GetNumericLsn(f.readwritelsn),     differential_base_lsn = GetNumericLsn(f.diffbaselsn),     differential_base_guid = f.diffbaseguid,     differential_base_time = nullif(f.diffbasetime, 0),     redo_start_lsn   = GetNumericLsn(f.redostartlsn),     redo_start_fork_guid = f.redostartforkguid,     redo_target_lsn  = GetNumericLsn(f.redotargetlsn),     redo_target_fork_guid = f.forkguid,     backup_lsn   = GetNumericLsn(f.backuplsn) FROM     master.sys.sysbrickfiles f     LEFT JOIN         sys.syspalvalues st         ON         st.class = ‘DBFS’         AND         st.value = f.filestate     LEFT JOIN         sys.syspalvalues ft         ON         ft.class = ‘DBFT’         AND ft.value = f.filetype WHERE     f.dbid < 0x7fff — consistent with sys.databases     AND     f.pruid = 0     AND     f.filestate NOT IN (1, 2) — x_efs_Dummy, x_efs_Dropped     AND     has_access(‘MF’, 1) = 1

ビューの元になるデータは [master.sys.sysbrickfiles] というテーブルになっています。
Resource データベースはこのようなシステムビューやシステムストアドプロシージャを格納し、master 上に格納されている情報を透過的に見せるために使用されています。
# 今回のベース表になっている、[master.sys.sysbrickfiles] は直接参照できないので。

この Resource データベースですが、以下の 2 つのファイルから構成されています。

• mssqlsystemresource.mdf
• mssqlsystemresource.ldf

通常、システムデータベースは
[C:Program FilesMicrosoft SQL ServerMSSQL10_50.<インスタンス ID>MSSQLDATA]
というディレクトリに格納されるのですが、リソースデータベースのファイルは、
[C:Program FilesMicrosoft SQL ServerMSSQL10_50.<インスタンス ID>MSSQLBinn]
に格納がされます。
インスタンスのプログラム扱いでファイルが格納されていますね。

この Resource データベースですが、バージョンがあり [SELECT SERVERPROPERTY(‘ResourceVersion’)] というクエリを実行することでバージョンを確認することができます。

このバージョンですが、SQL Server のバージョンと一致するようで、

• SQL Server 2008 R2 RTM ： [10.50.1600]
• SQL Server 2008 R2 CU4 ： [10.50.1746]

となります。

修正プログラムをインストールすると、Resource データベースのバージョンも更新されます。

Resouce データベースには実データではなく実データを見せるための定義が格納されているので、Books Online で

SQL Server では、Resource データベースをバックアップできません。 ファイル ベースまたはディスク ベースのバックアップは、mssqlsystemresource.mdf ファイルをデータベース ファイルではなくバイナリ (.EXE) ファイルのように実行できますが、SQL Server を使用してバックアップを復元することはできません。 mssqlsystemresource.mdf のバックアップ コピーの復元は手動でのみ実行できます。 また、現在の Resource データベースを古いバージョンや安全でない可能性のあるバージョンで上書きしないように注意する必要があります。

と書かれているのは、実データは含まれず定義のみが格納されており適切なバージョンの SQL Server をインストールすれば最適な状態になるからだと思います。

 

Resource データベースは SSMS に表示がされないので通常はどのような情報が格納されているのか見ることはできないのですが、実はデータベースのファイルをコピーしてアタッチすることで内容を確認することができます。
# mssqlsystemresource.mdf / ldf は読み取り専用で SQL Server 上で認識されているのでオンラインでもコピー可能です。

通常のアタッチでは、以下のようなエラーになります。

このエラーですが、[mssqlsystemresource] というデータベース名でアタッチをしようとしたために発生しています。
# Resource データベースですが内部的には、[mssqlsystemresource] で認識されているためだと思います。

[次の名前でアタッチ] のデータベースの名前を変更することで Resource データベースをアタッチすることが可能です。
今回は、Resource というデータベース名でアタッチしています。

アタッチをすることで Resource データベースの内容を直接確認することが可能になります。

通常、[sys.xxxxx] はシステム ビューやシステム ストアド プロシージャーとして認識されているのですが、アタッチした Resource データベースではユーザービュー / ユーザー ストアド プロシージャーとして認識がされます。
# システムビューやシステム ストアド プロシージャーとしても認識はされるのですが。

システム ビュー / システム ストアド プロシージャーの状態では、スクリプト化ができないため [OBJECT_DEFINITION] を介して定義を確認していました。

ユーザーオブジェクトになっていればスクリプト化が可能なため、[sys.xxxx] といったものも簡単に内容を確認できます。

 

Resource データベースは SQL Server 2005 になってから搭載されたものなのですが、通常使用している中ではあまり意識はしないので、どんなデータが入っているのかイメージがしにくいのですよね…。
# 私は、sys. 系の定義が入っているだけだと考えているのですが。

OpsMgr の勉強の続きです。

OpsMgr ではインストール時にいくつかのサービスアカウントの設定があります。

ローカルシステムアカウントやローカル Administrator を使用するとインストールすることはできるのですが、実運用環境に置いては権限が強すぎる、アカウントを変更する必要があるというケースが考えられると思います。

インストール時に指定したアカウントが設定される個所についてみていきたいと思います。
アカウントに関しては、OpsMgr の管理コンソールの [管理] アカウントで大体のユーザーを確認することができます。

各アカウントがどのように使用されるかは以下の技術情報に記載されています。
Operations Manager 2007 のアカウント情報

 

■管理サーバー アクション アカウント

 

管理サーバー アクション アカウントに関しては、ローカルの [Users] グループのユーザーで設定が可能なようです。
最低限の権限を持つユーザーで設定ができるようですね。

管理サーバー アクションアカウントは、[種類:アクション アカウント] に設定がされます。

[Local System Action Account] はデフォルトで作成されます。
このアカウントには、[Local System] (ローカルシステムアカウント) が設定されており、管理サーバー アクション アカウントを [ローカルシステム] で設定した場合には、このアクションアカウントのみが作成された状態になります。

アクションアカウントについては、[実行アカウントの作成] で [アクション アカウント] を選択することで新規に作成ができますので、アカウントを変更したいとなったら、新規に実行アカウントを作成すれば良さそうですね。

[Local System Action Account] 以外に関しては、ユーザー名を変更することができますので新規に作成しなくても変更することで対応ができそうです。

[ローカル セキュリティ ポリシー] の [ユーザー権利の割り当て] として以下の権限が付与されているようです。

[サービスとしてログオン]

サービスアカウントとして、アクションアカウントが設定されているサービスはないのですが、[サービスとしてログオン] の権限が付与されているようでした。

SQL Server のログインとしても設定がされていますのでこちらも変更の必要がありそうです。

■SDK と Config サービスアカウント

 

SDK と Config サービスアカウントに関しては、ローカルの [Administrators] グループのユーザーの必要があるようです。
Administrators グループに属していないユーザーをアカウントに設定しようとするとこのようなエラーになります。

このエラーですが、サービスアカウントとしてローカルユーザーを使用する場合も表示されるようで、ローカルアカウントを使用する場合はローカルの [Administrator] でないと駄目でした。
# Administrators グループのローカルユーザーではインストールできませんでした。

ここで設定したアカウントに関しては、OpsMgr の管理コンソールで指定できるアカウントではなくサービスアカウントとして設定がされます。
変更については技術情報が提供されています。
Operations Manager 2007 で SDK と Config サービス アカウントを変更する方法

設定したアカウントは以下のサービスのアカウントとして設定がされます。
[Ops Mgr VSS Writer Service]

このサービスに関しては上述の技術情報に記載されていないのですよね…。
ただ、サービスアカウントとしては設定がされていますので、変更の必要はあると思います。

[System Center Data Access]

[System Center Management Configuration]

[ローカル セキュリティ ポリシー] の [ユーザー権利の割り当て] として以下の権限が付与されているようです。

[サービスとしてログオン]

[セキュリティ監査の生成]

こちらも SQL Server のログインができていますので作成する必要がありそうです。

 

■データウェア ハウス 書き込みアカウント

 

このアカウントはローカルの [Users] グループで問題ないようです。

データウェア ハウス 書き込みアカウントは [種類:Windows] の [データウェアハウス アクション アカウント] として設定がされます。

実行アカウントを作成する場合は [Windows] で作成すれば良さそうですね。

このアカウントは編集することができますので、新規に作成しなくてもすでに作成されているアカウントを変更することでも対応できそうです。

データベース用のアカウントですので、SQL Server にもログインが作成されています。

■データ リーダー アカウント

 

このアカウントはローカルの [Users] グループで問題ないようです。

データウェア ハウス 書き込みアカウントは [種類:Windows] の [データウェアハウスのレポート展開アカウント] として設定がされます。

実行アカウントを作成する場合はデータウェアハウス アクション アカウントと同様 [Windows] で作成すれば良さそうですね。

 

このアカウントも編集することが可能です。

データリーダーアカウントについてはサービスのアカウントとしても設定されています。

[SQL Server Reporting Services]

Reporting Service のサービスアカウントとしても設定がされるみたいですね。
OpsMgr の Reporting Service のアカウント変更に関しては技術文書が提供されています。
Operations Manager 2007 でレポート サーバー実行アカウントのパスワードを変更する方法

サービスからではなく [Reporting Services 構成マネージャー] から変更を行います。

 

ローカルセキュリティポリシーとしてもいくつか権限が付与されているようです。
[サービスとしてログオン]

[バッチジョブとしてログオン]

SQL Server のログオンとしても設定がされています。

 

 

ここまで書いた内容を簡単にまとめると下表のようになります。

アカウント	グループ	OpsMgr アカウント	サービス	ユーザー権利の割り当て	SQL ログイン
管理サーバー アクション アカウント	Users	アクション アカウント		サービスとしてログオン	あり
SDK と Config サービスアカウント	Administrators		OpsMgrVSSWriter OMSDK OMCFG	サービスとしてログオン セキュリティ監査の生成	あり
データウェア ハウス 書き込みアカウント	Users	データ ウェアハウス アクションアカウント			あり
データ リーダー アカウント	Users	データウェアハウスの レポート展開アカウント	ReportServer	サービスとしてログオン バッチジョブとしてログオン	あり

 

インストール時に暫定アカウントとして使っていない限り変更の必要はないとは思いますが、設定したユーザーがどこに設定されているかを知っていると便利かなと思いまとめてみました。

Winodws Server 2008 R2 SP1 RC のインストールが終わったので Hyper- マネージャーを少し触っています。

Windows Server 2008 R2 SP1 RC の評価ガイドは以下からダウンロードできるのですが現状は Beta の内容がベースになっているようで、RC での変更点は記載されていないようでした。
Windows Server 2008 R2 SP1 RC Reviewer’s Guide
Download Windows Server 2008 R2 Technical Whitepaper

■ RTM / Beta / RC の Hyper-V マネージャーの表示内容の比較

 

Hyper-V マネージャーは RTM / Beta / RC で設定できる内容や表示内容に変更があります。
それぞれを比較していきたいと思います。

SP1 Beta / RC で起動した仮想マシンですが、構成ファイルに SP1 特有の定義が入るためエクスポートしても RTM にインポートできなくなりますのでご注意ください。
# エクスポート前やエクスポート後の構成ファイルを手で書き換えればインポートできるかもしれませんが…。

 

■仮想マシンの一覧画面
SP 1 では Dynamic Memory の機能が追加されています。
SP1 以降では、仮想マシンの一覧画面が Dynamic Memory に対応した表示になっています。

[RTM]

[SP1 Beta]

[SP1 RC]

Beta では、[現在のメモリ] [使用可能なメモリ] という表示だったものが、SP1 Beta では、[Assgined Memory] [Memory Demand] [Memory Status] という表示になっています。

Beta では、[現在のメモリ] に、仮想マシンに割り当てらている物理メモリ、[使用可能なメモリ] に [(現在のメモリ – 仮想マシンのコミットチャージ) / 現在のメモリ] の値が表示されています。

Dynamic Memory で仮想マシンにメモリが割り当てられる場合は、使用可能めなメモリがマイナスを示すことはありませんが、メモリが割り当てられなくなり、コミットチャージが割り当てられている物理メモリを超えた場合、この値はマイナスになります。

上の画像は使用可能なメモリがマイナスとなっているときの仮想マシンの状態になります。
# Dynamic Memory はスタートアップ RAM が 1024 MB、最大 RAM が 1536 MB で設定しています。
[コミット (MB)] が 2046 MB になっていますが、[現在のメモリ] は 1536 MB になっています。
そのため、[(1536 ? 2046) / 1536 = ?0.33203125 = ?33%] となります。

仮想マシンに割り当てられているメモリが足りていないということですね。

 

SP1 RC だと、[Assgined Memory] [Memory Demand] [Memory Status] の 3 項目に表示が変更がされています。

• [Assgined Memory] は Beta の [現在のメモリ] に相当します。仮想マシンに割り当てられているメモリが表示されます。
• [Memory Demand] は、仮想マシンのコミットチャージの値が表示されます。
• [Memory Status] は、[OK] [Low] [Warning] のいずれかが表示されます。

Beta の [使用可能なメモリ] に相当するのは、[Memory Demand] と [Memory Status] に分けられたようです。
仮想マシンのコミットチャージが [Memory Demand] に表示され、[Assigned Memory] と [Memory Demand] の比較が [Memory Status] に表示されます。

[Assigned Memory] と [Memory Demand] の値に差がある (メモリに余裕がある) 場合は、[OK] が表示されます。

[Assigned Memory] と [Memory Demand] の値に差がな少ない (メモリに余裕が少ない) 場合は、[Low] が表示されます。
具体的にどれくらいの値になると [Low] になるかが記載されているドキュメントは見つからなかったのですが、割合が 86% ぐらいになると Low にはなるようでした。

[Memory Demand] が [Assgined Memory] を超えた (メモリに余裕がない) 場合は、[Warning] となります。

 

■Hyper-V の設定

NUMA アーキテクチャが使われている環境では、NUMA ノード内のメモリに当てはまる範囲で、仮想マシンのメモリを設定するのがベストプラクティスとなっています。
# NUMA ノード内に当てはまらないメモリを割り当てた場合、パフォーマンスが低下することがあります。
Hyper-V のパフォーマンスおよび容量の要件

SP1 では、[Hyper-V の設定] の設定が追加されています。

[RTM]

[SP1 Beta]

[SP1 RC]

SP1 では、[NUMA ノードにまたがるメモリ割り当て] という設定が追加されています。
デフォルトでは、[仮想マシンに NUMA ノードをまたがるメモリを割り当てる] が有効に設定されています。
この設定ですが変更をすると再起動が必要となりますので、稼働中は変更することができないので注意が必要です。

この設定ですがレジストリに格納がされています。

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationNumaSpanning]
この DWORD に値が設定されます。
[仮想マシンに NUMA ノードをまたがるメモリを割り当てる] を有効にしている場合は、[1] が、無効にしている場合は、[2] が設定されます。
RTM からアップグレードした場合は DWORD が存在していないようです。存在しない場合は有効という判断なのかもしれないですね。

 

■Dynamic Memory の設定

Dynamic Memory のバッファの設定方法が SP1 Beta と RC では変更されています。

[RTM]

[SP1 Beta]

[SP1 RC]

SP1 Beta ではメモリバッファーはスライドバーだったのですが、SP1 RC ではテキストボックスに変更がされています。

 

RetemoFX 関連の設定に関しては変わっていないようですね。

 

RTW した際にはまた変更されているかもしれませんが、ひとまず気づいたことをまとめてみました。