皆さん、こんにちは。SQL Server/Microsoft Azure SQL Database サポートチームです。今回のテーマは SQL Database から IaaS 環境へのデータ移行方法についてです。

Microsoft Azure SQL Database (以下 MASD) /Microsoft Azure 仮想マシン + SQL Server  (以下 SQL VM) をご利用いただいているお客様からよく頂くご質問の一つに、MASD から SQL VM へのデータ移行方法に関するものがあります。

当初は、MASD の使用した開発を検討していたが、SQL Server のフル機能を使用したいなど、開発途中で要件変更が発生し、別の環境にデータ移行を行う必要が出てくる可能性があると思います。 今回は、このような状況で役立つ、MASD から SQL VM へのデータ移行方法をご紹介します。

[前提条件]

データ移行先の Microsoft Azure 仮想マシンに SQL Server がインストールされていることを前提にしています。

[事前準備]

1) Microsoft Azure 仮想マシンに SQL Server がインストールされた環境を用意します。

※ Microsoft Azure 仮想マシン上の SQL Server を使用する上での注意点については、以下の Blog を参考ください。

Windows AzureのIaaS機能でSQL Serverを使ってみよう

2) Microsoft Azure 仮想マシン上の SQL Server 上で、以下の設定を実施します。

• SQL Server 認証の有効化 (設定方法は技術情報の サーバーの認証モードの変更を参照)
• SQL Server ログインを作成 (設定方法は技術情報の ログインの作成を参照)

[移行手順]

1) コマンドプロンプトを管理者として実行します。

2) SqlPackage.exe が配置されているパスに移動します。既定では以下のディレクトリに存在しています。

3) SqlPackage.exe で “Export” オプションを使用して、SQL Database のデータベースのバックアップを取得します。

以下に最低限指定するパラメータを記載します。 使用方法の詳細は末尾のリンクを参照。

実行例)

SqlPackage.exe

/Action:Export

/SourceServerName:abcdefg.database.windows.net

/SourceDatabaseName:abcdefg

/SourceUser:testuser

/SourcePassword:password

/TargetFile:c:\work\abcdefg.bacpac

※可読性の為、改行していますが1行にして実行してください。

4) SqlPackage.exe で ”Import” オプションを使用して先程のバックアップをインポートします

実行例)

SqlPackage.exe

/Action:Import

/TargetServerName:abcdefg.cloudapp.net

/TargetDatabaseName:AdventureWorks2012

/TargetUser:sa

/TargetPassword:abcdefg!

/SourceFile:c:\work\abcdefg.bacpac

※可読性の為、改行していますが1行にして実行してください。

[参考情報]

SqlPackage.exe

サーバーの認証モードの変更

ログインの作成

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

みなさん、こんにちは。若葉マークブログの第 3 回は、システム データベースについてお話したいと思います。

システム データベースとは、SQL Server が動作する上で必要なデータベースで、master、msdb、model、Resource、tempdb の5つのデータベースがあります。以下の表をご参照下さい。

また、SQL Server 2012 の既定のインスタンス (MSSQLSERVER) におけるデータベースを構成するファイルの既定の場所も記載しております。

<参考情報>

システム データベース
http://technet.microsoft.com/ja-jp/library/ms178028(v=sql.110).aspx

システム データベースのリストア手順
http://blogs.msdn.com/b/jpsql/archive/2013/08/16/10442187.aspx

DO’s&DONT’s #17: やっておいた方がいいこと - tempdb データファイル数を CPU 数に一致させる
http://blogs.msdn.com/b/jpsql/archive/2013/01/17/do-s-amp-dont-s-17-tempdb-cpu.aspx

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

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

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

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

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

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

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

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

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

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

こんにちは。
SQL Server Integration Services (以下 SSIS) でのログ出力方法についてご案内します。
今回は、3 つの方法をご紹介します。

1. パッケージ開発ツールでのログ出力設定
2. dtexec パラメーター指定でのログ出力 
3. SSISDB データベース内のログを参照する  ※SQL Server 2012 以降のバージョンでのみ利用可能

*** SSISDB について補足 ***
SQL Server 2012 より新機能としてプロジェクト配置モデルという実行形態が導入され、配置先に SSISDB が利用できるようになりました。
これに伴い、パッケージ開発ツールも一新されています。SQL Server 2012 以降は従来の SSIS パッケージの開発/実行形態をレガシ SSIS と呼び区別しています。

ではさっそく見ていきましょう！

1. パッケージ開発ツールでのログ出力設定

1) SQL Server Business Intelligence Studio、もしくは SQL Server Data Tools を [管理者として実行] から起動し、プロジェクトを開きます。 
※ どちらの開発ツールも Visual Studio ベースであり、以降のログ採取手順は同じです。

2) [SSIS] メニュー - [ログ記録] を選択します。 --> SSIS ログの構成 画面が開きます。

 

3) 左部ペインの コンテナーに チェックを入れます。パッケージ全体の実行をログするように設定します。

4) [プロバイダーとログ] タブから下記を選択し、追加 ボタンをクリックします。
- プロバイダーの種類: テキストファイルの SSIS ログ プロバイダー --> [テキストファイルの SSIS ログ プロバイダー] が生成されます。

5) [テキストファイルの SSIS ログ プロバイダー] にチェックを入れます。

6) 構成 の列から、新しい接続を選択します。 --> ファイル接続マネージャー エディター 画面が表示されます。

7) ファイル接続マネージャー エディター 画面にて、下記の設定を行い、設定を保存します。

- 使用法の種類: ファイルの作成
- ファイル: 参照ボタンより任意のパス、ファイル名（例：log.txt など）を指定します。

8) [詳細] タブを選択します。イベントの左のチェックを有効にし、すべてのイベントをログするように設定後、[OK] をクリックし、設定を保存します。

上記設定を経て、パッケージを実行頂きますと、手順 7) で指定頂いたパスにログ情報が出力されます。

この例ではテキストファイルにログを出力していますが、他の形式としてSQL Server やイベントログに記録することも可能です。
詳細は、下記を参考にしてください。

Integration Services (SSIS) のログ記録

2. dtexec パラメーター指定でのログ出力

dtexec により、コマンドプロンプトからSSISパッケージを実行することが可能ですが、実行時のパラメーター指定によってログ出力の指定が可能です。
パッケージの再ビルドはできないけれど、ログ出力だけ操作したい時など便利ですね。
代表的なパラメーターとして、/VLog と /Rep をご紹介します。

/VLog

例) dtxec /F package.dtsx /VLog c:\work\test.log

/VLog の後に指定したパス (この場合 c:\work\test.log) のテキストファイルにログが出力されます。
SQL Server 2005 SP3以降から利用可能なパラメーターです。

/Rep

例) dtxec /F package.dtsx /Rep EW

出力するログレベルを変更する場合は /Rep パラメータを使用します。既定のレベルは、E (エラー)、W (警告)、P (進行状況) です。
/Rep EW とすれば、進行状況は除外してエラーや警告のみに絞ったログ出力が可能です。
/Rep V とすれば、詳細モードにてログを出力します。(V は他の引数と同時に指定できないので、単独で指定してください。)

※なお、コンソールの出力内容をコマンドプロンプトのリダイレクト (>, >>) を使用することで、ファイル出力可能です。

各パラメーターの詳細については、下記技術情報を参考にしてください。

dtexec ユーティリティ

3. SSISDB データベース内のログを参照する

SQL Server 2012からは新たにプロジェクト配置モデルがサポートされましたが、SSIS サーバーに配置されたパッケージを実行する際にもログ記録について設定が可能です。

1) SQL Server Management Studio のオブジェクト エクスプローラーで、パッケージに移動します。
    [統合サービス カタログ] - [SSISDB] - [フォルダ名] とノード展開してください。

2) パッケージを右クリックし、[実行] をクリックします。

3) [パッケージの実行] ダイアログ ボックスで、[詳細設定] タブをクリックします。

4) [ログ記録レベル] で、ログ記録レベルを選択します。

5) 他のパッケージの構成を完了し、[OK] をクリックしてパッケージを実行します。

ログの参照方法
上記ログは、SSISDBカタログの内部テーブルに保存されています。クエリやビューで参照可能ですが、SQL Server Management Studioからレポートとしてグラフィカルに表示させることが可能です。
SQL Server Management Studioにて [統合サービス カタログ] - [SSISDB] - [フォルダ名] とノード展開し、[パッケージ名] で右クリック、[レポート] - [標準レポート] - [すべての実行] をクリックします。 




下記のようなレポート一覧が表示されます。プロジェクト実行毎に 1 行表示されています。さらに詳細を確認するにはレポート内の各リンクをクリックしてください。



表示される具体的な内容は、下記を参考にしてください。

Integration Services サーバーのレポート

ログの提供方法
サポートサービスをご利用いただく際など、SSISDBカタログ内に採取されたログのご提供が必要なケースがあります。
この場合、SSISDB データベースのバックアップを採取ください。

- 手順
1) SQL Server Management Studio から、該当のインスタンスに接続します。

2) 該当のデータベース (SSISDB) を右クリック [タスク] - [バックアップ] をクリックします。

3) 画面下部の [バックアップ先] に表示されているフォルダパスを控えます。

4) 画面で表示されている状態のまま[OK]をクリックします。3) のフォルダ配下にバックアップファイルが格納されますので格納されたバックアップファイル (SSISDB.bak) を送付下さい。

以上です。

SQL Server Integration Service パッケージにて、OLE DB プロバイダーを使用してフラットファイルをインポートすると正しくない結果となる場合があります。
この事象について例を基に対処方法について紹介します。

例
以下の様なシンプルな Integration Services パッケージを想定してください。

取り込み先のテーブル定義
CREATE TABLE [dbo].[Table_1](
    [Col1] [int] NULL,
    [Col2] [int] NULL,
    [Col3] [int] NULL,
    [Col4] [int] NULL,
    [Col5] [int] NULL,
    [Col6] [int] NULL
)

CSV ファイル

パッケージ
この様に非常にシンプルなパッケージを想定してください。

パッケージ実行結果
パッケージ実行の結果、Table_1 には以下の様にデータが格納されます。

CSV ファイルの 2、4、5 列目は空文字であるにも関わらず、その前に位置する数値が挿入される結果となります。
本来ならば、「数値型へ空文字を挿入できない」というエラーが発生するか、以下の様な結果を期待すると思います。

要因
申し訳ございませんが、Microsoft OLE DB Provider for SQL Server の Bug です。


条件
この現象が発生する条件は、以下の通りとなります。

・データベースへアクセスするプロバイダーとして Microsoft OLE DB Provider for SQL Server を使用している(*1)
・取り込み先対象のテーブルに、数値型の列（int や float、smallint 等）が複数存在する
・フラットファイルのデータが空文字でサイズが 0 である
・空文字が存在するうち、フラットファイルの先の列に適切な（エラーとならない）数値型のデータが存在する(*2)

(*1) 使用しているプロバイダーは接続マネージャーから確認できます。


(*2)
「1,2,<空文字>」のように空文字の前に有効な数値データが存在する場合、本現象が発生します。
「<空文字>,1,2」の様な場合だと、以下の様なエラーが発生します。

対処方法
以下のいずれかの対処方法が有効となります。
どのような実行結果としたいか、によって対処方法を検討してください。

・データソースの NULL 値を保持する扱いとする
・プロバイダを変更する
・列型を文字列型に変更する

データソースの NULL 値を保持する扱いとする
空文字は、NULL として扱い、そのままテーブルに取り込みますと、空文字が Null として扱われ、以下の結果となります。

-- 設定手順
(1) フラット ファイル ソース エディターを開きます。
(2) [接続マネージャー] のページから「データソースの NULL 値をデータ フローで NULL 値として保持する」のチェックを ON にします。

 この設定を実施すると、以下の様な結果となります。

プロバイダを変更する
Microsoft OLE DB Provider for SQL Server ではなく、SQL Server Native Client を使用します。

本来、SSIS パッケージ上で、フラットファイルの空文字をデータベースに取り込む場合、取り込み先が int などの数値型の場合、型が合致しない旨のエラーが発生します。
SQL Server Native Client を使用した場合には、本来のエラーである「型が合致しない」というエラーが発生するようになります。

空文字を 数値列に取り込まない、という考えになり、データのチェック機構が働くこととなります。

列型を文字列型に変更する
int を、空文字が取り込めるように、varchar 等の文字列型に変更する案となります。

今回の記事では、SQL Server データアクセスを行うアプリケーションについて、その実体の配置場所によって処理の遅延が発生し、接続処理がタイムアウトしたという事例について紹介いたします。もし、身近に同様の事例や、経験をお持ちの方は、以下の内容がご参考になれば幸いです。

事例 : 「ファイル共有に配置したADO から ADO.NET アプリケーションに移行したら遅くなった」

ADO 経由で SQL Server に接続しデータアクセスを実行するアプリケーション（*.exe）を共有フォルダ上に配置し、クライアントには共有フォルダ上のアプリケーションのショートカットをダブルクリックしてアプリケーションを実行していたシステムを、.NET Framework で再構成し、ADO.NET 経由で SQL Server に接続するようにマイグレーションしたところ、SQL Server への接続が高確率でタイムアウトするようになった。
接続文字列で、"Connection Timeout" プロパティを 120 秒程に延長してみたが、状況は改善しなかった。処理の序盤ではタイムアウトせず、だんだんタイムアウトしていく確率が上がっていくような動きになっている。そこでアプリケーションをクライアント ローカルもしくは SQL Server と同じ環境に配置したところ、タイムアウトは一切発生しないことがわかった。 検証結果から、アプリケーションの配置場所がローカルか、リモートかという違いのみ、動作に影響しているようであるが、以前の ADO 経由のアプリケーションでは問題が発生しなかった。

発生例) Visual Basic 6.0 アプリケーションから Visual Basic (.NET Framework ベース) に移行した場合など

この事例での対処

この問題は障害ではなく、以下の二つの要因により接続処理のすべてのフェーズが接続タイムアウト期間中に完遂していない可能性が高いという判断に至りました。このため、この件ではアプリケーションの配置を各ローカルに変更することにより、問題を解消することができました。

1. 非同期で読み込まれていくアプリケーション実行関連のファイル（DLL、EXE、ini、config ファイルなど）のネットワーク伝送およびネットワーク伝送処理における IO のオーバーヘッド 
2. .NET Framework に搭載されたコード アクセス セキュリティの監査の影響

もし、本記事をご覧いただいている方が同じ同様の構成で同様の状況が発生しているのであれば、アプリケーションの配置をローカルにしていただき、状況が改善するか確認してみてください。ローカル配置で状況が改善するのであれば、アプリケーションの配置場所や、配布方法の見直しをしていただくことをお勧めします。

図 : クライアント コンピュータからサーバーの共有フォルダに配置した実行ファイル (exe) を実行し、さらに SQL Server に接続を行うパターン
SQL Server へのセッションは三つのフェーズをすべて時間内に成功して初めて確立される上、各フェーズ毎に実際には何回もパケットがやり取りされている。
その為、プロセスの SQL Server への接続以外の処理が入ると、プロセスの全体的な動作が遅延しタイムアウトしてしまうことなどがある。 ファイルロード処理はプログラムのメインの処理と非同期に行われることもあるが、IO の状況などによってはメインの処理（たとえば、SQL Server への接続など）が待たされるということも有り得る。

図 : クライアント コンピュータローカルに配置した実行ファイル (exe) から SQL Server に接続を行うパターン
プログラムに実行するためのファイルはローカルの HDD からロードされる。従って、ネットワーク経由での起動と異なりネットワーク伝送のオーバーヘッドも、コードアクセスセキュリティの制限対象外になるため、検証のオーバーヘッドもない。

どのような調査をしたか

クライアント - SQL Server 間でネットワーク トレースを採取したところ、以下の状況が把握できました。
このため上記の見解となりました。

・多数のプログラム関連のファイル読み込みの処理が実施されている合間で SQL Server へのネットワーク伝送処理が行われている
・SQL Server へのセッション確立関連のパケット送出がプログラム上での SqlConnection.Open() から数十秒経過してから開始されている
・.NET Framework のセキュリティの仕組み上、リモートに配置されたアセンブリはローカルに配置されたアセンブリと異なり、完全に信頼されるものとはみなされず、また、アセンブリが配置されている場所に応じたアクセス制限を設定することが可能となっている。この仕組みのため、リモートに配置されアプリケーションの実行は、ローカルに配置されたアプリケーションに比べて実行時のオーバーヘッドが存在する

Visual Basic 6.0 と .NET Framework の違いについて

Visual Basic 6.0 設計時よりも、セキュリティについての重要性が格段に増している現代において設計された .NET Framework ベースのアプリケーションの設計思想のうち最も重要なコンセプトのひとつがセキュリティです。

.NET Framework では、Code Access Security (CAS) と呼ばれるセキュリティの仕組みが導入されており、実行しようとしているプログラムが、どこに配置されているものか、デジタル署名がなされているかなどといった情報をもとに、信頼された安全なプログラムであるか検証することが可能です。アプリケーションが実際に実行するマシンからみてどこに配置されているものかという情報については、ローカル マシン上、イントラネット上の共有フォルダー、インターネット上といった区別に応じて、プログラムが実行できる処理内容を細かく制限できるような機能が提供されるようになりました。これにより、例えば、フィッシング等により、ユーザーが意図せずインターネット上の危険なプログラムを実行した場合でも、システム フォルダーへの書き込みや、レジストリの変更などは行えないように保護する、といった設定が可能となっています。

図 : ローカル外の環境から実行するファイルの安全性は必ず保障できるわけではない

.NET Framework では、対象のプログラムの配置場所にも応じたセキュリティの機能を提供している関係で、セキュリティ機能を持たない Visual Basic 6.0 アプリケーションと比較して安全である反面、各種検証処理のためにパフォーマンス的には不利な面が出てくることになります。このため、環境のリソース使用状況や、性能などによって必ずしも発生するとは限りませんものの、出来る限りパフォーマンスを重視するシステムや、今回のようにタイムアウト期間中に一連の処理を完了しなくてはいけないような処理を実装する場合においては、このような機構的な問題があり得るため、共有フォルダに .NET アプリケーションを配置して運用することは推奨できません。

.NET Framework の CAS の機能の詳細につきましては、以下のドキュメントをご参照ください。

  .NET Framework 2.0 でのコード アクセス セキュリティの新機能の探索
  http://msdn.microsoft.com/ja-jp/magazine/ee177036.aspx

なお、上記ドキュメントのとおり、.NET Framework 2.0 の CAS の構成は非常に複雑であり、導入・運用上の負担が大きいものでした。このため、.NET Framework 4 では本機能が大幅に変更・簡略化されております。ただし、セキュリティ関連のチェック処理を搭載していなかった Visual Basic 6.0 のレベルまで簡略化されていることを意味するものではございません。
.NET Framework 4 におけるセキュリティの変更に関しましては、以下のドキュメントをご参照ください。

  .NET Framework 4 におけるセキュリティの変更点
  http://msdn.microsoft.com/ja-jp/library/dd233103(v=vs.100).aspx

一般的にリモート アクセスにおいてパフォーマンスを両立させたい場合のソリューション

デスクトップ アプリケーションを各端末にインストールする運用では、アプリケーションのバージョンアップや修正が必要となった際のコストが高くなりがちです。一方、Web アプリケーションの場合はバージョン アップ時などの展開にかかるコストは抑えられる反面、デスクトップ アプリケーションと比較してリッチな描画や応答性の面で劣り、ローカルリソースへのアクセスも制限されるといったデメリットがあります。このように、デスクトップ アプリケーションと Web アプリケーションではトレードオフとなる部分があります。

また、このトレードオフの打開策として、デスクトップアプリケーションを共有フォルダーに配置して、リモートから実行するというソリューションが考えられますが、前述のとおり、こちらの方法は推奨されません。

マイクロソフトでは、この問題に対する解決策の 1 つとして、ClickOnce というデプロイメント テクノロジーを提供しています。ClickOnce では、通常のデスクトップ アプリケーションをローカルで実行可能なため、リッチな描画や応答性を維持することが可能であり、かつ、バージョンアップ時にはインストール ポイントに配置された資源をアップデートするだけで、ユーザーが特別な操作を行わなくても、アプリケーションの更新が自動的に実行されます。

管理者権限が必要な処理は行えないなどといった制限もあるため、必ずしも ClickOnce が配布に関する全ての問題を解決できるわけではありませんが、アプリケーションの展開方法の 1 つとして検討していただければ幸いです。

配置ストラテジの選択
http://technet.microsoft.com/ja-jp/subscriptions/index/e2444w33(v=vs.100).aspx

ClickOnce と Windows インストーラの使い分け
http://msdn.microsoft.com/ja-jp/library/ms973805.aspx

ClickOnce によるクライアン�� アプリケーションの配置の紹介
http://msdn.microsoft.com/ja-jp/library/ms996413.aspx

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

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

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

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

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

SQL Server の新しいバージョンで、データベース バックアップ時に記録されるログが追加されましたので、ご紹介します。

変更点

SQL Server 2012 SP2、SQL Server 2014 から、イベントログ(アプリケーション) と SQL Server エラーログに、バックアップ完了時に次のようなメッセージが記録されるようになりました。

例: SQL Server 2014

イベント ID 18264 とともに、イベント ID 3014 が記録されます。

イベントログ (アプリケーション)

SQL Server エラーログ

例: SQL Server 2012 SP1

イベント ID 18264 のみが記録されます。

イベントログ (アプリケーション)

SQL Server エラーログ

補足

このメッセージは、以前はバックアップ完了時にクライアントに返されるだけでした。

しかしながら、バックアップ パフォーマンス等バックアップの調査をするにあたり、過去のバックアップの実行時間が重要な手がかりになることがあります。 クライアントだけではなく、サーバーにも記録して残しておくことで、よりスムーズな調査ができるようにするための変更となります。バックアップの動作自体には全く影響はないため、ご安心ください。

横井 羽衣子
Microsoft SQL Developer Support Engineer

みなさんごきげんよう。本日は、Visual Studio 2012 の MFC CDatabase クラスにおける実装変更と、それに伴う挙動の変化についてご紹介します。この挙動は、レガシー テクノロジの一つである ODBC カーソル ライブラリが非推奨になったことに伴う変更です。
ODBC カーソル ライブラリをはじめ、いくつかの古くから存在するデータアクセス テクノロジには時代の変化に伴い、非推奨となった機能があります。今回の記事では、そうした非推奨となった機能についての情報を今後確認頂くための情報などもご紹介します。

【現象】
Visual Studio 2012 より前のバージョンの MFC の CDatabase クラスで以下の条件で処理を実行した場合と、Visual Studio 2012 以降の同クラスを用いた場合で接続先の SQL Server のバージョンに関わらず、処理の結果が異なる。
実装の流れは以下の通り。

1. CDatabase::OpenEx() のオプションに、CDatabase::useCursorLib を指定してデータベースをオープン
2. CRecordset::Open() でレコードセットタイプ (nOpenType) を明示的に指定しないか、あるいは CRecoredset::snapshot(※) を指定して Edit() メソッドを実行する

結果は以下の通り。

(※) CRecoredset::snapshot は既定値であり、レコードセットタイプを指定しない場合はこの値が適用される。

【解説】
概要
ODBC カーソル ライブラリが非推奨になったため、Visual Studio 2012 以降はサーバー カーソルを使用するように MFC の実装が変更されたことが要因となります。CRecordset クラスを使用して SQL Server でサーバー カーソルを開く場合、既定値でもある CRecoredset::snapshotが適用される場合、読み取り専用の静的カーソルとなるため、CRecorset を通しての更新は許可されません。この結果、Edit() メソッドで「更新ができない」旨のエラーが発生します。
ODBC カーソル ライブラリが非推奨となったために動作が変更されたことを踏まえた場合、対処方法は以下のいずれかです。

A. ODBC カーソル ライブラリを使う派生クラスを実装して使用する。
B. CRecordset クラスにオプション指定することで更新可能なカーソルを使用するようにする。

しかし、MFC の実装変更理由が ODBC カーソル ライブラリが非推奨になったためであることを考慮した場合、将来性の観点では A よりも B のほうが望ましい方法であると言えます。従って、弊社としては、このパターンの場合はB の対処を推奨しています。

詳細
なぜ CRecordSet::Edit() で更新しようとしてエラーになるか
Visual Studio 2012 以前のバージョンでは、SQL_CUR_USE_ODBC (ODBC カーソル ライブラリ：クライアントカーソル) が指定されていましたが、Visual Studio 2012 以降は既定で SQL_CUR_USE_DRIVER (サーバーカーソル) が使用されるように変更されています。
MFC 側での変更箇所は、Visual Studio 付属の MFC のソースコード中の dbcore.cpp 内の CDatabase::AllocConnect()で確認できます。
(MFC のソースは、C:\Program Files (x86)\Microsoft Visual Studio <バージョン>\VC\atlmfc\src\mfc にあります。例 : VS2012 / C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\atlmfc\src\mfc)

■ VS2012 以前のバージョン付属 dbcore.cpp (CDatabase::AllocConnect())
----------<抜粋 ここから>----------
            // Turn on cursor lib support
            if (dwOptions & useCursorLib)
            {
                        AFX_SQL_SYNC(::SQLSetConnectOption(m_hdbc,
                                    SQL_ODBC_CURSORS, SQL_CUR_USE_ODBC));
                        // With cursor library added records immediately in result set
                        m_bIncRecordCountOnAdd = TRUE;
            }
----------<抜粋 ここまで>----------

■ VS 2012以降のバージョン付属 dbcore.cpp (CDatabase::AllocConnect())
----------<抜粋 ここから>----------
            // Turn on cursor lib support
            if (dwOptions & useCursorLib)
            {

                        AFX_SQL_SYNC(::SQLSetConnectAttr(m_hdbc, SQL_ATTR_ODBC_CURSORS, (SQLPOINTER)SQL_CUR_USE_DRIVER, 0));
                        // With cursor library added records immediately in result set
                        m_bIncRecordCountOnAdd = TRUE;
            }
----------<抜粋 ここまで>----------

CRecordset::Open() でレコードセットタイプ (nOpenType) を明示的に指定されていないと、既定値 CRecoredset::snapshotが適用されることになります。(あるいは、明示的に CRecoredset::snapshotを指定していても同じです) これは静的カーソルを開くことを意味します。SQL Server では、静的カーソルは読み取り専用となります。このため、更新できずにエラーが発生します。

参考 :
CRecordset::Open
https://msdn.microsoft.com/ja-jp/library/1hkkwdf0.aspx

CRecordset::snapshot   双方向スクロールが行われる静的レコードセット。 レコードのメンバーシップと順序は、レコードセットを開いたときに決定されます。データ値は、レコードをフェッチしたときに決定されます。 他のユーザーが行った変更は、レコードセットを閉じてから再度開くまで表示されません。

CRecordset の既定値は CRecordset::snapshot です。  既定値の機構により、Visual C++ ウィザードで既定値の異なる ODBC CRecordset と DAO CDaoRecordset 両方を操作できます。

静的カーソル (データベース エンジン)
https://technet.microsoft.com/ja-jp/library/ms191286(v=sql.90).aspx

Microsoft SQL Server 2005 の静的カーソルは常に読み取り専用です。

なお、今回の現象は Microsoft Connect サイトで、実際に MFC の開発エンジニアが、ODBC カーソル ライブラリは非推奨の旨のコメントを表明しています。

CDatabase::useCursorLib broken in MFC11
http://connect.microsoft.com/VisualStudio/feedback/details/760374/cdatabase-usecursorlib-broken-in-mfc11

投稿者: Microsoft、投稿日時: 2013/01/10 13:38 Hello, Thanks for the report. We have investigated and found that this change was made because the SQL_CUR_USE_ODBC value was deprecated, so the MFC library build failed if that option was used. If this is causing problems in your application's behavior, I suggest you check with the SQL Server forum at http://social.msdn.microsoft.com/Forums/en-US/category/sqlserver/ to ask about solutions. You also may be able to set the option on your HDBC yourself, but this may not be supported. Pat Brenner Visual C++ Libraries Development

従いまして、今後のバージョンにおいても、VS2012 以降の変更をベースとした対応になる方向です。

対処方法について
弊社が製品利用において、今後将来を踏まえて検討した場合と、対処方法の方向性は以下の二つが挙げられます。

A. ODBC クライアントカーソルを使用するよう派生クラスを作成する。
B. サーバーカーソルで更新可能なカーソルを使用するようにする。

<対処 A について>
ODBC カーソル ライブラリを使用するためには、自分が使用するために、 VS2012 以前のバージョン付属 dbcore.cpp をベースに派生クラスを作成し、OpenEx メソッドをオーバーライドしたものを参照するようにします。

<対処 B について>
対処 A は、上記の通り、ODBC カーソルライブラリを使用するように明示的に実装したクラスを代替利用しますため、事実上以前と同じ動作結果を得ることが可能です。
しかしながら、MFC の実装が変更された理由は、ODBC カーソルが非推奨となったためであることを踏まえると、対処 A については技術面では、想定通りの結果が得られるという点で対処可能ですが、今後の将来性を考えると妥当とは言えません。
このため、今回を機会に、サーバー カーソルのうち更新可能なカーソル タイプを利用いただくようにしていただくことをお勧めします。
CRecordset クラスを使う場合には、CRecordset::Open() において nOpenType に CRecordset::dynaset もしくは CRecordset::dynamic を指定する方法で更新可能なカーソルタイプを使用することが可能です。

データアクセスコンポーネントの今後を確認するための情報について

ODBC カーソルライブラリも含め、データアクセステクノロジの今後については、以下のページを随時更新しています。

データアクセスコンポーネントは、予告なく突然サポートを打ち切ったり、同梱しなくなるといったようなことはありませんが、必ず数年前から非推奨になった旨が告知され、いずれ終了する形を取っています。こちらのページは日本語版もありますが、内容が古く、英語版が随時更新されますので、今後方向性を検討される際は都度ご一読ください。

Data Access Technologies Road Map
http://msdn.microsoft.com/en-us/library/ms810810.aspx
→ "has been deprecated. " = 推奨しない

ODBC カーソル ライブラリが非推奨であることは以下に記載があります。

ODBC カーソル ライブラリの扱い（今後 OS 同梱されなくなるか）
ODBC カーソル ライブラリはもともと、SQL Server などのデータベースでカーソルという概念がない時代、アプリケーション側でデータを読み出す際に順次読みだす実装を実現するために作成された機能です。ただし、サーバー カーソルが実装された後も、互換性のために残され続けたという歴史的な経緯があるコンポーネントです。今後において、少なくとも現時点で廃止の明確な時期は決まっていませんが今後の OS に搭載されることは保証しません。 また、一般的に、クライアントカーソルは、少量データなどを使用する場合に適しており、大量のデータを必要とする場合ではデータ転送負荷、およびクライアント環境への依存度（マシンスペック、領域等）といった観点で推奨されません。また、実装設計も古い時代のままで(※) あることなどを踏まえ、弊社においては、ODBC カーソル ライブラリをどうしても使用せざるを得ないご事情がある場合を除き、基本的にカーソル タイプの変更を推奨しております。

(※) たとえば、ODBC カーソル ライブラリはカーソル動作を実現するために、データソースから受け取ったデータを一時フォルダ（環境変数 TEMP）にファイルを作成し、アプリケーション側でそのファイルからデータを読み出しています。現在では、SQL Server 側でサーバー カーソルの機能を持つことから、実装や設計も古く（たとえば、一時ファイルのサイズ上限として 2GB であることなど）、現在に至るまで機能更新もない状況である ODBC カーソル ライブラリを必ずしも使用する必要は無くなっています。 また、上記のように、ネットワーク伝送だけでなく、ファイル作成、読み取りのオーバーヘッドがあることから、パフォーマンスについてもギガビットネットワークが主流の現在においては、サーバーカーソルに優位性が十分あります。

これは、削除されなかった仮の記事です。この記事を手動で削除してください。(12ac1d33-384c-44a3-b8ac-3ba7f6e5555e - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

皆さん、こんにちは。 今回は 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 Developer Support チーム
須田 恵

現象
このたび SQL Server 2014 Reporting Services におきまして、パフォーマンスオブジェクト ReportServer:Service が適切に動作しないことが判明しました。
ReportServer:Service 内のすべてのカウンターにおいて、値が 0 のまま更新されません。
弊社製品の不具合によりご迷惑をおかけしていることを、深くお詫び申し上げます。

現在、本不具合の修正について検討中の段階ですが、詳細が確定しましたら、あらためまして本ブログにてお知らせするとともに、弊社サポート技術情報 (KB) での公開も予定しております。

対象製品バージョン
SQL Server 2014 Reporting Services
(2012 など以前のバージョンには該当しません。)

代替案について
Reporting Services のパフォーマンス傾向は、パフォーマンスモニターの Process オブジェクトにおいて、該当の Reporting Services インスタンスのカウンターを監視することで確認することが可能です。
大変恐縮ですが、代替案としてご検討ください。

※本記事は 2015 年 2 月時点の情報です。

佐藤 靖典
SQL Developer Support Engineer

みなさん、こんにちは。

今回は、Visual Studio 2013 の SQL Server Data Tools (SSDT) 日本語版を使用している開発者の方が遭遇する可能性のある問題と対処方法を紹介します。

[1] 事象

SSDT のアップデートを行うと、次のように SSDT のエディタのフォントが色分けされなくなる事象が発生する場合があります。 この事象が発生したら、以降の対処策をご確認ください。

[2] 対処策

次のどちらかを実施ください。

(a) Visual Studio 2013 Update 3 以上を適用する。
(b) レジストリ キーを削除する。

(a) Visual Studio 2013 Update 3 以上を適用する。

Visual Studio 2013 の [ツール] メニューの [拡張機能と更新プログラム] から、Visual Studio 2013 Update 4 を適用します。(2015 年 2 月現在では、Visual Studio 2013 Update 4 が最新です。)

(b) レジストリ キーを削除する。

次のレジストリ キーを削除します。

  [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\FontAndColors\Cache]

削除の手順は以下の通りです。

1) レジストリ エディタ (regedit.exe) を起動します。

2) 上記のキーを右クリックし、[削除] を選択します。

3) [キーの削除の確認] ダイアログが表示されますので、[はい] ボタンをクリックします。

対処後の状態

Visual Studio 2013 を再起動しますと、SSDT のエディタのフォントが色分けされるようになります。

[3] 詳細

以前のバージョンの SSDT は、上記のレジストリ キーのフォントと色の設定についてのキャッシュ情報を使用しておりました。
SSDT バージョン 12.0.40706.0 以降では、以前のバージョンと異なるキャッシュ情報を使用するように内部実装が変更されており、上記のレジストリ情報が残っている場合、Visual Studio 2013 Update 3 以前のバージョンでは、色分けされない場合があります。

なお、この事象は、英語以外のローカライズ版の SSDT で発生する可能性があります。

[4] 補足

SSDT のバージョンは、Visual Studio 2013 の[ヘルプ] メニューの [Microsoft Visual Studio のバージョン情報] から確認可能です。

インターネットに接続していない日本語 Windows 環境に「SQL Server 2014 Express日本語版 x86」 をインストールする場合の以下 2点についてお話したいと思います。

  -  インストール要件
  -  インストール/アンインストールされるコンポーネント

本ブログが SQL Server 2014 のインストールに関して公開している以下のトピックを補足するものとして役立てばうれしいです。
 
◆SQL Server 2014 のインストールに必要なハードウェアおよびソフトウェア
http://msdn.microsoft.com/ja-jp/library/ms143506.aspx

【インストール要件】

<補足>
1 : x86 (32bit) および x64 (64bit) の OS にインストールする場合、どちらにもあてはまります。

2 : [インストール済み確認方法] はいずれもレジストリ値を確認する方法です。レジストリ値はレジストリ エディタ ([ファイル] -> [ファイル名を指定して実行] -> ボックスに regedit.exe と入力し、[OK] を使って確認できます。

3 : [インストール済み確認方法] のレジストリ値は、x64 環境では以下の WOW64 (Windows 32-bit On Windows 64-bit) のレジストリでも確認可能です。
\Microsoft 以降は、上記レジストリと同じ内容となります。

/// .NET Framework ///
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP

/// PowerShell 2.0 ///
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\PowerShell\1\PowerShellEngine
PowerShellVersion (REG_SZ) = 2.0 
 
4 : スタンドアロン (インターネットに接続していない) 環境では、.NET Framework 4.0 以上をインストールしても、.NET Framework 4.0 以上の言語パックは、自動でインストールされません（Web インストーラーでは、自動で言語パックもインストールされます）。また、.NET Framework 4.0 以上の言語パックがインストールされていない環境では、「SQL Server 2014 Express日本語版 x86」のインストールは行なえません。

 5 : 上記インストール要件を満たしていなくても、「SQL Server 2014 Express日本語版 x86」をインストールできる場合があります。しかし、このインストール要件は、動作を含めた上での必須コンポーネントであり、推奨事項となります。

<補足>
上記、アンインストール後に残るコンポーネントは、いずれも SQL Server に接続するアプリケーションで使用されるデータ アクセス用の再頒布可能なコンポーネントです。SQL Server インスタンスをアンインストールした場合でも、当該マシン上で動作するアプリケーションで使用する場合もありますので、同時削除は行わない動作仕様となっております。そのため、残っていても問題のないコンポーネントです。

 

<参考情報>

◆Windows PowerShell の新機能 
https://technet.microsoft.com/ja-jp/library/dd378784(v=WS.10).aspx 

◆.NET Framework のインストール (.NET Framework 4) 
https://msdn.microsoft.com/ja-jp/library/5a4x27ek(v=vs.100).aspx 

◆.NET Framework 4.5、4.5.1、および 4.5.2 のインストール 
http://msdn.microsoft.com/ja-jp/library/5a4x27ek(v=vs.110).aspx 

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

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

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

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

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

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 Integration Services (以下 SSIS) でのログ出力方法についてご案内します。
今回は、3 つの方法をご紹介します。

1. パッケージ開発ツールでのログ出力設定
2. dtexec パラメーター指定でのログ出力 
3. SSISDB データベース内のログを参照する  ※SQL Server 2012 以降のバージョンでのみ利用可能

*** SSISDB について補足 ***
SQL Server 2012 より新機能としてプロジェクト配置モデルという実行形態が導入され、配置先に SSISDB が利用できるようになりました。
これに伴い、パッケージ開発ツールも一新されています。SQL Server 2012 以降は従来の SSIS パッケージの開発/実行形態をレガシ SSIS と呼び区別しています。

ではさっそく見ていきましょう！

1. パッケージ開発ツールでのログ出力設定

1) SQL Server Business Intelligence Studio、もしくは SQL Server Data Tools を [管理者として実行] から起動し、プロジェクトを開きます。 
※ どちらの開発ツールも Visual Studio ベースであり、以降のログ採取手順は同じです。

2) [SSIS] メニュー - [ログ記録] を選択します。 --> SSIS ログの構成 画面が開きます。

 

3) 左部ペインの コンテナーに チェックを入れます。パッケージ全体の実行をログするように設定します。

4) [プロバイダーとログ] タブから下記を選択し、追加 ボタンをクリックします。
- プロバイダーの種類: テキストファイルの SSIS ログ プロバイダー --> [テキストファイルの SSIS ログ プロバイダー] が生成されます。

5) [テキストファイルの SSIS ログ プロバイダー] にチェックを入れます。

6) 構成 の列から、新しい接続を選択します。 --> ファイル接続マネージャー エディター 画面が表示されます。

7) ファイル接続マネージャー エディター 画面にて、下記の設定を行い、設定を保存します。

- 使用法の種類: ファイルの作成
- ファイル: 参照ボタンより任意のパス、ファイル名（例：log.txt など）を指定します。

8) [詳細] タブを選択します。イベントの左のチェックを有効にし、すべてのイベントをログするように設定後、[OK] をクリックし、設定を保存します。

上記設定を経て、パッケージを実行頂きますと、手順 7) で指定頂いたパスにログ情報が出力されます。

この例ではテキストファイルにログを出力していますが、他の形式としてSQL Server やイベントログに記録することも可能です。
詳細は、下記を参考にしてください。

Integration Services (SSIS) のログ記録

2. dtexec パラメーター指定でのログ出力

dtexec により、コマンドプロンプトからSSISパッケージを実行することが可能ですが、実行時のパラメーター指定によってログ出力の指定が可能です。
パッケージの再ビルドはできないけれど、ログ出力だけ操作したい時など便利ですね。
代表的なパラメーターとして、/VLog と /Rep をご紹介します。

/VLog

例) dtxec /F package.dtsx /VLog c:\work\test.log

/VLog の後に指定したパス (この場合 c:\work\test.log) のテキストファイルにログが出力されます。
SQL Server 2005 SP3以降から利用可能なパラメーターです。

/Rep

例) dtxec /F package.dtsx /Rep EW

出力するログレベルを変更する場合は /Rep パラメータを使用します。既定のレベルは、E (エラー)、W (警告)、P (進行状況) です。
/Rep EW とすれば、進行状況は除外してエラーや警告のみに絞ったログ出力が可能です。
/Rep V とすれば、詳細モードにてログを出力します。(V は他の引数と同時に指定できないので、単独で指定してください。)

※なお、コンソールの出力内容をコマンドプロンプトのリダイレクト (>, >>) を使用することで、ファイル出力可能です。

各パラメーターの詳細については、下記技術情報を参考にしてください。

dtexec ユーティリティ

3. SSISDB データベース内のログを参照する

SQL Server 2012からは新たにプロジェクト配置モデルがサポートされましたが、SSIS サーバーに配置されたパッケージを実行する際にもログ記録について設定が可能です。

1) SQL Server Management Studio のオブジェクト エクスプローラーで、パッケージに移動します。
    [統合サービス カタログ] - [SSISDB] - [フォルダ名] とノード展開してください。

2) パッケージを右クリックし、[実行] をクリックします。

3) [パッケージの実行] ダイアログ ボックスで、[詳細設定] タブをクリックします。

4) [ログ記録レベル] で、ログ記録レベルを選択します。

5) 他のパッケージの構成を完了し、[OK] をクリックしてパッケージを実行します。

2015/3/2 追記：
上記パッケージ実行ダイアログからのログ記録レベルの設定は、そのパッケージ1回の実行時のみ有効な設定となり、次回パッケージ実行時には、サーバー既定のログ記録レベルに戻されます。
サーバー既定のログ記録レベルは、下記 SSISDB カタログのプロパティ画面より設定します。

ログの参照方法
上記ログは、SSISDBカタログの内部テーブルに保存されています。クエリやビューで参照可能ですが、SQL Server Management Studioからレポートとしてグラフィカルに表示させることが可能です。
SQL Server Management Studioにて [統合サービス カタログ] - [SSISDB] - [フォルダ名] とノード展開し、[パッケージ名] で右クリック、[レポート] - [標準レポート] - [すべての実行] をクリックします。 




下記のようなレポート一覧が表示されます。プロジェクト実行毎に 1 行表示されています。さらに詳細を確認するにはレポート内の各リンクをクリックしてください。



表示される具体的な内容は、下記を参考にしてください。

Integration Services サーバーのレポート

ログの提供方法
サポートサービスをご利用いただく際など、SSISDBカタログ内に採取されたログのご提供が必要なケースがあります。
この場合、SSISDB データベースのバックアップを採取ください。

- 手順
1) SQL Server Management Studio から、該当のインスタンスに接続します。

2) 該当のデータベース (SSISDB) を右クリック [タスク] - [バックアップ] をクリックします。

3) 画面下部の [バックアップ先] に表示されているフォルダパスを控えます。

4) 画面で表示されている状態のまま[OK]をクリックします。3) のフォルダ配下にバックアップファイルが格納されますので格納されたバックアップファイル (SSISDB.bak) を送付下さい。

以上です。

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

皆さん、ご機嫌よう。今日は共有フォルダ上のファイルをソースとして Bulk Insert を実行した際、アクセス拒否エラーが発生する現象についてご紹介します。

エラー :
メッセージ 4861、レベル 16、状態 1、行 1
ファイル "<CSV ファイル名>" を開けなかったので、一括読み込みできません。オペレーティング システム エラー コード 5(アクセスが拒否されました。)。

発生条件 :
・Active Directory 環境であること
・Windows 認証 を使うこと
・Bulk Insert のソースは SQL Server 構成マシンとは別のマシン上に配置されていること
※ SQL Server 認証ユーザーで実行される場合は、問題は発生しません。
※ Always ON / シングル構成に限らず発生します。

図 : File Server ”sql178cl” 上のフォルダ “ShareforAlwaysOn1” 内の CSV ファイル “t1.csv” をソースにして Bulk Insert を実行する際は、SQL Server がファイルサーバーにアクセスすることになる

原因

ファイルサーバー上のファイルをソースとして Bulk Insert を行う場合、SQL Server が元々のアクセス元であるクライアントの資格情報を利用してファイル サーバーにアクセスします。ここで SQL Server がクライアントの資格情報を利用するためには、 SQL Server のサービスを動作させているアカウント (SQL Server サービスの起動アカウント) が委任において信頼される必要があります。委任において信頼されるよう、SQL Server サービスを設定しない状況においてファイルサーバー上のソースにアクセスしようとすると、結果として上記のようにアクセス拒否エラーのためファイルを読み込むことができず、bulk insert が失敗します。

対処方法

対処方法は、Kerberos 認証を行うよう構成し、かつ、委任設定を行うことになります。

"委任" とは、ネットワーク中のリソースにアクセスするため、ユーザー アカウントまたはコンピュータ アカウントの代理として動作することをサービスに許可することを指します。"委任に対して信頼されている" サービスは、ユーザーの代理として他のネットワーク サービスを使用できるようになります。
つまり、対処方法は委任設定を実施することですが、以下の二つの方法があります。

1. 無制限委任
       対象 : SQL Server 実行ユーザー
2. 制限付き委任
      対象 : SQL Server 実行ユーザー、SQL Server 稼働コンピューター アカウント (AlwaysON など構成マシンが複数存在する場合は、全稼働コンピューターアカウント対象)

無制限委任の場合は、特定のサービスを指定せず委任を��成します。対象は SQL Server サービス起動アカウントとなります。
この設定を実施することで、クライアントからファイル サーバーに対するチケットを取得するために必要なアクセス元ユーザーの Kerberos のチケット保障チケット TGT (Ticket-granting Ticket) 自体が提供されるようになります。SQL Server は、その TGT を利用してファイル サーバーに対するチケットを取得しますが、ここでは SQL Server 起動アカウントで閉じた認証処理となりますので、SQL Server 稼働コンピューターに対する委任設定は、指定されたサービスの委任時においてのみ必要です。

一方制約付きの委任 (指定されたサービスに対しての委任だけを許可) の場合は、ファイル サーバーへのアクセス時には特殊な動きになります。
具体的には、 OS の動作として、 SQL Server 実行ユーザーだけでなく、システム アカウントによる認証処理要求も行われます。この動作のために、委任設定を SQL Server 実行ユーザーに対しておこなうだけでなく、 SQL Server 稼働コンピューター アカウントに対しても行う必要があります。指定されたサービスの委任設定時には、ファイル サーバーのチケットを特殊な方法で取得する必要があります。具体的には SQL Server は、ファイル サーバーへのアクセス時に自身のチケットをドメイン コントローラーに提供し、そのチケットに含まれるキー情報を元にファイル サーバーにアクセスするためのチケットを暗号化してもらう必要があります。このときファイル サーバーへのアクセスのためには SQL Server 起動アカウントに加えて、 SQL Server のシステム アカウントも利用されます。その両アカウントが、ファイル サーバーに対してのチケット情報を利用する必要があるため、 SQL Server のシステム アカウントについても委任設定が行われている必要があります。
そのため、SQL Server 稼働コンピューター アカウントに対しても指定されたサービスに対する委任だけを許可する際は、委任設定が必要です。

ユーザーに特定のサービスに対する委任時の信頼を付与する
https://msdn.microsoft.com/ja-jp/library/cc757194(v=ws.10).aspx

なお、この動作は Kerberos 認証自体ではなくファイル共有にアクセスする場合に利用される OS のリダイレクタというコンポーネントと Windows の認証プロセスの実装により生じている動作になります。

参考 :
Constrained Delegation For CIFS fails with ACCESS_DENIED.
http://support.microsoft.com/kb/2602377/en-us

対処方法の流れ

手順をまとめますと以下の通りです。

■ 1. 無制限の委任構成方法

1. ドメインコントローラーにドメインの管理者でログインします。
2. "Active Directory ユーザーとコンピュータ" を起動します。
3. コンソール ツリーで "Users" を選択します。
4. SQL Server サービスの起動アカウントを右クリックし、"プロパティ" を表示します。(下記図)
5. "委任" タブを開き、"任意のサービスへの委任でこのコンピューターを信頼する (Kerberos のみ)" を選択します。(下記図)
6. [OK] を押し下げしてプロパティ ダイアログを閉じ、SQL Server 稼動マシンを再起動します。(※ 設定を反映するには再起動が必要です)

図 : SQL Server の起動アカウント = Administrator の場合

■ 2. 制限つき委任構成方法

シングル構成で制限付きの委任を構成する方法
1. ドメインコントローラーにドメインの管理者でログインします。
2. "Active Directory ユーザーとコンピュータ" を起動します。
3. コンソール ツリーで "Users" を選択します。
4. SQL Server サービスの起動アカウントを右クリックし、"プロパティ" を表示します。
5. "委任" タブを開き、"指定されたサービスへの委任でのみこのユーザーを信頼する"、"任意の認証プロトコルを使う" を選択します。(下記図A)
6. "追加" を押下し「サービスの追加」画面を表示します。
7. "ユーザーまたはコンピューター" を押下し「ユーザー または コンピューターの選択」画面を表示します。
8. "選択するオブジェクト名を入力してください" にファイル シェアのあるコンピュータ名を入力し、"名前の確認"、"OK" の順に押下します。
9. "サービスの種類" が "CIFS" のものから、ファイル シェアのあるコンピュータ名のものを選択し、"OK" を押下します。(下記図B)
10. ファイル シェアのあるコンピュータを右クリックし、"プロパティ" を表示します。
11. "委任" タブを開き、"指定されたサービスへの委任でのみこのユーザーを信頼する"、"任意の認証プロトコルを使う" を選択します。(下記図A)
12. "追加" を押下し「サービスの追加」画面を表示します。
13. "ユーザーまたはコンピューター" を押下し「ユーザー または コンピューターの選択」画面を表示します。
14. "選択するオブジェクト名を入力してください" にファイル シェアのあるコンピュータ名を入力し、"名前の確認"、"OK" の順に押下します。
15. "サービスの種類" が "CIFS" のものから、ファイル シェアのあるコンピュータ名のものを選択し、"OK" を押下します。
※ SQL Server の起動アカウントに加え、SQL Server の稼働マシンアカウントに対しても CIFS の委任の設定を行います。(下記図C)
16. SQL Server 稼動マシンを再起動します。(※ 設定を反映するには再起動が必要です)

図A : SQL Server の起動アカウント (上記例では、Administrator) に対して CIFS サービスを委任に追加した例

図B : サービスの追加で、ファイル配置サーバー（ファイルサーバ、この例では SQL178CL というマシン）の CIFS サービスを委任に追加した例

図C : SQL Server の稼働コンピューター（上記例では SQL178SQL1) に対して、CIFS サービスを委任に追加した例

AlwaysOn 構成で制限付きの委任を構成する方法
0. 以下についてあらかじめ構成を確認しておきます。
-a. AlwaysOn AG 環境を構成するすべての SQL Server の起動アカウントを同一にする。
-b. AlwaysOn AG リスナーの名前の SPN を手動登録しておく。(SetSPN -s MSSQLSrv/リスナー名のFQDN:ポート番号)
1. ドメインコントローラーにドメインの管理者でログインします。
2. "Active Directory ユーザーとコンピュータ" を起動します。
3. コンソール ツリーで "Users" を選択します。
4. SQL Server サービスの起動アカウントを右クリックし、"プロパティ" を表示します。
5. "委任" タブを開き、"指定されたサービスへの委任でのみこのユーザーを信頼する"、"任意の認証プロトコルを使う" を選択します。
6. "追加" を押下し「サービスの追加」画面を表示します。
7. "ユーザーまたはコンピューター" を押下し「ユーザー または コンピューターの選択」画面を表示します。
8. "選択するオブジェクト名を入力してください" にファイル シェアのあるコンピュータ名を入力し、"名前の確認"、"OK" の順に押下します。
9. "サービスの種類" が "CIFS" のものから、ファイル シェアのあるコンピュータ名のものを選択し、"OK" を押下します。
10. ファイル シェアのあるコンピュータを右クリックし、"プロパティ" を表示します。
11. "委任" タブを開き、"指定されたサービスへの委任でのみこのユーザーを信頼する"、"任意の認証プロトコルを使う" を選択します。
12. "追加" を押下し「サービスの追加」画面を表示します。
13. "ユーザーまたはコンピューター" を押下し「ユーザー または コンピューターの選択」画面を表示します。
14. "選択するオブジェクト名を入力してください" にファイル シェアのあるコンピュータ名を入力し、"名前の確認"、"OK" の順に押下します。
15. "サービスの種類" が "CIFS" のものから、ファイル シェアのあるコンピュータ名のものを選択し、"OK" を押下します。
※ SQL Server の起動アカウントに加え、SQL Server の稼働マシンアカウントに対しても CIFS の委任の設定を行います。前述の構成例の場合は、SQLServ1 と SQLServ2 が対象となります。 (下記図)
16. [OK] を押し下げしてプロパティ ダイアログを閉じ、SQL Server 各稼動サーバーを再起動します。(※ 設定を反映するには再起動が必要です)

図 : SQL Server AlwaysOn の構成環境 2 台それぞれのコンピュータアカウント(上記例では SQL178SQL1と SQL178SQL2)に対し、ファイルサーバの CIFS サービスの委任を設定する

委任が設定されることにより、ネットワーク越しのファイル リソースにアクセスできるようになります。

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

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

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

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

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