神谷 雅紀
SQL Server Escalation Engineer

SQL Server 7.0 と 2000 では、統計情報の自動更新が行われるタイミングは、前回の統計更新以降に変更された行数に基づいて決定され、更新された行数は、 sysindexes システムテーブルの rowmodctr により知ることができました。SQL Server 2005 以降では、統計情報の自動更新は、Microsoft SQL Server 2005 のクエリ オプティマイザが使用する統計情報やSQL Server 2005 のバッチのコンパイル、再コンパイル、およびプランのキャッシュに関する問題で述べられているように、行の変更数ではなく列の変更数に基づいて行われるようになりました。しかし、SQL Server 2005 以降には、sysindexes.rowmodctr に相当するような、変更数を確認することのできる正式な機能はありませんでした。

SQL Server 2012 Service Pack 1 および SQL Server 2008 R2 Service Pack 2 で、その変更数を確認することのできる機能を持った DMF が追加されました。 sys.dm_db_stats_properties の modification_counter 列がそれです。

sys.dm_db_stats_properties (Transact-SQL)

http://msdn.microsoft.com/ja-jp/library/jj553546.aspx

関連情報

※ トレースフラグ 2371 自体は KB や Blog として公開されている情報ですが、一般的にはあまり知られていないようなので、関連情報としてここに記載します。

SQL Server 2012 と SQL Server 2008 R2 SP1 以降では、統計情報の自動更新を行うかどうかのしきい値の計算方法として、Microsoft SQL Server 2005 のクエリ オプティマイザが使用する統計情報で述べられている方法とは異なる新たな方法が導入されています。この新しい方法は、トレースフラグ 2371 が設定���れている場合にのみ有効となります。

この新しいしきい値の計算方法は、大量の行を含む大きなテーブルのある環境で使用されることを想定しています。トレースフラグ 2371 により有効となる新しいしきい値計算が使用されない場合は、テーブル全体の約 20% が更新された場合に、統計更新の自動更新が行われます。一方、トレースフラグ 2371 により新しいしきい値計算が有効になると、テーブル内の行数が多くなるほどパーセンテージが低くなり、例えば、100,000 行が格納されているテーブルではしきい値は約 10%、1,000,000 行では約 3.2% となります。

大量の行を含む大きなテーブルで、普段はテーブル全体の 20% 未満の更新しか行われないために統計情報の自動更新が実行されないようなテーブルであっても、トレースフラグ 2371 を設定することで、自動更新が行われる頻度は高くなり、統計情報をより新しい状態に維持できるようになります。

Changes to automatic update statistics in SQL Server – traceflag 2371

http://blogs.msdn.com/b/saponsqlserver/archive/2011/09/07/changes-to-automatic-update-statistics-in-sql-server-traceflag-2371.aspx

Controlling Autostat (AUTO_UPDATE_STATISTICS) behavior in SQL Server

http://support.microsoft.com/kb/2754171/EN-US

皆さん、こんにちは。 今回は、非ドメイン環境上のマシン間で プリンシパル、ミラーの２台構成のミラーリングを構築する方法 (SQL Server 2008 R2) について紹介したいと思います。

まず、重要なポイントとして、一般的に 非ドメイン環境上のサーバー間でミラーリングを構築する場合には、エンドポイント間の通信を行うために、証明書を使用する必要があります。

今回は、証明書を使用した プリンシパル、ミラーの２台構成のミラーリング構築手順 について、見ていきましょう。

プリンシパル サーバー側 作業 (発信接続設定)

A1) データベース マスター キーを作成します。

---
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Passw@rd1';
GO
---

※ "PASSWORD" には任意のパスワードを指定します。

A2) 証明書(プリンシパル) を作成します。

---
CREATE CERTIFICATE ss2008r2p_cert
WITH SUBJECT = 'ss2008r2p certificate for database mirroring',START_DATE = '06/01/2013',EXPIRY_DATE = '06/01/2023';
GO
---

※ 証明書名 (例: "ss2008r2p_cert") は、任意の名前を指定します。

A3) エンドポイントを作成します。

---
CREATE ENDPOINT Endpoint_Mirroring STATE = STARTED AS TCP (LISTENER_PORT=5022, LISTENER_IP=(192.168.1.1)) FOR DATABASE_MIRRORING (AUTHENTICATION = CERTIFICATE ss2008r2p_cert,ENCRYPTION = REQUIRED ALGORITHM RC4,ROLE = ALL);
GO
---

※ "LISTENER_IP" には、プリンシパルマシンの IP アドレスを指定します。
※ "LISTENER_PORT" には、任意のポート指定します。

A4) A2) で作成した証明書を任意の場所にバックアップします。

---
BACKUP CERTIFICATE ss2008r2p_cert TO FILE = 'C:\TEMP\ss2008r2p_cert.cer';
GO
---

A5) A4) で作成した証明書のバックアップを、ミラー側の任意の場所にコピーします。

ミラー サーバー側 作業 (発信接続設定)

B1) データベース マスター キーを作成します。

---
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Passw@rd1';
GO
---

※ "PASSWORD" には任意のパスワードを指定します。

B2) 証明書(ミラー)を作成します。

---
CREATE CERTIFICATE ss2008r2m_cert
WITH SUBJECT = 'ss2008r2m certificate for database mirroring',START_DATE = '06/01/2013',EXPIRY_DATE = '06/01/2023';
GO
---

B3) エンドポイントを作成します。

---
CREATE ENDPOINT Endpoint_Mirroring STATE = STARTED AS TCP (LISTENER_PORT=5022, LISTENER_IP=(192.168.1.2)) FOR DATABASE_MIRRORING (AUTHENTICATION = CERTIFICATE ss2008r2m_cert,ENCRYPTION = REQUIRED ALGORITHM RC4,ROLE = ALL);
GO
---

※ "LISTENER_IP" には、ミラーマシンの IP アドレスを指定します。
※ "LISTENER_PORT" には、任意のポートを指定します。

B4) B3) で作成した証明書を任意の場所にバックアップします。

---
BACKUP CERTIFICATE ss2008r2m_cert TO FILE = 'C:\TEMP\ss2008r2m_cert.cer';
GO
---

B5) B4) で作成した証明書のバックアップを、プリンシパル側の任意の場所にコピーします。

プリンシパル サーバー側 作業 (着信設定)

C1) ミラー着信用の新規ログイン 及び ユーザーを作成します。

---
CREATE LOGIN ss2008r2m WITH PASSWORD = 'Passw@rd1';
CREATE USER ss2008r2m FOR LOGIN ss2008r2m;
---

※ "PASSWORD" には任意のパスワードを指定します。

C2) C1) で作成したユーザーと証明書の関連付けを行ないます。

---
CREATE CERTIFICATE ss2008r2m_cert
AUTHORIZATION ss2008r2m
FROM FILE = 'C:\TEMP\ss2008r2m_cert.cer';
GO
---

※ “FILE” には、B5) でコピーした、ミラー サーバー側の証明書のバックアップファイルを指定します。

C3) エンドポイントに対する接続権限を付与します。

---
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO ss2008r2m;
GO
---

ミラー サーバー側 作業 (着信設定)

D1) プリンシパル着信用の新規ログイン及びユーザーを作成します。

---
CREATE LOGIN ss2008r2p WITH PASSWORD = 'Passw@rd1';
CREATE USER ss2008r2p FOR LOGIN ss2008r2p;
---

※ "PASSWORD" には任意のパスワードをご指定下さい。

D2) D1) で作成したユーザーと証明書の関連付けを行ないます。

---
CREATE CERTIFICATE ss2008r2p_cert
AUTHORIZATION ss2008r2p
FROM FILE = 'C:\TEMP\ss2008r2p_cert.cer';
GO
---

※ “FILE” には、A5) でコピーした、ミラー サーバー側の証明書のバックアップファイルを指定します。

D3) エンドポイントに対する接続権限を付与します。

---
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO ss2008r2p;
GO
---

プリンシパル サーバー側 作業 (バックアップ)

E1) ミラーリング対象データベースの完全バックアップ 及び トランザクションログ バックアップを採取します。
E2) E1) にて採取したバックアップを、ミラー側の任意の場所にコピーします。

ミラー サーバー側 作業 (リストア)

F1) E2) でコピーしてきたバックアップファイルを使用し、ミラーリング対象のデータベースを RESTORE WITH NORECOVERY で復元します。

※ E1)、E2) 及び F1) の詳細な手順については、以下の URL を参照下さい。

ミラーリング用のミラー データベースを準備する方法 (Transact-SQL)
< http://msdn.microsoft.com/ja-jp/library/ms189047(v=sql.105).aspx>

ミラー サーバー側 作業 (ミラーリング開始)

G1) ミラーリング開始コマンドを実行します。

---
ALTER DATABASE <ミラーリング対象データベース名> SET PARTNER = 'tcp://192.168.1.1:5022'
---

※ "PARTNER" には、プリンシパル サーバーの IP アドレス 及び プリンシパル サーバーでエンドポイント作成時に "LISTENER_PORT" に指定したポート番号 を指定します。

プリンシパル サーバー側 作業 (ミラーリング開始)

H1) ミラーリング開始コマンドを実行します。

---
ALTER DATABASE <ミラーリング対象データベース名> SET PARTNER = 'tcp://192.168.1.2:5022'
---

※ "PARTNER" には、ミラー サーバーの IP アドレス 及び ミラー サーバーでエンドポイント作成時に "LISTENER_PORT" に指定したポート番号 を指定します。

H1) 手順を実施後、コマンドが正常に完了し、プリンシパル サーバー側の ミラーリング対象のデータベースのステータスが、”プリンシパル、同期済み” になれば、正常にミラーリングの構築が完了したと判断できます。

また、今回構築したミラーリング環境を再構築するため、今回構築したミラーリング環境を削除する場合は、以下の手順で削除が可能です。

プリンシパル サーバー側 削除作業

-- ミラーリング削除

USE master
GO
ALTER DATABASE <ミラーリング対象データベース名> SET PARTNER OFF;
GO

-- A3) で作成したエンドポイント削除

USE master
GO
DROP ENDPOINT  Endpoint_Mirroring;
GO

-- A2)、C2) で作成した証明書削除

USE master
GO
DROP CERTIFICATE ss2008r2p_cert;
GO
DROP CERTIFICATE ss2008r2m_cert;
GO

-- C1) で作成した ログイン、データベース ユーザー削除

USE master
GO
DROP USER ss2008r2m;
GO
DROP LOGIN ss2008r2m;
GO

ミラー サーバー側 削除作業

-- B3) で作成したエンドポイント削除

USE master
GO
DROP ENDPOINT  Endpoint_Mirroring;
GO

-- B2)、D2) で作成した証明書削除

USE master
GO
DROP CERTIFICATE ss2008r2m_cert;
GO
DROP CERTIFICATE ss2008r2p_cert;
GO

-- D1) で作成した ログイン、データベース ユーザー削除

USE master
GO
DROP USER ss2008r2p;
GO
DROP LOGIN ss2008r2p;
GO

今回は、SQL Server 2008 R2 における 非ドメイン環境上のサーバー間で プリンシパル、ミラーの２台構成のミラーリングを構築する方法について紹介しましたが、他のSQL Server のバージョン (SQL Server 2005、2008、2012 など) でも同様の手順で構築することが可能です。

また、もっと ミラーリング機能のついて知りたいという方、非ドメイン環境上のサーバー間で 監視サーバー (ウィットネス) を含む 3台構成のミラーリングを構築してみたいと思われる方は、SQL Server 2008 R2 自習書シリーズ (データベース ミラーリング入門)や、徹底検証シリーズ (SQL Server 2005 データベース ミラーリング検証)をご参照して頂ければと思います。

[参考情報]

証明書を使用したデータベース ミラーリングの設定の例 (Transact-SQL)     

今回はHalloween Protection (以降は HP とします) についてお話します。この問題はデータベース全般的に発生する可能性のあるハロウィーン問題に対する対策を意味したもので、日本ではハロウィーン保護とも呼ばれています。

HPの名前は、30年以上も前ですがIBMの研究者が問題を発見した日がハロウィーンの日（October 31）だったことにちなんでいます。この問題はUPDATEステートメントを実行する際に発生する可能性があることが指摘された問題ですが、UPDATEステートメント以外でもINSERT、DELETE、そして MERGE ステートメントが実行される際にも発生する可能性のある問題として指摘されています。

ここでは、問題が最初に発見されたUPDATEステートメントにおける問題を説明します。この問題が発生する可能性がある場合は、UPDATEステートメントのUPDATE対象が、UPDATEするために選択されてきたリストに存在する場合です。

それではこの問題を具体的に見ていきましょう。

HPの問題が最初に発覚したのは、ある会社で年収 $25,000（当時）以下の社員全員に10%の昇給を行うことが決定され、そのデータ更新が社員データベースに実行されたときでした。データ更新はエラーなく終了し、年収約$25,000以下の社員に限定されていたはずが、データ更新のクエリは すべての社員が最低でも$25,000 になるまで10%の昇給をし続けました。つまり、例えば $10,000 の人は $11,000 になるべきところを、$25,000 以上になるまで（WHERE句の対象から外れるまで）更新の対象となり続けたことを意味します。

どうしてそのようなことが起きたのでしょうか？

まず、UPDATEが実行されるときの動作をみてみましょう。一般的にUPDATEには以下の３つのフェーズがあります。

１．WHERE句の条件に合致する行を読み取ります。
２．１で取得された行に対しUPDATEが実行されます。
３．UPDATE実行時に制約違反がないかどうか等、データベースの整合性が保たれるよう確認がされます。

このフェーズは1回1行ずつ取得され実行されます。WHERE句の条件に合致すれば、10%の昇給が実施され、最終的にすべての行がWHERE句の条件に合致しなくなるまで繰り返し実行されました。

たとえば以下のようなイメージです。
注意：ここでは例としてHPの名前の由来となった状況をもとに説明しますが、現在SQL Server上で同様のクエリを実行しても同様の実行プランは得られません。これは都度問題が発見され次第修正されてきていることを示します。都度修正が発生するのはハロウィーン問題が現在は複雑かつ特殊な条件下で起こりうる可能性があるものの、発見することが容易ではないことが関係しています。

UPDATEが実行される前は以下のような状態です。

クエリ実行プランは以下のようなイメージです。1回1行ずつ non-clustered index からWHERE句に合致する行が取得されます。

取得された行に対し、Compute Scalar、たとえば佐藤さんの22,000 が対象になり佐藤さんの年収は 24,200に昇給されます。次に田中さんの21,000 が対象になります。田中さんの年収は同様に計算され23,100 に昇給されます。

さらにWHERE句の条件に合致する行が検索され、佐藤さんの 24,200 が対象となり、26,620 に昇給されます。田中さんも同じく23,100 から 25,410に昇給されます。

ここでようやく WHERE句の条件に合致する行がなくなったのでUPDATEの実行が終了します。しかし、これは意図していた結果ではありません。

どうしたらこのようなことを防ぐことができるでしょうか？

それは、クエリオプティマイザーにおいて、UPDATEをするために選択されてきた行のリストと、UPDATE対象のリストをそれぞれ個別のものとして扱うように強制することによって互いに影響されることを防ぐことができます。

たとえば上記の例では以下のように Table Spool（Eager Spool）が入ります。

このTable Spool（Eager Spool）が入ることにより、UPDATE対象の行がすべて最初に取得されます。そのリストをもとに、更新が実行されるため上記で発生したような繰り返し更新を実行する状況を避けることができます。

上記の例では、以下のリストがTable Spool（Eager Spool）されます。

このリストにある行を1行ずつ順番にUPDATEするため、繰り返して更新されることを避けることができます。

なお、マイクロソフトはハロウィーン問題に真摯に取り組むため、ハロウィーン問題の可能性が発見された場合はすぐにハロウィーン保護を導入し製品を日々改善しています。 また Craig Freedman’s SQL Server Blogでも触れられていますが、これらの修正によりデータをスプール（Eager Spool）する分時間がかかる場合もあり、パフォーマンスに影響がでる場合もありますが、常にデータの一貫性が最優先事項として選択されるため、このような動きとなっています。

参考

マイクロソフト SQL Serverチームからのハロウィーン保護についての取り組みについては以下をご覧ください。（英文）

Craig Freedman’s SQL Server Blog

Paul Whiteによるハロウィーン問題についての完結シリーズ

--

SQL Server Support Escalation Engineer
Kayoko Gray

SQL Server Developer サポートチーム

はじめに

PowerPivot for SharePoint はクラシックモード認証用に構成された SharePoint Web アプリケーションのみサポートします。

一方 SharePoint 2013 はクレームベース認証が既定の認証モードとなります。

この為、SharePoint 2013 Web アプリケーション上で PowerPivot for SharePoint を使用したり、BI セマンティックモデル接続ファイル (.bism) を作成するには、SharePoint Web アプリケーションをクラシックモード認証で作成する必要があります。

本ブログではその手順を案内します。

システム 

構成は次の通りです。

• SharePoint Application Server : SharePoint 2013, PowerPivot for SharePoint アドイン
• Database Server : SQL Server 2012 SP1 (SQL Server データベースエンジン (SharePoint 構成、コンテンツデータベースが存在) , PowerPivot for SharePoint )

手順概要

手順概要は下記の通りです。

1.  SQL Server PowerPivot for SharePoint のインストール

2.  PowerPivot for SharePoint に SQL Server 2012 SP1 の適用

3.  PowerPivot for SharePoint アドインのインストール

4.  PowerPivot for SharePoint 2013 の構成ツールを実行

5.  クラシックモード認証の SharePoint Web アプリケーションを作成

6.  サイトコレクションの作成

7.  SharePoint Web アプリケーションに PowerPivot Web application solution を配置

8.  各サイトに対して PowerPivot 機能を有効化

9.  PowerPivot の構成の確認

10. BI セマンティック モデル接続のコンテンツ タイプのライブラリへの追加 (Optional)

11. BI セマンティックモデル接続ファイルの作成 (Optional)

手順

1. SQL Server PowerPivot for SharePoint のインストール

Database Server に、SQL メディアから [SQL Server PowerPivot for SharePoint] セットアップ オプションを選択し、ウィザード に沿ってインストールします。

2. PowerPivot for SharePoint に SQL Server 2012 SP1 の適用

PowerPivot for SharePoint に対して、SQL Server 2012 SP1 を適用します。(2013 年 6 月時点)

SQL Server 2012 SP1 は下記からダウンロード可能です。

Microsoft® SQL Server® 2012 Service Pack 1 (SP1)

※ SQL Server 2012 データベースエンジンに対しても SQL Server 2012 SP1 を適用することを推奨しております。 (2013 年 6 月時点)

3. PowerPivot for SharePoint アドインのインストール

SharePoint Server 上に、下記サイトから入手した PowerPivot for SharePoint アドイン (spPowerpivot.msi ) をインストールします。

Microsoft® SQL Server® 2012 SP1 PowerPivot® for Microsoft® SharePoint®

http://www.microsoft.com/en-us/download/details.aspx?id=35577

参考

PowerPivot for SharePoint アドインのインストールまたはアンインストール
http://technet.microsoft.com/ja-jp/library/jj218792.aspx

4. PowerPivot for SharePoint 2013 の構成ツールを実行

SharePoint Server 上で、PowerPivot for SharePoint 2013 の構成ツールを実行し、SharePoint の PowerPivot 機能を配置および構成します。

SharePoint のインストール時に使用したアカウントでログインするか、SharePoint サーバーの全体管理サイトのプライマリ管理者としてセットアップ アカウントを構成します。

1)   [スタート] メニューの [すべてのプログラム] をクリックし、[ Microsoft SQL Server 2012 ] をクリックします。次に、[構成ツール] をクリックし、[PowerPivot For SharePoint 2013 の構成] をクリックします。 ツールは、PowerPivot for SharePoint がローカル サーバーにインストールされている場合にのみ表示されます。

2)  [PowerPivot for SharePoint の構成または修復] をクリックし、[OK] をクリックします。

3)  [パラメーター] タブで、次の操作を行います。

[既定のアカウント ユーザー名]: 既定のアカウントのドメイン ユーザー アカウントを入力します。 このアカウントは、PowerPivot サービス アプリケーション プールなどのサービスを準備する際に使用します。 Network Service や Local System などのビルトイン アカウントは指定しないでください。 ビルトイン アカウントを指定する構成はブロックされます。

[データベース サーバー]: SharePoint ファームでサポートされている SQL Server データベース エンジンを使用できます。 (本手順では Database Server のサーバ名となります)

[パスフレーズ]: パスフレーズを入力します。 新しい SharePoint ファームを作成する場合、SharePoint ファームにサーバーまたはアプリケーションを追加するたびにこのパスフレーズが使用されます。 ファームが既に存在する場合、ファームにサーバー アプリケーションを追加するためのパスフレーズを入力してください。

[Excel Services 用 PowerPivot サーバー]: SharePoint モードの Analysis Services サーバーの名前を入力します。 シングル サーバー配置では、データベース サーバーと同じサーバーです。 [ServerName]\powerpivot  (本環境では Database Server となりますので、Database Server のサーバー名\powerpivot を指定します。 ) 

例) 

5)  必要に応じて、各アクションを完了するために使用された残りの入力値を確認します。 左側のウィンドウで各アクションをクリックして、アクションの詳細を確認します。 それぞれの入力値の詳細については、 「PowerPivot for SharePoint 2010 の構成または修復 (PowerPivot 構成ツール)」の「サーバーの構成に使用する入力値」を参照してください。

6)  必要に応じて、今回は処理しないすべてのアクションを削除します。 たとえば、Secure Store Service を後で構成する場合は、[Secure Store Service の構成] をクリックし、[この操作をタスク一覧に含めます] チェック ボックスをオフにします。

7)  [検証] をクリックして、一覧のアクションを処理するための十分な情報があるかどうかを確認します。 検証エラーがある場合は、左ペインで警告をクリックして検証エラーの詳細を確認します。 検証エラーを修正し、もう一度 [検証] をクリックします。

8)   [実行] をクリックして、タスクの一覧にあるすべてのアクションを処理します。 [実行] は、アクションの検証後に有効になります。

[実行] が有効になっていない場合は、まず [検証] をクリックしてください。

参考

PowerPivot の構成とソリューションの配置 (SQL Server 2012 SP1)
http://technet.microsoft.com/ja-jp/library/jj682085.aspx

5. クラシックモード認証の SharePoint Web アプリケーションを作成

SharePoint Server 上で、クラシック モード認証の Web アプリケーションを作成します。

クラシック モード認証を使用する Web アプリケーションを作成するには、サーバーの全体管理サイトの代わりに PowerShell スクリプトを使用する必要があります。

1)  SharePoint 2013 管理シェルを起動します。
[スタート] メニューで、[すべてのプログラム]、[Microsoft SharePoint 2013 製品]、[SharePoint 2013 管理シェル] の順にクリックします。

2)  Windows PowerShell コマンド プロンプトで、次のコマンドを入力します。

New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod <WindowsAuthType> -ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>

指定するパラメータの詳細は下記の通りです。

- <Name> は、新しい Web アプリケーションの名前です。
- <ApplicationPool> は、アプリケーション プールの名前です。任意の名称を指定します。
- <WindowsAuthType> は、"NTLM" または "Kerberos" です。
- <ApplicationPoolAccount> は、このアプリケーション プールを実行するユーザー アカウントを指定します。
- <Port> は、IIS で Web アプリケーションが作成されるポートです。
- <URL> は、Web アプリケーションのパブリック URL です。アクセス時に使用する URL を指定します。

例)
New-SPWebApplication -Name "PowerPivot Classic site1" -ApplicationPool "PowerPivotClassicPool1" -AuthenticationMethod "NTLM" -ApplicationPoolAccount "contoso\administrator" -Port 40000 –URL “http://sps2k13sp”

参考

タイトル : クラシック モード認証を使用する Web アプリケーションを作成する (SharePoint 2013)
アドレス : http://technet.microsoft.com/ja-jp/library/gg276326.aspx

6. サイトコレクションの作成

クラシック モード認証を使用する Web アプリケーションを作成したら、その Web アプリケーションにサイトを作成するためにサイト コレクションを作成します。

本手順はサーバーの全体管理から実施頂けます。

サイト コレクションは複数のサイトのまとまりの単位で、サイトを作成するためには Web アプリケーションに 1 つ以上のサイト コレクションが必要です。
サイト コレクションを作成すると、同時にサイト コレクションのルートのサイトが作成されます。

この手順は、クラシック モード認証、クレームベース認証を問わずサーバーの全体管理サイトから実施いただくことが可能です。

サイト コレクションを作成するには、SharePoint サーバーの全体管理 Web サイトを実行しているコンピューターの Farm Administrators SharePoint グループのメンバーである必要があります。

1) SharePoint 2013 サーバーの全体管理を起動します。
[スタート] ボタンをクリックし、[Microsoft SharePoint 2013 製品]、[SharePoint 2013 サーバーの全体管理] の順にクリックします。

2) サーバーの全体管理 Web サイトの [アプリケーション構成の管理] セクションで、[サイト コレクションの作成] をクリックします。

3)  [サイト コレクションの作成] ページの [Web アプリケーション] セクションで、サイト コレクションを作成する Web アプリケーションが選択されていない場合は、[Web アプリケーション] メニューの [Web アプリケーションの変更] をクリックします。次に、1) で作成したサイト コレクションを作成する Web アプリケーションをクリックします。

4)   [タイトルと説明] セクションで、サイト コレクションのタイトルと説明を入力します。

5)    [Web サイトのアドレス] セクションで、URL に使用するパスを選択します。特に理由がなければ "/" を選択します。

"/sites/" などのワイルド カードを使用したパスを選択する場合は、サイトの URL で使用するサイト名も入力する必要があります。

6)  [テンプレートの選択] セクションの [エクスペリエンス バージョンの選択] ボックスの一覧で、使用するテンプレートの SharePoint エクスペリエンス バージョンを選択します。特に理由がなければ 2013 を選択します。

* そのサイト コレクションの見た目と動作を、SharePoint Server 2010 のサイト コレクションと同じようにする場合は、2010 エクスペリエンス バージョンを選択します。2010 エクスペリエンス バージョンを使用するサイト コレクションは SharePoint 2013で実行されますが、サイト コレクションのユーザー インターフェイスとユーザー エクスペリエンスは SharePoint Server 2010 と同じです。サイト コレクションをアップグレードする方法の詳細については、「サイト コレクションを SharePoint 2013 にアップグレードする」を参照してください。

7)   [テンプレートの選択] セクションの [テンプレートの選択] 一覧で、サイト コレクションのトップレベル サイトに使用するテンプレートを選択します。テンプレートの一覧の下に、選択したテンプレートの説明が表示されます。

8)   [サイト コレクション管理者] セクションに、サイト コレクションの管理者のユーザー名を DOMAIN\username の形式で入力します。

9)  [代理のサイト コレクション管理者] セクションに、サイト コレクションの代理の管理者のユーザー名を入力します。

サイト コレクションの管理者が不在の場合に誰かがサイト コレクションを管理できるように、サイト コレクションの代理の管理者を指定しておくことをお勧めします。

10)  クォータを使用してサイト コレクションの記憶域を管理する場合は、[クォータ テンプレート] セクションの [クォータ テンプレートの選択] 一覧でテンプレートをクリックします。

11)  [OK] をクリックします。

12)  クラシックモード認証の Web アプリケーションのサイトコレクションが作成されます。

参考

タイトル : SharePoint 2013 でサイト コレクションを作成する
アドレス : http://technet.microsoft.com/ja-jp/library/cc263094.aspx

7. SharePoint Web アプリケーションに PowerPivot Web application solution を配置

SharePoint Web アプリケーションに PowerPivot Web application solution を配置します。

1)  SharePoint 2013 全体管理を起動し、[システム設定] – [ファームソリューションの管理] をクリックします。

2) powerpivotwebapplicationsolution.wsp をクリックします。

3)  [ソリューションの配置] のリンクをクリックします。

4) 配置先に、作成したクラシックモード認証の web application を選択し、OK ボタンをクリックします。

8. 各サイトに対して PowerPivot 機能を有効化

SharePoint 全体管理から、各サイトに対して PowerPivot 機能を有効化します。

1) 作成したクラシックモード認証の SharePoint サイトで、[サイトの設定] をクリックします。

2) [サイト コレクションの管理] で [サイト コレクションの機能] をクリックします。

3)  [PowerPivot 統合サイト コレクション機能] が表示されるまで、ページを下にスクロールし、[アクティブ化] をクリックします。
他のサイト コレクションについても、各サイトを開き、[サイトの操作] をクリックして手順を繰り返します。

参考

PowerPivot 機能のアクティブ化
http://technet.microsoft.com/ja-jp/library/ee637271.aspx 

9. PowerPivot の構成の確認

SharePoint 全体管理から、PowerPivot の構成を確認します。

サービス、ファーム機能、サイトコレクション機能、PowerPivot サービスアプリケーションをそれぞれ確認します。

■ サービス
サーバーの全体管理で、[システム設定] の [サーバーのサービスの管理] をクリックします。
SQL Server PowerPivot System サービスが開始されていることを確認します。

■ ファーム機能

サーバーの全体管理で、[システム設定] の [ファーム機能の管理] をクリックします。
[PowerPivot 統合機能] が [アクティブ] になっていることを確認します。

■ サイト コレクション機能
サイトの URL を参照します。
[設定] をクリックし、[サイトの設定] をクリックします。
[サイト コレクションの機能] をクリックします。
[サイト コレクションの PowerPivot 機能の統合] が [アクティブ] になっていることを確認します。

■ PowerPivot サービス アプリケーション
サーバーの全体管理で、[アプリケーション構成の管理] の [サービス アプリケーションの管理] をクリックします。
サービス アプリケーションの状態が [開始済み] になっていることを確認します。 既定の名前は、[既定の PowerPivot サービス アプリケーション] です。

10. BI セマンティック モデル接続のコンテンツ タイプのライブラリへの追加  (Optional)

コンテンツ タイプを追加および構成するには、管理リスト権限以上の権限が必要です。 この権限は、デザイン権限レベル以上の権限に組み込まれています。

BI セマンティックモデル接続のコンテンツタイプをライブラリへ追加するには、 PowerPivot for SharePoint の機能のアクティブ化が必要です。  (前述の手順)

1)  クラシックモード認証のサイトを開き、SharePoint リボンで、[ライブラリ ツール] の [ライブラリ] をクリックします。
[ライブラリの設定] をクリックします。

2)  [全般設定] の [詳細設定] をクリックします。

3) [コンテンツ タイプ] の [コンテンツ タイプの管理を許可する] セクションで [はい] を選択し、[OK] をクリックします

4) [コンテンツ タイプ] の [既存のサイト コンテンツ タイプから追加] をクリックします。

5)  [サイト コンテンツ タイプの選択元] で [ビジネス インテリジェンス] をクリックします。

6)  [利用可能なサイト コンテンツ タイプ] で [BI セマンティック モデル接続ファイル] をクリックしてから [追加] をクリックし、選択したコンテンツ タイプを [追加するコンテンツ タイプ] ボックスの一覧に追加し、[OK] をクリックします。

11. BI セマンティックモデル接続ファイルの作成 (Optional)

1) クラシックモード認証のサイトで、SharePoint リボンの [ドキュメント] をクリックします。

2) [新しいドキュメント] の下矢印をクリックし、[BI セマンティック モデル接続ファイル] を選択して、[新しい BI セマンティック モデル接続] ページを開きます。

3)  [サーバー] プロパティと [データベース] プロパティの両方を設定します。

※ データベース名がわからない場合は、SQL Server Management Studio を使用して、サーバーに配置されているデータベースの一覧を表示します。

[サーバー名] には、サーバーのネットワーク名、IP アドレス、または完全修飾ドメイン名 (myserver.mydomain.corp.adventure-works.com など) を指定します。

サーバーが名前付きインスタンスとしてインストールされている場合は、computername\instancename の形式でサーバー名を入力します。

[データベース] には、サーバーで現在使用可能なテーブル データベースを指定する必要があります。 他の BI セマンティック モデル接続ファイル、Office Data Connection (.odc) ファイル、Analysis Services OLAP データベース、または PowerPivot ブックを指定しないでください。 データベース名を取得するには、Management Studio を使用してサーバーに接続して、使用可能なデータベースの一覧を表示します。 データベースのプロパティ ページを使用して、名前が正しいことを確認します。

4) [OK] をクリックしてページを保存します。 この時点で、PowerPivot サービス アプリケーションが接続を検証します。

接続情報が正しく、PowerPivot サービス アプリケーションに管理権限が付与されていて、現在のユーザーとして Analysis Services に接続できるようになっていれば、検証は成功します。

参考

テーブル モデル データベースへの BI セマンティック モデル接続の作成
http://technet.microsoft.com/ja-jp/library/hh230972.aspx

皆さん、こんにちは。 今回は、SQL Server 2008 R2 SP2 適用後に、クエリのパフォーマンスに影響を及ぼす可能性があるクエリ例 及び クエリの動作について、紹介したいと思います。

SQL Server 2008 R2 SP1 では、クエリの実行プランを作成時、特定の条件下において、本来 クエリ完了までに正しく整合性を保持するために必要となる “Table Spool (Eager Spool)” オペレータが使用されず、誤ったクエリ結果を返すという問題がございました。

そこで、SQL Server 2008 R2 SP2 では、特定の条件においても、クエリ完了までに正しく整合性を保持できるよう、“Table Spool (Eager Spool)” オペレータ が使われるように修正したものが含まれております。

この修正により、本来  “Table Spool (Eager Spool)” オペレータを追加する必要があったクエリに、正しく “Table Spool (Eager Spool)” オペレータを追加できるようになった一方で、本オペレータが追加されることに伴い、クエリのパフォーマンスに影響を及ぼす可能性があります。

それでは、クエリ例 及び クエリ動作を見ていきましょう。

クエリ例 及び クエリ動作を紹介するにあたり、まずは、以下のスクリプトを実行しサンプルデータベース 及び テーブルを作成します。

---

CREATE DATABASEDB_TEST;
GO

USEDB_TEST
GO

CREATE TABLE[tbMain](
    [c1]int NOT NULL,
    [c2]int NOT NULL,
    [c3]datetime NOT NULL
);
GO

CREATE TABLE[tbSub](
    [c1] int NOT NULL,
    [c2] int NOT NULL,
    [c3] datetime NOT NULL
);
GO

ALTER TABLE[tbMain]ADD
CONSTRAINTpk_tbMain_c1PRIMARY KEY NONCLUSTERED ( c1 ),
CONSTRAINTuk_tbMain_c2UNIQUE CLUSTERED (c3, c1, c2 );
GO

ALTER TABLE[tbSub]ADD
CONSTRAINTpk_tbSub_c1c2
PRIMARY KEY CLUSTERED ( c1, c2 );
GO

ALTER TABLE[tbSub]ADD
CONSTRAINT[fk_tbSub_c1]FOREIGN KEY
(
    [c1]
)
REFERENCES[tbMain]
(
    [c1]
)
ON DELETE CASCADE;
GO

INSERT INTO[tbMain]
VALUES (1,1,'2013-06-12'),(2,2,'2013-06-13'),(3,3,'2013-06-14');
GO

INSERT INTO[tbSub]
VALUES (1,1,'2013-06-12'),(2,2,'2013-06-13'),(3,3,'2013-06-14');
GO
---

スクリプトで作成したテーブルに対して、以下のクエリを SQL Server 2008 R2 SP1 の環境 及び SP2 の環境上で実行します。

---

UPDATE[tbSub]
SETc1 = 1,
    c2 = 1,
    c3 = '2013-06-15'
WHEREc1 = 1
ANDc2 = 1;
GO

---

[実行プラン] SQL Server 2008 R2 SP1 環境

UPDATE [tbSub] set [c1] = @1,[c2] = @2,[c3] = @3  WHERE [c1]=@4 AND [c2]=@5
   |--Assert(WHERE:(CASE WHEN [Expr1019] IS NULL THEN (0) ELSE NULL END))
        |--Nested Loops(Left Semi Join, OUTER REFERENCES:([DB_TEST].[dbo].[tbSub].[c1]), DEFINE:([Expr1019] = [PROBE VALUE]))
             |--Clustered Index Update(OBJECT:([DB_TEST].[dbo].[tbSub].[pk_tbSub_c1c2]), SET:([DB_TEST].[dbo].[tbSub].[c1] = RaiseIfNullUpdate([@1]),[DB_TEST]..
             |--Index Seek(OBJECT:([DB_TEST].[dbo].[tbMain].[pk_tbMain_c1]), SEEK:([DB_TEST].[dbo].[tbMain].[c1]=[DB_TEST].[dbo].[tbSub].[c1]) ORDERED FORWARD)

[実行プラン] SQL Server 2008 R2 SP2 環境

UPDATE [tbSub] set [c1] = @1,[c2] = @2,[c3] = @3  WHERE [c1]=@4 AND [c2]=@5
  |--Assert(WHERE:(CASE WHEN [Expr1031] IS NULL THEN (0) ELSE NULL END))
       |--Nested Loops(Left Semi Join, OUTER REFERENCES:([DB_TEST].[dbo].[tbSub].[c1]), DEFINE:([Expr1031] = [PROBE VALUE]))
            |--Clustered Index Update(OBJECT:([DB_TEST].[dbo].[tbSub].[pk_tbSub_c1c2]), SET:([DB_TEST].[dbo].[tbSub].[c1] = ..
            |    |--Compute Scalar(DEFINE:([Expr1023]=(1), [Expr1024]=(1)))
            |         |--Compute Scalar(DEFINE:([Expr1003]='2013-06-15 00:00:00.000'))
            |              |--Table Spool
            |                   |--Clustered Index Seek(OBJECT:([DB_TEST].[dbo].[tbSub].[pk_tbSub_c1c2]), SEEK:([DB_TEST].[dbo].[tbSub].[c1]=(1) AND ..
            |--Index Seek(OBJECT:([DB_TEST].[dbo].[tbMain].[pk_tbMain_c1]), SEEK:([DB_TEST].[dbo].[tbMain].[c1]=[DB_TEST].[dbo].[tbSub].[c1]) ORDERED FORWARD)

同じクエリを実行しましたが、SQL Server 2008 R2 SP1 環境と、SQL Server 2008 R2 SP2 環境とで、実行プランが異なることが確認でき、また、SQL Server 2008 R2 SP2 の環境では、”Table Spool (Eager Spool)” というオペレータが追加されていることが確認できると思います。

この “Table Spool (Eager Spool)” は、クエリの実行プランを作成する際、条件に合致した行データを取得後、クエリが完了するまでの動作の中で取得した行データが変更される恐れがあり、かつ、変更される恐れがある行データが他のオブジェクトなどを参照するためのキーとして使用されているなど、取得時の行データの一貫性を保つ必要があるとオプティマイザが判断した場合に、追加されるオペレータの一つとなります。

SQL Server 2008 R2 SP1 環境の場合、本クエリが実行される際、本来 追加されるべき “Table Spool (Eager Spool)” オペレータが追加されないという問題があったため、“Table Spool (Eager Spool)” オペレータが追加されていませんが、SQL Server 2008 R2 SP2 環境では、正しく “Table Spool (Eager Spool)” オペレータを追加できるように改修されたため、“Table Spool (Eager Spool)” オペレータが追加されています。

なお、今回のUPDATE文を実行した場合、以下のような条件例の場合に合致し、“Table Spool (Eager Spool)” が追加されるようになります。

[条件例]

UPDATE の WHERE句に指定した条件と同じ値を、SET句に指定している。

UPDATE の SET句に指定された列が、インデックスのキー列に含まれている。

UPDATE の SET句に指定された列は、外部キーとして別テーブルを参照している。

一般的に “Table Spool (Eager Spool)” オペレータ が存在する場合と存在しない場合とを比較した場合、“Table Spool (Eager Spool)” オペレータは実行コストが高く、存在しない場合と比較し、CPU タイムを多く必要する可能性があるため、クエリのパフォーマンスに影響を及ぼす可能性がございます。

今回のクエリ例の場合、UPDATE の WHERE句に指定した条件と同じ値を、SET句に指定しないようクエリを修正することにより、“Table Spool (Eager Spool)” オペレータ を必要としない、クエリの実行プランが作成されることになります。

---

UPDATE[tbSub]
SET  c3 = '2013-06-15'
WHEREc1 = 1
ANDc2 = 1;
GO

---

[実行プラン] SQL Server 2008 R2 SP2 環境

UPDATE [tbSub] set [c3] = @1  WHERE [c1]=@2 AND [c2]=@3
  |--Clustered Index Update(OBJECT:([DB_TEST].[dbo].[tbSub].[pk_tbSub_c1c2]), SET:([DB_TEST].[dbo].[tbSub].[c3] = RaiseIfNullUpdate([Expr1003])), ..

 最後に、クエリ完了までに正しく整合性を保持できず、誤ったクエリ結果を返す現象のことを、ハロウィーン問題と呼んでいます。

今回紹介しましたクエリでは、SQL Server 2008 R2 SP2 適用後、“Table Spool (Eager Spool)” オペレータ が追加されますが、これは ハロウィーン問題への対策 (ハロウィーン保護 (Halloween Protection)) を実施したためとなります。

マイクロソフトでは、ハロウィーン問題の可能性が発見された場合は、データの一貫性を最優先事項として、ハロウィーン保護 (Halloween Protection) を製品に導入しております。

ハロウィーン保護 (Halloween Protection) は、データの一貫性を保つために、必要な対策である点をご理解頂ければ幸いです。

ハロウィーン保護 (Halloween Protection) の詳細につきましては、Halloween Protection (HP) についてを参照して頂ければと思います。

山田 浩史
SQL Engine Support Engineer

みなさん、こんにちは。今回は、osql を使用していると直面しうるエラーについて紹介します。

現象
osql ユーティリティにて DBCC CHECKDB を実行した場合、出力結果内に "SQLGetDiagRec failed" のメッセージが大量に出力される。

-o オプションを使用して、結果をファイルに出力した場合も、コマンドプロンプトの標準出力に結果を出力した場合も同様に "SQLGetDiagRec failed" のメッセージが出力されます。

本現象の特徴は、出力結果内の 32768 行目から "SQLGetDiagRec failed" のメッセージが連続して出力される事です。

    出力例：
    -----
    32766 行目 'test_table' の DBCC 結果。
    32767 行目オブジェクト "test_table" の 0 ページには 0 行あります。
    32768 行目 SQLGetDiagRec failed
    32769 行目 SQLGetDiagRec failed
    32770 行目 SQLGetDiagRec failed
    32771 行目 SQLGetDiagRec failed
    32772 行目 SQLGetDiagRec failed
    32773 行目 SQLGetDiagRec failed
    ：
    -----

原因
osql の仕様上の制限です。

影響
DBCC CHECKDB の結果が正常に確認出来ません。

回避策
sqlcmd ユーティリティを使用します。

sqlcmd ユーティリティでは、"SQLGetDiagRec failed" のメッセージが出力される事はありません。
osql ユーティリティは SQL Server の将来のバージョンで削除される予定の機能となるため、sqlcmd ユーティリティの使用を推奨しています。

    コマンド例：
    sqlcmd -E -Q"DBCC CHECKDB (test_db)" -o C:\checkdb.txt

参考情報
osql ユーティリティ
http://msdn.microsoft.com/ja-jp/library/ms162806.aspx

sqlcmd ユーティリティ
http://msdn.microsoft.com/ja-jp/library/ms162773.aspx

山﨑 実久
SQL Developer Support Engineer

以前、本ブログの “Reporting Services のレポートで印刷を行うと「クライアントの印刷コントロールを読み込めません。」のエラーが発生する” の記事で、Reporting Services のレポートで印刷時の下記エラーの発生パターンおよび回避方法をご案内しました。

--------
クライアントの印刷コントロールを読み込めません。
--------

“Reporting Services のレポートで印刷を行うと「クライアントの印刷コントロールを読み込めません。」のエラーが発生する” の記事で、上記エラーが発生するパターンの1つとして、Reporting Services の印刷時、RSClientPrint  という ActiveX コントロールがクライアントにインストールできないため、このエラーが発生する場合があることをお伝えしました。

本 blog では、SQL Server 2008 以降の環境において、RSClientPrint という ActiveX コントロールがクライアントにインストールできない場合について、下記 2 点を補足説明します。

・RSClientPrint の ActiveX コントロールがクライアントにインストールされているか確認する方法
・対処方法

[RSClientPrint の ActiveX コントロールがクライアントにインストールされているか確認する方法]

事象が発生するクライアントマシンにて C:\Windows\Downloaded Program Files\ 配下の RSClientPrint.dll のファイルが存在しているか否かで、判断できます。
RSClientPrint.dll のファイルが存在しない場合、RSClientPrint の ActiveX コントロールがクライアントにインストールされていないと判断できます。その場合、以下の対処方法に記載の内容を確認します。

[インストールできない原因についての確認方法]

事象が発生するクライアントマシンにて RSClinetPrint ActiveX コントロールをインストールできない一般的な原因は以下となります。以下 2 点に該当しないか確認します。

1. 印刷を行っているユーザーの権限が不足している。（PowerUser 以上の権限が必要です。）
2. IE の セキュリティ設定で、ActiveX コントロールのダウンロード等が無効となっている。 ※

※ 2 について、IE の設定の確認方法の詳細は以下となります。

事象が発生するクライアントマシンにて確認手順
------------------------------------------------------
[インターネットのオプション] - [セキュリティ] の下記 4 つの項目について、それぞれ以降に記載のURL を参照いただき、ActiveX に関する設定を確認します。

  [インターネット]
  [ローカルイントラネット]
  [信頼済みサイト]
  [制限付きサイト]

+ ActiveX に関する設定を紹介しているサイト

  Internet Explorer の ActiveX に関する設定を調整する
  http://windows.microsoft.com/ja-jp/windows/help/genuine/ie-activex

上記、1, 2 を確認後、該当しない場合は、以下を事象が発生するクライアントマシンにて実施ください。以下の手順は SQL Server 2008の既定インスタンスについての例となります。
SQL Server 2008 以降の場合は、 1) の cab ファイルの場所を SQL Server のバージョンに合わせ変更します。

例 ) 対処方法
----------------
1) RSClientPrint の cab ファイルの中身をクライアントの任意のディレクトリ (例：c:\temp) にコピーし展開します。
RSClientPrint の cab は、既定では、対象の SQL Server 稼働マシン上の、以下のフォルダ配下にあります。

C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\bin

SQL Server 2008 Reporting Servicesの RSClientPrint の cab は以下の 3 種類があります。

・RSClientPrint-ia64.cab
・RSClientPrint-x64.cab
・RSClientPrint-x86.cab

これは、レポートにアクセスを行うブラウザによって使用する cab が異なります。
32bit 環境の場合は「RSClientPrint-x86.cab」をコピーし展開します。
また、x64 環境であっても、IE を 32bit モードで起動する場合には、上記と同様に「RSClientPrint-x86.cab」をコピーし展開します。

2) 印刷を行うクライアントマシン上にて、管理者権限でコマンド プロンプト(CMD.EXE) を起動して、以下のコマンドを入力します。

Regsvr32 c:\temp\rsclientprint.dll

-> 成功した場合、以下のメッセージが表示されます。
c:\temp\rsclientprint.dll の DLLRegisterServer は成功しました。

※ 1) で展開した cab ファイルの中身のうち、「rsclientprint.dll」を指定します。
※ x64、IA64の cab を使用する場合には、下記のように「rsclientprint64.dll」を指定します。
Regsvr32 c:\temp\rsclientprint64.dll

3) レポートに接続し、印刷ボタンをクリックし印刷可能か確認します。

以上となります。参考になりましたら幸いです。

高橋 理香

SQL Developer Support Escalation Engineer

SQL Server では、パラメータ付きのストアドプロシージャを作成して実行したり、sp_executesql を使用してパラメータ クエリを実行することができます。このパラメータ クエリを実行する際には、パラメータのデータ型やパラメータ値が必要となります。また、文字列型やバイナリ型の場合には、サイズの指定も必要です。

一方で .NET Framework Data Provider for SQL Server (以降 SqlClient) を使用するアプリケーションからストアドプロシージャやパラメータ クエリを実行する場合、SqlParameter クラスを使用してパラメータのデータ型等を設定できますが省略することもできます。これは、SqlClient が SqlParameter の Value プロパティに代入された値を基にデータ型やサイズの推論を行っているからです。

しかしながら、パラメータのデータ型やサイズを明示的に指定しなかった場合には、意図しないデータ型やサイズとなることで、クエリのパフォーマンス劣化が発生したり、エラーによって実行できないなどの問題が発生する可能性もあります。そのため、可能な限りパラメータのデータ型やサイズは明示的に記述しておいた方が、アプリケーションの堅牢性の面からもよいでしょう。

推奨事項

1. パラメータのデータ型は SQL Server 側のデータ型に合わせて明示的に指定する。
2. 文字列やバイナリのデータ型の場合、サイズも明示的に指定する。
3. varchar(max) 等の max を使用したデータ型についてはサイズに -1 を指定する。

なぜデータ型を明示的に指定した方がいいのか？

以前に以下のブログで紹介しているように、データ型が一致していない場合にはデータ型変換を行ってから比較を行うことになります。つまり、クエリ パフォーマンスが悪化し、ひいては、アプリケーションのパフォーマンス劣化につながります。

DO's&DONT's #2: 絶対にやらなければいけないこと - データ型を一致させる

データ型変換が発生する例をご紹介しましょう。

ADO.NET では、次のようにパラメータのデータ型やサイズを指定しないパラメータ クエリを実行するコー��を記述することができます。

この例の場合、パラメータ ＠AccountNumber のデータ型の指定がないため、渡された値である "AW00011354" を基にデータ型とサイズを推論します。.NET Framework では文字列は Unicode で扱いますので、この結果は、nvarchar(10) になります。したがって、SQL Server で実行される SQL 文は次のようになります。

しかし、サンプル データベース AdventureWorks 上の Sales.Customer テーブルの AccountNumber 列は varchar(10) です。したがって、AccountNumber 列をいったん nvarchar (10) に変換し、その結果とパラメータ値を比較する操作が行われることになり、処理に非常に時間がかかる結果となります。

上記を次のように書き換えるだけで、ある環境では 1分以上も要していたクエリが 100ミリ秒程度で完了するようになりました。

データ型として SqlDbType.VarChar を指定しただけでこんなにも違うのであれば、指定した方がいいですよね。

なぜサイズを明示的に指定した方がいいのか？

サイズを明示的に指定しない場合に発生しうる問題として次の2つがあります。

• 最大サイズが使用されることで、作業テーブルを利用したクエリの処理において、テーブルの行の最大許容サイズを超え、エラー 1701 が発生する。
• 推論によって設定されたサイズが最大サイズを超えるため、SQL Server の仕様に沿わないリクエストと判断され、エラーが発生する。

順にどのような状況下で発生するかご説明しましょう。

作業テーブル利用でエラー 1701 が発生するシナリオ

先の例では、Value プロパティに設定されたデータから推論が行われ、データが 10 文字であったためにサイズに 10 が設定されました。
では、NULL 値をパラメータ値として渡した場合、このサイズはどうなるでしょう？

Value プロパティからは長さを推論できませんね。このような場合、指定されているデータ型の最大値がサイズに指定されることになります。

例えば SqlDbType.Char がデータ型として指定されている場合、そのサイズは 8000 と設定されることになります。ここで問題となるのは、SQL Server における SQL 文の処理で並び替えなどのために作業テーブルを必要とする場合です。作業テーブル自体は、他の列に加えて char(8000) の列を含めることになっても作成は成功します。しかし、実際にこの作業テーブルには、SQL Server におけるテーブル行の最大許容サイズの 8094 バイトを超えるレコードが格納されることになるため、制限によって次のエラー 1701 が発生する結果となります。

パラメータに相当する列が char(2) であれば、あらかじめ SqlParameter の Size プロパティに 2 を設定しておくことで、作業テーブルが作成される場合でも、余分なリソースを使うことを避けることができ、かつ、エラーも回避できます。

推論によって設定されたサイズが最大サイズを超えるシナリオ

非常に長い文字列をパラメータ値として使用する場合について考えてみましょう。

仮にサイズの指定を行っていないと推論が行われることになりますが、基本的にはこの推論は Value プロパティに指定された文字列の長さで決定されることになりますので、8001 バイト以上の文字列の場合には、8001 以上のサイズとして扱われることになります。

しかしながら SQL Server では、varchar(max) や nvarchar(max) などのデータ型で 2GB までのデータの格納を許容できるも���の、これらのデータ型における明示的なサイズの指定は varchar の場合には 8000 まで、nvarchar の場合には 4000 までになります。そのため、varchar の場合には 8001 といった数値は不適切なサイズということになります。

推論の結果が SQL Server では不適切なサイズであると判断された場合、SQL Server からは以下のようなエラーが返されます。

あらかじめ SQL Server 側のデータ型が varchar(max) などの max を使用するデータ型であった場合には、Size プロパティに -1 を指定しておくことで、この推論を避けることができ、varchar(max) のデータ型にて SQL 文が実行されるようになります。

参考情報

パラメーターおよびパラメーターのデータ型の構成

SqlParameter.SqlDbType プロパティ

SqlParameter.Size プロパティ

作業テーブル

nchar および nvarchar (Transact-SQL)

char および varchar (Transact-SQL)

binary と varbinary (Transact-SQL)

日頃、弊社製品をご愛顧いただき、誠にありがとうございます。

現在、マイクロソフトでは、SQL Server および Visual Studio 製品など、各国語版製品のローカライズ (日本語への翻訳) についての品質や要望についてのアンケート調査を実施しております。アンケートの参加は匿名です。

調査対象製品
•         Visual Studio
•         SQL Server
•         Windows Azure
•         Windows Server
•         System Center

調査期間
•         6/3/2013~7/28/2013 (ただし、SQL Serverは11月末日まで継続)

日本語のドキュメントについてや、ローカライズに対して日頃モノ申したい！という方、是非忌憚ないご意見をお願いいたします。率直なところ、われわれの意見(特に内容が書いてあるもの）については、研究開発本部において、驚くほど読み込まれてディスカッションされたりしています。どうせ読んでないんだろう。。。ということはありません。本当に、皆様、特に日頃から使い込んでいる皆様ならではの意見を頂ければと思います。研究開発本部の担当も、私たちの意見を聞いてみたいと言っております。

お忙しいところ恐縮ですが、以下の URL から、是非ともお声をお聞かせいただければと存じます。

サーバーおよびツール製品に関するインターナショナル ユーザー アンケート 2013

http://aka.ms/stb13_ja

アンケートは、5 分 ～ 15 分程度の所要時間となり、無記名でお客様の個人情報をマイクロソフトが取得することはありません。

ご参加いただける場合には、上記のリンクからアンケート設問の表示言語を選択いただき、対象となる製品を選択していただ上、アンケートにご協力いただけますと幸いです。

どうぞよろしくお願いいたします。ご意見、お待ちしております！

お客様各位

毎週水曜日を「サポート・サービスデイ」とし、障害以外の製品利用技術に関してお客様からのご質問や疑問にお応えする機会を設けました（こちらは無償となります）。相談されたい案件をお持ちのお客様は、以下を記載いただき、 ms8spday@microsoft.com宛に電子メールをお送りください。

なお、弊社までお越しいただくことが難しい場合はオンライン会議での対応も可能ですので、是非ご検討ください。

※ 対象製品：SQL Server, Internet Information Server, Internet Explorer, Visual Studio, SDK（但し最新バージョンと一世代前のバージョン）

＜いただきたい内容＞
①サポート契約番号
②相談事項概要

後程、弊社担当者よりご連絡を差し上げ日程等を調整させて頂きます。

※補足 ※
・案件によってはお受け出来ない場合や、相談事項が多い場合等は別途有償サポートのご案内となります。
・水曜日が休日の場合は調整致します。

横井 羽衣子 (よこい ういこ)
SQL Developer Support Engineer

皆さんごきげんよう。今日は、みんな大好き Windows Azure で、Web ロールで特定のバージョンの (Guest OS に入ってるより新しいバージョンなど) SQL Server Native Client を常に使えるようにしたいときにはどうしたらいいか？というお話しをご紹介します。

PHP などで、ODBC 接続を使いたいシナリオがあります。こんな時、SQL Server Native Client を使って接続します。Windows Azure SQL Database のポータルで接続文字列をコピーするときも、いろいろ選べますが、SQL Server Native Client が文字列に入っています。しかし、オンプレミスの OS 上で動作するアプリケーションと異なり、Windows Azure であることを考慮したポイントがあります。今日はそれらの注意点などを踏まえながら、SQL Server Native Client を使えるようにする方法を見ていきましょう。

最初に : Windows Azure のロールとゲスト OS の関係

Visual Studio で Web ロールを作って配置すると、リモートデスクトップもできてしまいます。でも、Visual Studio では、プロジェクトを作るだけで、OS の設定とかしてませんよね？では、Windows Azure 上に構成された Web ロールは、どのように動くのでしょうか。

これらのプログラムは、実はマイクロソフトが管理しているゲスト OS のイメージ上で動作します。基本的に、概念としてはアプリケーションを利用する側は、ゲスト OS の構成を考慮する必要はなく、マイクロソフトにお任せ、ということになり、定期的にメンテナンスなどが行われる過程において、OS のリプレースが発生します。イメージ的には、「まっさらな」状態に戻ってしまうのです。これはすなわち、デバッグ用に提供されたリモート デスクトップなどを利用して、モジュールを構成していても、永続性は完全に保証されないということを意味します。(※)これは、Windows Azure の PaaS としての設計上、想定された動作となります。

図 : SQL Server Native Client がメンテナンスに伴うリプレースのためバージョンが戻っちゃって Windows Azure SQL Database に接続できない。この例では、接続可能な最低限のバージョンである 10.50.2500より古い 10.00.2531 が使われている。(ダイアログはイメージです。また、上記はあくまでもイメージをつかむための図です。正確な構成図などはMSDN などをご覧くださいませ。)

では、こうした状況に対し、常に自アプリケーションが依存するモジュールを使用できるようにするためにはどのようにすればよいのでしょうか。
その手段として、「スタートアップ タスク」が存在します。スタートアップ タスクによって、プロジェクト中にて依存関係を持つモジュールを構成してあげればよいのです。これにより、リプレースによって OS が某アニメの女子のように "n 人目" になっても、変わらずモジュールを使い続けることができるのです。次項では、スタートアップ タスクの構成手順についてご案内します。

(※) 仮想環境を構築するハイパーバイザー上に存在している間は再起動で変更されることはありませんが、OSの更新のタイミングで固定イメージにリプレースされることがあります。リプレースされると、新しいイメージの OS に入れ替わるため、リモートデスクトップなどで構成した一時的な情報は更新前の OS のイメージとともに削除されます。

Note : リモート デスクトップ経由での構成についての注意

リモート デスクトップ経由での構成は、デバッグ用途であり、運用を焦点に置いたアプリケーションの追加などは想定していないことに留意頂く必要があります。こうした注意点については、下記ドキュメントをご参照ください。 OS のアップグレード処理について http://msdn.microsoft.com/ja-jp/windowsazure/hh705141 ※注意 4: Host OS のアップグレード時にはインスタンス (Guest OS) が停止します。 リモート デスクトップを利用したデバッグ http://msdn.microsoft.com/ja-jp/windowsazure/hh913770 ※ "3: 重要な注意事項 - リモート デスクトップを利用した OS のカスタマイズについて" の項をご参照ください。

図 : スタートアップタスクでリプレース後もプロジェクト中にて依存関係を持つモジュールを構成するように設定してあげればいつでも使いたいバージョンが使用可能！

スタートアップ タスクを利用して SQL Server Native Client を構成する

Guest OS には、SQL Server 2008 Native Client が既にインストールされていますが、接続先が Windows Azure SQL Database の場合、バージョンが古いものとなるため、新しいバージョン (SQL Server Native Client 10 のバージョン 10.50.2500以上または SQL Server Native Client 11.0) を使っていただく必要があります。

1. 以下のサイトから、新しいバージョンの Native Client を開発マシン上にダウンロードしてください。

 Microsoft SQL Server 2008 R2 SP2 Feature Pack (Feature Pack は、サービス パックごとに用意されます。2013/07 現在の最新は SP2 です。)

http://www.microsoft.com/ja-jp/download/details.aspx?id=30440

Microsoft SQL Server 2012 Feature Pack※ SQL Server Native Client 11.0     

http://www.microsoft.com/ja-jp/download/details.aspx?id=29065  

※ 何れのリンクにおいても、x64 版の sqlncli.msiをダウンロードします。

ダウンロード時の注意

ページを開いて、ダウンロードボタンを押します。

(b) [ダウンロードするプログラムを選んでください。] という画面に遷移しますので、sqlncli_<プラットフォーム名>.msi のチェック ボックスをオンにして、ボタンを押します。チェックボックスは複数チェックできます。

(c) お使いのブラウザにて、ダウンロードが開始されます。ブラウザの設定に合わせ、ダウンロードをお願いします。

接続文字列を書き換える : SQL Server Native Client 11 を使う場合

Windows Azure SQL Database 管理ポータルから接続文字列をコピーしてきて使う場合は、SQL Server Native Client 11 の場合、ODBC 接続において Driver 指定を、{SQL Server Native Client 10.0} → {SQL Server Native Client 11.0} に書き換える必要があります。

図 : 管理ポータルから得られる接続文字列

2. エディタで startup.cmdというファイルを作成し、内部に以下の記述を追加します。
このコマンドは、sqlncli.msiパッケージをサイレントモードでインストールするコマンドです。 なお、ファイルを保存する際には、UTF-8 等の Unicode 形式ではなく、ANSI 形式で保存してください。

msiexec.exe /i sqlncli.msi /passive /qn IACCEPTSQLNCLILICENSETERMS=YES /l*v C:\sqlncli.log

3. ご利用いただいて��る Web Role プロジェクトを Visual Studio で開きます。
4. ソリューション エクスプローラ内の Web Role のプロジェクトを右クリックし、[追加] → [既存の項目] を選択します。以下のファイルを追加してください。

- sqlncli.msi
- startup.cmd

5. ソリューション エクスプローラ上で sqlncli.msi を右クリックし、プロパティを表示し、プロパティ画面の [出力ディレクトリにコピー] 個所で [新しい場合はコピーする] を選択ください。

6. startup.cmd についても、項目 5 と同様に [新しい場合はコピーする] を選択ください。
この処理を実施いただくことで、sqlncli.msi と startup.cmd が出力されるパッケージに追加が行われます。

7. 今度は、ソリューション エクスプローラ内のクラウドプロジェクト側 (VS2010 では地球儀のアイコン / VS2012 では雲のアイコン) で、ServiceDefinition.csdef をダブルクリックして開きます。

XML が表示されるので、<WebRole> タグの中に、以下のタグを追加します。

例)   サービス名 WindowsAzure_2013_01 の場合。全文貼り付けせず、適宜参考にして<Startup> – </Startup>までを張り付けてください。
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzure_2013_01" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2012-10.1.8">
  <WebRole name="WebRole1" vmsize="Small">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
    <Startup>
      <Task commandLine="startup.cmd" executionContext="elevated" taskType="simple" />
    </Startup>
  </WebRole>
</ServiceDefinition>

これで、ロールの初期化時に、指定したコマンドが実行されるようになります。

Note : うまく配置が進まない時は

スタートアップ タスクが失敗し、再試行を繰り返し続けている場合があります。taskType が simple の場合は、スタートアップ タスク実行中はシステムが待機状態になりますので、その場合は、taskType を simple から background に変更してみてください。   background の場合は、非同期に実行されるため、システムが止まることはありません。 また、リモート デスクトップに入ることが出来るようであれば、上記 2. 項で /l*v オプションで指定したログ (2. の例では、C:\sqlncli.log) を確認し、インストールに成功しているか見てみます。 成功している場合は、再度 taskType を simple に戻します。 <Task commandLine="startup.cmd" executionContext="elevated" taskType="background" /> なおインストーラは、失敗した場合も成功時も必ずログを残しますので、ログが出力されていない場合はスタートアップ タスクでインストーラが動作していない可能性があります。

8. 以上の設定をしたのちに、実際に Windows Azure 環境にパッケージをアップロードください。
その後、リモートデスクトップで接続を行い、以下のフォルダの sqlncli1n.dll(n はバージョン) が新しいモジュールに更新されれば構成は成功したことになります。

例) SQL Server Native Client 11.0 の場合 – sqlncli11.dll

(64 bit) D:\Windows\System32\sqlncli11.dll
(32 bit) D:\Windows\SysWOW64\sqlncli11.dll

参考文書  

How to Define Startup Tasks for a Role
http://msdn.microsoft.com/en-us/library/windowsazure/gg456327.aspx

WebRole Schema
→ “Task Element” の項をご参照ください。
http://msdn.microsoft.com/en-us/library/windowsazure/gg557553.aspx#Startup 

おまけ : リモートデスクトップに入るのって、どうするの？（VS2012 編）

0. Windows Azure サービスプロジェクトを Visual Studio で作成し、ロールを追加してプロジェクトが開いたら、ソリューション エクスプローラを下にスクロールし、Windows Azure プロジェクトを右クリックし、[リモート デスクトップの構成(R)] を選択します。

- [すべてのロールの接続を有効にする] チェックボックスをオンにして、ユーザ証明書を指定します。

- リモート デスクトップに接続するアカウント名とパスワードを入力し、[OK] を押します。

1. Visual Studio 上の、[サーバー エクスプローラ] で、[Windows Azure で計算] を展開します。
2. 配置したロール名が展開されるのでさらに展開します。
3. "インスタンス n" (n は数字) を右クリックして、[リモート デスクトップで接続] を選択します。

例)
Windows Azure で計算
  + <プロジェクト名>
   + WebRole1
    - インスタンス0 ← ここを右クリック

4. リモートデスクトップ接続のダイアログが現れます。前の項の手順の 0 で指定したユーザでログインします。

/////////////////////////////

いかがでしたでしょうか。是非、スタートアップ タスク、使ってみてください。

それでは皆さんごきげんよう。

横井 羽衣子
SQL Developer Support Engineer

みなさんごきげんよう。今日は、みんな大好きレポートの大敵「PDF の文字化け」についてです。

以前、弊社森が Reporting Services でエクスポートした PDF における文字化け問題について書いています。これは SQL Server Reporting Services 上のレポート、いわゆるサーバー レポート (*.rdl) についてのお話でしたが、この記事では、意外に気づかないローカル レポート (*.rdlc) について「Report Viewer コントロールは Version 10 ではフォント埋め込み対応してるけど、Version 9 では対応されていない」という件についてと、エクスポート時の文字化けの確認ポイントについて触れたいと思います。

ちなみに、Version 9 は、Visual Studio 2008 付属、Version 10 は Visual Studio 2010 に付属しています。

PDF で文字化けしてしまうときのフォントの扱われ方

まず、レポートをエクスポートするときの動きについておさらいしてみましょう。PDF にする際は、サーバーレポート、クライアント レポートともに、以下のような動きになります。

(1) レポートのエクスポート出力元は、そのマシン上の OS のフォント情報を使い、PDF ファイルをレンダリングします。その際、フォントが埋め込まれない場合、文字識別情報 (グリフ ID) を埋め込みます。

例 : エクスポート出力元は、フォントのグリフ ID 10000 を埋め込む

(2) PDF ファイルにはフォントではなく、フォントを識別する グリフ ID の情報が保持されています。

(3) PDF Viewer (Adobe Reader など) で上記の PDF をクライアントマシン上で表示しようとします。

(4) クライアントでは、PDF 内のグリフ ID に相当する文字をクライアント OS 内のフォント ファイルに一致するものがあるか試みます。

図 : グリフ ID 10000 に合致する文字はこの環境にない

(5) しかし、その環境に合致するグリフ ID がない場合、別の文字が割り当てられてしまいます。結果、合致するグリフ ID がなかった文字は、文字化けしてしまいます。

また、エクスポート出力元と出力先で、同じグリフ ID を保持する場合でも、そのグリフ ID が異なる情報を保持する場合、文字化けします。

PDF を開くマシン上 (クライアントとしましょう) で表示する際、このグリフ ID をクライアント環境のシステムにあるフォントの中から、グリフ ID が合致するもので表示しようとしますが、合致するものがない場合やエクスポート元と異なる情報を保持する場合、人間が読むうえではなんだかよくわからない文字が割り当てられてしまい、結果的に文字化けと言われる解読不明な状況に陥ってしまったりするのです。これが、PDF の出力時の文字化けの動作です。

エクスポートする時レンダリングをするのは「誰」だ？~ ReportViewer のバージョンに注目！

レポートをエクスポートする時、あまり意識しないことですが、問題が発生した時などには大きなポイントになるのが、エクスポートする時レンダリングをするのは「誰」だ？ってところです。実は、この「文字」の情報、どこから来るか、どう扱われるかは、レンダリングする役割の機能が何かによって着目ポイントが変わってくるのです。

大まかにいうと（本当に大まかですが）ファイル出力の処理（フォントの埋め込み方法含む）は、双方以下の相違点があります。

・サーバー レポート : "Reporting Services" がレンダリングを行う。
・ローカル レポート : "ReportViewer コントロール" がレンダリングを行う。

サーバー レポートであり、かつ、以下の条件を満たす場合は、フォント埋め込みがなされます。

(1) Reporting Services がインストールされている環境に、埋め込むためのフォントが用意されていること
(2) レポート中で使用しているフォントが、埋め込みを許可していること
(3) フォントが TrueType であること
(4) 文字列の文字の Font プロパティが ANSI ではなく、Unicode に設定されていること
(5) レポート中で、フォントの Hidden プロパティが True ではないこと
(6) SQL Server 2005 Service Pack 3 以降の Reporting Services であること
(7) レポートの中の文字に日本語が含まれること

ローカル レポートの場合、ReportViewer 9.0コントロールがレンダリングをする場合は、フォント埋め込みがされません。一方、ReportViewer 10を利用した場合は、ローカル レポートにおいても、フォント埋め込みが可能です。

では、これを踏まえて、次は確認ポイントのパターンをみていきましょう。

構成を踏まえた確認ポイントのパターン

文字化けに実際であった場合、最も重要なポイントは、レポートを出力するまでのシステムの構成要素です。それらによって、確認パターンが変わってきます。以下は、代表的な構成と、各構成パターンにおける確認ポイントです。

パターン1 : [Client] – [SSRS + RDL]

→ SSRS によって、PDF にフォントが埋め込まれます。

確認ポイント :

1．SQL Server はフォント埋め込みに対応したバージョンであるか。

> バージョンが対応していない場合、SSRS に埋め込みフォントに対応した修正モジュールを適用します。(SQL Server 2005 の場合、SP3 以降適用)

2. PDF 化の対象レポートはフォント埋め込みの条件を満たしているか。

パターン2 : [Client] – [SharePoint 統合(SSRS + SharePoint) + RDL]

確認ポイント :

1．SQL Server と SharePoint Server は統合されているか。

Ø 統合されている場合、統合のために利用されるモジュールのバージョンを確認し、モジュールの適用が必要となります。

Ø 統合されていない場合、その利用方法を確認し、利用方法に応じた修正モジュールの適用が必要となります。

(※) SQL Server 2005 の場合、SP3 以降適用

2. PDF 化の対象レポートはフォント埋め込みの条件を満たしているか。

パターン3 : [Client] – [Web App + RDLC]

確認ポイント :

1．ReportViewerControl はフォント埋め込みに対応したバージョンであるか。(VS2008 付属の Report Viewer Control Ver.9 は対応していません。)

2. PDF 化の対象レポートはフォント埋め込みの条件を満たしているか。

パターン4 : [Client] – [Web App + Reporting Services]

確認ポイント :

1．SQL Server はフォント埋め込みに対応したバージョンであるか。

> バージョンが対応していない場合、SSRS に埋め込みフォントに対応した修正モジュール（SQL Server 2005 の場合、SP3 以降）を適用します。

2 PDF 化の対象レポートはフォント埋め込みの条件を満たしているか。

> バージョンは対応しているが、フォントの埋め込みが為されない場合、レポートの構造を埋め込みフォントが為されるように変更します。

いかがでしたでしょうか。

レポートをエクスポートした PDF だけを見ていると、文字化けの原因はわかりません。エクスポートした結果の成果物 (PDF など) に至る過程に着目する必要があります。意外に見落としがちで、かつサーバーの管理と開発は別の管轄になることもあると思います。サーバー管理者の方とともに確認を進めていただくとよいこともあるとご参考になれば幸いです。

それではみなさん、ごきげんよう。

2013 年 7 月 26 日時点の SQL Server 最新モジュールです。

SQL Server 2000 は 2013 年 4 月 9 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。

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

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

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

神谷 雅紀
Escalation Engineer

「ログファイルが大きくなってディスク領域を圧迫し始めているので、ファイルサイズを小さくしたい」という内容の問合わせは今でも多く寄せられます。今回は、SQL Server Management Studio GUI を使って、トランザクションログファイルのサイズを小さくする手順を紹介します。

ここに記載した方法で、トランザクションログファイルのサイズを小さくしたいという状況のほとんどに対応可能だと思います。

ここに記載した方法でトランザクションログファイルのサイズを小さくできない場合は、おそらく、トランザクションログファイルのサイズを小さくする前に、レプリケーションやミラーリングのトラブルシューティングなどが必要になるでしょう。

ステップ 1 : データベースの復旧モデルを確認する

復旧モデルが「単純」かそれ以外かによって、以降の手順が違ってきますので、まず最初に、データベースの復旧モデルを確認します。

手順

復旧モデルを確認するために、データベースのプロパティを表示します。データベースのプロパティは、オブジェクトエクスプローラでデータベース名を右クリックし、「プロパティ」をクリックすることで表示できます。

表示されたダイアログボックスの左ペインで「オプション」を選択すると、右ペインに「復旧モデル」が表示されます。復旧モデルは、「単純」「完全」「一括ログ」のいずれかです。

ステップ 2 : トランザクションログをバックアップする

トランザクションログは、データベースファイルへの更新履歴ですので、データベースに対して更新を行うたびにトランザクションログファイルには履歴データが記録され、何もしなければ、トランザクションログファイル内の履歴データはどんどん増えていきます。

復旧モデルが「単純」の場合は、トランザクションログファイル内のデータ量が一定量を超えると、SQL Server がファイルの中身を消し、ファイル内に空き領域を作り、空いた領域は再利用されます。

一方、復旧モデルが「完全」または「一括ログ」に設定されている場合は、過去に一度でもデータベースの完全バックアップ (データベースフルバックアップ) を取得していると、SQL Server はファイルの中身を消すことはしませんので、トランザクションログファイル内のデータは、バックアップしなければ削除されません。

このステップ 2 は、復旧モデルが「完全」または「一括ログ」の場合のみ行います。「単純」の場合は、次のステップ 3 に進みます。

手順

データベースを右クリックし、「タスク」 -  「バックアップ」をクリックします。

「バックアップの種類」として「トランザクションログ」を選びます。もし、復旧モデルが「単純」に設定されている場合は、「トランザクションログ」は選択できません。

「バックアップセットの有効期限」は既定のまま、「バックアップ先」は、バックアップデータを書き込むファイル名を指定します。「ディスク」を指定して、「追加」でファイル名を指定して下さい。そのサーバーにテープデバイスがある場合には、「テープ」を選んでも構いません。

最後に「OK」を押すと、バックアップが開始されます。

ステップ 3 : トランザクションログファイルのサイズを小さくする

バックアップにより、トランザクションログファイルの中身を消したとしても、ファイル自体のサイズは小さくなりません。

ファイル内に空きがなくなれば、データを書き込むために再びファイルサイズを大きくしなければなりません。当然、ファイルサイズを変更するためには、メモリも CPU も使いますし、ある程度は時間もかかります。そのため、パフォーマンスの観点からは、トランザクションログファイルには、常に空き領域がある状態を保つ方が理想的です。ディスクの空き領域の問題などにより、ファイルを小さくしなければならない場合は、可能な限り小さくするというよりも、ある程度の余裕を持ったサイズにした方がいいでしょう。

手順

データベースを右クリックし、「タスク」、「圧縮」、「ファイル」の順にクリックします。

「ファイルの種類」は「ログ」、「ファイル名」は、大きくなってしまったトランザクションログファイルの論理名、「圧縮アクション」として「未使用領域の解放前にページを再構成する」を選択し、ファイルサイズの目標となるサイズを MB 単位で指定します。このサイズは目標サイズであるため、必ずしも、そのサイズまで小さくできるとは限りません。

この手順を実施してもトランザクションログファイルが小さくならない場合

これら 3 ステップを実施することで、トランザクションログファイルのサイズは小さくできるはずですが、小さくならない場合は、ステップ 1 ～ 3 をもう一度繰り返してみて下さい。

もし、それでも小さくならない場合は、そのほとんどは、以下のいずれかが原因です。(これ以外にも原因となるものはありますが、それらは長時間存在し続けるものではないため、通常、上の手順を繰り返し行えば必ずファイルは小さくなります。)

• 実行中のトランザクションがある場合
• トランザクションレプリケーションが構成されていて、まだ配布されていないトランザクションがある場合
• データベースミラーリングが構成されていて、まだ配信されていないトランザクションがある場合
• CHECKPOINT が実行されていない場合

実行中のトランザクションがある場合

実行中のトランザクションの有無は、GUI ではなく DBCC OPENTRAN コマンドにより確認します。

確認手順

[新しいクエリ] ボタン、もしくは、[ファイル] メニューの [新規作成] – [クエリを現在の接続で実行] から、Management Studio のクエリウィンドウを開き、以下を実行します。

DBCC OPENTRAN(‘データベース名’)

例 : DBCC OPENTRAN('AdventureWorks')

以下は、実行中のトランザクションがない場合の DBCC OPENTRAN 実行結果の例です。この場合、トランザクションログファイルが小さくならない原因は、実行中のトランザクションがあるからではありません。他の原因を確認する必要があります。

開かれたアクティブなトランザクションがありません。

以下は、実行中のトランザクションがある場合の DBCC OPENTRAN 実行結果の例です。この場合、トランザクションログファイルが小さくならない原因は、実行中のトランザクションがあるからです。トランザクションログファイルを小さくするためには、このトランザクションを終了した後に、ステップ 1 ～ 3 を実行する必要があります。

データベース 'AdventureWorks' のトランザクション情報。 最も古いアクティブなトランザクション: SPID (サーバー プロセス ID): 51 UID (ユーザー ID) : -1 名前 : user_transaction LSN : (43:2238:2) 開始時刻 : 12 12 2011 7:43:41:553PM SID : 0x0105000000000005150000005d28f57fd53ad8354354e02a481c0000

上で確認した SPID を使って以下のクエリを実行すると、このトランザクションを実行しているクライアントプロセスが実行されているマシン名やプログラム名、ログインユーザ名、PID 等を確認することができます。

select * from sys.dm_exec_sessions where session_id=上で確認した spid

例 : select * from sys.dm_exec_sessions where session_id=51

 

対処方法

実行中のままになっているトランザクションの実行元マシン、アプリケーション名、PID などを確認できたら、そのアプリケーションがなぜトランザクションをずっと実行中のままなのかを確認しましょう。それが、正常と考えられる状況であれば、そのまま放置し、アプリケーションが処理を完了するのを待ちます。それが異常と考えられる状況であれば、アプリケーションを終了することで、トランザクションも終了させます。

もし、トランザクションを実行しているアプリケーションに対する操作ができないような場合には、以下を実行することで、SQL Server 側からこのトランザクションを強制的に終了させることも可能です。ただし、これを行うと、アプリケーション側ではエラーを受け取り、トランザクションはロールバックされます。

手順

オブジェクトエクスプローラで対象 SQL Server インスタンスを右クリックし、「利用状況モニタ」を起動します。

上で確認した SPID を右クリックし、「強制終了」をクリックします。

もう一度 DBCC OPENTRAN を実行して実行中のトランザクションがなくなっていることを確認後、再度ステップ 1 ～ 3 を実行します。

トランザクションレプリケーションが構成されていて、まだ配布されていないトランザクションがある場合

確認手順

[新しいクエリ] ボタン、もしくは、[ファイル] メニューの [新規作成] – [クエリを現在の接続で実行] から、Management Studio のクエリウィンドウを開き、以下を実行します。

DBCC OPENTRAN(‘データベース名’)

例 : DBCC OPENTRAN('AdventureWorks')

以下は、トランザクションレプリケーションの未配布トランザクションがない場合の、DBCC OPENTRAN 実行結果の例です。この場合、トランザクションログファイルが小さくならない原因は、トランザクションレプリケーションの未配布トランザクションがあるからではありません。

開かれたアクティブなトランザクションがありません。

以下は、トランザクションレプリケーションの未配布トランザクションがある場合の、DBCC OPENTRAN 実行結果の例です。この場合、トランザクションログファイルが小さくならない原因は、トランザクションレプリケーションの未配布トランザクションがあるからです。トランザクションログファイルを小さくするためには、この未配布トランザクショントランザクションを配布した後に、ステップ 1 ～ 3 を実行する必要があります。

データベース 'AdventureWorks' のトランザクション情報。 レプリケートされたトランザクション情報: 配布された最も古い LSN : (39:46:1) 配布されなかった最も古い LSN : (39:47:1)

ここで言う「配布 (distribution/distribute)」とは、ログリーダーエージェントが、パブリケーションデータベースのトランザクションログからトランザクションログを読み取り、読み取ったトランザクションの内容をディストリビューションデータベースに格納することです。

対処方法

配布されていないトランザクションがパブリケーションデータベースにある場合、それは、ログリーダーが正しく動いていない、もしくは、動けていないことが原因です。トランザクションログファイル内の未配布トランザクションを配布してトランザクションログファイルのサイズを小さくするためには、ログリーダーが動かない原因を排除して、レプリケーションを再開することが必要です。

手順

レプリケーションの状態を確認するために、[レプリケーション] を右クリックし、「レプリケーションモニタ」を起動して、レプリケーションの状態を確認してみましょう。

レプリケーションモニタでエラーが確認できる場合、「サブスクリプション ウォッチリスト」内の行をダブルクリックして、エラーの詳細が確認できます。

発生している可能性のあるエラーはいろいろとあるので、ここではその解決方法までは伝えられませんが、発生しているエラーの原因を特定して、その原因を排除し、レプリケーションを再開した後にステップ 1 ～ 3 を実行すれば、トランザクションログファイルのサイズを小さくすることができます。

データベースミラーリングが構成されていて、まだ配信されていないトランザクションがある場合

データベースミラーリングもトランザクションレプリケーションと同様にトランザクションログをベースとした機能です。プリンシパルサーバーからミラーサーバーへのトランザクション配信が行えなくなると、配信が可能になった時にミラーリングを再開できるように、プリンシパルサーバー上のトランザクションログは、バックアップをしても削除されなくなります。この場合は、ミラーリングを再開することが、トランザクションログファイルのサイズを小さくするために必要なことです。

確認手順

ミラーリングの状態は、Management Studio のオブジェクトエクスプローラで確認することができます。

上の画像のように、「同期済み」となっている場合には、トランザクションログファイルが小さくならない原因は、ミラーリングではありません。

それ以外の場合、ミラーリングが原因である可能性があります。

対処方法

「同期中」である場合は、しばらく待った後、再度ミラーリングの状態を確認して下さい。

「接続解除」である場合は、ミラーサーバーが起動しているかどうかを確認して下さい。起動していない場合は、起動して下さい。
起動している状態でも「接続解除」になっている場合は、ping により、ネットワーク接続に問題がないかどうかを確認して下さい。ping が通る場合は、プリンシパルサーバー上で Management Studio や sqlcmd.exe から、ミラーサーバーとなっている SQL Server へ接続できるかどうか確認して下さい。これらのテストに失敗する場合は、名前解決を含むネットワークの問題やファイアウォールの設定の問題である可能性があるため、ネットワークやファイアウォールの設定を見直して下さい。

プリンシパル上の Management Studio や sqlcmd を用いてミラーサーバーに接続できる場合、プリンシパルサーバー上の SQL Server Errorlog (SQL Server 2008 R2 既定インスタンスの場合 C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log 下の Errorlog ファイル) を参照し、エラーの原因を突き止める必要があります。

ミラーリングの状態が「同期済み」となれば、ステップ 1 ～ 3 を実行することで、トランザクションログファイルのサイズを小さくすることができます。

sync with backup オプションが ON に設定されているディストリビューションデータベースのバックアップが行われていない場合

ディストリビューションデータベースの sync with backup オプションが有効になっている場合、トランザクションレプリケーションのパブリケーションデータベースでは、トランザクションログバックアップを行ったとしても、ディストリビューションデータベースのフルデータベースバックアップが完了するまではトランザクションログは切り捨てられません。

対処方法

ディストリビューションデータベースのフルデータベースバックアップを行います。ディストリビューションデータベースのフルデータベースバックアップ完了後、パブリケーションデータベースのトランザクションログバックアップを行います。

スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式

http://msdn.microsoft.com/ja-jp/library/ms152560.aspx

CHECKPOINT が実行されていない場合

これが原因になることはほとんどありませんが、復旧モデルが「単純」で上のステップ 1、3 を実行してもトランザクションログファイルサイズが小さくならない場合は、Management Studio のクエリウィンドウを開き、トランザクションログファイルのサイズを小さくしたいデータベースに変更した後に、CHECKPOINT コマンドを実行して下さい。

対処方法

以下の例は、AdventureWorks データベースのトランザクションログファイルを小さくしたい場合に実行する CHECKPOINT コマンドの実行例です。

対象データベースを選択し、そのデータベース上で実行することがポイントです。

その後、ステップ 3 を再実行して下さい。

山田 浩史
SQL Engine Support Engineer

みなさん、こんにちは。今回は、Windows Azure SQL Database を使用していると直面しうるエラーについて紹介します。

現象：
SQL Server Management Studio(SSMS) を使用して SQL Database 上のデータベースに対してスクリプト生成を行うとエラーで失敗する。

エラーレポートを確認すると以下のエラーが出力されている。

------
名前：
 'test_database' からオブジェクトの一覧を取得しています。

結果：
失敗

メッセージ：
     Microsoft.SqlServer.Management.Sdk.Sfc.EnumeratorException: この要求のデータを取得できませんでした。
---> Microsoft.SqlServer.Management.Sdk.Sfc.InvalidVersionEnumeratorException: バージョン 11.0 ではサポートされていない操作。
場所 Microsoft.SqlServer.Management.Smo.XmlReadDoc.LoadFile(Assembly a, String strFile)
場所 Microsoft.SqlServer.Management.Smo.SqlObject.LoadInitDataFromAssemblyInternal(Assembly assemblyObject, String file, ServerVersion ver, String alias, StringCollection requestedFields, Boolean store, StringCollection roAfterCreation, DatabaseEngineType databaseEngineType)
場所 Microsoft.SqlServer.Management.Smo.SqlObject.LoadInitData(String file, ServerVersion ver, DatabaseEngineType databaseEngineType)
場所 Microsoft.SqlServer.Management.Sdk.Sfc.ObjectCache.LoadElement(ObjectLoadInfo oli, ServerVersion ver, DatabaseEngineType databaseEngineType)
場所 Microsoft.SqlServer.Management.Sdk.Sfc.ObjectCache.GetElement(ObjectLoadInfo oli, ServerVersion ver, DatabaseEngineType databaseEngineType)
場所 Microsoft.SqlServer.Management.Sdk.Sfc.ObjectCache.GetAllElements(Urn urn, ServerVersion ver, DatabaseEngineType databaseEngineType)
場所 Microsoft.SqlServer.Management.Sdk.Sfc.Environment.GetObjectsFromCache(Urn urn, Object ci)
場所 Microsoft.SqlServer.Management.Sdk.Sfc.Environment.GetData(Request req, Object ci)
場所 Microsoft.SqlServer.Management.Sdk.Sfc.Enumerator.GetData(Object connectionInfo, Request request)
場所 Microsoft.SqlServer.Management.Sdk.Sfc.Enumerator.Process(Object connectionInfo, Request request)
--- 内部例外スタック トレースの終わり ---
場所 Microsoft.SqlServer.Management.SqlScriptPublish.GeneratePublishPage.worker_DoWork(Object sender, DoWorkEventArgs e)
場所 System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
場所 System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
------

原因：
製品の不具合です。
本現象は以下の 2 つの条件を満たす場合に発生します。

    ・SSMS のバージョンが 11.00.3000 未満の場合(※1)
    ・SQL Database のデータベースの照合順序がデフォルトの "SQL_Latin1_General_CP1_CI_AS" 以外に設定されている場合(※ 2)

※1 SSMS のバージョンは、[ヘルプ] - [バージョン情報] から確認出来ます。
※2 データベースの照合順序は以下のクエリにて確認出来ます。
      SELECT name, collation_name FROM sys.databases

対処方法：
本現象は下記サイトで提供している、SSMS 2012 SP1 (11.00.3000) にて修正されています。
そのため、こちらのバージョンより新しい SSMS を使用することで本現象は回避出来ます。

例：

    Microsoft SQL Server 2012 Service Pack 1 (SP1) Express
    http://www.microsoft.com/ja-jp/download/details.aspx?id=35579
 

補足：
今回のエラーは、SSMS より "データ層アプリケーションの抽出" や "データ層アプリケーションのエクスポート" を実施した際にも発生する可能性のあるエラーです。
対処策は同様ですので、最新のサービスパックを適用した SSMS を使用してください。

なお、2013年7月31日時点での SQL Server 2012 の最新のサービスパックは、Service Pack 1 です。

神谷 雅紀
Escalation Engineer

最近 recovery interval オプションが何を指定しているオプションであるのかはっきりしないという話がありましたので、今回は recovery interval について説明したいと思います。

データベースの復旧とは？

recovery interval は、Books Onlineにも記載があるとおり、データベースの復旧に必要な時間の上限を指定するオプションです。では、データベースの復旧とは何でしょうか？

データベースの復旧 (英語では recovery) とは、未完了のトランザクションの取り消し (ロールバック / roll back) と、データファイルに反映されていない完了済みトランザクションのデータファイルへの反映 (ロールフォワード / roll forward) を行う処理です。

※ ハードウェアエラーなどにより壊れてしまったデータベースを修復する (repair) ことやバックアップからデータベースを復元する (restore) ことではありませんのでご注意下さい。

データベース復旧は、データベースの開始時に自動的に行われます。データベース復旧においてロールバックやロールフォワードしなければならないトランザクションの数は、データベースシャットダウン時に実行されていたトランザクション量とデータベースファイルへの書き出しが行われてから実行された更新量に依存します。

データベースへの書き出し処理は CHECKPOINT と呼ばれ、自動 CHECKPOINT は、ユーザー処理とは非同期にバックグラウンドタスクとして実行されています。

例えば、図 1 のように、データベースのシャットダウン直前に 4 つのトランザクションが実行されていたとします。トランザクション 1 は最後の CHECKPOINT 後に Commit、トランザクション 2 は最後の CHECKPOINT 後に Rollback、トランザクション 3 はデータベースシャットダウン時にはまだ実行中で Commit も Rollback もされておらず、トランザクション 4 は最後の CHECKPOINT よりも前に Commit されている状態であったとします。

<図 1>

このようにしてシャットダウンされたデータベースを開始すると、図 2 のようにデータファイルは最後の CHECKPOINT が実行された時の状態になっています。

<図 2>

この状態から、トランザクションの原子性 (atomicity) と永続性 (durability) が保たれ、一貫性のある状態 (consistency) にするためには、図 3 のように、トランザクション 1 については、前回の CHECKPOINT 後に行われた更新をデータファイルに反映するためにロールフォワードし、トランザクション 2 と 3 については、トランザクション全体をロールバックしなければなりません。

※ ACID (atomicity, consistency, isolation and durability) については、Books Onlineや Wikipediaなどを参照して下さい。

 

<図 3>

その結果、データベースには、トランザクション 1 と 4 の更新結果が反映され、トランザクション 2 と 3 は取り消された状態になり、前回データベースがシャットダウンされた時の状態となります。

この図 3 で示されているロールバックとロールフォワードの処理が、データベース復旧処理です。

データベース復旧が完了すると、データベースは利用可能な状態 (オンラインの状態) になります。

recovery interval は何を指定しているのか？

実際には、トランザクションは、その分離性および独立性 (isolation) を維持するために直列化されていますので、実際のデータベース復旧は図 4 のように複数のトランザクションが直列化された状態で行われます。このデータベース復旧に必要となる予想時間の最大時間を指定するためのオプションが recovery interval です。

<図 4>

ただし、データベースシャットダウン時に実行中であったトランザクションのロールバックにかかる時間は考慮されません。正確に言えば、考慮されないのではなく、そのようなトランザクションのロールバックは、実行されるトランザクションに依存するため、制御することができません。

例えば、recovery interval の値が既定値であっても、データベースシャットダウン時に、開始から 10 時間経過している実行中の更新トランザクションがあった場合には、次回データベース開始時の復旧では、そのトランザクションのロールバックに 10 時間必要になる場合もあります。

尚、Enterprise エディションであれば、高速復旧 (fast recovery) と呼ばれる機能により、そのようなロールバックが完了する前にデータベースはオンラインになり、ロールバック中にアクセスされるデータ以外へのアクセスは可能になります。

recovery interval の変更は何に作用するのか？

データベース復旧は、前回の CHECKPOINT 以降に行われた変更を再実行する処理であるため、CHECKPOINT 以降に行われた変更が多ければ多いほど、処理に必要な時間が長くなります。つまり、データベース復旧にかかる時間は、CHECKPOINT の頻度に左右されることになり、データベース復旧にかかる最大時間を指定する recovery interval の設定値は、「どの程度の更新が行われると CHECKPOINT を実行するか」を制御する値ということになります。

つまり、recovery interval の値を大きくすると、CHECKPOINT の間隔は長くなり、小さくすると短くなります。(図 5 の赤や黄色の○はトランザクションでの更新を表しています。)

<図 5>

recovery interval 変更時の考慮事項

recovery interval の値を大きくすると、CHECKPOINT の間隔が長くなるため、一般的に、一度の CHECKPOINT で書き出されるデータ量は多くなります。その結果、CHECKPOINT 時にディスク負荷が高くなる可能性があります。

追加情報 : さらに詳細な調整を行う方法

recovery interval 構成オプション以外にも CHECKPOINT を制御するための方法が提供されています。-k 起動パラメータや ALTER DATABASE SET TARGET_RECOVERY_TIME (SQL Server 2012 以降) がそれです。より短い CHECKPOINT 間隔が必要な状況や CHECKPOINT により書き出されるデータ量を調整したい場合には、これらの機能を使用することができます。

2013 年 7 月以前の Windows Azure の ゲスト OS には、SQL Server 2008 Native Client (以下 SQLNCLI10)が含まれていましたが、7 月リリースの Azure ゲスト OS (バージョン 1.24 / 2.16 および 3.4) には、SQL Server 2012 Native Client (以下 SQLNCLI11) に置き換えられました。SQL Databaseに接続するクライアント アプリケーションにおいて Azure ゲスト OS に含まれる SQLNCLI10を使用していた場合、この変更によってデータソース接続ができなくなり、例外がスローされるなどの問題が発生することになります。

問題

Azure ゲスト OS に含まれる SQLNCLI10を使用してデータベースを使用する Windows Azure アプリケーションにおいて、Azure ゲスト OS をアップグレードした後、データベースに突然接続できなくなるという現象が発生します。エラーメッセージは以下の通りです。

ODBC の場合

ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
ERROR [IM002] [Microsoft][ODBC Driver Manager] データ ソース名および指定された既定のドライバが見つかりません。

OLEDB の場合(※下記Note : OLEDB の接続について参照)

The 'SQLNCLI10' provider is not registered on the local machine.
'SQLNCLI10' プロバイダーはローカルのコンピュータに登録されていません。
 
PHP:
Error establishing a Database Connection
The connection has timed out – the server at XXXXXXXX.database.windows.net is taking too long to respond.

Note : OLEDB の接続について

SQL Azure でサポートされるドライバー、プロバイダーについて http://msdn.microsoft.com/ja-jp/windowsazure/hh977108.aspx OLE DB を使用して、SQL Azure へ接続することはサポートされません。ADO OLE DB をベースに開発された API や開発言語を使用されている場合には、注意する必要があります。

要因

2013 年 7 月以前の Windows Azure ゲスト OS には、SQLNCLI10 が含まれていました。 しかし、7 月以降の、Windows Azure ゲスト OS には SQLNCLI11 と差し替えられました。 ODBC および OLEDB における接続文字列には、基本的に以下のように SQLNCLI のバージョンを明記しますが、これにより以前のバージョン 10 が指定されているアプリケーションでは、Azure ゲスト OS 上にモジュールがないため接続処理を呼び出すことが出来ず、問題が発生します。

例) SQL Server 2008 Native Client ODBC Driver を接続文字列中でを指定している場合
Driver={SQL Server Native Client 10.0};Server=tcp:[serverName].database.windows.net;Database=myDataBase;Uid=[LoginForDb]@[serverName];Pwd=myPassword;Encrypt=yes;

例) SQL Server 2008 Native Client OLE DB Provider を接続文字列中でを指定している場合
Provider=SQLNCLI10;Password=myPassword;User ID=[username]@[servername];Initial Catalog=databasename;Data Source=tcp:[servername].database.windows.net;

影響があるゲスト OS のバージョン

ご利用のゲスト OS に含まれる SQLNCLI のライブラリのバージョンを確認する

リモートデスクトップでログインし、以下のいずれかの方法で確認することが可能です。

• D:\Windows\System32 フォルダに移動し、以下を確認します。
  > sqlncli10.dll がある場合 : SQLMCLI10の環境です。
  > sqlncli11.dll がある場合 : SQLMCLI11の環境です。

• コントロール パネルの「プログラムと機能」を開き、以下を確認します。
  > Microsoft SQL Server 2008 Native Client がある場合 : SQLMCLI10の環境です。
  > Microsoft SQL Server 2012 Native Client がある場合 : SQLMCLI11の環境です。

問題の影響を受けるか判断するには   
・データベース接続文字列で、"Driver=" もしくは "Provider=" があれば、そこで "SQLNCLI10" を指定しているか、あるいは "SQLNCLI11" というキーワードを使用しているかを確認することで判断することが出来ます。
・PHP / Wordpress の場合は、PHP のログを確認します。ログ中で、"sql" という文字列を探します。この文字列を含む場合、SQLNCLI10を使用していることになります。

Note : System.Data.SqlClient (System.Data.dll) を使用している場合

.NET Framework アプリケーションでデータアクセス処理を含む場合、コード中で System.Data.SqlClient (System.Data.dll) を使用している場合は、SQLNCLI ではなく、.NET Framework Data Provider for SQL Server を使用しています。従って、この場合今回のモジュール差し替えの影響は受けません。

対処方法  

対処方法は以下のうち、いずれかとなります。

・SQLNCLI10 を含む以前のゲスト OS に戻します。 (June release – versions 1.23, 2.15, 3.3 以前)
この操作は、Windows Azure 管理ポータルから実行するか、あるいは OS の構成を含むサービス定義ファイルをアップロードすることによって実行します。
しかしこれはあくまでも一時的な対処になります。6 月以前の Azure Guest OS において、SQLNCLI10 同梱はいずれ廃止される予定です。

・Database への接続文字列を SQLNCLI11に変更します。
これは最もシンプルな対応方法になる場合があります。 接続文字列中のドライバの指定を以下のように "SQLNCLI10" から "SQLNCLI11" に変更するだけだからです。ただし、接続テストなど、必ず動作検証を実施ください。

例)
Provider=SQLNCLI10;Password=myPassword;User ID=[username]@[servername];Initial Catalog=databasename;Data Source=tcp:[servername].database.windows.net;
↓
Provider=SQLNCLI11;Password=myPassword;User ID=[username]@[servername];Initial Catalog=databasename;Data Source=tcp:[servername].database.windows.net;

参考 : http://www.connectionstrings.com/sql-azure/

・PHP の場合、PHP 用 SQL ドライバをバージョン 3.0 以降にします。
参考 : http://www.microsoft.com/en-us/download/details.aspx?id=20098

・SQLNCLI 10 をダウンロードし、スタートアップ タスクに含めてアプリケーションの配置時に構成されるようにする。(※下記Note : スタートアップタスクに SQLNCLI10 など必要なモジュールを含める方法参照)
SQLNCLI は、サイドバイサイドで構成可能なため、SQLNCLI10 と SQLNCLI11が同じ環境に共存することが出来ます。
配置済みのアプリケーションを更新する際は、インプレース アップグレードか、VIP SWAP のいずれかで再配置を行うことが出来ます。

Note : スタートアップタスクに SQLNCLI10 など必要なモジュールを含める方法

以前以下のブログで対応方法をご案内しています。 ご参考になれば幸いです。 Windows Azure で、Web ロールで特定のバージョンの SQL Server Native Client を常に使えるようにする方法 http://msdn.microsoft.com/ja-jp/windowsazure/hh977108.aspx

参考情報

こちらは、Windows Azure - Troubleshooting & Debugging ブログの以下記事をベースに公開しています。原文はこちらを参照ください。

Compatibility Issue - SQL Azure connectivity using the SQL Native Client may break after the July release of the Windows Azure Guest OS

http://blogs.msdn.com/b/kwill/archive/2013/08/01/compatibility-issue-sql-azure-connectivity-using-the-sql-native-client-may-break-after-the-july-release-of-the-windows-azure-guest-os.aspx

SQL Server Developer Support

藤丸陽子

はじめに

Analysis Services トレースファイルを採取することで、Analysis Services に対して発行されたクエリや処理状況が確認できます。

また、エラーが発生した際の処理状況を確認することで、原因や対処を見つけやすくなります。

そこで、今回は Analysis Services のトレース ファイルを採取する方法をご案内したいと思います。

Analysis Services 2005 以降、Analysis Services 2012 まですべて同じ方法で採取可能ですので是非ご活用下さい。

手順概要

Analysis Services サーバトレースの使用は、大きく分けて以下の 3 つの作業に分けられます。

- 作業 1-1. スクリプト準備

- 作業 1-2. スクリプト実行

- 作業 1-3. スクリプト停止

作業手順

作業 1-1. スクリプト生成

以下の手順で、XMLA スクリプトを準備します。

(1)  StartDetailedProfilerTrace.xmlaを作成します。

詳細のイベントを採取するよう設定した、StartDetailedProfilerTrace.xmla は http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-43-18-ASTrace/4186.ASTrace.zipからダウンロードできます。

ダウンロード後、任意のテキストエディタもしくは SQL Server Management から紫の箇所を環境に併せて、適宜変更します。 次の設定は AS_ProfilerTraceとして、ログファイルの最大サイズを 255 MBで、ロールオーバーの上、D:\AS_ProfilerTrace.trcトレースを生成します。また、Analysis Services サービスの再起動時も、自動的にトレースが再実行する例となっています。

補足

------

StartDetailedProfilerTrace.xmlaを環境に併せて変更する箇所は次の通りです。

下記をそれぞれご利用に 合わせ変更し、保存します。

LogFileName

~~~~~~~~~~~

Log ファイルを保存するファイルのフルパスを指定下さい。 なお、指定する際、ファイルの拡張子は .trc と指定します。

例) <LogFileName>D:\AS_ProfilerTrace.trc</LogFileName>

*1 指定するイベントとサーバ で実行される処理量、監視期間によって大量のデータがファイルに出力される可能性があります。

LogFileSize

~~~~~~~~~

Log ファイルの最大値を MB 単位にて指定できます。

Log ファイルのサイズが指定したサイズに到達すると Log ファイルはロールオーバします。

例) <LogFileSize>100</LogFileSize>

LogFileRollover

~~~~~~~~~~~~

1 を指定した場合はログファイル をロールオーバする指定になります。

例) <LogFileRollover>1</LogFileRollover>

ロールオーバーとは、ファイルサイズが 255 MB に達すると、ファイルの上書きをせず新しくファイルを生成し、そのファイルにログを書き込む動作を意味します。新しく作成したファイル名は、例えば AS_ProfilerTrace1.trc、AS_ProfilerTrace2.trc、AS_ProfilerTrace3.trc などファイル名の末尾に番号がついた名前となります。

AutoRestart

~~~~~~~~~~~

1 を指定した場合は SSAS が再起動した際にもトレースが再実行されます。

例) <AutoRestart>1</AutoRestart>

トレースファイルは、十分余裕のあ るディスクに対して保存ください。

作業 1-2. スクリプト実行

以下の手順でスクリプトを実行しま す。

(1) SQL Server Management Studio を起動し、Analysis Services に接続します。

(2) [ファイル]-[開く]-[ファイル] を選択します。

(3) 作業 1-1 で作成した StartDetailedProfilerTrace.xmlaを選択します。

(4) XMLA クエリを実行 します。

作業 1-3. スクリプト停止

(1)  StopProfilerTrace.xmlaをサイト http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-43-18-ASTrace/4186.ASTrace.zip

よりダウンロードします。

TraceID に指定する値は、トレース StartDetailedProfilerTrace.xmlaに指定した <Trace><ID> の値となります。

(2)  SQL Server Management Studio を起動し、Analysis Services に接続します。

(3) [ファイル]-[開く]-[ファイル] を選択します。

(4)  StopProfilerTrace.xmla を開きます。

(5) XMLA クエリを実行 し、Analysis Services トレースを停止します。

(6) 生成された .trc ファイルを採取します。

.trc ファイルは、 トレースを開始した、StartDetailedProfilerTrace.xmla  内の <LogFileName>に指定したパスに存在します。

採取した .trc ファイルは SQL Server プロファイラツールより確認ができます。

Analysis Services トレースファイルを取得することで、エラーが発生した際の処理状況が確認できますので是非ご活用下さい。

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

今回は、SQL Server 2012 に関するお問い合わせの中で、よくあるお問い合わせの一つを紹介したいと思います。

[質問]

SQL Server 2012 の BCP ユーティリティ を使用し、テーブル上のデータをエクスポートした場合、 以下の警告が毎回 発生する。

コマンドプロンプト から BCP ユーティリティ で テーブル上のデータをエクスポートする際、 –o オプション や –e オプション を使用し、エラーや警告の発生有無により、処理が正常に完了しているかを判断しているが、毎回 警告が発生するため、処理の正常有無を判断することができない状態となっている。

この警告を出さないようにする方法があるか？ 

[回答]

この警告を出力させないようにする方法はありません。

SQL Server 2012 BCP ユーティリティでは、テーブル列に NULL 値を含む テーブルをエクスポートした場合、この警告が出力されるようになりました。

そのため、SQL Server 2012 BCP ユーティリティ で テーブル列に NULL 値を含む テーブルをエクスポートした場合は、この警告が出力されることになります。

なお、バッチファイルから BCP ユーティリティを実行後、エラーや警告の何れかがログに出力されたことを検知し、処理が正常に完了していないと判断している場合は、BCP の処理自体は正常に完了していたとしても、SQL Server 2012 BCP ユーティリティでは警告が発生する場合があることに起因し、処理が正常に完了していないと判断されてしまうことが予測されます。

そこで、SQL Server 2012 BCP ユーティリティを使用する場合、少し複雑にはなりますが、以下に記載しましたバッチ例のようにエラー判定を実施することにより、今回の警告のみが出力されている場合は、BCPの処理は正常に完了していると判断することが可能となります。

---

ECHO OFF

SET iErrorCnt=0
SET iWarnCnt=0

: BCP 処理を記載 :
BCP.exe BCP.dbo.tab1 out e:\temp\tab1.dat -T -t, -w -oE:\temp\bcp_tab1.log

: BCP 処理で出力されたログの中から "SQLState" を検索し、ヒットした件数を保持
FOR /f %%a IN ('findstr "SQLState" E:\temp\bcp_tab1.log’) DO SET /a iErrorCnt=iErrorCnt+1

: BCP 処理で出力されたログの中から "警告" を検索し、ヒットした件数を保持
FOR /f %%b IN ('findstr "警告" E:\temp\bcp_tab1.log') DO SET /a iWarnCnt=iWarnCnt+1

: エラー判定処理 :
IF %iErrorCnt% GTR 0 IF %iWarnCnt%  == 0 GOTO ERR_MSG
IF %iErrorCnt% GTR 1 GOTO ERR_MSG

Exit

:ERR_MSG

森  隆博
SQL Developer Support Engineer

みなさんは、SQL Server Reporting Services 2008 以降のバージョンを使用していて、イベントログにこんなエラーメッセージが記録されたことはありませんか？
Reporting Services のインストール直後や Reporting Services のサービスを再起動したりしたときにイベントログに記録されることがあるエラーです。 

または SharePoint 統合モードの SQL Server 2012 Reporting Services を使用していて、このようなエラーがイベントログに記録されたことはありませんか？  
SharePoint 統合モードの場合、レポートデータソースの「接続テスト」や「OK」ボタンをクリックすると、イベントログに以下のエラーが記録されることがあります。

 
■イベントログの詳細 

 今回は、このエラーについて説明します。

エラーの説明
Reporting Services は Teradata と連携するために拡張機能を用意しています。
予め、Reporting Serices の構成ファイルには Teradata と連携するための拡張機能の記述が用意されているものの、実際の Teradata アセンブリは SQL Server または .NET Framework に付属していないために記録されるエラーです。

このエラーが記録されたとしても、Reporting Services の動作には問題はありません。
このため、このエラーは無視しても問題ないものですが、エラーの記録を止めたい場合、以下の対処方法が有効です。

対処方法（Reporting Services ネイティブモード、SharePoint 統合 RS 2008 R2 までの場合）

Teradata 拡張機能によって提供される機能が必要かどうかによっていずれかを選択できます。

・Teradata 拡張機能によって提供される機能が不要な場合： [A. 構成ファイルを変更する方法] をご覧ください。
・Teradata 拡張機能によって提供される機能が必要な場合：[B  .NET Data Provider for Teradata をインストールする方法] をご覧ください。

A 構成ファイルを変更する方法
(1) 構成ファイルを探します。
SQL Server 2008 R2 を例にすると既定の構成ファイルのパスは以下の通りです。

C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config

(2) rsreportserver.config を別名でコピーしてバックアップを取ります。

(3) Reporting Services 構成ファイルを変更します。

構成ファイル内を TERADATA キーワードで検索し、下記それぞれの要素配下の Extension Name="TERADATA" の要素をすべてコメントアウトもしくは削除してください。

------------------------------------
<Data> 要素配下
<Extension Name="TERADATA" Type="Microsoft.ReportingServices.DataExtensions.TeradataConnectionWrapper,Microsoft.ReportingServices.DataExtensions"/>

<SemanticQuery> 要素配下
<Extension Name="TERADATA" Type="Microsoft.ReportingServices.SemanticQueryEngine.Sql.Teradata.TdSqlSQCommand,Microsoft.ReportingServices.SemanticQueryEngine">

<ModelGeneration> 要素配下
<Extension　Name="TERADATA" Type="Microsoft.ReportingServices.SemanticQueryEngine.Sql.Teradata.
TdSqlModelGenerator,Microsoft.ReportingServices.SemanticQueryEngine"/>
------------------------------------

(4) 構成ファイルを変更した後 Reporting Services サービスを再起動します。

B .NET Data Provider for Teradata をインストールする場合
将来的に Teradata データベースを利用される��能性がある場合は、.NET Data Provider for Teradata (version 12以降) をインストールすることでエラーが回避できます。
.NET Data Provider for Teradata は、Teradata 社のサイトにてご入手ください。

Teradata .NET Data Provider
http://downloads.teradata.com/download/connectivity/dot-net-data-provider

参考情報
構成上の問題のトラブルシューティング："TERADATA レポート サーバー拡張機能のインスタンスを生成中に例外が発生しました
 

対処方法（Reporting Services 2012 以降の SharePoint 統合 RS の場合）
Reporting Services 2012 SharePoint 統合モードの場合、拡張機能は SharePoint 管理シェルで管理しています。
SharePoint 管理シェル コマンドで拡張機能のリストと無効化を行うことができます。

(1) 管理シェルを起動します。


(2) 以下のコマンドを実行します。

    $apps = Get-SPRSServiceApplication
    Get-SPRSExtension -identity $apps
    Remove-SPRSExtension -identity $apps -ExtensionType "Data" -name "SQLPDW"
    Remove-SPRSExtension -identity $apps -ExtensionType "SemanticQuery" -name "SQLPDW"
    Remove-SPRSExtension -identity $apps -ExtensionType "SemanticQuery" -name "TERADATA"
    Remove-SPRSExtension -identity $apps -ExtensionType "ModelGeneration" -name "TERADATA"
    Remove-SPRSExtension -identity $apps -ExtensionType "Data" -name "TERADATA"

これで、 イベントログに該当のエラーが記録されることはなくなります。