高橋 理香
SQL Developer Escalation Engineer

みなさん、こんにちは。
次は接続エラーを再度・・・と予告していたのですが、今回も接続タイムアウトについての情報を書きたいと思います。

接続タイムアウト値はどこで設定するのか

---

前回の「Troubleshooting Connectivity #6 - 接続タイムアウトは悪なのか？」に記載したように、接続タイムアウトの設定は、接続確立完了までに要する時間として許容する限界値を定めたものであり、かつ、障害が発生しているかを見極めるための時間の設定です。したがって、接続をしようとしている側 (アプリケーションやツール等) で設定するものであり、サーバー側で設定するものではありません。たとえば、サーバーがダウンしている場合を考えてみてください。接続相手がいない状態でリクエストを行うわけですから、もしサーバー側での設定があったとしたらそれは機能できませんね。

このように、接続タイムアウト値は接続をリクエストする際にそのリクエストを行う側がその接続に要してもいい時間を設定するものですので、基本的にはアプリケーションにてその設定を行うものとお考えください。

接続タイムアウト値はどのように働くのか

---

では、接続タイムアウト値を設定したはいいけど、指定した時間になったらちょうどでエラーになるのでしょうか。

残念ながらか、気が利いているのかは要件によるのですが、ちょうどの時間ではエラーにならないパターンがあります。
先に例にあげたサーバーがダウンしている場合がこのパターンに該当しますので、その動作について以下の2点の機能に分けて説明します。

A:    接続に使用するプロトコルの自動切り替え
B:    プロトコル自体のタイムアウトおよび再転送設定

A: 接続に使用するプロトコルの自動切り替え

SQL Server へアクセスするドライバーやプロバイダーの多くは、接続時には以下のように複数のプロトコルでの接続試行を行うよう設計されています。

ADO.NET の System.Data.SqlClient (.NET Framework Data Provider for SQL Server) を使用してリモートの SQL Server に接続する場合を例にすると以下の通りです。

1) TCP/IP プロトコルで接続試行する。
2) TCP/IP プロトコルによって OS レベルのセッション確立がタイムアウトした場合、名前付きパイプに切り替えて接続試行する。
3) 名前付きパイプによるセッション確立もタイムアウトした場合、接続タイムアウトと判断してエラーを返す。

これは、可能な限りサーバー側で待ち受けているプロトコルに応じて接続が可能となる確率をあげるために行っていることです。先に記載した「気を利かせている」機能ですね。
したがって、サーバーがダウンしている状況において接続試行すると、既定の設定ではこれらの2つのプロトコル分の処理が行われることになります。

※参考
System.Data.SqlClient のプロトコルに関する既定の動作については以下に記載があります。

SqlClient Default Protocol Order
http://blogs.msdn.com/b/adonet/archive/2010/04/18/sqlclient-default-protocol-order.aspx

B: プロトコル自体のタイムアウトおよび再転送設定

System.Data.SqlClient などの SQL Server に接続に使用されるドライバやプロバイダーでは、ソケット関数を呼び出して、その結果を待ってから接続タイムアウト時間を経過しているかどうかを判断する実装となっています。これは、ソケット関数の処理の完了までに要する時間が接続タイムアウト設定値には左右されないことを意味します。

また、TCP/IP プロトコルは双方向通信のプロトコルであり、何かリクエストを送信した場合にはその応答があるまで待つのが基本の動作です。そのため、接続先のサーバーが停止している場合、そのサーバーは応答できませんので、接続リクエスト元では来ない応答を待つことになります。

わかりやすい例をあげると、電話したら通話音は鳴るけれども誰も出ない状態があります。

みなさんは何コールくらいで電話を切りますか？また、何回くらいかけてみて誰も出なければ不在なのだろうと考えますか？

私は 10コールで切ってすぐに1回かけなおし、5-10分おいて１回かけたら不在、そんなところです。

Windows では、サーバーからの応答の待ち時間 (タイムアウト) は初回 3秒、再試行回数は既定で 2回で設定されています。また、再試行時には前回の倍の秒数を待ちます。したがって、ソケット関数がタイムアウトするまでには 3 + 6 + 12 = 21 秒を要することになります。上位層ではこの完了までを待つため、例えば System.Data.SqlClient で接続タイムアウト値を 5秒にしていたとしても、21秒は待つことになります。

名前付きパイプの場合も、サーバーが停止している状態では、接続のリクエストのパケット送信によるセッション確立からの開始になるため、TCP/IP の場合と同様のタイムアウト値となります。

接続タイムアウトのエラーまでの時間を制御できるか

---

先の Aおよび Bの機能により、接続タイムアウトまでの時間が設定した時間よりも長い時間が経過してから発生する可能性があることをおわかりいただけたかと思います。
では、この時間を制御することはできるのでしょうか。

残念ながら厳密な制御はできませんが、それぞれの機能の面から以下の２つのいずれかの方法でより短い時間でエラーとすることが可能です。

A に対する方法: 接続試行は単一のプロトコルのみで行う
B に対する方法: TCP/IP の再転送回数を減らす

一例ですが、System.Data.SqlClientにおいては以下のいずれかの方法で単一のプロトコルを使用できるようになります。

- Network Library キーワードを使用する。
  例えば接続文字列に Network Library=dbmssocn を指定すると TCP/IP のみを使用することになります。

- Data Source に指定する IP アドレスやインスタンス名にプロトコルを明示する。
  例えば Server01 インスタンスにアクセスする場合には Data Source=Server01と記載しますが、名前付きパイプで接続したい場合には以下のように変更します。

        Data Source=np:Server01

.NET Framework アプリケーションの場合は、どちらも MSDN リファレンスの以下のページにそれぞれの指定方法についての記載がありますのでご覧ください。

SqlConnection.ConnectionString プロパティ
http://msdn.microsoft.com/ja-jp/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.100).aspx

接続時の再転送回数設定を調整するには

・アプリケーション実行環境が Windows Server 2008 / Vista 以降のバージョンの場合

以下から入手できる修正プログラムを導入することで接続時の再転送回数の設定を netsh コマンドによって調整できます。

Hotfix enables the configuration of the TCP maximum SYN retransmission amount in Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/kb/2786464

・アプリケーション実行環境が Windows Server 2008 / VIsta 以前のバージョンの場合

Windows Vista 以前ではレジストリの TcpMaxConnectRetransmissions の値を設定することで接続試行の再転送回数を制御可能ですが Windows Vista 以降ではこのレジストリは存在しません。

TCP/IP Registry Values for Microsoft Windows Vista and Windows Server 2008
http://www.microsoft.com/en-us/download/details.aspx?id=9152

Appendix A: TCP/IP Configuration Parameters
http://technet.microsoft.com/ja-jp/library/cc739819(v=ws.10).aspx

今回の接続タイムアウト時の動作についての情報が何か役立つようであればうれしいです。
さて次回はスキップしたエラーについてまとめられたらと思っています。

福原 宗稚
Support Escalation Engineer

最近複数のお客様から、レプリケーションについて同様の事象を報告いただくことがありました。レプリケーションモニターやエージェントのヒストリーを見ても、エージェントの起動に失敗したという記録くらいしか確認できずなかなか分かりにくい事象のため、ここでご紹介します。

問題

サブスクリプションのスナップショット適用時、もしくはその後の同期において、ディストリビューション エージェントでエラーが発生します。
SQL Server エラーログや、アプリケーションイベントログには、エラー 14151が記録されます。

特徴

下記の特徴があります。これらに合致する場合には、この問題に合致していると判断できます。

1) システム イベントログに、ディストリビューションエージェントの起動後にエラー 243が 1 回記録されます。

2) 多くのサブスクリプションを設定しています。これまでの実績としては、約300個のサブスクリプションを設定している環境で発生しています。

原因

多くのディスクトリビューションエージェントが起動することによって、デスクトップヒープが枯渇することが原因です。

デスクトップヒープはアプリケーションが通常動作する際に内部的に使用されるメモリ領域です。このデスクトップヒープはサーバーの物理メモリに関係なく、OSによって固定サイズが割り当てられています。 この領域が不足すると、物理メモリ領域に空きがあっても、アプリケーションが起動しない現象が発生することがあります。
 

対処

以下のいずれかの方法により対応可能です。

1.デスクトップヒープのサイズを拡張する

2.サブスクリプションの定義を PUSH 型と PULL 型の2種類に分割する

3.ディストリビューションエージェントの設定を変更する

1.デスクトップヒープのサイズを拡張する

ヒープサイズを拡張する方法となります。

メリットおよびデメリット

 変更方法

1) レジストリエディタを起動し、次のレジストリに移動します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

2) SharedSection の値を変更します。

3) OSを再起動して、変更を有効にします。

例)

設定前

  デスクトップヒープの割り当て方法は、"SharedSection=" の後に続く 3 つの数値によって制御されます。
  これらの SharedSection の値は、KB 単位で指定されます。今回の事象では、以下のように、第 3 パラメーターの値を変更します。

  SharedSection=1024,20480,768  -------> 変更前
  ↓ ↓ ↓
  SharedSection=1024,20480,1024 -------> 変更後

設定後

(*)注: 上記設定によって、回避ができない場合、徐々に(512KBを基準に)増加させて、回避できるかどうか確認します。

2.サブスクリプションの定義を PUSH 型と PULL 型の2種類に分割する

PUSH 型では distrib.exe がディストリビューターで起動します。一方、PULL 型では distrib.exe がサブスクライバーで起動します。
起動するプロセスをディストリビューターとサブスクライバーで分散させることによって、それぞれのサーバーで実行されるプロセスを減らす方法となります。

メリットおよびデメリット

変更方法

PUSH サブスクリプションが多い場合には、既存の PUSH サブスクリプションを削除し、PULL サブスクリプションで再作成します。
PULL サブスクリプションが多い場合には、既存の PULL サブスクリプションを削除し、PUSH サブスクリプションで再作成します。

3.ディストリビューションエージェントの設定を変更する

共有エージェントを使用することにより、ディストリビューション エージェント (distrib.exe) の数を削減する方法となります。
SQL Server は既定で独立エージェントを使用するようになっており、パブリケーション単位、サブスクリプション単位でディストリビューション エージェントが起動されます。 一方で、共有エージェントの場合には、パブリケーション データベースとサブスクリプション データベースが同一である場合にはディストリビューション エージェントを共有して利用できます。

例) パブリケーション データベースに対して 2 つのパブリケーションを作成し、それぞれが 2 つのサブスクリプション データベースへ同期を行う場合

独立エージェント : 4つのディストリビューション エージェントが起動する
共有エージェント : 2つのディストリビューション エージェントが起動する

メリットおよびデメリット

変更方法

共有エージェントを使用するためには、以下の手順で変更します。
1) Management Studio でパブリッシャ兼ディストリビュータの SQL Server に接続します。
2) オブジェクト エクスプローラーで [レプリケーション] フォルダを展開し、設定変更を行うパブリケーションに対するすべてのサブスクリプションをすべて削除します。サブスクリプションの削除は右クリックして [削除] を選択します。
3) パブリケーションのプロパティを開き、[サブスクリプション オプション] のページを開きます。
4) "独立したディストリビューション エージェント" を False に設定します。(*)
5) 設定変更後、あらためてサブスクリプションを作成します。

 (*)注: "匿名サブスクリプションを許可" と "スナップショットが常に利用可能" のオプションが True の場合には "独立したディストリビューション エージェント" の設定を Management Studio で変更できません。その場合には、システム ストアドプロシージャ sp_changepublication により以下の順で設定を変更します。
 
sp_changepublication @publication = 'パブリケーション名',
@property = 'allow_anonymous',
@value = false

sp_changepublication @publication = 'パブリケーション名',
@property = 'immediate_sync',
@value = false

sp_changepublication @publication = 'パブリケーション名',
@property = 'independent_agent',
@value = false

補足

レジストリ エディタの誤った使用は、システム全般に渡る重大な問題を引き起こす可能性がありま���。 こうした問題を解決するためには、Windows をインストールしなおさなければいけません。 Microsoft では、レジストリ エディタを使用することによって引き起こされた障害の解決については、一切保証しておりません。 レジストリ エディタを使用する場合には、お客様の責任において使用してください。

皆さん、こんにちは。 SQL Server/Microsoft Azure SQL Database サポートチーム です。

今回は、Microsoft Azure SQL Database (以下 MASD) を使用するうえで、必ずお目に掛かる Reconfiguration (リコンフィグレーション) について紹介します。

[Reconfiguration (リコンフィグレーション) とは！？]

Reconfiguration は、MASD 環境上の高可用性を維持するために実装された仕組みであり、ロールの変更 (セカンダリからプライマリへの昇格など) が行われる動作のことを意味します。

具体的には、以下のような場合に発生する可能性のある動作になります。

1. SQL Database、OS に対して更新プログラムなどを適用する場合

2. SQL Database を構成しているレプリカ (プライマリ、セカンダリ) 上で何らかの異常を検知した場合 (物理ハードウェアの問題を含む)

Reconfiguration に伴い、既存のセッションが切断され、ロールの変更が完了するまでの 数秒、数十秒間、お客様データベースへの接続に時間を要するなどの現象が発生する可能性があります。

しかしながら、長期間のダウンタイムを発生させないよう、必要な更新プログラムの適用などを適切なタイミングで実施したり、長期間のダウンタイムが発生しうる状況を事前に検知し、事前に問題を解消させるために必要な動作となります。

そのため、Reconfiguration は悪ではなく、長期間のダウンタイムの発生を可能な限り防ぎ、高可用性を維持するという意味では、私達の味方ですね。

なお、ここで重要となる点として、MASD 環境を使用したシステムを構築する場合は、Reconfiguration が行われることを前提としたアプリケーションを実装することが、お客様 アプリケーション側の可用性を維持するために必要となります。

MASD 環境を使用したシステムを構築する上で、推奨しているアプリケーションの実装方式については、以下の ブログ を参照下さい。

[SQL Database] アプリケーション作成における推奨事項について (Microsoft Azure SQL Database)
http://blogs.msdn.com/b/jpsql/archive/2014/10/22/sql-database-windows-azure-sql-database.aspx

[補足 : Reconfiguration (リコンフィグレーション) の発生はどのように確認できるの！？]

MASD で master データベースに接続後、システム テーブル “sys.event_log” を検索し、”event_subtype_desc” : “reconfiguration” というレコードが存在する場合は、接続されていたセッションが、reconfiguration により切断されたと判断可能です。

なお、reconfiguration は障害ではなく、高可用性を維持するために必要な動作になります。 そのため、接続されたセッションの切断や、短期間、アプリケーション から MASD への接続に時間を要する現象が発生した場合は、まずは、システム テーブル “sys.event_log” を参照し、reconfiguration の発生有無を確認ください。

一般的に、数分、数十分間、reconfiguration が多発する現象が見られない場合、また、継続的に MASD に接続ができない現象が発生していない場合は、データセンター側では問題が発生していないと判断可能 です。

sys.event_log (SQL データベース)
http://msdn.microsoft.com/ja-jp/jp-ja/library/dn270018.aspx

※ 本Blogの内容は、2014年10月 現在の内容となっております

佐藤 靖典
SQL Developer Support Engineer

こんにちは。

今回の記事では、SSIS パッケージの接続マネージャーの Connect Timeout プロパティ (接続タイムアウト) の動作について紹介します。この動作は、製品の仕様上の動作ですが、混乱しやすい部分で質問をいただくことも多いため、詳しく説明します。

1. 概要

ほとんどの開発者は、.NET Framewrok データ プロバイダ、OLE DB プロバイダ、ODBC ドライバで設定できる接続タイムアウトを 0 に設定した場合、無制限を意味することをご存知だと思います。
しかしながら、SQL Server Integration Services (SSIS) パッケージの接続マネージャーの Connect Timeout の既定の表示 0 は、無制限を示しているものではなく、未設定を示しています。未設定の場合は、使用する OLE DB プロバイダや ODBC ドライバの接続タイムアウトの既定値が使用されます。
SQL Server ODBC Driver や OLE DB Provider for SQL Server、SQL Server Native Client の接続タイムアウトの既定値は 15 秒です。

2. 詳細

OLE DB 接続マネージャーなどを作成すると、既定で Connect Timeout プロパティは 0 と表示されます。(図 – 1)
この図の例では、SQL Server Native Client 11.0 を使用しているため、本プロバイダの既定値 15 秒が接続タイムアウト値となります。

図 – 1

既定値以外の Connect Timeout を使用する場合は、明示的に値を設定します。(図 – 2)

図 – 2

Connect Timeout 値を無制限の 0 と設定する場合は、既定の表示の 0 を別の値に変更後、0 を設定します。(図 – 3)
既定の状態 (図 – 1) との違いは、既定値から変更した場合の Connect Timeout 値は太字 (Bold) になっていることです。

図 – 3

また、既定値から変更した場合の PackageName.dtsx ファイルをメモ帳などで開くと、Connect Timeout プロパティの設定が追加されていることを確認できます。(図 – 4)

図 – 4

3. 補足

ADO.NET の接続マネージャー (.NET Framework Data Provider for SQL Server) を使用した場合は、.NET Framework Data Provider for SQL Server の Connect Timeout の既定値である 15 秒が初期値として表示されます。(図 – 5)

図 – 5

動作の詳細は Business Intelligence Development Studio (BIDS) / SQL Server Data Tools (SSDT) の内部動作であるために割愛しますが、簡単にお伝えしますと、BIDS や SSDT はプロバイダーの各プロパティを取得する動作となっています。.NET Framework Data Provider for SQL Server を使用した場合は、Connect Timeout を含むすべてのプロパティ値を取得しますが、OLE DB 接続マネージャーを使用した場合は、各 OLE DB プロバイダーの共通のプロパティのみ取得し、OLE DB プロバイダーによってはプロパティが存在しない Connect Timeout は取得せず、OLE DB 接続マネージャーの表示を 0 としています。

皆さん、こんにちは。 SQL Server/Microsoft Azure SQL Database サポートチームです。 今回は、SQL Server 2012/2014 をインストールするために必要な .NET Framework について紹介します。

SQL Server 2012/2014 をインストールするために必要な .NET Framework については、以下の Books Online で公開していますが、本 Blog の中で、.NET Framework の要件について補足したいと思います。

SQL Server 2014 のインストールに必要なハードウェアおよびソフトウェア

SQL Server 2012 のインストールに必要なハードウェアおよびソフトウェア

 [補足事項]

- 該当バージョンの .NET Framework が OSの機能に含まれている場合は、”Windows の機能の有効化または無効化” から 機能を有効化

- SQL Server 2014 Express Edition SP1 以降のバージョンで データベース エンジン のみを選択する場合、.NET Framework 3.5 SP1 もしくは、.NET Framework 4 以上のいずれかをインストール することで、SQL Server 2014 Express Edition SP1 以降のバージョンをインストールすることが可能

- インターネットに接続されていないオフラインの環境に SQL Server 2012/2014 をインストールする場合、オフライン インストーラーより、.NET Framework 及び .NET Framework 言語パック をインストール

Microsoft .NET Framework 4.6 (オフライン インストーラー)

Microsoft .NET Framework 4.6 Language Pack (オフライン インストーラー)

 [参考情報]

Microsoft .NET Framework サポート ライフサイクル ポリシー

SQL Server 2014 Express 日本語版 x86 インストール要件

エラー “Windows 機能 (NetFx3) を有効にしている時にエラーが発生しました。 エラー コード : -2146498298” について

Support Ending for the .NET Framework 4, 4.5 and 4.5.1

※ 本Blog の内容は、2016年 1月 現在の内容となっております

山崎 実久
SQL Server Developer Support Engineer

以前、SQL Server Engine のトラブルシューティングや SQL Server Reporting Services のトラブルシューティングについて案内いたしました。
今回は SQL Server Analysis Services (SSAS) のトラブルシューティングに必要な情報採取項目について本 blog でご案内します。

SSAS に関して問題が発生した場合、以下の情報を採取後、2 以降のログに対し問題が発生した日時に関連するエラーが記録されていないか確認します。

1. Analysis Services のバージョンの確認
===========================
現象が発生した Analysis Services のバージョン（Build 番号）を正確に把握し、バージョンに関する技術情報で確認できる類似の問題の修正が該当環境に既に適用されているか否かを判断できます。

Analysis Services のバージョンは、SQL Server Management Studio から Analysis Services インスタンスへ接続し、オブジェクトエクスプローラーから該当インスタンスのアイコン（キューブの形をしています）の右側を参照することで確認できます。

2. イベントログ（アプリケーション、システム、セキュリティ） の確認
===========================
イベントログ（アプリケーション、システム、セキュリティ） の確認方法は、以前本 blog [SQL Troubleshooting] 第1回 : Tips – SQL Server エラーログとイベント ログを採取する (SQL 2000 ～ 2008 R2) で確認します。

3. Analysis Services のログの確認
===========================
SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014 のバージョンごとに Analysis Services のログである msmdsrv.log  や、フライトレコーダーとよばれる FlightRecorderCurrent.trc および FlightRecorderBack.trc のログの確認手順を記載します。

※ フライトレコーダーは既定では 1 時間毎、またはファイルサイズが 10 MB を超えると破棄されます。この為、問題が発生した際は、破棄される前にログフォルダ配下を待避ください。なお、拡張子 .trc は SQL Server の Profiler を起動し該当のファイルを開いて内容を確認します。

Analysis Services のインストール フォルダ下の Log フォルダ配下に出力されるファイルを確認します。
各バージョンごとの既定のログフォルダ配下は以下になります。

– SQL Server 2005
C:\Program Files\ \Microsoft SQL Server\MSSQL.n\OLAP\Log

※ MSSQL.n の n は整数値で、SQL Server、Analysis Services などのインストールの有無により異なります。対象のインスタンスと MSSQL.n は次のレジストリで確認します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instancenames\OLAP

– SQL Server 2008
C:\Program Files\Microsoft SQL Server\MSAS10.xxx\OLAP\Log

※ MSAS10.xxxx の xxxx はインスタンス名称です。たとえば既定の C ドライブにインストールされた既定のインスタンスの場合、以下のようになります。
C:\Program Files\Microsoft SQL Server\MSAS10.MSSQLSERVER\OLAP\Log

– SQL Server 2008 R2
C:\Program Files\Microsoft SQL Server\MSAS10_50.xxx\OLAP\Log

※ 既定の場合
C:\Program Files\Microsoft SQL Server\MSAS10_50.MSSQLSERVER\OLAP\Log

– SQL Server 2012
C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\Log

※ 既定の場合
C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\Log

– SQL Server 2014
C:\Program Files\Microsoft SQL Server\MSAS12.xxx\OLAP\Log

※ 既定の場合
C:\Program Files\Microsoft SQL Server\MSAS12.MSSQLSERVER\OLAP\Log

4. Analysis Services の構成情報の確認
===========================
Analysis Services の構成情報は SQL Server Management Studio から該当の Analysis Services インスタンスへ接続、インスタンスを右クリック – プロパティ – [分析サーバーのプロパティ] の全般ページから確認できます。
この設定から、現在の値と既定値の比較調査が可能です。

なお、本分析サーバーのプロパティから確認できる構成情報を含む、すべての Analysis Services の構成情報は、msmdsrv.ini に格納されています。SQL Server のバージョン毎の msmdsrv.ini ファイルの場所は以下となります。

– SQL Server 2005
C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Config

＋参考情報
Analysis Services のサーバーのプロパティの構成
https://msdn.microsoft.com/ja-jp/library/ms174556(v=sql.90).aspx

– SQL Server 2008
C:\Program Files\Microsoft SQL Server\MSAS10.MSSQLSERVER\OLAP\Config

＋参考情報
Analysis Services のサーバーのプロパティの構成
https://msdn.microsoft.com/ja-jp/library/ms174556(v=sql.100).aspx

– SQL Server 2008 R2
C:\Program Files\Microsoft SQL Server\MSAS10_50.MSSQLSERVER\OLAP\Config

＋参考情報
Analysis Services のサーバーのプロパティの構成
https://msdn.microsoft.com/ja-jp/library/ms174556(v=sql.105).aspx

– SQL Server 2012
C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\Config

＋参考情報
Analysis Services のサーバーのプロパティの構成
https://msdn.microsoft.com/ja-jp/library/ms174556(v=sql.110).aspx

– SQL Server 2014
C:\Program Files\Microsoft SQL Server\MSAS12.MSSQLSERVER\OLAP\Config

＋参考情報
Analysis Services のサーバーのプロパティの構成
https://msdn.microsoft.com/ja-jp/library/ms174556.aspx

5. パフォーマンスログの確認
===========================
パフォーマンスログの採取方法および解析方法は、以前以下のブログでお伝えいたしました内容を確認し実施ください。
[SQL Troubleshooting] 第2回 : Tips -パフォーマンス ログの採取方法 (Windows Server 2003 ～ Windows Server 2008 R2)
[SQL Troubleshooting] 第3回 : パフォーマンスログの確認方法について

パフォーマンスカウンタの詳細につきましては、下記をご参照ください。

– SQL Server 2005 から SQL Server 2008 R2 まで

SQL Server 2008 R2 Analysis Services Operations Guide
https://msdn.microsoft.com/library/hh226085.aspx
 
– SQL Server 2012

パフォーマンス カウンター (SSAS)
https://msdn.microsoft.com/ja-jp/library/hh230807(v=sql.110).aspx

– SQL Server 2014 

パフォーマンス カウンター (SSAS)
https://msdn.microsoft.com/ja-jp/library/hh230807.aspx

6. サーバートレースの確認
===========================
Analysis Services に対してどのようなクエリが発行されているかについて確認します。
下記ブログに記載の手順で Analysis Servicesの サーバートレースを利用し情報を採取します。

[SSAS] SQL Server Analysis Services トレース採取方法

以上、SQL Server Analysis Services に関するエラーの切り分けに是非ご活用ください。

2016 年 1月18日 時点の SQL Server 最新モジュールです。

SQL Server 2000 は 2013 年 4 月 9 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。
SQL Server 2008 は 2014 年 7 月 8 日にメインストリームサポートが終了しました。

RTM : Release To Manufacturing (製品出荷版)
SP : Service Pack (サービスパック)
CU : Cumulative Update (隔月リリースの累積更新プログラム)
OD : On-Demand (オンデマンドリリースの累積更新プログラム)

SQL Server の更新プログラムの詳細については、SQL Server の更新プログラムを参照して下さい。

メインストリームサポート、延長サポートについては、マイクロソフトサポートライフサイクルを参照して下さい。

山崎 実久
SQL Server Developer/Microsoft Azure SQL Database Support

新しい Microsoft Azure Portal (https://portal.azure.com/) で利用可能な、”削除されたデータベース” に関する機能についての説明です。

”削除されたデータベース” の一覧には、復元可能な削除されたデータベースの一覧が表示されます（図1）。
しかし、データベースを作成してから 10 分以内にデータベースを削除した場合、”削除されたデータベース” の一覧に削除されたデータベースが表示されない場合があります。

理由は、データベースが作成されてからバックアップファイルを生成し、データベースが復元可能になるまで 10 分程度時間を要するためです。

図1、 ”削除されたデータベース” に復元可能な削除されたデータベース testdb01 が表示されていることがわかります。

※ 本ブログの内容は、2016年1月時点の情報です。

Microsoft SQL Server/Microsoft Azure SQL Database サポートチーム
サポート エンジニア 清水 磨
サポート エスカレーション エンジニア 荒井 太郎
プレミア フィールド エンジニア 松本 吉弘

Azure ギャラリーイメージより、SQL Server が含まれた仮想マシンをデプロイすることが可能ですが、現在は英語版のみの提供となっています。
そのため、今回はSQL Server を日本語化する手順をご紹介します。

大まかな流れは以下の通りです。以下ではSQL Server 2014を例にご説明いたしますが、SQL Server 2012でも手順はほぼ変わりません。
*******************************************
A. SQL Server のアンインストール
B. OSのロケール設定を日本語に変更
C. 日本語のSQL Server 2014 Evaluation Editionを用いて、日本語版のSQL Server をインストール
D. SQL Server IaaS Agent 拡張機能の設定
*******************************************

順にご説明致します。

A. SQL Server のアンインストール
===============================
まず以下のURLに従い、既存の英語版SQL Server をアンインストールします。

SQL Server の既存のインスタンスのアンインストール (セットアップ)
https://msdn.microsoft.com/ja-jp/library/ms143412(v=sql.120).aspx

// 一部抜粋
********
1. アンインストール プロセスを開始するには、コントロール パネルで [プログラムと機能] をクリックします。

2. [Microsoft SQL Server 2014] を右クリックし、[アンインストール] を選択します。次に、[削除] をクリックします。これにより、SQL Server インストール ウィザードが起動します。

セットアップ サポート ルールが実行され、コンピューターの構成が確認されます。続行するには、[次へ] をクリックします。

3. [インスタンスの選択] ページのドロップダウンボックスを使用して、削除する SQL Server インスタンスを指定するか、SQL Server の共有機能と管理ツールだけを削除するオプションを指定します。続行するには、[次へ] をクリックします。

4. [機能の選択] ページで、指定した SQL Server インスタンスから削除する機能を指定します。

削除ルールが実行され、操作を正常に完了できることが確認されます。

5. [削除の準備完了] ページで、アンインストールされるコンポーネントおよび機能の一覧を確認します。 [削除] をクリックしてアンインストールを開始します。

6. 最後の SQL Server インスタンスをアンインストールした直後は、SQL Server に関連付けられたその他のプログラムがまだ [プログラムと機能] のプログラムの一覧に表示されています。ただし、[プログラムと機能] を閉じ、次に [プログラムと機能] を開いたときには、プログラムの一覧は更新され、実際にインストールされているプログラムのみが表示されます。
********

B. OSのロケール設定を日本語に変更
===============================
日本語版SQL Server を英語版OSにインストールする場合、事前にOSの言語設定を変更する必要があります。
具体的には以下の設定です。

・オペレーティング システムのユーザー インターフェイス設定
・オペレーティング システムのユーザー ロケール設定
・システム ロケール設定

以下のURLよりダウンロードできるドキュメントにOS日本語化のスクリーンショット付き手順がございます。
必要に応じてご確認下さい。

12: Microsoft Azure SQL Server の活用(IaaS 環境における設定や運用のベストプラクティス)
http://www.microsoft.com/click/services/Redirect2.ashx?CR_EAC=300173769
+ [3.2 OS の日本語化] の章をご確認ください。

以下URLでも紹介されておりますので、こちらも必要に応じてご確認いただけますと幸いです。

SQL Server のローカル言語版
https://msdn.microsoft.com/ja-jp/library/ee210665(v=sql.120).aspx

C. 日本語のSQL Server 2014 Evaluation Editionを用いて、日本語版のSQL Server をインストール
===============================
OSの言語設定を日本語に変更後、日本語のSQL Server 2014 Evaluation Editionをインストールします。
この際、ギャラリーの英語版SQL Server に同梱されているSQL Server のプロダクトキーを、日本語版SQL Server のインストール時に設定していただき、作業は完了となります。

インストール ウィザードからの SQL Server 2014 のインストール (セットアップ)
https://msdn.microsoft.com/ja-jp/library/ms143219(v=sql.120).aspx

1. 下記URLより、IaaSのマシン上に日本語版のSQL Server 2014 をダウンロードします。

評価版のダウンロード: Microsoft SQL Server 2014 SP1
https://technet.microsoft.com/ja-jp/evalcenter/dn205290.aspx

この際、[プロダクト キー] ページで、SQL Server 2014 SP1 ISOを選択してください。
また、ダウンロードするためにはマイクロソフト アカウントが必要になります。

ダウンロード後には、該当ISOファイルをマウントし、DVDドライブに読み込ませます。

2. IaaS上のマシンにて、C:\SQLServer_12.0_Full\x64\DefaultSetup.ini を開きます。

3. PIDに指定されているプロダクトキーを確認します。

// DefaultSetup.ini
********************
;SQL Server 2014 Configuration File
[OPTIONS]
PID="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
PCUSOURCE=".\PCU"
********************
※ XXXXXの部分が実際のプロダクトキーになります。

4. 日本語版のSQL Server 2014のインストールを開始します。（既定では、Eドライブにマウントされていますので、ここからセットアップを開始します。）
この際、[プロダクト キー] ページで、該当プロダクトキーを入力することで、EditionをEvaluationから変更できます。

// 補足情報
SQL Server 2012 の場合には、該当の設定ファイルパスが C:\SQLServer_11.0_Full\x64\DefaultSetup.ini になります。
また、SQL Server 2012 の場合、下記の SP1 のダウンロードサイトよりメディアを入手することが可能です。

Microsoft® SQL Server® 2012 Service Pack 1 (SP1)
https://www.microsoft.com/ja-jp/download/details.aspx?id=35575
+ SQLServer2012SP1-FullSlipstream-JPN-x64.iso

D. SQL Server IaaS Agent 拡張機能の設定
===============================
SQL Server IaaS Agent 拡張機能を使用している場合には、対象のサービスで使用するログインを SQL Server に作成する必要があります。
管理者権限のアカウントで、SQL Server へ接続し、下記のクエリを実行することで、サービス SID に紐づいたログイン情報を作成することが可能です。

*****
USE [master]
GO
CREATE LOGIN [NT Service\SQLIaaSExtension] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT Service\SQLIaaSExtension]
GO
*****

SQL Server IaaS Agent 拡張機能については、下記の公開情報にご参考にしていただければ幸いです。

SQL Server IaaS Agent 拡張機能
https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-sql-server-agent-extension/

2016 年 2月 23日 時点の SQL Server 最新モジュールです。

SQL Server 2000 は 2013 年 4 月 9 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。
SQL Server 2008 は 2014 年 7 月 8 日にメインストリームサポートが終了しました。

RTM : Release To Manufacturing (製品出荷版)
SP : Service Pack (サービスパック)
CU : Cumulative Update (隔月リリースの累積更新プログラム)
OD : On-Demand (オンデマンドリリースの累積更新プログラム)

SQL Server の更新プログラムの詳細については、SQL Server の更新プログラムを参照して下さい。

メインストリームサポート、延長サポートについては、マイクロソフトサポートライフサイクルを参照して下さい。

神谷 雅紀
Escalation Engineer

今回は、混同しやすい用語である「復旧」「復元」「修復」について解説します。

復旧

復旧 (英語では recover, recovery) は、データベース開始時に実行されるトランザクションのロールフォワード、ロールバックなどの処理を表します。

SQL Server は、多くのデータベースシステムと同様に、ログ先行書き込み (Write-Ahead-Logging, WAL) を行います。データベースファイルへの書き込みは、必ずトランザクションログファイルへの書き込みが先行されます。トランザクション完了時、トランザクションログへの書き込みは必ず同期されます。言い換えれば、クライアントが COMMIT を発行しても、トランザクションログへの書き込みが終わらないと、クライアントへは制御が返されません。一方、データファイルへの書き込みは非同期です。そのため、データベースクローズ時にデータファイルの内容が最新の状態であるとは限りません。データベース開始時には、トランザクションログを使用して、データファイルをトランザクションとして整合性のとれた最新の状態にするために、未完了トランザクションをロールバックしたり、データファイルへ未反映のトランザクションをロールフォワードしたりします。つまり復旧が必要になります。

データベースの開始は、SQL Server の起動時やデータベースのアタッチ時に実行されたり、WITH RECOVERY の指定された RESTORE DATABASE または RESTORE LOG ステートメントの実行時に実行されます。データベースが開始されると、Errorlog ファイルには “Starting up <database name>” と記録されます。

復元

復元 (restore, restoration) は、RESTORE ステートメントによってバックアップデータからデータベースを作成したり、復元中 (restoring) の状態にあるデータベースにトランザクションログを適用することを指します。

修復

修復 (repair) は、SQL Server のデータベースとして論理的に正常ではない状態になってしまったデータベースを、データベースとして使用可能な状態に戻すことを指します。

通常は、復旧に失敗し、データベースが未確認 (suspect) の状態となってしまったものの、そのデータベースのバックアップがなく、バックアップからデータベースを復元できない状況の場合に、最後の手段として、DBCC CHECKDB に修復オプションを指定することで修復します。

データベースの状態遷移

Microsoft SQL Server/Microsoft Azure SQL Database サポートチーム
サポート エンジニア 清水 磨

[概要]
SQL Database では Query Performance Insight と呼ばれる機能が新しく追加されました。Query Performance Insight では、自動的にデータベース リソース（DTU）の詳細な消費量やCPU負荷の高いクエリ、クエリの詳細を保存、確認することができるようになり、よりデータベース パフォーマンスのトラブルシューティングが実施しやすくなりました。これらは内部的にSQL Server 2016 から新しく実装されているクエリ ストアという機能を用いており、その結果をAzure ポータル上からグラフィカルに確認できる機能になります。
今回はこのQuery Performance Insight の設定方法についてご案内します。

[前提事項]
・V12サーバーでのみ、使用可能です。
・Query Performance Insight（クエリ ストア） の有効化を行っていない場合には、データベース単位で手動で設定する必要があります。

・リソース消費上位クエリおよびチャートを表示するには、リーダー、所有者、共同作成者、SQL DB の共同作業者、または SQL Server の共同作業者の権限が必要です。
・クエリ テキストを表示するには、所有者、共同作成者、SQL DB の共同作業者、または SQL Server の共同作業者の権限が必要です。

※権限の確認、設定は、Azure のロールベースのアクセス制御 の 「Azure ポータルを使用したアクセス権の管理」の手順で行います。

[設定方法]
Azure ポータル、および、クエリによる設定方法をご説明します。

// Azure ポータルからの設定方法
———————————————-
1. Azure ポータルより該当データベースを開きます。
以下では AdventureWorkLT というサンプルデータベースを基に説明します。

Azure Portal
https://portal.azure.com/

2. 画面中部にあるQuery Performance Insight のアイコン、もしくは [すべての設定] から [機能] – [Query Performance Insight] の項目を選択します。

3. 既定ではクエリストアが設定されていないため、まず以下の警告を選択します。

上記警告を選択すると以下の有効化ボタンが表示されますので、選択します。

上記の後、設定が有効になりますが、パフォーマンス情報を取得するまでは、利用することができません。そのため、しばらく待機し、普段から行っている処理を実施します。

// その他の設定方法
———————————————-
上記 Azure ポータルからの設定以外では、クエリによる設定方法とSQL Server Management Studio を用いた方法があります。

A. クエリによる設定方法
******************************
該当データベースに対して以下のようにクエリを実行します。
————————
ALTER DATABASE AdventureWorksLT SET QUERY_STORE = ON;
————————

B. SQL Server Management Studio
*****************************************
最新の SQL Server 2016 Management Studio CTP でも設定を行うことができます。
該当データベースのプロパティを開き、[Query Store] – [Operation Mode] を Read Writeに変更します。

 
[確認方法]
クエリに関するパフォーマンスデータがクエリストアに格納されると、ポータル上から以下のようなグラフが確認できるようになります。
以下のグラフではDTU使用率が100％近くになっている時間帯が確認できます。また、該当時刻にクエリ ID:87が実行されていることが分かります。  

クエリのごとのパフォーマンス統計も取得されており、以下ではクエリ ID:87 が非常に多く実行されていることが確認できます。  

クエリ ID:87 は以下のSELECT 文であることが、ここから特定できます。   

SQL Server 2016 Management Studio CTP を利用することでさらに詳細なデータを見ることも可能です。
例えば、クエリごとの詳細な処理時間や実行プランといった情報です。もし実行プランが変化した場合には古い実行プランの情報は蓄積され、必要に応じて確認、そのプランを強制的に使用させることも可能になります。（いわゆるプランガイドと同等の機能です。）

該当サーバーへ接続します。

オブジェクトエクスプローラーより、[Databases] – [該当データベース] – [Query Store]まで展開します。
配下には4種類のビューが用意されており、リソース消費量が多いクエリ（Top Resource Consuming Queries）などを簡単に表示することが可能です。

Top Resource Consuming Queriesのビューの画面です。

実行プランも簡単に確認できます。

[参考情報]
Azure SQL Database Query Performance Insight
https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-query-performance/

Monitoring Performance By Using the Query Store
https://msdn.microsoft.com/library/dn817826.aspx

SQL Server Management Studio
https://msdn.microsoft.com/en-us/library/mt238290.aspx

上記からは英語版のSQL Server Management Studioのみ、ダウンロード可能です。
もし、日本語版をご利用されたい方は、以下のURLより、SQL Server 2016 日本語版をダウンロードしていただき、インストールしてください。

SQL Server 2016 Community Technology Preview 3.3
https://www.microsoft.com/ja-jp/evalcenter/evaluate-sql-server-2016

Microsoft SQL Server/Microsoft Azure SQL Database サポートチーム
サポート エンジニア 清水 磨

[概要]
Index Advisor はSQL Databaseに新しく追加された機能の１つで、SQL データベースの使用パターンを分析し、現在のクエリパフォーマンスを向上できる推奨インデックスを提供します。これにより、ユーザーはデーターベースに関する深い知識がなくとも、インデックスを用いたチューニングが可能になります。また、推奨インデックスを自動的に実装することも設定可能であり、V12サーバーをご利用のお客様は、Azureポータル上からインデックスの追加を数クリックで実現可能になりました。
今回はこの Index Advisor の使用方法についてご案内します。

[前提状況]
・V11サーバー、V12サーバーそれぞれで使用可能です。ただし、Azure ポータルサイトからのインデックス操作はV12でのみ、サポートされています。
・推奨インデックスの自動作成、削除を有効化するためには、クエリストアを有効化しておく必要があります。

・推奨インデックスを表示するには、リーダー権限と SQL DB の共同作成者権限が必要です。
・インデックスの作成またはドロップおよびインデックス作成のキャンセルなどのアクションを実行するには、所有者権限と SQL DB の共同作成者権限が必要です。
※権限の確認、設定は、Azure のロールベースのアクセス制御 の 「Azure ポータルを使用したアクセス権の管理」の手順で行います。

[設定方法] 
1. Azure ポータルにサインインします。
2. [参照] – [SQL データベース] の順にクリックし、ご使用のデータベースを選択します。
3. 画面中段にある[インデックス アドバイザー]のアイコンを選択する、もしくは[すべての設定] – [Index Advisor] の順にクリックし、[インデックス アドバイザー]の項目を選択します。

なお、データベース作成直後などは推奨されるインデックスは表示されません。これは、[概要]に記載した通り、該当データベースにおけるクエリパターンがある程度、蓄積される必要があるためです。
目安として約1週間程度、またこの期間内に一貫性のある処理を実行することで推奨インデックスが表示されやすくなります。

// インデックスが表示されない場合

// インデックスが表示された場合
パフォーマンスに与える影響ごとに4つのカテゴリに分かれて表示されます。

4. 推奨されたインデックスを選択し、[適用]を選択することで適用することができます。[インデックス操作] からはインデックスの作成状況も確認できます。
また、推奨インデックスを無視することや、スクリプト化することが可能です。

5. Index Advisor を使用してインデックスを作成した場合、パフォーマンスへの悪影響が見つかるとインデックスは自動的に元に戻されます。
[インデックス操作] から該当のインデックスを選択し、手動で行うことも可能です。
 

6. またIndex Advisor が自動的にインデックス作成、削除を行うように設定することも可能です。（クエリストアの有効化が必要）

[注意事項]
以下の場合には推奨インデックスが表示されません。
・十分な利用履歴がない場合。例えば、データベースが最近作成されたり、しばらくデータベースが使われていない場合です。
・該当データベースにて、スキーマや実行されるクエリ内容に大幅な変更があった場合。
・該当データベースにて必要なインデックスがすでに作成済みの場合。

[補足情報]
- アーキテクチャについて
Index Advisor は該当データベースの使用パターンを学習し、機械学習のモデルによって、推奨されるインデックスを提案します。Index Advisorは数日前の使用パターンを基に推奨インデックスを提案するため、データベースの作成後、ある程度、処理を実行し、使用パターンを蓄積させる必要があります。
また、Index Advisor は世界中のデータベースにおける使用パターンを基に、様々なパターンをAzure Machine Learningにより機械学習させ、日々、そのモデルの精度を向上させています。ユーザーによって向上されるサービスであるため、SQL Databaseのユーザーには無償でIndex Advisorが提供されています。なお、Index Advisorのための計算処理は、SQL Database外にて行われています。
上記のため、処理内容やスキーマが変更された場合でも、Index Advisorは継続的にデータベースを監視しつづけているため、新たな情報が収集された後、必要に応じて推奨インデックスを提案します。

- インデックス作成時の動作
インデックスの作成を行った場合、以下の流れでインデックスの作成が行われます。
推奨インデックスがすぐに作成されない場合もありますが、以下のいずれかで時間がかかっていることが考えられるため、必要に応じて[インデックスの操作]を確認します。

1. 該当インデックスにおけるパフォーマンスのベースラインを収集します。（”保留中” の状態になります）
2. インデックスを作成します。（”実行しています” の状態になります）
3. 再度、該当インデックスにおけるパフォーマンスのベースラインを収集します。（”確認中” の状態になります）
4. もし、該当インデックスが悪影響を及ぼした場合、自動的に元に戻します。（”復元中” の状態になります）
5. インデックス操作が完了し、”成功”, ”復元”, もしくはエラーのステータスを返します。

[参考情報]
SQL Database Index Advisor
https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-index-advisor/

2016 年 3月 22日 時点の SQL Server 最新モジュールです。

SQL Server 2000 は 2013 年 4 月 9 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。
SQL Server 2008 は 2014 年 7 月 8 日にメインストリームサポートが終了しました。

RTM : Release To Manufacturing (製品出荷版)
SP : Service Pack (サービスパック)
CU : Cumulative Update (隔月リリースの累積更新プログラム)
OD : On-Demand (オンデマンドリリースの累積更新プログラム)

SQL Server の更新プログラムの詳細については、SQL Server の更新プログラムを参照して下さい。

メインストリームサポート、延長サポートについては、マイクロソフトサポートライフサイクルを参照して下さい。

SQL Server の最新モジュール情報ページです。各リンクにそれぞれ詳細情報がございます。

なお、SQL Server Compact Editionについては、こちら をご確認下さい。

2016 年 4月 19日 時点の SQL Server 最新モジュールです。

SQL Server 2005 は 2016 年 4 月 12 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。
SQL Server 2008 は 2014 年 7 月 8 日にメインストリームサポートが終了しました。

RTM : Release To Manufacturing (製品出荷版)
SP : Service Pack (サービスパック)
CU : Cumulative Update (隔月リリースの累積更新プログラム)
OD : On-Demand (オンデマンドリリースの累積更新プログラム)

SQL Server の更新プログラムの詳細については、SQL Server の更新プログラムを参照して下さい。

メインストリームサポート、延長サポートについては、マイクロソフトサポートライフサイクルを参照して下さい。

Microsoft Japan Data Platform Tech Sales Team

今回はマイクロソフトのデータプラットフォーム製品群のプリセールスを担当しているチームからのお知らせです。

先月より、プリセールスチームでも MSDN での Blogサイトの公開を始めました。

Microsoft Japan Data Platform Tech Sales Team Blog

https://blogs.msdn.microsoft.com/dataplatjp/

こちらの Blog では SQL Server の歴史や新製品・新機能のご紹介、またAzure を利用する際のベストプラクティスや Power BI の Tips 等、様々な記事を公開していく予定となっております。

サポートチームの Blog の成功体験を参考に、より幅広いユーザの皆様に SQL Server の価値・魅力を伝えていくことを目的としております。

是非こちらの Blog も定期的にチェック頂ければ幸いです。

また、 Power BI については、日本語のデモ動画を日本マイクロソフト公式 YouTube チャンネルで公開をしております。

https://www.youtube.com/playlist?list=PL1RqQ3kddIpbfgIcBT7RB6xaGdUKpwKiq

Power BI の操作感や、新機能についてわかりやすくキャッチアップできる内容になっておりますので、こちらも是非ご活用ください。

Microsoft SQL Server/Microsoft Azure SQL Database サポートチーム

サポート エスカレーション エンジニア　高原　伸城

皆さん、こんにちは。 Microsoft SQL Server/Microsoft Azure SQL Database サポートチーム です。

今回は、Microsoft Azure SQL Database (以下 MASD) のパフォーマンス チューニング手法について紹介します。

MASD 上のデータベースに対して、アプリケーション から クエリを実行し、コマンドタイムアウトが発生したという現象についてお問い合わせを頂くことがあります。

コマンドタイムアウトが発生した場合は、一般的に、以下の項目について確認する必要があります。

そして、コマンドタイムアウトが発生している状況に応じた対処方法を検討する必要があります。

しかしながら、コマンドタイムアウトが発生したクエリを特定し、クエリのチューニングを実施することは、一般的に時間を要する作業となります。

そのため、今回のブログでは、コマンドタイムアウトが多発し、即座に問題を緩和させる必要がある場合 に、まずは試して欲しい対処方法を紹介します。

※ 一般的に、データセンター側の問題でクエリの処理時間が著しく低下する現象は発生しないため、今回は確認項目から省いています。

[対処方法]

1) アプリケーション側で指定しているコマンドタイムアウト値を延ばす。

＋ 参考情報

SqlCommand クラス

SqlCommand.CommandTimeout プロパティ

EntityCommand クラス

EntityCommand.CommandTimeout プロパティ

2) インデックスの統計情報を更新する。

コマンドタイムアウトが発生しているクエリが参照しているテーブル上に存在するインデックスの統計情報を最新の状態に更新することで、最適なクエリの実行プランが選択されるようになり、クエリのパフォーマンスが向上できることが期待できます。

そして、”UPDATE STATISTICS” コマンドを実行することで、インデックスの統計情報 (テーブル上に存在する全てのインデックス、特定のインデックス) を更新することが可能です。

”UPDATE STATISTICS” コマンドでオプションをつけない場合は、一部のデータをサンプリングしてインデックスの統計情報が更新されます。 また オプション (WITH FULLSCAN) を付けることで、テーブル上に存在する全てのデータをもとに統計情報を更新することも可能です。

もちろん全てのデータをもとに更新する方がより正確なインデックスの統計データを作成することが可能ですが、データページの読み取りなどのディスク I/O、CPU リソースが多く消費されることが予測されます。

そのため、データ量の多いテーブルに対して ”UPDATE STATISTICS” コマンドを実行する場合は、まずは オプション無し (サンプリング) よる統計情報の更新を実行後、効果が見られない場合に オプション (WITH FULLSCAN) で再度実行してみましょう。

＋ 参考情報

UPDATE STATISTICS (Transact-SQL)

3) 強制的に実行プランをリコンパイルする。

パラメータ化クエリ、 ストアドプロシージャ 及び トリガー の場合、統計情報を更新したのみでは、クエリの実行プランが リコンパイル されない場合があります。

そのため、統計情報を更新した後もクエリのパフォーマンスが改善しなかった場合には、明示的に該当の パラメータ化クエリ、 ストアドプロシージャ 及び トリガー に対して “sp_recompile” を実行し、強制的にクエリの実行プランをリコンパイルさせることが有効となる場合があります。

また、どのクエリでパフォーマンスが低下しているかが明確ではないが、クエリで参照されているテーブルをある程度 特定できる場合は、特定のテーブルに対して実行されるクエリをすべて強制的にリコンパイルさせることも可能です。

＋ 参考情報

sp_recompile (Transact-SQL)

[補足]

アプリケーションで発生しているタイムアウトがコマンドタイムアウトであるかを確認する方法の一つとして、タイムアウト発生時にクライアント側に返された スタック (Stack) 情報を確認する方法があります。

System.Data.SqlClient.SqlCommand の処理の中でタイムアウトが発生した場合は、コマンドタイムアウトが発生していると判断可能となります。

### コマンドタイムアウト発生時の Stack 例 ###

Microsoft Azure SQL Database パフォーマンス チューニング (第 2 回) では、リソースの使用状況の確認方法、及び パフォーマンス レベル (DTU) の変更方法などを紹介する予定です。

※ 本Blogの内容は、2016年5月 現在の内容となっております。

システムで何らかのエラーが発生したという場合や、やりたいことができないといった場合に、トラブルシューティングを行うことになりますが、その際の一般的なトラブルシューティングの流れについてご紹介します。私たちサポートチームもだいたいこのようなフローの考え方をもとに調査を行っています。また、テクニカルサポートでは、インシデント単位で承っているプロフェッショナルサービスと、時間単位で承っているプレミアサービスがあります。トラブルシューティング内容に応じた、それらのサポートサービスの違いについても、参考としてご案内します。

大きく、運用でのエラー発生、開発時の How-to では考え方も異なりますので、それぞれ分けて見ていきます。

エラー発生

A) いま事象が発生しているか

これは一番重要なポイントになります。いま事象が発生している場合には、すぐに対処が必要なため緊急度は高くなり、できることも多くなります。復旧優先で対処となりそうな対応をすぐに行ったり、原因調査のためにいったん情報も採取してから対処を行うといった対応があります。

一方、いま発生していないけれども、過去発生していたエラーをさかのぼって調査することもあります。この場合には、どれだけ手掛かりとなる情報が残っているかが重要です。

B)エラーメッセージやログから調査

いま事象が発生している場合には、エラーメッセージやログを確認します。

SQL Server を例にとると、既定で出力されている情報として参考になるのは、下記があります。

既定の情報

• SQL Server エラーログ (ERRORLOGファイルや、同じフォルダにあるデフォルトトレースやダンプファイル等)
• Reporting Services ログ (ログファイルや同じフォルダにあるダンプファイル、ExcecutionLog ビュー)
• Analysis Services ログ (msmdsrv.logやフライトレコーダー)
• イベントログ

その他、事象に応じて、次のような情報を採取することもあります。

追加情報

• ブロッキング情報
• 動的管理ビュー
• サーバートレース
• 拡張イベント
• パフォーマンス カウンター
• 問題ステップ記録ツール
• BID トレース
• ネットワークトレース
• ダンプファイル

C) 発生状況の切り分け

事象によっては、情報採取よりも、事象が発生するパターン、発生しないパターンを切り分けることによって、問題点が特定できる場合があります。また、発生しないパターンが確認できると、それが対処方法に直結する場合もあります。例えば、次のような切り分けがあります。

• 特定の環境で発生する、もしくは複数の環境で発生する
• 特定のクライアントで発生する、複数のクライアントで発生する
• 特定のユーザーで発生する、複数のユーザーで発生する
• 設定を変更することで発生しない
• 操作する順番によって発生しない

また、何らかの違いが確認できた場合には、発生する場合と発生しない場合の、B) の情報や設定を比較することで、問題点を特定しやすくなります。

D) 残っている情報から調査

すでに発生していない事象であれば、残っているログから手掛かりとなる情報を探します。

まずは、既定で残っている B) の「既定の情報」があります。B) の「追加の情報」もうまく採取できていましたら、それらの情報も参照します。

E) 次回発生時の情報採取

何も手掛かりとなる情報が残っていなかったり、残っている情報からは判断がつかない場合も多くありますので、その場合には、再発時にしっかりと調査できるように採取する情報を検討します。

F) 再現手順の確立

再発させたくない、あらかじめ仕掛けておくような情報採取が困難といった場合には、再現手順の確立、発生パターンの切り分けが必要となります。例えば、下記のような発生パターンを見極めて、検証環境でも同様の事象を発生させて、E) で検討したような情報を狙って採取します。

• 特定の操作をすると100%発生
• 一度発生すると発生し続ける
• リトライ等によりすぐに発生しなくなる

How-to

A) 参考となる情報があるか

マイクロソフトのサイト(msdnやTechNet、KB等) や書籍で、サンプルや実現方法が説明されている場合には、それを参考に実装します。また、マイクロソフト以外のサイトやフォーラム等有効な情報は数多くありますので、参考となる情報を探します。

B) 情報をもとに実装

参考となるわかりやすい情報があれば、実装できると思います。

C) 動作確認のサンプルはあるか

参考となる情報がなければ、少し厄介です。その場合には、何かエラーが発生するようなわかりやすい場合には、そのエラーを手掛かりに上記の「エラー発生」のようなトラブルシューティングを行うことになります。

D) サンプルをもとに動作検証

サンプルがあれば、それをもとに動作検証し、プロパティを変更したり、コードを変更したりして、実現できる方法を探します。

E) シンプル化したサンプル作成

サンプルがまだない場合には、遠回りになるかもしれませんが、まずはやりたいことを最小限に実行できるようなサンプルを作成します。それにより、やりたいことはできるのか、他の手法を検討する必要があるのか確認します。

F) 期待する動作にならない環境で情報を取得して調査

サンプルの作成も困難な場合には、期待する動作にならない環境で、「エラー発生」の 「B)エラーメッセージやログから調査」のようにトラブルシューティングを行います。

「調査」とは？

上のトラブルシューティングでは、情報を採取して「調査」すると説明していますが、具体的には私たちサポートエンジニアは次のようなことを行っています。

• msdn や TechNet、KB 等の公開情報を確認する
• 事例データベースや不具合データベースを検索し、合致している事例や不具合、すでに実績のある手法を確認する
• ホワイトペーパーや社内インターナルの技術情報を確認する
• 検証環境を構築して、テストにより実際の動作を確かめる
• シンプル化したプログラムを作成して、テストにより実際の動作を確かめる
• 検証環境で再現させた上で、設定を変更したり、違う操作をしてみる
• 検証環境で再現させた上で、詳細なログを採取して問題点を特定する
• 問題の環境で採取したダンプファイルをソースコードと紐づけてデバッグする
• 検証環境で再現させた上で、ステップ実行させてデバッグする

最後に

トラブルシューティング時のフローが、今後トラブルシューティングを実施される際の参考になりましたら幸いです。

また、エラー発生、How-to という非常にざっくりした分類とともに、サポートサービスについてもご案内しました。もちろん実際の問題は、これらの分類に該当しなかったり、サポートサービスのサービスレベルで分けられるものではなかったりしますので、お問合せいただいた際に伺った問題に応じて柔軟に対応していきます。お気軽にお問合せください。

皆さん、こんにちは。 Microsoft SQL Server/Microsoft Azure SQL Database サポートチームです。

今回は、TempDB を圧縮する場合の注意点について紹介したいと思います。

一時テーブルに大量のデータを挿入したり、大量データをソートする必要があるような ロング トランザクション を実行した場合、TempDB のファイルサイズが大きく拡張される可能性があります。

そして、拡張された TempDB のファイルサイズを最も安全に初期サイズまで縮小させるためには、SQL Server サービスの再起動を実施することになります。

しかしながら、24時間365日 稼働し続けるシステムの場合、SQL Server サービスを即座に再起動させることは困難であるものと想定しています。

そのため、TempDB についても、ユーザーデータベースと同様に、DBCC SHRINKDATABASE, DBCC SHRINKFILE コマンド、または、SQL Server Management Studio (以降 SSMS) の圧縮タスクで、データベースを圧縮することが可能になっています。

＋参考情報

SQL Server で tempdb データベースを圧縮する方法

しかしながら、TempDB に対して DBCC SHRINKDATABASE, DBCC SHRINKFILE コマンド、または、SSMS の圧縮タスクを実行する場合、以下の点に注意が必要です。

それでは、実際に、Tempdb の初期サイズがどのように更新されるかを見ていきましょう。

※ 検証では、SQL Server 2014 を使用しています。

まず Tempdb の初期サイズについて説明します。

SQL Server サービス起動時に Tempdb が再作成されますが、Tempdb 作成時のファイルサイズは、sys.master_files の size 列の値が、初期ファイルサイズとして使用されます。

[クエリ]

[結果]

今回の例の場合は、Tempdb のデータベース物理ファイル (tempdev) サイズ、トランザクションログファイル (templog) サイズの何れも 10 MB となっています。

ここで、Tempdb のファイルサイズを拡張させるため、以下のクエリを実行します。

[クエリ]

[結果]

クエリの実行結果を確認すると、sys.master_files の size 列の値と sys.database_files の size 列の値が異なっていることが分かると思います。

sys.master_files の size 列の値は、Tempdb の初期サイズであり、sys.database_files の size 列の値は、現在の実際のファイルサイズ (SQL Server Management Studio の データベースのプロパティに表示されている [初期サイズ (MB)]) となります。

Tempdb 上に一時テーブルのデータが残っている状態 (圧縮をすることが出来ない状態) で、DBCC SHRINKDATABASE コマンドを実行してみます。

[クエリ]

[結果]

クエリの実行結果を確認すると、sys.master_files の size 列の値と sys.database_files の size 列の値が同じ値になっていることが分かると思います。

つまり、Tempdb に対して 圧縮コマンドを実行した場合、圧縮コマンドで期待したファイルサイズまで圧縮されていなかったとしても、圧縮コマンド実行後のファイルサイズが、Tempdb の初期サイズとして更新されることになります。

今回の例では、Tempdbの物理ファイルサイズが 83 MB と大きくないサイズですが、仮に Tempdbの物理ファイルが 100 GB であった場合、でかつ、圧縮コマンドで 90 GB までしか圧縮できなかった場合は、Tempdb の初期サイズが 90 GB に更新されます。

そして、Tempdb の初期サイズが大きいなサイズの場合、次回 SQL Server 再起動時、Tempdb の再作成に時間を要し、SQL Server プロセスの起動までに時間を要するなどの悪影響を及ぼす可能性があります。

Tempdb データベース物理ファイル (tempdev)、トランザクションログファイル (templog) のサイズを明示的に指定して運用されている環境の場合、意図せず Tempdb の初期サイズが変わり、運用に支障を及ぼす可能性もあるかもしれません。

そのため、Tempdb を SQL Server サービスの再起動ではなく、圧縮コマンド、または、SSMS の圧縮タスクで圧縮される場合は、Tempdb の初期サイズが更新される点を注意してもらえればと思います。

[補足]

SQL Server Management Studio の データベースのプロパティに表示されている [初期サイズ (MB)] の値を明示的に変更しても、Tempdb の初期サイズは更新されます。

＋参考情報

sys.master_files (Transact-SQL)

sys.database_files (Transact-SQL)

DBCC SHRINKDATABASE (Transact-SQL)

DBCC SHRINKFILE (Transact-SQL)

データベースの圧縮

※ 本Blogの内容は、2016年5月 現在の内容となっております。