2014 年 9 月 29 日時点の SQL Server 最新モジュールです。

SQL Server 2000 は 2013 年 4 月 9 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。
SQL Server 2008 は 2014 年 7 月 8 日にメインストリームサポートが終了しました。CU17 が最後の累積的な更新プログラムとなります。

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

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

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

SQL Developer Support Engineer 山崎実久

以下の内容は 2014年9月29日時点の内容となります。今後機能が更新され内容が変更される場合があります。

SQL Server や CSV ファイルなどを参照した  Excel のブックで、PowerView を利用しグラフを追加した場合でも、グラフを更新することが可能です。

しかし、ウィザードに従ってブックを作成し、PowerBI のサイトにアップロードしたブックのデータを更新しただけでは、PowerView で作成したグラフは更新されません。更新データをグラフに反映するには、下記を参考に PowerView で作成したグラフを更新対象となるデータで作成しなおす必要があります。

    
対処方法
   
1. 作成したブックを開き PowerView のシートを選択します。
2. グラフをクリックすると、右側に “Power View フィールド” が表示されます。このまま、ブックを PowerBI サイトにアップロードし、データ更新を行うと、該当のグラフが更新されない事象が発生します。

Fig1

3. 対処方法として、アップロードしたブックを開き、ブックの右側に表示された “Power View フィールド” の列のチェックを外し、”PowerView フィールド” にあるもう一方のフィールドの列 (更新対象の列) を利用して、改めてグラフを作成します。

4. 編集したブックを PowerBI のサイトへアップロードし、グラフを更新することが可能か確認します。

以上です。参考になれば幸いです。

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

SQL Server 2000 は 2013 年 4 月 9 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。
SQL Server 2008 は 2014 年 7 月 8 日にメインストリームサポートが終了しました。CU17 が最後の累積的な更新プログラムとなります。

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

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

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

皆さん、こんにちは。 今回は SQL Server の高可用性ソリューションについて紹介します。

SQL Server では、複数の可用性ソリューションを実現させるための機能が備わっています。 しかしながら、複数の可用性ソリューションが存在するため、どの機���を選択すべきかについて、迷われている方もおられるのではないでしょうか。

今回、SQL Server で実現可能な高可用性ソリューションの各機能をポイント別に評価し、比較してみたいと思います。

まず初めに、評価するポイントとして、以下の項目を定義しました。

高可用性ソリューションの各機能を上記のポイントで評価したものが、以下の表になります。

注1) AlwaysOn 可用性グループでは、プライマリとレプリカ間の同期状態を常に監視しており、既定のタイムアウト値 (SESSION_TIMEOUT もしくは PARTNER_TIMEOUT) の間までに、プライマリとレプリカ間の通信が正常に行えない状態を検知した場合、レプリカを切断するという動作が行われます。 また、プライマリとレプリカ間の通信の正常性を確認している間、レプリカへの同期処理は待ち状態となり、レプリカ側が異常な状態と判断され、レプリカが可用性グループから解除されるまで、プライマリ側で行われた UPDATE/DELETE/INSERT 処理のコミット処理は待ち状態となります。

尚、レプリカが解除された以降では、プライマリ側の UPDATE/DELETE/INSERT 処理のコミット処理は即座に行われ、レプリカへの同期処理で待ちが発生することはありません。また、プライマリとレプリカ間の通信が正常に行えることが検知された場合、自動的にプライマリとレプリカ間の同期が開始されます。

※ 機能は異なりますが、データベース ミラーリングでも類似の動作が行われます。

注2)同期モードの場合、プライマリ側で行われたトランザクション処理のコミットが、レプリカ (もしくは ミラー) への書き込みが完了した後に行われます。 そのため、プライマリとレプリカ (もしくは ミラー）間は、常に同期が保たれた状態になり、障害発生によるデータ損失のリスクを回避することが可能となります。

注3)非同期モードの場合、プライマリとレプリカ (もしくは ミラー) 間のデータ同期が非同期で行われるため、何らかの障害がプライマリ側で発生し、レプリカ (もしくは ミラー) に配信されていないトランザクションがプライマリ側に残っていた場合は、データ損失が発生します。 そのため、レプリカ (もしくは ミラー) をプライマリに昇格されるためには、強制フェールオーバーを実施する必要があります。尚、強制フェールオーバーを実施せず、プライマリ側が正常に動作する状況に復旧された場合、同期モードと同様に、自動的に同期の再開が行われます。

注4)プライマリ クラスタノード上で稼動している SQL Server リソースの停止、SQL Server リソースグループの移動、新プライマリ クラスタ ノード上での SQL Server リソースの起動処理の時間が必要となります。 そのため、通常 数分程度で本処理は完了することが予測されますが、データベースの整合性を保つためにリカバリが必要なトランザクションが多ければ、数分以上の時間を要する可能性があります。

注5) AlwaysOn フェールオーバー クラスタリング インスタンス の場合、各クラスタノード上で、共有ディスク (もしくは SMB) に配置されたデータベース物理ファイルを共有するため、ディスク装置 (ストレージ) 側でも冗長性を持たせる必要があり��す。

注6)リアルタイムによるデータ同期が保証されていない機能であるため、何らかの障害発生時に レプリケーション サブスクライバ、ログ配布先に配信されていないトランザクションが存在する場合、データ損失が発生する可能性があります。尚、レプリケーション プライマリ、ログ配布元の環境が正常に動作できる状態に復旧された場合、同期の再開が行われます。

いかがでしたでしょうか。今回はポイントを絞ったうえでの機能比較を実施しました。

実際にシステム構成を設計される場合、コストなどの様々な要素により、多岐にわたる検討が必要であると思いますが、その一助になれば幸いです。

[参考情報]

高可用性ソリューション (SQL Server)

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

清水 磨 （しみず おさむ）
SQL Server Support Engineer

現象

Microsoft SQL Server Backup to Microsoft Azure Tool をインストールしている環境では、Windows Server Backup 時にエラーが発生し、正常にバックアップすることが出来なくなります。
また、Windows Azure 上の仮想マシンの場合、Windows Azure Backup が使用できなくなります。

バックアップに失敗した場合、以下のようなエラー メッセージが出力されます。

Windows Server Backupに失敗した場合：  

Windows Azure Backup に失敗した場合：  

Microsoft SQL Server Backup to Microsoft Azure Tool は、Azure Blob ストレージへのSQL Server データベース バックアップを可能にするツールです。
Azure Blob ストレージへのバックアップ機能は、SQL Server 2012 SP1 CU2 以降、もしくはSQL Server 2014 ではSQL Server の標準機能として実装されています。
（Microsoft SQL Server Backup to Microsoft Azure Tool をインストールしなければ問題は発生致しませんので、ご安心下さい。）

<参考情報>
Microsoft SQL Server Backup to Microsoft Azure Tool
http://www.microsoft.com/ja-JP/download/details.aspx?id=40740

Windows Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元
http://msdn.microsoft.com/ja-jp/library/jj919148(v=sql.120).aspx

Azure Backup の概要
http://msdn.microsoft.com/ja-jp/library/azure/hh831419.aspx

原因       

Microsoft SQL Server Backup to Microsoft Azure Tool のフィルタ ドライバー （SQLBackup2AzureDriver） の仕様上の問題です。
なお、本問題については弊社開発部門には報告済みです。弊社内での調査に進展がありましたら、本情報をアップデートする予定です。

対処策
Windows Server Backup やWindows Azure Backup を実行するためにはMicrosoft SQL Server Backup to Microsoft Azure Tool をアンインストールすることにより、暫定対処が可能です。もしくは、以下の技術情報に記載の設定により、該当のフィルタドライバーを一時的に無効化にすることでも対処可能です。ただし、レジストリを変更する必要があるため、設定変更する度に、OS再起動が必要になります。   

Windows でカーネル モードのフィルタ ドライバを一時的に無効にする方法
http://support2.microsoft.com/kb/816071/ja

2014 年 3 月 18 日時点の 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 の更新プログラムを参照して下さい。

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

清水 磨 （しみず おさむ）
SQL Server Support Engineer

現象

Microsoft SQL Server Backup to Microsoft Azure Tool をインストールしている環境では、Windows Server Backup 時にエラーが発生し、��常にバックアップすることが出来なくなります。
また、Windows Azure 上の仮想マシンの場合、Windows Azure Backup が使用できなくなります。

バックアップに失敗した場合、以下のようなエラー メッセージが出力されます。

Windows Server Backupに失敗した場合：  

出力されるエラー メッセージ 例 
-----------------
名前
C:

メッセージ
ボリュームをバックアップする操作は、操作の実行開始前に停止されました。
-----------------

アプリケーション ログには以下のように記録されます:
------------------------------------------------------
ログの名前:         Application
ソース:           Microsoft-Windows-Backup
日付:            2014/10/07 10:41:28
イベント ID:       521
タスクのカテゴリ:      なし
レベル:           エラー
キーワード:        
ユーザー:          SYSTEM
コンピューター:       test
説明:
バックアップ対象のボリュームのシャドウ コピーを作成するボリューム シャドウ コピー サービスの操作が、次のエラー コード '2155348075' により失敗したため、'‎2014‎-‎10‎-‎07T01:40:40.186000000Z' に開始したバックアップ操作は失敗しました。イベントの詳細で解決策を確認し、問題の解決後にバックアップ操作を再実行してください。
------------------------------------------------------

Windows Azure Backup に失敗した場合：  

出力されるエラー メッセージ 例
-----------------
名前
C:\

メッセージ
Microsoft Azure Recovery Services Agent は選択されたボリュームのスナップショットを作成できませんでした。 操作をやり直してください。問題が解決しない場合は、Microsoft サポートにお問い合わせください。 (0x186C2)
-----------------     

システムログには以下のように記録されます：
------------------------------------------------------
ログの名前:         System
ソース:           volsnap
日付:            2014/10/07 2:01:34
イベント ID:       20
タスクのカテゴリ:      なし
レベル:           エラー
キーワード:         クラシック
ユーザー:          N/A
コンピューター:       test
説明:
ボリューム F: のシャドウ コピーが、空き領域の計算に失敗したために中止しました。
------------------------------------------------------

Microsoft SQL Server Backup to Microsoft Azure Tool は、Azure Blob ストレージへのSQL Server データベース バックアップを可能にするツールです。
Azure Blob ストレージへのバックアップ機能は、SQL Server 2012 SP1 CU2 以降、もしくはSQL Server 2014 ではSQL Server の標準機能として実装されています。
（Microsoft SQL Server Backup to Microsoft Azure Tool をインストールしなければ問題は発生致しませんので、ご安心下さい。）

<参考情報>
Microsoft SQL Server Backup to Microsoft Azure Tool
http://www.microsoft.com/ja-JP/download/details.aspx?id=40740

Windows Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元
http://msdn.microsoft.com/ja-jp/library/jj919148(v=sql.120).aspx

Azure Backup の概要
http://msdn.microsoft.com/ja-jp/library/azure/hh831419.aspx

原因       

Microsoft SQL Server Backup to Microsoft Azure Tool のフィルタ ドライバー （SQLBackup2AzureDriver） の仕様上の問題です。
なお、本問題については弊社開発部門には報告済みです。弊社内での調査に進展がありましたら、本情報をアップデートする予定です。

対処策
Windows Server Backup やWindows Azure Backup を実行するためにはMicrosoft SQL Server Backup to Microsoft Azure Tool をアンインストールすることにより、暫定対処が可能です。もしくは、以下の技術情報に記載の設定により、該当のフィルタドライバーを一時的に無効化にすることでも対処可能です。ただし、レジストリを変更する必要があるため、設定変更する度に、OS再起動が必要になります。   

Windows でカーネル モードのフィルタ ドライバを一時的に無効にする方法
http://support2.microsoft.com/kb/816071/ja

更新履歴
2014/10/17 一部内容を補足しました。

可用性を高めるために、AlwaysOn 可用性グループとレプリケーションを組み合わせて利用したいというご要望を聞くことがよくあります。一例として、AlwaysOn 可用性グループを構成しているデータベースをパブリケーションとして、トランザクション レプリケーションを構築することが可能です。この記事では以下のような構成を前提としてご紹介します。

手順は、AlwaysOn 可用性グループ用のレプリケーションの構成 (SQL Server)でご案内しています。また、英語ですが、米国の AlwaysOn サポートチームが公開しているブログ記事 Setting up Replication on a database that is part of an AlwaysOn Availability Groupで、スクリーンショット付きで分かりやすい手順もあります。

この構成のポイントとしては、次の点があります。

＜ポイント1＞ ディストリビューターは、可用性グループを構成しているサーバー以外のサーバーで稼動させる必要がある。
＜ポイント2＞ 可用性グループがフェールオーバーしてもレプリケーションの配信は続行される。
＜ポイント3＞ 可用性グループのセカンダリ レプリカのサーバーが停止していると、レプリケーションの配信は行われない。

ここで、＜ポイント3＞ の動作について注意が必要なため、今回はこの動作についてご案内します。

「AlwaysOn 可用性グループを構成しているサーバーが停止しているときのレプリケーションの配信タイミング」

通常であれば、変更対象のログ レコードがレプリケーション ログ リーダー エージェントによって読み取られ、ディストリビューターを経由してサブスクライバーにトランザクション情報が配信されますが、可用性グループのセカンダリ レプリカが停止している場合には、配信されません。状況により、次のような動作の違いがあります。

平常稼動時:

変更対象のログ レコードがログ リーダー エージェントによって読み取られ、ディストリビューター/サブスクライバーに配信されます。

可用性グループのフェールオーバー後:

変更対象のログ レコードがログ リーダー エージェントによって読み取られ、ディストリビューター/サブスクライバーに配信されます。

可用性グループのセカンダリ レプリカが停止している場合:

AlwaysOn としては同期待ち状態となります。この場合、変更対象のログ レコードがログ リーダー エージェントで読み取れず、ディストリビューター/サブスクライバーに配信が行われません。レプリケーション モニターで、ログ リーダー エージェントの詳細表示を見ると、「レプリケートされたトランザクションは、次のログ バックアップまたはミラーリング パートナーが遅延を解消するのを待機しています。」というメッセージが表示されています。

「AlwaysOn 可用性グループを構成するサーバー停止しているときも、レプリケーションを配信する方法」

停止したセカンダリ レプリカがすぐに復旧してくれば、セカンダリ レプリカへ再接続し、レプリケーションの配信は再開されます。しかし、障害によってはセカンダリ レプリカの復旧に時間が必要なこともあります。セカンダリ レプリカの復旧に時間がかかる時にも、レプリケーションの配信は続行したい場合には、下記のいずれかの方法で対処します。

A. 可用性グループからセカンダリ レプリカを削除する
B. 可用性グループからデータベースを削除する

A. 可用性グループからセカンダリ レプリカを削除する

1) 停止したセカンダリ レプリカを可用性グループから削除します。

その結果、パブリッシャからサブスクライバへのレプリケーションは続行されます。
セカンダリ レプリカが復旧して使用可能になった際に、次の方法で再度可用性グループにセカンダリ レプリカを追加します。

2) 停止していたレプリカに残っているデータベースを削除します。

3) 停止していたレプリカを、可用性グループにレプリカとして追加します。

B. 可用性グループからデータベースを削除する

1) 対象のデータベースを可用性グループから削除します。

その結果、パブリッシャからサブスクライバへのレプリケーションは続行されます。
セカンダリ レプリカが復旧して使用可能になった際に、次の方法で再度可用性グループにデータベースを追加します。

2) 可用性グループにデータベースを追加します。

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

皆さん、こんにちは。 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 Server/Microsoft Azure SQL Database サポートチーム です。

今回は、Microsoft Azure SQL Database (以下 MASD) を使用したシステムを構築するうえで、推奨されるアプリケーションの実装について紹介します。

MASD は、クラウド上に配置されたデータベースをサービス (Software as a Service : SaaS) として提供しており、高可用性を実現するため、複数レプリカによる冗長性を備えています。また、高可用性を維持していくために、Reconfiguration (リコンフィグレーション) が内部的に行われています。

※ Reconfiguration (リコンフィグレーション) の詳細については、以下の ブログを参照ください。

[SQL Database] Reconfiguration (リコンフィグレーション) は悪ではない。
http://blogs.msdn.com/b/jpsql/archive/2014/10/22/sql-database-reconfiguration.aspx

そのため、MASD を使用したシステムを構築する場合は、アプリケーション側でも、 アプリケーションからデータベースまでの経路間におけるネットワーク遅延、及び、Reconfiguration (リコンフィグレーション) の発生に伴う、既存セッションの切断、ロールの変更 (セカンダリからプライマリへの昇格など) が完了するまでの期間 (数秒から数十秒程度) における、新規接続の一時的な遅延を考慮した実装を検討する必要があります。

上記の事項を考慮した実装として、アプリケーション側で以下を実装することを推奨しています。

推奨実装 (アプリケーション側)

1) リトライ ロジックを実装し、接続切断や接続タイムアウトなどを検知時にリトライ処理を実施する

2) 接続タイムアウト値 (既定 15秒) を 30秒に以上に設定する

3) リトライ処理の間隔は、10秒以上 (最低 5 秒以上) に設定する

推奨実装に関する補足事項を以下に記載します。

1) リトライ ロジックについて

接続タイムアウトが発生した場合、リトライ処理の中で接続オブジェクトを再利用せず、オブジェクトの作成から処理を再実行します。

※ リトライ ロジック の実装例として、以下のサンプル ソースを参考ください。

SQL Azure Retry Logic
https://code.msdn.microsoft.com/windowsazure/SQL-Azure-Retry-Logic-2d0a8401

2) 接続タイムアウト値について

接続タイムアウト値は、アプリケーションからデータベースに対する接続処理において、アプリケーション側が接続処理が完了するまでに待機できる最大時間を設定するものになります。

そのため、接続タイムアウト値を延ばしたとしても、アプリケーションからデータベースに対する接続処理が、接続タイムアウト値に指定した時間まで必ず待機状態になるわけではなく、通常時の即座にアプリケーションからデータベースに接続ができる状況時において、即座に接続が可能となりますので、ご安心ください。

[参考URL]

SqlConnection.ConnectionTimeout プロパティ (ADO.Net)
http://msdn.microsoft.com/ja-jp/library/system.data.sqlclient.sqlconnection.connectiontimeout(v=vs.110).aspx

接続文字列 (Entity Framework)
http://msdn.microsoft.com/ja-jp/library/cc716756.aspx

3) リトライ 間隔について

短期間の間に接続が失敗し続ける現象が大量に発生した場合、SQL Database 側では、攻撃を受けていると検知し、一定期間、アプリケーションからのすべての接続を拒否するという現象(DoS Guard) が発生する可能性があります。

そのため、リトライ処理を実施する際には、リトライ間隔を十分に取ることを推奨しています。

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

SQL Server Developer Support Team

藤丸陽子

SQL Server Analysis Services 利用時に、メタデータマネージャーエラーが記録され、Analysis Services に対する操作が失敗する事象とその対処について案内します。

要因

Analysis Services データベースを構成する一部、もしくは複数のファイルの破損や不整合が発生した場合に起きうる問題です。

Analysis Services 稼働マシンで以下のような運用がなされた場合に発生する可能性があります。

・ Analysis Services データベースファイルが存在するディスクの障害による、ファイル破損やファイルの書き込みエラーが発生した場合

・  データベースおよびキューブ処理中に Analysis Services サービスを再起動した場合

・  データベースバックアップ中に Analysis Services サービスを再起動した場合

・  ウィルス対策ソフトが Analysis Services データベースファイルの一部をスキャン中に、Analysis Services を再起動した場合

・ Analysis Services が稼働するマシンの強制終了等、正しくない形で Analysis Services サービスを終了した場合

補足

どの要因に該当しているかは、残念ながらログ等からは確認することはできません。

対処方法

メタデータマネージャーエラーが発生した場合、問題が検知されたファイルを含むデータベースを削除し、再配置することが対処方法となります。再配置はメタデータマネージャーエラーが発生する前に採取しておいた Analysis Services データベースのバックアップファイルが必要です。 正常時のデータベースバックアップファイルが存在しない場合、Analysis Services データベースプロジェクトを再配置の上、データベースを再処理します。

重要

事前作業

Analysis Services のデータフォルダ配下を別の場所にコピーの上、退避しておきます。

Tips

対処手順 (バックアップ復元による対処)

1) SQL Server Analysis Services サービスを停止します。 ([管理ツール] - [サービス] - [SQL Server Analysis Services] )

2) Analysis Services データフォルダ配下から、エラーメッセージに記録されているデータベースの .db フォルダを削除します。

例) Analysis Services データフォルダが "C:\Program Files\Microsoft SQL Server\MSAS<Version>.MSSQLSERVER\OLAP\Data" で、メタデータマネージャーエラーが記録されているデータベースが SSASDB1 の場合：

"C:\Program Files\Microsoft SQL Server\MSAS<Version>.MSSQLSERVER\OLAP\Data" フォルダ配下の SSASDB1.<number>.db フォルダを削除します。

3) SQL Server Analysis Services サービスを開始します。 ([管理ツール] - [サービス] - [SQL Server Analysis Services] )

4) メタデータマネージャーエラーが発生する前に採取しておいた該当の Analysis Services データベースバックアップファイル (.abf)

(例: SSASDB1.abf) を SQL Server Management Studio から復元します。

上記手順でエラーが解消しない場合、次の対応で、エラーの解消がなされるかご確認下さい。

• 他のデータベースを一点一点削除し、エラーの解消を確認する。 (上記対処手順 1) から 4) を繰り返す。)
• Analysis Services データフォルダの場所を変更し、事前に採取しているバックアップを順次復元する

補足

バックアップファイルが存在しない場合

正常時のデータベースバックアップファイルが存在しない場合、Analysis Services データベースプロジェクトを再配置の上、再処理します。

前述の対処手順 1) から 3) を実行し、Analysis Services データベースプロジェクトを該当の Analysis Services インスタンスに配置の上、データベース完全処理を実施下さい。

エラーが解消しない場合、前述の対処手順同様に下記を確認下さい。

• 他のデータベースを一点一点削除し、エラーの解消を確認する。
• Analysis Services データフォルダの場所を変更し、事前に採取しているバックアップを順次復元する

エラーを可能な限り抑止するための運用方法

Analysis Services 運用にあたり、下記の運用がなされていることを確認下さい。

• Analysis Services データベース処理中やオンラインでデータベースデザインを変更している最中の Analysis Services サービス停止・再起動や OS 停止・再起動をしないようにする。
• ウイルス対策ソフトで Analysis Services 関連のファイル除外設定をする。*1
• SQL Server を最新のサービスパックで運用する *2

*1 ファイル除外設定を行っていない場合、下記技術情報を参考にファイル除外設定を行います。

SQL Server を実行しているコンピューター上で実行するウイルス対策ソフトウェアを選択する方法

<http://support.microsoft.com/kb/309422/ja>

*2  SQL Server を最新のサービスパックで運用することも合わせて推奨しております。

SQL Server の最新モジュール情報 (まとめページ)

http://blogs.msdn.com/b/jpsql/archive/2010/08/01/sql-server.aspx

SQL Server Developer Support

藤丸陽子

SharePoint 2013 と SQL Server 2014、同一筐体のシングル構成における手順を案内します。

前回案内した[SSRS] SharePoint 統合モードのレポートサーバー構築手順 (単一サーバー） - SQL Server 2012 と SharePoint 2013 の組み合わせと基本的に同じ構成手順となります。

■■■ 構成 ■■■

SharePoint 2013 と SQL Server 2014、同一筐体のシングル構成における手順です。

■■■ 手順概要 ■■■

以下が手順概要となります。

1. 事前準備 (.NET Framework 3.5 SP1 のインストール)

2. SQL Server 2014 をインストール

3. SharePoint 2013 をインストール

4. Reporting Services SharePoint サービスの登録と開始

5. Reporting Services サービスアプリケーションの作成

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

■■■ 手順詳細 ■■■

1. 事前準備 (.NET Framework 3.5 SP1 のインストール)

2. SQL Server 2014 をインストール

1) SQL Server 2014 メディアからルートフォルダの Setup.exe をダブルクリックします。

[インストール] - [SQL Server の新規スタンドアロンインストールを実行するか、既存のインストールに機能を追加します] をクリックします。

2) プロダクトキーを入力します。

3) ライセンス条項を確認し、次へ進みます。

4) Microsoft Update を確認し、次へ進みます。

5) インストールルールが終了次第、次へ進みます。

6) [セットアップロール] 画面で "SQL Server 機能のインストール" をチェックし、次へ進みます。

7) [機能の選択] 画面で次の通り選択し、次へ進みます。 緑で囲ったものが、 シングル環境における SharePoint 2013 + SQL Server 2014 Reporting Services 統合環境に必須のコンポーネントとなります。

8) [機能ルール] が成功することを確認し、次へ進みます。

9) [インスタンスの構成] 画面でインスタンス名を指定します。 既定のインスタンスで構成するには、そのままの設定で次へ進みます。

10) [サーバーの構成] - サービスアカウントを設定し次へ進みます。 (特に変更がない場合既定の設定とします。)

11) [データベースエンジンの構成] 画面で SQL Server 管理者を追加します。

SQL 認証を有効にする場合、"混合モード" にチェックし、SQL Server のシステム管理者 (sa) のパスワードを指定します。

12) (Optional - Analysis Services をインストールしている場合) [Analysis Services の構成] 画面で、サーバーモードを選択の上、Analysis Services 管理者を追加します。

13) [Reporting Services の構成] 画面で "Reporting Services SharePoint 統合モード" の 'インストールのみ' にチェックが入っていることを確認の上、次へ進みます。

14) [インストールの準備完了] 画面でインストール対象の機能をチェックの上、[インストール] ボタンをクリックします。

15) セットアップ完了を確認の上、OS を再起動します。

参考情報

=====

インストール ウィザードからの SQL Server 2014 のインストール (セットアップ)

<http://msdn.microsoft.com/ja-jp/library/ms143219.aspx>

3. SharePoint 2013 をインストール

1) ソフトウェア必須コンポーネントのインストールをします。

SharePoint 2013 のメディアを実行し、[インストール] - [ソフトウェア必須コンポーネントのインストール] を選択します。

2) Microsoft SharePoint 2013 製品準備ツールが起動します。 そのまま次へ進みます。

3) ライセンス条項を確認し、次へ進みます。

4) 製品準備ツールの実行完了後、[完了] ボタンをクリックし、OS を再起動します。

5) OS 再起動後、SharePoint Server のインストールを実施します。

6) プロダクトキーを入力します。

7) ライセンス条項を確認し、次へ進みます。

8) [サーバーの種類] が "完全" となっていることを確認し、[今すぐインストール] をクリックします。

9) インストールが完了するの���待ちます。

10) SharePoint 2013 のインストール完了後、 SharePoint 2013 製品構成ウィザードを実行します。

11) [SharePoint 製品構成ウィザード] が起動します。 次へ進みます。

12) 各サービスの開始、リセットについてのポップアップが立ち上がります。 [はい] をクリックします。

13) [サーバーファームへの接続] 画面で "新しいサーバーファームの作成" にチェックし、次へ進みます。

14) SharePoint サーバーファームの構成データベースの設定を行います。

SQL Server データベースエンジンが稼働するサーバーと構成データベースへの接続に使用する Windows アカウントを指定します。

(今回はシングル構成ですので、SharePoint と同一のサーバーを指定します。)

15) [ファームセキュリティ設定の指定] 画面で、任意のパスフレーズを指定します。

このパスフレーズはファームを追加する際に必要となります。

16) [SharePoint サーバーの全体管理 Web アプリケーションの構成] で全体管理のポート番号と認証プロバイダを指定します。

ここでは既定の設定のまま、次へ進みます。

17) SharePoint 製品構成ウィザードの終了画面で設定を確認し、次へ進みます。

18) 製品構成ウィザードの完了を確認し、[完了] ボタンをクリックします。

19) ファーム構成の初期構成ウィザードが起動します。

20) [ウィザードの開始] をクリックします。

21) サービスアカウント、サービスの設定を行います。

22) 設定後、SharePoint 全体管理の画面が表示されることを確認します。

4. Reporting Services SharePoint サービスの登録と開始

1) SharePoint 2013 管理シェルを [管理者として実行] で実行します。

2) 下記のコマンドをそれぞれ実行します。

Install-SPRSService

Install-SPRSServiceProxy

get-spserviceinstance -all |where {$_.TypeName -like "SQL Server Reporting*"} | Start-SPServiceInstance

参考情報

======

SharePoint 2013 用 Reporting Services の SharePoint モードのインストール

<http://msdn.microsoft.com/ja-jp/library/jj219068.aspx>

--> 手順 2:Reporting Services SharePoint サービスの登録と開始

5. Reporting Services サービスアプリケーションの作成

1) SharePoint サーバーの全体管理で、[アプリケーション構成の管理] の [サービス アプリケーションの管理] をクリックします。

2) SharePoint リボンで、[新規作成] ボタンをクリックします。

※ [新規作成] ボタンがグレイアウトして選択できない場合、ブラウザを [管理者として実行] で起動し、SharePoint サーバーの全体管理を起動ください。

3) [新規作成] メニューで [SQL Server Reporting Services サービスアプリケーション] を選択します。

4) [SQL Server Reporting Services サービス アプリケーションの作成] ページで、アプリケーションの名前を入力します。

例) RSServiceApp1

5) Reporting Services サービスアプリケーションが正常に作成されることを確認し、[OK] ボタンをクリックします。

6) Reporting Services サービスアプリケーションが作成されていることを確認します。

7) 作成した Reporting Services サービスアプリケーション (例: RSServiceApp1) を選択し、プロパティをクリックの上、 Web アプリケーションの関連付けを行います。 ( Reporting Services サービスアプリケーションを利用する Web アプリケーションにチェックを入れます。)

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

1) [アプリケーション構成の管理] - [サイトコレクションの作成] を選択します。

2) サイトコレクションの作成画面で各項目を設定します。

3) サイトコレクション作成後、 レポートを作成したサイトコレクションにアップロードし、レポートの表示がなされることをご確認ください。

※ レポートが参照できない場合、サイトコレクションが属する Web アプリケーションが Reporting Services サービスアプリケーションと関連付けがなされていることをご確認ください。

以上の通りとなります。

みなさん、こんにちは。

Reporting Services では PDF ファイルへのエクスポートが可能です。
その PDF ファイルを 2 次利用する場合において文字化けが発生するケースがあります。

再現手順
1) Reporting Services でエクスポートした PDF ファイルを開きます。
2) 表示されているデータの文字列を [Ctrl] + [C] キーなどでクリップボードにコピーします。
3) メモ帳などを開き、コピーした値を貼り付けると文字化けが発生します。(2 バイト日本語など)

要因
これは、Reporting Services が出力する PDF のフォントが、グリフ形式で記録される場合に発生します。
日本語のフォントの場合は、グリフで扱われています。

グリフって？
文字の形状のことです。コンピュータの画面表示や紙に印刷するための、文字を形づくる輪郭線、グラフィック的な情報です。
これは、Unicode などの文字コードとは異なる情報です。

コピー＆ペーストのようにアプリケーションが値を文字列として扱うケースでは、グリフ のほかに文字コードが必要になります。現在、Reporting Services が出力する PDF では、埋め込まれているグリフから Unicode への変換を行う機能を持っていないため、コピー＆ペーストを行った場合は正確な Unicode 文字コードが得られず文字化けします。

この動作は、大変恐縮ではあるのですが Reporting Services で生成された PDF を扱う上での制限事項です。

補足
Reporting Services 文字化けといえば、異なる OS 間の PDF 文字化けもあります。
リンク先のブログで紹介しているように、異なる OS 間の文字化けの現象は、フォントの埋め込み対応バージョンの Reporting Services では発生しませんが、コピー＆ペーストでの文字化け現象は埋め込みフォント対応有無にかかわらず再現します。フォントが PDF に埋め込まれるようになりましたが、グリフ形式で扱っている点には変更がないためです。

回避するには
残念ながら、出力された PDF ファイルからの操作では 回避策はありません。
出力した内容をコピー＆ペーストするなど 2 次利用したい場合には、HTML や Excel などあらかじめ他の形式でエクスポートすることが代替案となります。

参考になれば幸いです。

Microsoft Japan SQL Server Support Team
森  隆博
SQL Developer Support Engineer

SharePoint では、Reporting Services SharePoint 統合モードの設定を行うと、SharePoint 製品およびテクノロジを使用して、SQL Server Reporting Services のレポ���トの管理等を行うことができます。

本 Blog では、SharePoint 統合モードの Reporting Services レポートサーバーを構築する手順をご案内します。
ここでの対象プロダクトは Windows Server 2008 R2 上の SQL Server 2014 ならびに SharePoint 2010 です。

SharePoint 2010 のシステム要件の詳細は下記技術情報に記載を、ご参照ください。

    ハードウェア要件およびソフトウェア要件 (SharePoint Server 2010)

また、以下に、Reporting Service と統合する上で、サポートされる SharePoint と SQL Server Reporting Services とのバージョンの組み合わせの情報の記載があります。
本記事はSQL Server 2014 と SharePoint 2010 の統合手順を記載したものですが、そのほかのバージョンで構築を検討する際の参考にしてください。

    SharePoint、Reporting Services サーバー、Reporting Services アドインのサポートされる組み合わせ (SQL Server 2014)
 

■ここで手順を案内しているシステムについて

・SQL Server 2014 Enterprise
※SharePoint 統合が可能な Reporting Services のエディションは Enterprise と Business Intelligence と Standard です。

    SQL Server 2014 の各エディションがサポートする機能

・SharePoint 2010 Enterprise
・Windows Server 2008 R2 Enterprise
・SQL Serer データベース、Reporting Services、SharePoint を全て同一マシン上にインストールする

■統合における注意点

注意点 1 ) SQL Server 2014 での変更点
-- Report Server データベース
SQL Server 2008 R2 までのバージョンでは、SharePoint 統合レポートサーバーデータベースは、Reporting Services 構成マネージャで作成しました。
SQL Server 2014 では SharePoint 全体管理側から作成します。

SharePoint は、Excel や Access などの統合連携するアプリケーションを、サービスアプリケーションとして管理します。
SQL Server 2008 R2 までは SharePoint と Reporting Services サービスが連携する形で統合していましたが、SQL Server 2014 では、Reporting Services も他のアプリケーション同様、SharePoint のサービスアプリケーションのひとつとして、より密な連携を行うことができるようになりました。

このため、Reporting Services 構成マネージャのような Reporting Services のツールではなく、SharePoint 全体管理から SharePoint 統合レポートサーバーデータベースを作成、構成するよう変更されています。

注意点 2 ) ファーム構成の注意点
この Blog 記事は単一構成（Reporting Services も SharPpoint Server も同一環境でのインストール）の構成手順をご案内したものです。
ですが、SQL Server 2014 ではファーム構成については注意点があります。
SQL Server 2014 Reporting Services と SharePoint 2010 の統合を行うには、Reporting Services（アドイン含む）と SharePoint を同一環境にインストールします。
これは、Reporting Services 2014 では SharePoint のサービスアプリケーションのひとつという扱いになったためです。
SharePoint サービスアプリケーションと SharePoint コンポーネントは同一の環境に存在する必要があります。

注意点 3) SharePoint 2010 Service Pack
SharePoint 2010 と SQL Server 2014 の Reporting Services を統合するには SharePoint 2010 に Service Pack 1 を適用する必要があります。

注意点 4) Reporting Services アドイン
SharePoint 製品用 Microsoft SQL Server Reporting Services アドインを SharePoint サーバーにインストールすると、SharePoint の配置内で Reporting Services レポート サーバーを実行するための機能が提供されます。
SharePoint 2010 の場合 SharePoint 2010 必須コンポーネントにそれが含まれていますが、SQL Server 2008 R2 バージョンの Reporting Services アドインが含まれています。
しかし、SQL Server 2014 の Reporting Services と統合するには SQL Server 2014 バージョンの SharePoint 製品用 Reporting Services アドインをインストールする必要があります。

SharePoint、Reporting Services サーバー、Reporting Services アドインのサポートされる組み合わせ (SQL Server 2014)

SharePoint の必須コンポーネントのインストールでは、すでにインストール済みのコンポーネントはスキップされる特徴があります。
このため、SQL Server 2014 と SharePoint 2010 の組み合わせにおいては先に SQL Server 2014 をインストールしておくと便利です。

SharePoint 用 Reporting Services アドインのインストールまたはアンインストール (SharePoint 2010 および SharePoint 2013)

■手順概要

1. .NET Framework 3.5 Service Pack1 のインストール
2. SQL Server 2014 をインストールする
3. SharePoint 2010 必須コンポーネントをインストールする
4. SharePoint 2010 をインストールする
5. SharePoint 2010 Service Pack 1 をインストールする
6. SharePoint の構成を設定する
7. SharePoint と Reporting Services を統合構成する

さて、前置きが長くなりましたが、早速手順の構成を見てみましょう。

1. .NET Framework 3.5 Service Pack1 のインストール

 2. SQL Server 2014 をインストール

SQL Server 2014 メディアからインストーラーを起動します

[インストール] - [SQL Server の新規スタンドアロンインストールを実行するか、既存のインストールに機能を追加します] をクリックします。

プロダクトキーを入力します。

ライセンス条項を確認し、次へ進みます。

Microsoft Update を確認し、次へ進みます。

インストールルールが終了次第、次へ進みます。

[セットアップロール] 画面で "SQL Server 機能のインストール" をチェックし、次へ進みます。

[機能の選択] 画面で次の通り選択し、次へ進みます。 緑で囲ったものが、 シングル環境における SharePoint 2013 + SQL Server 2014 Reporting Services 統合環境に必須のコンポーネントです。

[機能ルール] が成功することを確認し、次へ進みます。

[インスタンスの構成] 画面でインスタンス名を指定します。 既定のインスタンスで構成するには、そのままの設定で次へ進みます。

[サーバーの構成] - サービスアカウントを設定し次へ進みます。 (特に変更がない場合既定の設定とします。)

[データベースエンジンの構成] 画面で SQL Server 管理者を追加します。

SQL 認証を有効にする場合、"混合モード" にチェックし、SQL Server のシステム管理者 (sa) のパスワードを指定します。

(Optional - Analysis Services をインストールしている場合) [Analysis Services の構成] 画面で、サーバーモードを選択の上、Analysis Services 管理者を追加します。

[Reporting Services の構成] 画面で "Reporting Services SharePoint 統合モード" の 'インストールのみ' にチェックが入っていることを確認の上、次へ進みます。

[インストールの準備完了] 画面でインストール対象の機能をチェックの上、[インストール] ボタンをクリックします。

セットアップ完了を確認の上、OS を再起動します。

参考情報
インストール ウィザードからの SQL Server 2014 のインストール (セットアップ)


3. SharePoint 2010 必須コンポーネントをインストールする
SharePoint 2010 必須コンポーネントをインストールしましょう。 
インストーラーを起動して「ソフトウェア必須コンポーネントのインストール」をクリックします。


ウィザードに従い、インストールを進めます。
 

使用許諾に同意いただける場合、チェックのうえ、ウィザードを進めます。



ウィザードに従い、インストールを進めます。





4. SharePoint 2010 をインストールする

続いてSharePoint 本体をインストールします。
インストーラーから、「SharePoint Server のインストール」をクリックします。


 

プロダクトキーを入力します
 

ライセンス条項に同意いただける場合、チェックのうえ、ウィザードを進めます。
 

インストールの種類で「サーバーファーム」を選択します。

サーバーの種類から、「完全」を選択し、インストールを行います。

 

しばらくお待ちください。



5. SharePoint 2010 Service Pack 1 をインストールする
SQL Server 2014 Reporting Services と SharePoint 2010 の統合を行う場合、SharePoint にService Pack 1 を適用する必要があります。
Service Pack 1 を適用していないと、後続のインストール作業で以下のエラーが発生します。

SharePoint 2010 Service Pack の入手先はこちらです。

入手したインストーラーを実行します。
ライセンス条項に同意いただける場合、チェックの上、ウィザードを進めます。


更新プログラム用ファイルを展開するのでしばらくお待ちください。


ウィザードを進めます。
 

インストール完了までお待ちください。


6. SharePoint の構成を設定する
Service Pack 適用完了後、SharePoint の構成ウィザードを実行します。
※SharePoint の Service Pack 適用を完了するには構成ウィザードを実行する必要があります。
また、 SharePoint はインストール後に構成が必要となります。ここでは同時にやってしまいましょう。

スタートメニューから SharePoint 構成ウィザードを右クリックし、管理者として実行します。
 

構成ウィザードが起動します。ウィザードに沿って進めましょう。



新しいサーバーファームを作成します。


SharePoint  が動作するために必要な構成データベースの作成場所を指定します。先ほどインストールした SQL Server 2014 を指定します。
 

任意のパスフレーズを設定します。


SharePoint 全体管理画面のポート番号など、設定します。


ウィザードを進めます。
 

しばらくお待ちください
 

構成の完了を確認します。


完了ボタンをクリックすると、自動的に SharePoint 全体管理画面が立ち上がります。引き続き全体管理の設定を行いましょう。 
全体管理画面から SharePoint ファームの構成を設定していきます。

 

[ウィザードの開始] ボタンからファーム構成のウィザードを開始します。
 

ファームアカウントを指定し、後は既定で結構です。



ファーム構成完了までしばらくお待ちください。

続いて SharePoint のサイト（サイトコレクション）を作成しましょう。任意のタイトル名称を入力し、[OK] ボタンでウィザードを進めます。


ウィザードの完了を確認します。



7. SharePoint と Reporting Services を統合構成する

続いて、SharePoint と Reporting Servies の統合を構成をします。
SharePoint 2010 管理シェルからコマンド実行によって統合設定を行います。
  

管理シェルにて以下のコマンドを実行します。これにより、SQL Server Reporting Services サービスアプリケーションがインストールされます。
※コマンドが正常に実行されても、特に「正常に終了しました」の様なメッセージは表示されません。
Install-SPRSService

続いて以下のコマンドを実行します。これにより、SQL Server Reporting Services サービスプロキシがインストールされます。
Install-SPRSServiceProxy

 

SQL Server Reporting Services サービスアプリケーションの状態を確認してみましょう。

SharePoint サーバーの全体管理画面から [システム設定] のカテゴリ - [サーバーのサービスの管理] をクリックします。

SQL Server Reporting Services サービス が「開始済み」になっていることを確認します。
停止中の場合は開始しましょう

続いて Reporting Services サービスアプリケーションを作成しましょう。
SharePoint サーバーの全体管理画面から [アプリケーションの構成の管理] のカテゴリ - [サービスアプリケーションの管理] をクリックします。

サービスアプリケーションの一覧が表示されます。

リボンメニューの [新規] - [SQL Server Reporting Services サービス アプリケーション] を選択します。

名前とアプリケーションプールを指定し、「Web アプリケーションの関連付け」 にてReporting Services サービスアプリケーションを使用したい Web アプリケーションをチェックして [OK] ボタンをクリックします。

正常に完了することを確認します

統合が完了すると、SharePoint サイトのドキュメントライブラリにレポートファイルを配置し、レポートを参照することが可能となります。

以上で構築作業が完了です。ぜひご利用ください。

清水 磨 （しみず おさむ）

SQL Server Support Engineer

SQL Server 2012 SP1の製品不具合 (KB 2793634) に起因し、一部のレジストリ ハイブのサイズが拡張される可能性がある事象について説明します。
本不具合はすでに修正されておりますが、この不具合に起因し、一部のレジストリハイブの拡張が進行した場合、OSの再インストールが必要になる場合があります。
そのため、SQL Server 2012 SP1 を使用されている場合には、SQL Server 2012 の最新のサービスパックを適用ください。

以下に詳細を記載します。

[影響を受けるSQL Serverのバージョン]  
SQL Server 2012 SP1 (11.*.3000.*)
SQL Server 2012 SP1 CU1 (11.*.3321.*)

※ アスタリスクの部分には環境によって異なる値が入ります。
そのため、先頭の値が11であること、3番目の値が上記の値（3000か3321）になっていることをご確認下さい。
例：11.00.3000.00 など

SQL Server のバージョンを確認する方法は、下記公開情報の” 実行している SQL Server データベース エンジンのバージョンとエディションを確認する方法” をご参照下さい。

SQL Server とそのコンポーネントのバージョンとエディションを確認する方法
http://support.microsoft.com/kb/321185/ja

[影響を受けるSQL Serverのエディション]  
SQL Server 2012 Express Edition を含む、全てのエディションが影響を受けます。

[事象]
SQL Server 2012 SP1 のインストール後、一部のレジストリハイブのサイズが徐々に拡張されていく可能性があります。
その結果として、レジストリ全体のサイズが拡張されることになり、自分のプロファイルを用いてWindows にログオンできなくなったり、リソース不足に関連したエラーが発生する可能性があります。

また、レジストリ全体のサイズが拡張されることにより、レジストリに関する操作ができなくなる可能性があります。
あわせてSQL Server の修正プログラムも適用できなくなる可能性があるため、結果としてOSの再インストールが必要となる場合があります。
根本的にレジストリの拡張を防ぐには、修正プログラムの適用が必要となります。（下記 “対処方法” をご確認下さい）

本不具合については、以下の公開情報に記載がございます。

Windows Installer starts repeatedly after you install SQL Server 2012 SP1
http://support.microsoft.com/kb/2793634/en-us

SQL Server 2012 SP1 のインストール後に Windows インストーラーを繰り返し開始します。 (機械翻訳)
http://support.microsoft.com/kb/2793634/ja

[対処方法]   
SQL Server 2012 の最新のサービスパックを適用します。
その他の不具合も修正されておりますため、弊社としても推奨している方法となります。

Microsoft® SQL Server® 2012 Service Pack 2 (SP2)
http://www.microsoft.com/en-us/download/details.aspx?id=43340

なお、運用上、SPの適用が難しいお客様もいらっしゃるかと思います。
そうした場合には、個別の修正プログラムを適用する、もしくはSQL Server 2012 SP1 CU2 を適用することでも対処が可能です。
状況に応じて、適切な修正プログラムを適用して下さい。

もし、SQL Server 2012 SP1 RTM をインストールされている場合には、下記修正プログラムまたは CU2以降を適用します。
SQL Server 2012 SP1 のセキュリティ以外の更新プログラム (KB 2793634)
http://www.microsoft.com/ja-JP/download/details.aspx?id=36215

もし、SQL Server 2012 SP1 CU1 をインストールされている場合には、SQL Server 2012 SP1 CU2 以降を適用します。
SQL Server 2012 Service Pack 1 用の累積的な更新プログラム パッケージ 2
http://support.microsoft.com/kb/2790947/ja

[原因]
SQL Server 2012 関連コンポーネントが不適切なアセンブリを参照し、ネイティブ イメージの生成に繰り返し失敗します。
この結果、.NET Framework の NGEN サービス(.NET アプリケーションのパフォーマンス向上のため、ネイティブイメージを作成し、キャッシュしておくサービス) の SQL Serverに関連するレジストリ ハイブが拡張されます。

[発生頻度]
環境によりレジストリの肥大化のスピードは異なります。
そのため、環境によってはレジストリの肥大化が進行していない場合もございますが、将来的にレジストリの肥大化が発生しうる状況は変わりません。
上記の理由より、出来る限り早い段階で修正プログラムを適用して頂くことをお勧め致します。

[確認方法]
弊社技術情報 2793634 の事象は、以下の条件すべてに合致している場合、影響を受けていると判断できます。

1) SQL Server 2012 SP1 を使用 (11.*.3000.*) 、もしくはSQL Server 2012 SP1 CU1 (11.*.3321.*) を使用している

2) イベントログ (アプリケーション) に以下のようなメッセージが記録されている
--------------------------
イベント Id: 1004
ソース: MsiInstaller
説明: 製品 '{A7037EB2-F953-4B12-B843-195F4D988DA1}' 機能 'SQL_Tools_Ans'、'{0CECE655-2A0F-4593-AF4B-EFC31D622982}' のコンポーネントの検出に失敗しました。リソース ' が存在しません。

イベント Id: 1001
ソース: MsiInstaller
説明: コンポーネント '{6E985C15-8B6D-413D-B456-4F624D9C11C2}' の要求時に製品 '{A7037EB2-F953-4B12-B843-195F4D988DA1}'、'SQL_Tools_Ans' の機能の検出に失敗しました。
--------------------------

また、”ru.exe” ツールにより、現在のレジストリ サイズを確認できます。
レジストリ サイズが大きく拡張されていることが確認できた際は、早急に上記対処策のいずれかを実施することをご検討下さい。

実行例)
--------------------------
c:\tools\RU>ru.exe HKLM\SOFTWARE
Ru v1.0 - report registry key usage
Copyright (C) 2013 Mark Russinovich
Sysinternals - www.sysinternals.com

Values:       775666
Keys:         459811
Size:         118,216,154 bytes
--------------------------
Registry Usage (RU) v1.0
http://technet.microsoft.com/ja-jp/sysinternals/dn194428

[変更履歴]
2014/09/09 一部内容をUPDATEしました。
2014/11/21 一部内容をUPDATEしました。（エディション、発生頻度について）

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

今回は、SQL Server 2008 R2 と SQL Server 2012 の仮想化対応状況についてご紹介します。

以下に Hyper-V の各テクノロジー サポート状況をまとめましたのでご参考ください。

[参考情報]

Support policy for Microsoft SQL Server products that are running in a hardware virtualization environment
http://support.microsoft.com/kb/956893/en-us

"Running SQL Server 2008 in a Hyper-V Environment Best Practices and Performance Considerations"
http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docx

Hyper-V Virtual NUMA Overview
http://technet.microsoft.com/en-us/library/dn282282.aspx

Best Practices for Virtualizing and Managing SQL Server
http://download.microsoft.com/download/6/1/D/61DDE9B6-AB46-48CA-8380-D7714C9CB1AB/Best_Practices_for_Virtualizing_and_Managing_SQL_Server_2012.pdf

Virtual Hard Disk Sharing Overview
http://technet.microsoft.com/en-us/library/dn281956.aspx

Hyper-V Support for Scaling Up and Scaling Out Overview
http://technet.microsoft.com/en-us/library/hh831389.aspx

Increased Network Performance using SR-IOV in Windows Server 2012
http://blogs.technet.com/b/privatecloud/archive/2012/05/14/increased-network-performance-using-sr-iov-in-windows-server-2012.aspx

Hyper-V Network Virtualization technical details
http://technet.microsoft.com/en-us/library/jj134174.aspx

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

※ 本件は、Visual Studio サポート チームのブログの転載となります。

2014 年 12 月 10 日に公開され、Windows Update で配信された Visual Studio 2012 対象の KB3002339 の更新プログラムをインストールすると、Windows Update が完了しない、システム再起動時に更新が完了せずシステムがハングアップしてしまうという現象が発生することを確認いたしました。

KB3002339

https://support.microsoft.com/kb/3002339/

本問題の報告を受け、Windows Update の配信は既に停止いたしましたが、Windows Server Update Services (WSUS) を使用して更新プログラムを配信されているお客様におかれましては、本更新プログラムの配信を停止していただけますようお願い申し上げます。

既に本更新プログラムを適用し、ハングアップなどの現象が発生している環境での復旧方法につきましては、現在調査中です。進展があり次第、Visual Studio チーム記事にて情報公開させていただきます。最新の内容は下記 Visual Studio チームブログ（※12/11 アップデート内容がございます）をご覧ください。

Visual Studio サポートチームブログ
[ご注意ください] 12 月 10 日に Windows Update で配信された Visual Studio 2012 対象の更新プログラム KB3002339 をインストールするとシステムのハングアップなどの問題が発生する
http://blogs.msdn.com/b/jpvsblog/archive/2014/12/10/12-10-windows-update-visual-studio-2012-kb3002339.aspx

(12/11 追記転載) 本現象の発生条件、ならびに弊社での本問題に対する対応状況について以下にお伝えいたします。 ・本問題は Windows Update から KB3002339 の更新プログラムをインストールした場合に発生します。KB3002339 の更新プログラムをダウンロード センターから入手し、単体でインストールした場合には発生しません。 ・KB3002339 の更新プログラムは、Visual Studio 2012 がインストールされている環境が適用対象となります。また、Visual Studio 2012 Shell (Isolated) を利用するアプリケーションがインストールされている場合も適用対象となることが想定されます。 ・今回の問題について修正した新しいパッケージをリリースする予定です。リリースの日程が決まりましたら本 Blog でご案内します。なお、既に KB3002339 の更新プログラムがインストール済みの環境では、特に問題が生じることはありませんので、処置を行っていただく必要はありません。 ・本更新プログラムはセキュリティに関する修正ではありませんので、KB3002339 に記載されている現象が発生していない環境では、インストール時の問題が修正されたパッケージがリリースされるまで適用をお待ちいただいても問題はありません。 ・KB3002339 の更新プログラムの適用後、Windows Update の画面でインストールが完了しない現象が発生した場合は、タスク マネージャーから “VS11-KB3002339.exe” プロセスを終了させることで処理を続行させることが可能です。その後、前述のダウンロード センターからインストーラー パッケージを入手し、更新プログラムを単体でインストールすることで現象を回避できる可能性があります。

お客様には多大なご迷惑をおかけしておりますこと、深くお詫び申し上げます。

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

今回は、日本語照合順序 (Japanese、Japanese_90、Japanese_XJIS_100、Japanese_Unicode) での、長音、繰り返し符号の特殊な取り扱いについて紹介します。

[長音、繰り返し符号の特殊な取り扱い]

長音、繰り返し符号には、以下のものが存在します。

SQL Server で 日本語照合順序を使用している場合、長音、繰り返し符号は、特殊な文字として、全て等価の符号として取り扱われます。そのため、長音、繰り返し符号で検索を実施した場合には、全ての 長音、繰り返し符号が同じ符合(文字)として認識されるようになります。

具体的に REPLACE 関数を実行し、動作を見てみましょう。

上記のクエリでは、文字列 “長音符号 ー 繰り返し符号 ヽ”の中に、”々”が含まれている場合、”☆”に変換するというクエリになります。

クエリの結果を見ると、長音、繰り返し符号が、”☆”に変換されていることがわかると思います。 これは、長音符号 “ー”、繰り返し符号 ”ヽ”、繰り返し符号 ”々” がすべて同じ符号(文字) として扱われるためとなります。

しかしながら、特定の長音、繰り返し記号のみを REPLACE 関数などで変換する必要がある状況もあると思います。 この場合、明示的に バイナリの照合順序 (Japanese_BIN など)を COLLATE 句で指定することにより、実現することが可能です。

バイナリの照合順序の場合は、文字の比較の際に、文字コードで比較が行われ、長音、繰り返し符号でも特殊な取り扱いはされません。そのため、明示的に バイナリの照合順序を COLLATE 句 で指定することにより、各長音、繰り返し符号が別の符号(文字) として認識させることが可能になります。

[関連情報]

日本語照合順序での漢数字 〇 (0x815A) の取り扱いについて

日本語照合順序での 濁音、半濁音 の取り扱いについて

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

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

今回は、日本語照合順序での 漢数字 〇 の特殊な取り扱いについて紹介します。

[漢数字 〇 特殊な取り扱い]

漢数字 〇 の文字コードは以下のものになります。

SQL Server で 日本語照合順序を使用している場合、一部の日本語照合順序 (Japanese、Japanese_90、Japanese_Unicode) では、ソートの重み付けを持つ文字として 漢数字 〇 が登録されていないため、漢数字 〇 を含む文字列で LIKE 検索した場合に、意図しない検索結果が返る場合があります。

具体的に LIKE 検索を実行し、動作を見てみましょう。

上記のクエリでは、文字列 ”12” を、”1〇2” で LIKE 検索を実施し、LIKE 検索で指定した文字で検索ができた場合に “TRUE” を返すクエリになります。

クエリ結果を見ると、検索対象文字 “12” には、漢数字 〇 は含まれていませんが、LIKE 検索でヒットされます。

なお、漢数字 〇 を含む文字列で LIKE 検索を実施したい場合には、明示的に バイナリの照合順序及び SQL Server 2008 以降であれば、Japanese_XJIS_100、Japanese_Bushu_Kakusu_100を COLLATE 句 で指定することにより、実現することが可能です。

[関連情報]

日本語照合順序での長音、繰り返し符号の取り扱いについて

日本語照合順序での 濁音、半濁音 の取り扱いについて

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

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

今回は、日本語照合順序での 濁音、半濁音 の特殊な取り扱いについて紹介します。

[濁音、半濁音 の 特殊な取り扱い]

濁音、半濁音 の文字コードは以下のものになります。

SQL Server で 日本語照合順序を使用している場合、半角文字の後に濁音、半濁音を追加すると、”半角文字” + “濁音、半濁音” が 1 文字として認識されます。

具体的に LIKE 検索を実行し、動作を見てみましょう。

上記のクエリは、文字列 “ﾊ゛A” (半角カナ + 全角濁音 + 半角英数字 の3文字) を、文字列 “_A” (アンダースコア + 半角英数字) で LIKE 検索で指定した条件で検索ができた場合に “TRUE” を返すクエリになります。

LIKE 検索時に “_” (アンダースコア) を指定した場合、ワイルドカード文字として扱われ、今回の場合、”任意の 1 文字” + “A” の条件に合致した場合に “TRUE” が返されます。

LIKE (ƒTransact-SQL)

今回の例では、 文字列 “ﾊ゛A” は 3文字 ですが、”半角文字” + “濁音、半濁音” が 1 文字と認識されるため、文字列 “ﾊ゛A” が 2文字 として扱われたことにより、”TRUE” の結果が返されています。

[関連情報]

日本語照合順序での長音、繰り返し符号の取り扱いについて

日本語照合順序での漢数字 〇 (0x815A) の取り扱いについて

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