Quantcast
Channel: Microsoft SQL Server Japan Support Team Blog
Viewing all 293 articles
Browse latest View live

[SSRS] SharePoint 統合モードのレポートサーバー構築手順 (単一サーバー) - SQL Server 2008 と SharePoint 2010 の組み合わせ)

$
0
0

森  隆博
SQL Developer Support Engineer

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

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

    ハードウェア要件およびソフトウェア要件 (SharePoint Server 2010)
    http://technet.microsoft.com/ja-JP/library/cc262485(v=office.14).aspx

 

■ここでご案内するシステム
・SQL Server 2008
※ここでご案内するのは SQL Server 2008 R2 ではありません
※SharePoint 統合が可能な Reporting Services のエディションは Enterpriset と Standard です。
・SharePoint 2010
・Windows Server 2008 R2
・SQL Serer データベース、Reporting Services、SharePoint を全て同一マシン上にインストールする

■注意点
SharePoint 統合モードで SQL Server 2008 Reporting Services を動作させるためには、以下の注意が必要です。

・SQL Server 2008 Service Pack 1 + 累積的な更新プログラム 8 が適用されていること または ServicePack 2 が適用されていること。
・Reporting Services のサービスをドメインアカウントで起動していること。

■手順概要
大きく以下の手順で作業を進めましょう

1. SQL Server 2008 をインストールする
2. SQL Server 2008 ServicePack 2 以降の Service Pack、修正プログラムを適用する。
3. SharePoint 2010 必須コンポーネントをインストールする
4. SharePoint 2010 をインストールする
5. SharePoint の構成を設定する
6. SharePoint と Reporting Services を統合構成する

では早速順に実施して行きましょう。

 

1. SQL Server 2008 のインストール
インストーラーを起動します。

 

SQL Server の新規スタンドアロン インストールまたは既存のインストールへの機能の追加を選択します。

 

セットアップサポートルールを確認し、「OK」ボタンをクリックします。

 

プロダクトキーを入力します。
注意点でも記述した通り、SharePoint 統合が可能な Reporting Services のエディションは Enterpriset と Standard です。

SQL Server 2008 の各エディションがサポートする機能
http://msdn.microsoft.com/ja-jp/library/cc645993(v=sql.100).aspx

 

 

使用許諾契約書に同意し「次へ」ボタンをクリックします。
 

 

セットアップサポートファイルをインストールします。
 

 

状態を確認し、「次へ」ボタンをクリックします。

 

機能の選択で必要な機能を選択します。ここではすべての機能を選択しています。

 

インストール対象のインスタンスを選択します。ここでは既定のインスタンスを指定します。
 

 

ディスク領域を確認し「次へ」ボタンをクリックします。

 

 各種サービスの起動アカウントを設定します。
注意点でも記載したとおり、SharePoint 統合する Reporting Services はドメインアカウントでサービスを起動する必要があります。

 

SQL Server 認証 と Windows 認証の混合モードを選択します。

 

Analysis Services の管理権限ユーザーを設定します(今回は Analysis Services は使用しませんのでインストールしてもしなくてもかまいません)

 

Reporting Services の構成にて「SharePoint 統合モードの既定の構成をインストールする」を選択します。
 

 

「次へ」ボタンをクリックします。

 

インストールルールの状態を確認し「次へ」ボタンをクリックします。

 

インストール内容を確認し「インストール」ボタンをクリックします。
 

 

インストールが開始されます。しばらくお待ちください。
 

 

セットアップ処理が完了したら「次へ」ボタンをクリックします。

 

インストールの正常終了を確認します。

 

SQL Server のインストールは完了です。続いて Services Pack を適用していきます。

2. SQL Server 2008 ServicePack 2 以降の Service Pack、修正プログラムを適用します

SQL Server 2008 Service Pack 2 以降の修正プログラムを適用します。

SQL Server 2008 Service Pack 2 は以下からダウンロード可能です。

Microsoft SQL Server 2008 Service Pack 2
http://www.microsoft.com/ja-jp/download/details.aspx?id=12548

また、Service Pack 2 よりも新しい、Service Pack 3 は以下からダウンロード可能です。

SQL Server 2008 Service Pack 3
 http://www.microsoft.com/ja-jp/download/details.aspx?id=27594

 

 

使用許諾契約書に同意し「次へ」ボタンをクリックします。

 

適用するインスタンスを選択し「次へ」ボタンをクリックします。

 

使用中のファイルを確認し「次へ」ボタンをクリックします。

 

更新の準備が完了したら「更新」ボタンをクリックします。

 

しばらくお待ちください

更新が完了したら、「次へ」ボタンをクリックします。

 

更新プログラムの適用の成功を確認し「閉じる」ボタンをクリックします。

 

これで SQL Server 側のセットアップは完了です。
続いて SharePoint のセットアップに進みましょう。

3. SharePoint 2010 必須コンポーネントをインストール
ここから SharePoint 2010 のインストール作業に入ります。
SharePoint のインストールの前に、まずはソフトウェア必須コンポーネントをインストールする必要があります。
ソフトウェア必須コンポーネントのインストールを実施します。

 

「次へ」ボタンをクリックします。

使用許諾契約書に同意し「次へ」ボタンをクリックします。


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

 

インストール途中でシステム再起動を求められた場合、「完了」ボタンをクリックします。
※ OS が再起動されますが、再起動後インストーラーは再開されます。

 

OS 再起動後、再びインストーラーが自動で実行されます。

 

インストールの成功を確認します。

 

4. SharePoint 2010 をインストール

次に SharePoint Server 本体をインストールします。インストーラーから「SharePoint Server のインストール」を選択します。

 

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

 

マイクロソフト ソフトウェアライセンス条項に同意し「続行」ボタンをクリックします。

 

「サーバーファーム」をクリックします。

 

「完全」を選びます。

 

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


5. SharePoint の構成を設定する

インストールが完了したら、次は SherePoint ファームの構成を行います。「SharePoint 2010 製品構成ウィザード」を実行します。

 

構成ウィザードで「次へ」ボタンをクリックします。

 

構成ウィザードの警告が出た場合「OK」ボタンをクリックします。

 

新しいサーバーファームの作成を選択し「次へ」ボタンをクリックします。

 

SharePoint サーバーが使用する構成データベースを指定します。
本手順では 先の手順で、SQL Server 2008 の既定のインスタンスをインストールしましたので、既定のインスタンスを指定し、そのインスタンスに接続するアカウントを指定して進めます。

 

ファーム構成を行うためのパスフレーズ(パスワード)を入力します。

 

SharePoint 全体管理のポート番号などを指定します。ここでは既定の設定のまま行います。

 

構成ウィザードの終了にて「次へ」ボタンをクリックします。

 

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

 

構成の成功を確認したら「完了」ボタンをクリックします。

自動で以下の画面が起動するので構成を進めます。

 

「ウィザードの開始」ボタンでファームウィザードを開始します。

 

管理アカウントやサービスアプリケーションを選択し「次へ」ボタンをクリックします。ここでは既存のアカウントを使用し、既定のサービスアプリケーションを選択します。


 

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

 

任意でサイトコレクションの設定を行います。

 

構成ウィザードの正常終了を確認します。

 

6. SharePoint と Reporting Services の統合構成
これまでで SQL Server と SharePoint とのセットアップ並びに構成が完了しました。
つぎはいよいよReporting Services と SharePioint の統合構成を行います。
Reporting Services サービスをアクティブ化し、Report Server を統合に追加するという流れになります。
まずは Reporting Services サービスをアクティブ化しましょう。

全体管理画面から「アプリケーションの全般設定」をクリックします。

 

Reporting Services カテゴリの「Reporting Sericves 統合」をクリックします。

レポートサーバー URL や資格情報を設定します。
レポートサーバー URL は http://<マシン名>/reportserver のように指定してください。http://localhost/reportserverの指定では設定することができません。

 

しばらく待ちます。

Reporting Services サービスをアクティブ化の成功を確認します。


Reporting Services サービスをアクティブ化が完了したため、次に Report Server を統合に追加します。
全体管理画面から「アプリケーションの全般設定」をクリックします。

 

Reporting Services カテゴリの レポート サーバー を統合に追加」をクリックします。

統合を行う対象となる、Reporting Serviees のホスト名とインスタンスを指定します。
ここでは、既定のインスタンスで Reporting Services をインストールしているので下記サーバー名と既定のインスタンスを指定します。

 

Reporting Servies サービスアカウントを取得するため、ユーザー情報を入力します。
しばらく待つと、統合が完了します。

 

 これで構築手順が完了です。ぜひ、ご利用ください。

 


IEの制限の影響によりWCF Data Services クライアントにおいて、300秒で'System.InvalidOperationException'が発生することがある

$
0
0

 

横井 羽衣子
SQL Developer Support

みなさんごきげんよう。今回は、WCF Data Services とデータアクセスを行う Silverlight アプリケーションにおいて、DataServiceQuery.EndExecute でキッチリ 300 秒で内部エラーが発生してしまうという現象についてお話したいと思います。

「DataServiceQuery.EndExecute で内部エラー」というと、WCF Data Services か、あるいは Silverlight 側を疑ってしまいがちではないでしょうか。ところが、今回ご紹介する現象は、実はクライアント側、それも Internet Explorer (IE) の制限事項の影響を受けた結果なのです。
WCF Data Services など、Web 系のアプリケーション、サービスにおいては、様々な要素が絡み合って機能を実現しています。たとえば "メモ帳" などのように、ローカルで閉じた環境で、他プロセスなどが介在しないようなアプリケーションで問題が発生した時とは異なります。まずシステムの構成要素と動作時の処理の流れを把握することが最も重要です。

今回の場合エラーが一般的問題を表すだけの内容の上、クライアントといっても、例外は Silverlight で発生していますので、 その先の IE 側まで着目せず、惑わされやすいパターンと言えます。
image

問題
Silverlight から WCF Data Services に要求を投げてデータ取得を行うシステムを実装している。 システム要件として、複数の画面用の処理を同時実行したいため、以下のような動作の流れとなっている。

1. WCF Data Services Client (Silverlight 側) において DataServiceQuery.BeginExecute を実行
2. WCF Data Services Client において別のページ用の処理のための DataServiceQuery.BeginExecute を実行 
3. 以下例外がクライアントにて発生

'System.InvalidOperationException' の初回例外が System.Data.Services.Client で発生しました。
上位例外 : 変更の保存中にエラーが発生しました。詳細については、内部例外を参照してください。
'iexplore.exe' (Silverlight): 'c:\Program Files (x86)\Microsoft Silverlight\5.1.10411.0\ja\mscorlib.resources.dll' が読み込まれました。
上位例外 :    場所 System.Data.Services.Client.BaseAsyncResult.EndExecute[T](Object source, String method, IAsyncResult asyncResult)
    場所 System.Data.Services.Client.QueryAsyncResult.EndExecute[TElement](Object source, IAsyncResult asyncResult)
    場所 System.Data.Services.Client.DataServiceQuery`1.EndExecute(IAsyncResult asyncResult)
    場所 SampleWeb.MainPage.<>c__DisplayClass2.<BeginQueryData>b__0(IAsyncResult asyncResult)
内部例外 :    場所 System.Data.Services.Http.HttpWebResponse.NormalizeResponseStatus(Int32& statusCode)
    場所 System.Data.Services.Http.HttpWebResponse..ctor(HttpWebRequest request, Int32 statusCode, String responseHeaders)
    場所 System.Data.Services.Http.HttpWebRequest.CreateResponse()
    場所 System.Data.Services.Http.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
    場所 System.Data.Services.Client.QueryAsyncResult.AsyncEndGetResponse(IAsyncResult asyncResult)
内部例外 : 'HttpWebResponse.NormalizeResponseStatus' での内部エラーです。

この動作を切り分けてみた方は、以下の状況を確認できたのではないでしょうか。

- WCF Data Services から WCF Data Services Client にデータは正しい形で到達している。
- すべてのデータが返るまでに時間を要する場合(データ量が多い場合)に発生している。       - クエリの取得件数を絞るとエラーは発生しない。
- 実行されているクエリを SQL Server Management Studio (SSMS) で実行すると約 30、40 秒程度要するような比較的大きいクエリが流れている。      
- DataServiceQuery.BeginExecute をループなどで 5 回など複数回実行した場合のみ高確率で発生。1 回だけの呼び出しでは発生していない。
- クエリ実行開始から、常に 300 秒でエラーになる
- サーバートレースを取るとExecution Warnings (Query Wait) が発生している。      
- デリゲートを介さず実行するように変更しても問題は変わらない。
- コールバックを明示的に非同期で対応するようにプロパティなどを設定しておいても効果がない。
- エンティティを使いまわしても問題は解消しない。
- WCF トレースを採取しても何もエラーは発生していない。
- WCF Data Services の Web.config で、executionTimeout の設定に追加して、sendTimeout 等を追加しても効果はない。

原因
この問題は、WCF Data Service ではなく、クライアントの Internet Explorer のタイムアウトの影響に起因しています。
Data Source (SQL Server データベースなど) からのクエリの結果が WCF Data Services に返され、そのデータがさらにクライアントに返される際、XMLHTTPRequest が用いられます。
この、XMLHTTP でクライアントにデータが返されるまでの時間が、Internet Explorer のタイムアウト値の時間を超える場合に、処理が中断されてしまい、結果としてこの例外がクライアント側で発生することになります。 よって、この現象については、WCF Data Services としてトレースを採取いただいても、問題として検知されません。

今回の問題に関係するタイムアウトの設定が、以下のレジストリ キーとなります。ここを延長することで、問題の回避が可能です。
なお、どの程度延長すべきかは、システムの設計次第といえます。ユーザーが使用するアプリケーションであれば、あまり長いと使用に耐えないということになってしまいます。この場合、既定 5 分以上でも結構長いのではないかと思いますので、クエリのチューニングなどを検討してもいいかもしれません。
バッチなどで比較的待機することにデメリットが少ないという場合などは、10 分など、クエリの実行時間を SSMS で計測し、それに合わせて調整するということなども良いかと思います。

キー : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings
値の種類 : REG_DWORD
名前 : ConnectTimeOut
データ : ミリ秒単位の時間 (10進)
既定値 : 300000 ミリ秒 (=5分)
(既定では、レジストリは存在しませんので、明示的にキーを作成いただく必要があります。)

参考情報
Silverlight 用 WCF Data Services クライアント ライブラリ
http://msdn.microsoft.com/ja-jp/library/ff650916(v=vs.95).aspx
→ "データ サービスに対するほとんどの要求に関して、Silverlight 用 WCF Data Services クライアントは XMLHTTP の実装を使用します。"

Internet Explorer 8 における XMLHttpRequest の強化
http://msdn.microsoft.com/ja-jp/library/cc534581(v=vs.85).aspx
→ "Internet Explorer 8 では、非同期 JavaScript および XML (AJAX) 要求をより細かく制御できます。 具体的に、開発者は XMLHttpRequest オブジェクトのタイムアウトを指定できるようになりました。"

具体的にはクライアント処理において、内部で WinInet の以下のステータスを返された時に、この問題が発生します。
環境によっては、300 秒以内で 12152 が発生する場合もありますが、300 秒を超えた場合は、いずれの環境においても 12002 が発生し続けます。

12152 ERROR_HTTP_INVALID_SERVER_RESPONSE
12002 ERROR_INTERNET_TIMEOUT

INFO: WinInet Error Codes (12001 through 12156)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;193625

ちなみに、今回は WCF トレースが残念ながらあまり役に立たないケースでしたが、WCF トレースについては、今後ブログに書いていこうと思います。

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

[SSMA] SSMA の動作環境についての推奨

$
0
0

本間 崇
SQL Server Support Escalation Engineer

今回は、SQL Server Migration Assistant (SSMA) についてのちょっとしたお話です。

SSMA については、既にこちらのポストで説明してある通り、Oracle や Sybase 等から、SQL Server への移行作業を支援するツールとなり、無償で利用できます。この SSMA を使用する際は、64bit 環境で 64bit 版を使用した方が良い、というお話です。

これは、32bit と 64 bitでは、使用できるメモリ量が異なるため、となります。以前、SQL Server のメモリ管理についてのポストで、仮想アドレス空間について説明が行われていますが、こちらのポストをお読みいただけましたでしょうか?
この仮想アドレス空間の制限を SSMA も受けるため、32bit 環境で SSMA を使用した場合、2GB までしかメモリを使用することが出来ません。そのため、大量のオブジェクトや大きなプロシージャを Convert する場合に、メモリ不足のエラー(System.OutOfMemoryException)によって処理が失敗する可能性があります。
お問い合わせ自体は少ないですが、弊社にも 32bit 環境でSSMAを使用した際にメモリ不足のエラーで Convert が失敗するお問い合わせがあり、海外のコミュニティ等でも同様の報告が上げられています。

このメモリ不足に対しての対応は64bit OS 上で 64bit 版の SSMA を使用する、というのが回答となります。

64bit であれば、仮想アドレス空間の制限は受けないため、後は物理メモリを潤沢に積むことで、少なくともメモリ不足での失敗を回避できる……ハズです。

やはり、対象のオブジェクトの作り等によってはそれでも回避できない可能性は残ります。こうしたオブジェクトについては、SSMAで移行できないオブジェクトや機能と同様、お客様にて移行を行って頂く必要があります。

SSMA が少しでも SQL Server への移行の手助けになれば幸いです :-)

システム データベースのリストア手順

$
0
0

みなさん、こんにちは。今回はシステム データベースのリストア手順についてご紹介します。

システムデータベースを含めたバックアップを取得しておけば、SQL Server が稼働しているマシンが壊れてしまった場合に新しいマシンに SQL Server をインストールし、バックアップからリストアすることによって、SQL Server の環境を簡単に再構築することができます。

本手順は SQL Server 2012 を使用してシステム データベースとユーザー データベースをバックアップからリストアし、新しいマシンに SQL Server の環境を再構築する方法について記載しています。

■前提条件   

1. オンライン バックアップ(完全バックアップ)を取得済みであること。

    ※本手順では、バックアップファイルを下記の名前で作成しています。

              ・master  データベース: master.bak

              ・msdb データベース:msdb.bak

              ・model データベース:model.bak

              ・test データベース: test.bak         ※ユーザー データベース

2. 新しいマシンは、旧いマシンと同じコンピューター名であること。

    ※コンピュータ名が異なるマシンへのシステム データベースの復元はサポートされていません。

       本手順では、コンピューター名を ServerA としています。

3. 新しいマシンの SQL Server のインストール先のパスは、旧いマシンの SQL Server のインストール先のパスと同一であること。

4. 新しいマシンは旧いマシンと同じ Active Directory ドメインまたはワークグループ構成であること。

 

■手順

1. 新しいマシンに SQL Server をインストールします。

2. 新しいマシンの任意のフォルダに、旧マ��ンで取得したバックアップ ファイルをコピーします。

    ※本手順では、C:\work にバックアップ ファイルをコピーしています。

3. コマンド プロンプトを起動し、下記のコマンドを実行してユーザー データベース (test) をリストアします。

    ----------------------------------------------------------------------------------------

    C:\> sqlcmd -E -SServerA
    1> RESTORE DATABASE test FROM DISK = 'C:\work\test.bak'     
    2> go

    ----------------------------------------------------------------------------------------

    ※本手順では、既定のインスタンスに接続しています。名前付きインスタンスの場合は下記のように sqlcmd  ユーティリティによる接続時にインスタンス名の指定が必要です。

    ----------------------------------------------------------------------------------------

    C:\> sqlcmd -E -SServerA\instancename

    ----------------------------------------------------------------------------------------

 4. 構成マネージャから SQL Server サービスを 停止します。SQL Server Agent サービスなど、SQL Server 関連の他のサービスが起動している場合は、それらのサービスもすべて停止します。

5. コマンド プロンプトを起動し、下記のコマンドを実行して SQL Server をシングルインスタンスモードで起動します。

    -----------------------------------------------------------------------------------------------------------------

    cd C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn 

    sqlservr -m -c

    -----------------------------------------------------------------------------------------------------------------

    ※ 上記のパスは、SQL Server 2012 のデフォルトです。

    ※ -c オプションを使用することにより、 コマンド プロンプトからの SQL Server の起動に要する時間を短縮することができます。

    ※  名前付きインスタンスとして SQL Server 2012 をインストールしている場合は、フォルダー パスの 「MSSQL11.MSSQLSERVER」 を 「MSSQL11.インスタンス名」 へ変更する必要があります。また、下記のように sqlservr  アプリケーションの実行時に -s オプションを使用して、インスタンス名を指定する必要があります。

    -----------------------------------------------------------------------------------------------------------------

    sqlservr -m  -sinstancename -c

    -----------------------------------------------------------------------------------------------------------------

    master

6. もう一つコマンドプロンプトを起動し、下記のコマンドを実行して master データベースをリストアします。

    ※WITH REPLACE  オプションをつけて実行することにより、指定したデータベースと同じ名前のデータベースが既に存在していても、データベースとその関連ファイルが作成されます。
       その場合、既存のデータベースは削除されます。

    ※リストアが成功した場合は、 SQL Server が自動的にシャットダウンされます。

    ----------------------------------------------------------------------------------------------------------------------  

    C:\> sqlcmd -E -SServerA
    1> RESTORE DATABASE master FROM DISK = 'C:\work\master.bak' WITH REPLACE    
    2> go

    ------------------------------------------------------------------------------------------------------------------------ 

7. 構成マネージャから SQL Server サービスを起動します。

    ※SQL Server 関連の他のサービスは、ここではまだ起動しません。

8. コマンド プロンプトを起動し、下記のコマンドを実行して msdb データベースをリストアします。

    ------------------------------------------------------------------------------------------------------------------ 

    C:\> sqlcmd -E -SServerA
    1> RESTORE DATABASE msdb FROM DISK = 'C:\work\msdb.bak' WITH REPLACE    
    2> go

    ------------------------------------------------------------------------------------------------------------------ 

    ※ レプリケーションを利用している場合は、ここで distibution データベースをリストアします。

9. 続けて、下記のコマンドを実行して  model データベースをリストアします。

    -------------------------------------------------------------------------------------------------------------------- 

    1> RESTORE DATABASE model FROM DISK = 'C:\work\model.bak' WITH REPLACE    
    2> go

    -------------------------------------------------------------------------------------------------------------------- 

10. 構成マネージャから SQL Server サービスを再起動します。

11. 構成マネージャから SQL Server Agent サービスなど、SQL Server 関連の他のサービスを起動します。

 

 ※tempdb データベースは自動的に再構築されるので、復元は不要です。

 

以上で、システム データベースとユーザー データベースの復元は完了です。新しいマシンに SQL Server の環境が再構築されました。

 

<参考情報>
 http://msdn.microsoft.com/ja-jp/library/ms190679(v=sql.105).aspx
  master データベースを復元する方法 (Transact-SQL)

[SSRS Troubleshooting] SQL Server Reporting Services トラブルシューティングのご案内

$
0
0

山崎 実久
SQL Server Developer Support Engineer

 

以前、[SQL Troubleshooting] SQL Server トラブルシューティング 6 回シリーズのご案内で、SQL Server Engine 側で発生する問題について、基本的な切り分け方法をご案内しました。

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

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

1.  Reporting Services のバージョンの確認
2.  イベントログ(アプリケーション、システム、セキュリティ) の確認
3.  Reporting Services ログの確認
4.  Reporting Services の詳細ログ
5.  HTTP ログ
6.  実行ログ executionlog
7.  パフォーマンスログ
8.  SQL Profiler による情報採取

 

 

 

 

 

 

 

1. Reporting Services のバージョンの確認
============================
Reporting Services のバージョンを確認し、SQL Server 最新モジュールと照らし合わせ、最新でない場合は、最新のモジュールを適用します。少なくとも最新のサービスパックが適用されていることを確認します。最新のサービスパック、もしくは修正モジュールを適用しても、問題が解消されない場合、2. 以降に記載の情報 を採取し確認します。
本記事作成時の最新のモジュール情報は、SQL Server の最新モジュール情報 (まとめページ)
 で確認することが可能です。SQL Server の最新モジュールは本 blog で毎月公開しています。

1-1. レポートサーバーから確認する方法
----------------------------------------------

1) Reporting Services がインストールされているマシンからブラウザを起動します。
2) 次のようにブラウザからアクセスし、画面の一番下に表示される SQL Server Reporting Services の詳細バージョンを確認します。


Reporting Services 2005
------------------------
  既定のインスタンスの場合  : http://localhost/reportserver
  名前付きインスタンスの場合: http://localhost/reportserver$<インスタンス名>
 
Reporting Services 2008 以降
---------------------------
  既定のインスタンスの場合  : http://localhost/reportserver
  名前付きインスタンスの場合: http://localhost/reportserver_<インスタンス名>
 
上記のように指定しますと、以下の様にバージョン情報が表示されます。

  例) Microsoft SQL Server Reporting Services Version 10.0.4000.0

 

上記以外に、SQL Server 2008 以降のバージョンでは、インストールセンターを利用し、バージョンを確認します。この方法を利用すると Reporting Services 以外のバージョンも確認できます。

1-2. インストールセンターから確認する方法
----------------------------------------------

SQL Server 2008 R2の場合の例を記載します。お使いの SQL Server のバージョンに合せて確認します。

- SQL Server 2008 R2の場合
1) [スタート] メニューから、[Microsoft SQL Server 2008 R2] - [構成ツール] - [SQL Server インストール センター] を選択します。
2) SQL Server インストールセンター画面の左部にて、[ツール] を選択し、画面右部から [インストール済み SQL Server 機能の検出レポート] を選択します。
3) 各サービスのバージョン情報の詳細情報がブラウザに表示されます。Web ページを「Web アーカイブ、単一のファイル (*.mht)」形式で保存し、確認します。


その他、以下の方法でもバージョンを確認することができます。

1-3. インストールされている exe から確認する方法
---------------------------------------------------------------------------------------
1) 既定で下記フォルダにある exe ファイルを右クリックにて選択しプロパティをクリックします。

 
Reporting Services 2005
------------------------
<\Program Files\Microsoft SQL Server\MSSQL.n\ReportingServices\ReportServer\bin\ReportingServicesService.exe>

 ※ MSSQL.n の n は整数値で、複数のインスタンスがインストールされている場合、対象のインスタンスと MSSQL.n は次のレジストリで確認します。

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQLServer\Instance Names\SQL


Reporting Services 2008
----------------------
<\Program Files\Microsoft SQL Server\MSRS10.<インスタンス名>\ReportingServices\ReportServer\bin\ReportingServicesService.exe>


Reporting Services 2008 R2
---------------------------
<\Program Files\Microsoft SQL Server\MSRS10_50.<インスタンス名>\ReportingServices\ReportServer\bin\ReportingServicesService.exe>

Reporting Services 2012
---------------------------
<\Program Files\Microsoft SQL Server\MSRS11.<インスタンス名>\ReportingServices\ReportServer\bin\ReportingServicesService.exe> 

 


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

 


3. Reporting Services ログの確認
======================
SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 のそれぞれのバージョンごとに Reporting Services ログの確認手順を記載します。

-- SQL Server 2005

Reporting Services のインストール フォルダ下の LogFiles フォルダ配下に出力されるファイルを確認します。
既定では、MSSQL.n 下の Reporting Services フォルダにインストールされます。

C:\Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\Log Files

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instancenames\RS


-- SQL Server 2008

Reporting Services のインストール フォルダ下の LogFiles フォルダ配下に出力されるファイルを確認します。
既定では、MSRS10.xxx 下の Reporting Services フォルダにインストールされます。

C:\Program Files\Microsoft SQL Server\MSRS10.xxxx\Reporting Services\LogFiles

※ MSRS10.xxxx の xxxx はインスタンス名称です。たとえば既定の C ドライブにインストールされた既定のインスタンスの場合、以下のようになります。

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

-- SQL Server 2008 R2

Reporting Services のインストール フォルダ下の LogFiles フォルダ配下に出力されるファイルを確認します。
既定では、MSRS10_50.xxx 下の Reporting Services フォルダにインストールされます。

C:\Program Files\Microsoft SQL Server\MSRS10_50.xxxx\Reporting Services\LogFiles

※ MSRS10_50.xxxx の xxxx はインスタンス名称です。たとえば既定の C ドライブにインストールされた既定のインスタンスの場合、以下のようになります。

C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\LogFiles


-- SQL Server 2012

Reporting Services のインストール フォルダ下の LogFiles フォルダ配下に出力されるファイルを確認します。
既定では、MSRS11.xxx 下の Reporting Services フォルダにインストールされます。

C:\Program Files\Microsoft SQL Server\MSRS11.xxxx\Reporting Services\LogFiles

※ MSRS11.xxxx の xxxx はインスタンス名称です。たとえば既定の C ドライブにインストールされた既定のインスタンスの場合、以下のようになります。

C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\LogFiles

 

4. Reporting Services の詳細ログ
=====================
Reporting Services の詳細ログの採取方法については、以前本ブログでお伝えしました [SSRS] Reporting Services の詳細ログを確認します。

5. HTTP ログ
========
HTTP ログの採取方法についても、以前本ブログでお伝えしました [SSRS] Reporting Services の詳細ログを確認します。

 

6. 実行ログ
========
SQL Server 2008 以降のバージョンで実行ログを採取することができます。事象発生後、以下の手順をもとに実行結果を確認します。

1) SQL Server Management Studio で SQL Server に接続します。
2) "新しいクエリ" ボタンでクエリ入力画面を開きます。
3) Ctrl + T で実行結果をテキスト形式表示にします (元のグリッド表示に戻す場合は Ctrl+D )。
4) 以下のクエリを実行し、事象発生付近の時間帯の結果を確認します。
(弊社に情報を送付いただく際は、Ctrl+Shift+F で実行結果を CSV ファイルに保存いただきご提供ください)

-- SQL Server 2005 の場合 --
-- ここから --
Use ReportServer
go
select * from ExecutionLog order by TimeStart DESC
--------------

-- SQL Server 2008 の場合 --
-- ここから --
Use ReportServer
go
select * from ExecutionLog2 order by TimeStart DESC
--------------

-- SQL Server 2008 R2 以降の場合 --
-- ここから --
Use ReportServer
go
select * from ExecutionLog3 order by TimeStart DESC
--------------

+ 参考情報
-- SQL Server 2005
レポート サーバー実行ログ
"http://msdn.microsoft.com/ja-jp/library/ms159110(v=sql.90).aspx"

-- SQL Server 2008
レポート サーバー実行ログ
"http://msdn.microsoft.com/ja-jp/library/ms159110(v=sql.100).aspx"

-- SQL Server 2008 R2
レポート サーバー実行ログと ExecutionLog3 ビュー
"http://msdn.microsoft.com/ja-jp/library/ms159110(v=sql.105).aspx"

-- SQL Server 2012
レポート サーバー実行ログと ExecutionLog3 ビュー
"http://msdn.microsoft.com/ja-jp/library/ms159110(v=sql.110).aspx"



7. パフォーマンスログ
==================

パフォーマンスログの採取方法および解析方法は、以前以下のブログでお伝えいたしました内容を確認し、情報採取を行います。

[SQL Troubleshooting] 第2回 : Tips -パフォーマンス ログの採取方法 (Windows Server 2003 ~ Windows Server 2008 R2)
[SQL Troubleshooting] 第3回 : パフォーマンスログの確認方法について

8. サーバートレースによる情報採取
==================
データソースに対してどのようなクエリが発行されているかについて確認します。
レポートのデータソースが SQL Server のデータベースを利用の際は、下記ブログに記載の手順で SQL Server サーバートレースを利用し情報を採取します。

SQL トレーススクリプトの作成、実行 (SQL Server 2005, 2008, 2008 R2)

レポートのデータソースが SQL Server Analysis Services のデータベースを利用の際は、下記ブログに記載の手順で Analysis Services サーバトレースを利用し情報を採取します。

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

 

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

2013 年 8 月 SQL Server 最新モジュール

$
0
0

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

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

                     
 

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2012

SP1

KB 2861107(CU5)

11.00.3373

2013/7

メインストリームサポート

SQL Server 2008 R2

SP2

KB 2871401(CU8)

10.50.4290

2013/8

メインストリームサポート

SQL Server 2008

SP3

KB 2863205 (CU12)

10.00.5844

2013/7

メインストリームサポート

SQL Server 2005

SP4

KB 2598903 (OD)

KB 2716427 Reporting Services (MS12-070)

9.00.5295

9.00.5324

2011/8

2012/10

延長サポート
(2016/4/12 終了)

 

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

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

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

Troubleshooting Connectivity #6 - 接続タイムアウトは悪なのか?

$
0
0

高橋 理香
SQL Developer Support Escalation Engineer

みなさん、こんにちは。

数年以上前からずっと個人的にいつかきっとわかってもらえる...と思いながら今日まで心の中でしまっていたこと。それが接続タイムアウトの存在意義。(いえ、実際にはお問い合わせいただいた方にはそれとなく、もしくははっきりとお伝えしたこともあるのですが、、、)

そんな接続タイムアウトについての考え方について今回は書きたいと思います。



接続タイムアウトとは?


接続タイムアウトとは、アプリケーションからの接続要求が一定時間内に完了しなかった事象を指します。また、その際に返されるエラーが、タイムアウト エラーです。

例えばこんなエラーがありますね。(接続時に発生するエラーとしてどんなエラーがあるかはまた後日に別のトピックにてご紹介予定です。)

Timeout に達しました。操作が完了する前にタイムアウト期間が過ぎたか、またはサーバーが応答していません

     

 

ログイン タイムアウトが時間切れになりました。


「一定時間内に完了しない」というのがどういうことかについては、このシリーズをご覧くださっている皆様ならお分かりいただけると思いますが念のため列挙します。

  • OS レベルのセッション確立に遅延が生じた。
  • ログイン認証の処理に遅延が生じた。
  • データベース アクセスに遅延が生じた。

ではそれぞれに遅延が生ずる主な理由は・・・

はい、皆様、以前のブログに書いていますので、そちらをご覧くださいね。

Troubleshooting: Connectivity #2 - エラー情報からわかる失敗原因

とにかくです。どこかに遅延が生じて、時間がかかってしまったという状況を指すわけです。

 


遅延を許容するか?それともエラーで中断させるか?


さてさて、ネットワーク等のインフラが整ってきた昨今ですが、いつどんな環境でも同じ程度のレスポンスって約束されているんでしょうか???


私が自宅で使っている PC は CPU のクロック数はそこそこであるもののメモリは少なく、また、ネットワークのスピードも、さっき下り 75Mbps だったのが今は 10Mbps くらいになっているなど、会社と同じようにインフラが整ってます!とは言いがたい状況です。会社で作業していたとしても、一部メンテナンスでつながりにくいことなどもあります。つまり、「いつどんな環境でも」という点でいえば、いまだそこまでは High Performance が保証されてはいないのが現実だと思います。


ではこの遅い状況もあるだろうという昨今の環境において、その遅い状況に遭遇した場合を考えてみましょう。あなたはどちらを望みますか?

遅いことを示すメッセージを出して後で再試行するのがいいですか?

それとも・・・

遅くてもいいからエラーは出さないで終わってほしいですか?


clip_image001少なくとも私が自宅にてちょっとした興味でどこかのサイトでお買い物なんかを行っているような状況の場合、メッセージが出て処理が中断されても問題ありません。むしろ、混雑していることを教えてもらえれば後日にやればいいだけということもあります。

勢いでクリックしたものなんかは考える余地ができます(笑)


clip_image002 

でも、これが職場で仕事中だったりすると「なんとか終わらせたいからエラーにはしないでー!」と思うこともあります。待ちを許容し、エラーよりもむしろ時間がかかっても終わってほしい場合ですね。


このように、遅延を許容するかエラーで中断させるかは、それを使用する環境が普段どのようなスピード感で使用できる環境で、かつ、使用するアプリケーション/システムがどのような要件で提供されるものであるかに依存するといえます。

 

接続タイムアウトの役割とは?


接続タイムアウトはこの「遅延を許容するか、それともエラーで中断させるか」を判断するための設定値と言えます。


著しく遅延している状況については障害として詳しく調査する必要があるかもしれませんが、いつもよりちょっとだけ遅いくらいなら、エラーにせずに時間かかったなという程度で済むものもあります。この判断材料として接続タイムアウトを使用してほしいのです。


したがって、開発者、および、システム提供者の皆様には、システムの利用環境、システムの利用者、システムの要件を加味してた上で、通常時の接続に要する時間の幅をあらかじめ計測するなどにより見積もり、その最長時間よりもどのくらい長くかかったものを障害とするか、という判断をぜひともまず最初に実施ください。


例えばこんな環境/システムがあったとします。

  • LAN 利用者の通常時の接続完了までの時間: 3秒 ~ 10 秒
  • WAN 利用者の通常時の接続完了までの時間: 20 秒 ~ 40 秒
  • サーバー環境でのフェールオーバーに要する時間: 40 秒 ~ 1分
  • システム要件: フェールオーバーした際にも可能な限りエラーとさせない。

上記の場合、接続要求が成功するのに 1分以上を要する可能性があるということになりますね。この場合には、接続タイムアウトが 100 秒ではギリギリの可能性がありますので、余裕を持たせて 120 秒、150 秒としてもいいかもしれません。(*)

(*) 実際の対応としては、接続タイムアウトを延ばすだけではなく、それに加えて接続の再試行のロジックを組み入れることが堅牢性に優れたシステムと言えます。


要件などは様々あり、上記は一例でしかありませんが、考え方の参考になれば幸いです。



最後に: 接続タイムアウトは悪なのか?


「接続タイムアウトは悪なのか?」ですが、私の答えは「No」 です。


前述の通り、接続タイムアウトは利用システム/環境の状況を判断するための材料でしかありません。その環境やシステムに応じて適切に設定している状況下で発生し、その遅延の要因となっているものが想定外の障害であった場合にはじめてそれが悪だといえるのだと思います。


なお、遅延の要因などを調査する場合には、前述した「Troubleshooting Connectivity #2 - エラー情報からわかる失敗原因」のほか、先に公開している以下のブログを参考に切り分けや情報採取などを実施してみてください。

Troubleshooting Connectivity #1 - SQL Server への接続

Troubleshooting Connectivity #4 - 接続エラーの調査方法


※今回は接続タイムアウトについて述べていますが、クエリ タイムアウト (もしくはコマンド タイムアウト) も同様です。どのくらいかかったら「そのシステムにおいて」問題があるとみなすのかの基準値として考えて適切な値を設定しましょう。仕組みについては、以下のブログで紹介していますのでご覧ください。

クエリタイムアウト - その仕組み

 

 

次回はまた #2 の続きとして、接続エラーとしてどのようなものが発生しうるかのご紹介ができればと思っています。

 

過去の Troubleshooting Connectivity シリーズはこちら。

 Troubleshooting Connectivity #1 - SQL Server への接続

 Troubleshooting Connectivity #2 - エラー情報からわかる失敗原因

 Troubleshooting Connectivity #3 - 予期しない接続切断

 Troubleshooting Connectivity #4 - 接続エラーの調査方法

 Troubleshooting Connectivity #5 - セッション確立までの動作

[SSRS] SharePoint 統合モードのレポートサーバー構築手順 (単一サーバー) - SQL Server 2012 と SharePoint 2013 の組み合わせ)

$
0
0

 

森  隆博
SQL Developer Support Engineer

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

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

SharePoint 2013 のシステム要件の詳細は下記技術情報に記載がございますので、ご参照ください。

    SharePoint 2013 のハードウェア要件およびソフトウェア要件

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

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

・SQL Server 2012 Enterprise
※SharePoint 統合が可能な Reporting Services のエディションは Enterprise と Business Intelligence と Standard です。
SQL Server 2012 の各エディションがサポートする機能

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

■統合における注意点

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

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

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

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


■手順概要

1. SharePoint 2013 必須コンポーネントをインストールする
2. SharePoint 2013 をインストールする
3. SQL Server 2012 をインストールする
4. SQL Server 2012 ServicePack 1 を適用する
5. SharePoint の構成を設定する
6. SharePoint と Reporting Services を統合構成する

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

1. SharePoint 2013 必須コンポーネントをインストールする
SharePoint 2013 必須コンポーネントをインストールしましょう。

ウィザードでどんどん先に進めます。
 

 
再起動を促されることがありますが、再起動後、インストーラーが自動で起動し、インストールは継続されます。

 

 

2. SharePoint 2013 をインストールする
SharePoint  2013 必須コンポーネントのインストールが完了したら、 SharePoint Server をインストールしましょう。
[SharePoint Server のインストール] をクリックしてインストールを開始します。

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

どんどん進めましょう。

 
[完全] インストールします。


 これで SharePoint 2013 インストールは完了です。

 

3. SQL Server 2012 をインストールする
SharePopint Server のインストールが完了しましたので、次にSQL Server 2012 のインストールを行います。

インストール画面左の [インストール] を選択します。


 インストールを進めましょう。

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

 

どんどん進めていきましょう。


ここでは全てのコンポーネントを選択しています。

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












4. SQL Server 2012 ServicePack 1 を適用する
SQL Server 2012 のインストール完了後、SQL Server 2012 の Service Pack 1 を適用します。
ウィザードに沿ってインストールしてください。







 

5. SharePoint の構成を設定する
SharePoint の構成をしていきましょう。
SharePoint 2013 製品構成ウィザードを管理者権限で実行します。

 
これもウィザードに沿って進めましょう。









構成が完了すると、ファーム構成の初期構成ウィザードが起動されます。



サービスは既定で結構です。










以上の設定で SharePoint サイトが使用できるようになりました。


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

SharePoint と Reporting Services の統合設定を行います。
SharePoint 2013 管理シェルからコマンド実行によって統合設定を行います。

 
管理シェルにて以下のコマンドを実行します。これにより、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 サービス アプリケーション] を選択します。

 

名前とアプリケーションプールを指定して [OK] ボタンをクリックします。

 

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

 

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

これにてすべての構築作業が完了です。ぜひご利用ください。


[SSRS] HTML 形式で表示したレポートと PDF や印刷で表示したレポートの見栄えが異なる。対処方法は!?

$
0
0

 

山崎 実久 
SQL Developer Support Engineer

SQL Server Reporting Services (SSRS) を利用してレポートをデザインし、PDF にエクスポートした場合や印刷した場合、デザインした通りにレポートのフォーマットを構成できない場合があります。
例えば、レポートのデザイン時にはなかった予期せぬ箇所での改行や、罫線の太さが異なるなどが挙げられます。

では、そういった場合どう対処すればよいか? また、なぜ見栄えが変わるのか? について、本 blog で説明します。

1. どのように対処するか?

 

対処方法は 3 つあります。
 

 A) デザインを変更する。

 B) 用途に応じたレポートをそれぞれ用意する。

 C) 最新の修正プログラムを適用する。

 

それぞれ詳細を説明します。

A) デザインを変更する。

HTML 形式や Word, Excel でエクスポートされたレポートの見栄えを重視するか、それとも PDFでのエクスポートや印刷されたレポートの見栄えを重視するか判断し、優先した方のフォーマットで運用する。
 

B)  用途に応じたレポートをそれぞれ用意する。

HTML 形式や Word, Excel でエクスポートするためのレポートと、PDFでエクスポートするためのレポートや印刷用のレポートと複数レポートを用意し、目的に合わせ使い分ける。

C) 最新の修正プログラムを適用する。

製品の制限や不具合に関する問題か否か確認するため、Reporting Services のバージョンを確認し、SQL Server 最新モジュールと照らし合わせ、最新でない場合は、最新のモジュールを適用します。少なくとも最新のサービスパックが適用されていることを確認します。

本記事作成時の最新のモジュール情報は、SQL Server の最新モジュール情報 (まとめページ)で確認することが可能です。
   

 

2. どうして見栄えが変わるのか?

 

SQL Server Reporting Services では 、レポートを処理する際、Report ProcessingData Processing、Report Renderingの 3 つの工程を経てレポートを出力します。

 

レポートの処理工程

 処理内容の概要

Report Processing

 レポート定義のレイアウト情報と取得したデータを組み合わせる。

 Data Processing

 データベースに接続しデータを取得する

 Report Rendering

 レポートを HTML や Word, Excel や PDF などの形式で出力する。

 

上記工程の Report Renderingでは、以下のような複数の レンダラ― (Renderer)を利用します。表示したいレポートの形式に合わせて、Renderer が選択されます。

 


 レンダラ― (Renderer)
 説明
 ATOM デバイス情報の設定      Atom 準拠の表示出力に関連するデバイス情報設定 
 CSV デバイス情報設定  CSV 表示出力に関連するデバイス情報設定
 Excel  デバイス情報設定 Excel 表示出力に関連するデバイス情報設定
 Word デバイス情報設定 Word 表示出力に関連するデバイス情報設定
 HTML デバイス情報設定 HTML 表示出力に関連するデバイス情報設定
 画像デバイス情報設定 IMAGE 表示出力に関連するデバイス情報設定
 MHTML デバイス情報設定 MHTML 表示出力に関連するデバイス情報設定
 PDF デバイス情報の設定 PDF 表示出力に関連するデバイス情報設定
 XML デバイス情報設定 XML 表示出力に関連するデバイス情報設定
 RGDI デバイス情報の設定 RGDI 表示出力に関連するデバイス情報設定

 

上記の表の通り、Excel としレポートを出力するのか、PDF としてレポートを出力するのかによって、SSRS で利用されるレンダラ―が異なることが分かります。

この利用されるレンダラーの違いにより、レポートの見栄えも変わるというのが、本事象です。

その他、レポートを Excel の xls 形式で出力した場合と、xlsx 形式で出力した場合の見栄えの違いも、レンダラーの違い、Excel 2003 レンダラーを利用するか、Excel レンダラーを利用するかの違いにより発生します。


HTML 形式で見たレポートのデザイン通りに、印刷したい場合や、PDF に出力したい場合でも、上記 SSRS の最適化の動作により、見栄えがどうしても変わってしまいます。

HTML 形式の見栄えを良くするか、印刷、PDF の見栄えを良くするかはトレードオフとなり、両方選択することができません。

 

+ 参考情報
レンダリングの動作 (レポート ビルダーおよび SSRS)
http://technet.microsoft.com/ja-jp/library/dd255244.aspx

 

 

以上、レポート表示の際に遭遇する問題について、参考になれば幸いです。

2013 年 9 月 SQL Server 最新モジュール

$
0
0

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

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

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2012

SP1

KB 2874879(CU6)

11.00.3381

2013/9

メインストリームサポート

SQL Server 2008 R2

SP2

KB 2871401(CU8)

10.50.4290

2013/8

メインストリームサポート

SQL Server 2008

SP3

KB 2880350 (CU13)

10.00.5846

2013/9

メインストリームサポート

SQL Server 2005

SP4

KB 2598903 (OD)

KB 2716427 Reporting Services (MS12-070)

9.00.5295

9.00.5324

2011/8

2012/10

延長サポート
(2016/4/12 終了)

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

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

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

どうする? SQL Server のクエリ パフォーマンスが低下した!

$
0
0

 

アプリケーションの応答が急に遅くなった、バッチ処理がいつもの時間に終わらない・・・
クエリのパフォーマンスが低下し早急に対処が必要な場合に、まずお試しいただきたいことをまとめました。

まずは 1 を実施してパフォーマンスが改善されるか確認し、ダメなら 2 または 3 へ進んでください。


1. 統計情報を更新する

統計情報を最新の状態にすることで、現在のデータ分布に最適な実行プランが選択されるようになる可能性があります。

a) データベース単位で実行   
    sp_updatestats

どのクエリを実行しても遅い、どのオブジェクトの統計情報を更新したらよいのかわからない、という場合にお試しください。

ステートメント)
----------------------------
USE <データベース名>;
GO
EXEC sp_updatestats;
----------------------------

使用例)
----------------------------
USE mydatabase;
GO
EXEC sp_updatestats;
----------------------------

sp_updatestats (Transact-SQL)
http://msdn.microsoft.com/ja-jp/library/ms173804.aspx

 

b) テーブル単位 or インデックス単位で実行
    UPDATE STATISTICS

特定のクエリが遅いとわかっている場合にお試しください。

ステートメント)
----------------------------
USE <データベース名>;
GO
UPDATE STATISTICS <テーブル名 or インデックス付きビュー名>;
GO
----------------------------
USE <データベース名>;
GO
UPDATE STATISTICS <テーブル名 or インデックス付きビュー名> <インデックス名 or 統計名>;
GO
----------------------------

使用例) tbl_01 テーブルのインデックス idx_01 の統計を更新します。
----------------------------
USE mydatabase;
GO
UPDATE STATISTICS dbo.tbl_01 idx_01;
GO
----------------------------

UPDATE STATISTICS (Transact-SQL)
http://msdn.microsoft.com/ja-jp/library/ms187348.aspx

WITH FULLSCAN  オプション
すべての行をスキャンして統計を計算することにより、高品質のクエリプランを作成できる場合もあります。


2. 実行プランを作成し直す

パラメータクエリ、ストアドプロシージャに有効���す。
実行プラン生成時に使用されたパラメータ値が特殊だった場合、大半のパラメータ値にとっては最適な実行プランになっていないことがあります。   
実行プランを作成し直すことによって、より適した実行プランが生成される可能性があります。

アドホッククエリの中には毎回実行プランが作成されるものもあるため、そのようなクエリに対してはこの対処は効果が期待できません。

a) プランキャッシュをクリアする(インスタンス単位)   
    DBCC FREEPROCCACHE

どのクエリが遅いのかわからない場合にお試しください。

ステートメント)
----------------------------
DBCC FREEPROCCACHE;
----------------------------

DBCC FREEPROCCACHE (Transact-SQL)
http://msdn.microsoft.com/ja-jp/library/ms174283(v=sql.110).aspx

 

b) 次回実行時にリコンパイルする(テーブル or ストアドプロシージャ単位)
    sp_recompile

特定のクエリが遅いとわかっている場合にお試しください。

ステートメント)
----------------------------
USE <データベース名>;
GO
EXEC sp_recompile N'<テーブル名 or ストアドプロシージャ名>';
GO
----------------------------

使用例) tbl_01 テーブルを対象とするストアド プロシージャおよびトリガーが次回実行時に再コンパイルされます。
----------------------------
USE mydatabase;
GO
EXEC sp_recompile N'dbo.tbl_01';
GO
----------------------------

sp_recompile (Transact-SQL)
http://msdn.microsoft.com/ja-jp/library/ms181647(v=sql.110).aspx


3. インデックスを再構築する

    ALTER INDEX ... REBUILD

インデックスの断片化を解消することにより、I/O 負荷を軽減し、パフォーマンスが向上する可能性があります。

ステートメント)
----------------------------
USE <データベース名>;
GO
ALTER INDEX <インデックス名> ON <テーブル名> REBUILD;
GO
----------------------------
USE <データベース名>;
GO
ALTER INDEX ALL ON <テーブル名> REBUILD;  -- テーブルに関連付けられているすべてのインデックスを対象
GO
----------------------------

使用例) tbl_01 テーブルのインデックス idx_01 を再構築します。
----------------------------
USE mydatabase;
GO
ALTER INDEX idx_01 ON dbo.tbl_01 REBUILD;
GO
----------------------------

ALTER INDEX (Transact-SQL)
http://msdn.microsoft.com/ja-jp/library/ms188388.aspx  

 

※ 断片化率の確認方法

以下のクエリを実行すると、再構築が必要と思われるインデックスに対する ALTER INDEX ... REBUILD 文が生成されます。
再構築の対象とする条件は、断片化率が 30 % 以上かつページの合計数が 1000 ページ以上のインデックスです。

USE <データベース名>;
GO
SELECT 'ALTER INDEX ' + '[' + C.name + ']' + ' ON [' + D.name + '].[' + B.name + '] REBUILD' cmd,     
             D.name AS schemaname,     
             B.name AS table_name,     
             C.name AS index_name,     
             C.index_id,
             A.partition_number,
             A.avg_fragmentation_in_percent,
             A.page_count
  FROM sys.dm_db_index_physical_stats (DB_ID(),null,null,null,null) as A
    JOIN  sys.objects AS B
      ON  A.object_id = B.object_id
    JOIN  sys.indexes AS C
      ON  A.object_id = C.object_id  AND A.index_id = C.index_id
    JOIN  sys.schemas D
      ON  B.schema_id = D.schema_id
WHERE B.type = 'U'
      and C.index_id > 0
      and A.page_count > 1000
      and A.avg_fragmentation_in_percent > 30
ORDER BY A.avg_fragmentation_in_percent DESC;
GO

sys.dm_db_index_physical_stats (Transact-SQL)
http://msdn.microsoft.com/ja-jp/library/ms188917.aspx

 

 

どれも試してみたけどダメだった場合は・・・

  詳細な調査のご参考に

      [SQL Troubleshooting] SQL Server トラブルシューティング 6 回シリーズのご案内
      http://blogs.msdn.com/b/jpsql/archive/2012/03/30/sql-server-6.aspx

  クエリ チューニングのご参考に

      実行プランを読む - 基本編
      http://blogs.msdn.com/b/jpsql/archive/2011/09/07/10207003.aspx

      実行プランを読む - 活用編
      http://blogs.msdn.com/b/jpsql/archive/2011/11/15/10235685.aspx

 

KB 2007728 - Error message when you use SSL for connections to SQL Server: "The certificate received from the remote server was issued by an untrusted certificate authority" の補足

$
0
0

 

神谷 雅紀
Escalation Engineer


KB 2007728 の説明が分かりにくいため補足の解説が欲しいという要望がありましたため、少し古い KB についての話題にはなりますが、今回は KB 2007728 を補足したいと思います。

 

KB 2007728
Error message when you use SSL for connections to SQL Server: "The certificate received from the remote server was issued by an untrusted certificate authority"

http://support.microsoft.com/kb/2007728/en-us

 

事象

KB が取り上げている事象は、システムイベントログに以下のイベントが記録されることがあるというものです。

ソース : Schannel
イベント ID : 36882
レベル : エラー
説明 : リモート サーバーから受信した証明書は、信頼されていない証明機関によって発行されています。 このため、この証明書に含まれているデータはどれも検証できません。 SSL 接続の要求に失敗しました。 添付されたデータにサーバー証明書が含まれています。


このイベントの [詳細] (「添付されたデータ」) には、このイベントが記録される原因となっている証明書の名前 “SSL_Self_Signed_Fallback” が含まれています。

また、以下のイベントも合わせて記録される場合があります。

ソース: Schannel
イベント ID: 36888
レベル: エラー
説明 : 次の致命的な警告が生成されました: 48。内部エラーの状態は 552 です。

 

原因

Schannel イベント 36882 は、イベントの説明のとおり、信頼されていない証明機関によって発行された証明書が使用されたことを示しています。

SQL Server では、クライアントとの通信を暗号化するように構成することができますが、暗号化には SSL を用います。SQL Server とクライアントとの通信が暗号化されるように構成されているにもかかわらず、 SSL のために使用することのできる証明書がインストールされていない場合、SQL Server は独自の証明書を発行し、その証明書を使用して暗号化を行います。しかし、SQL Server は、信頼された証明機関ではないため、イベント 36882 が記録されます。

このイベントはユーザー作成のクライアントアプリケーションに限って発生するのかという質問がありましたが、前述の要因により記録されるものであるため、クライアントアプリケーションの作成元や使用するデータアクセスインタフェースの種類には依存しません。ユーザーが独自に作成した Web アプリケーションであるのか、SQL Server 製品に付属している Management Studio や sqlcmd であるのかは、全く無関係です。どのようなクライアントアプリケーションからの接続であっても、前述の状況であればイベントは記録されます。また、データアクセスインタフェースが ODBC であるのか ADO.NET であるのかといったことも関係しません。

 

イベントを記録させないようにする方法

イベント 36882 のメッセージから対応方法は明白ではありますが、SQL Server を実行しているサーバーに、信頼された証明機関により発行された SSL 用の証明書をインストールし、その証明書を使用して接続を暗号化するように構成すれば、イベントは記録されなくなります。

証明書のインストール方法および暗号化設定方法については、以下を参照して下さい。

 

 

データベース エンジンへの暗号化接続の有効化 (SQL Server 構成マネージャー)

http://technet.microsoft.com/ja-jp/library/ms191192.aspx

 

Microsoft 管理コンソールで SQL Server 用に SSL 暗号化を有効にする方法

http://support.microsoft.com/kb/316898/ja

 

尚、セキュリティの観点からは、本来は証明書をインストールすべきですが、意図的に SQL Server の自己署名証明書を使用して暗号化を行っている場合には、このイベントを無視しても構いません。

 

[JDBC] JDBC ドライバーの Java 7 対応について

$
0
0

佐藤美菜
SQL Developer Support Engineer

Java 7 に対応している Microsoft SQL Server 用の JDBC Driver についての情報を紹介します。

Java 7 に対応しているのは、JDBC Driver 4.0 です。 sqljdbc4.jar クラス ライブラリで提供されています。
sqljdbc4.jar クラス ライブラリは、Java ランタイム環境(JRE) 6.0 または JRE 7.0での動作をサポートします。

 

参考情報

英語のド���ュメントとなりますが、以下サイトに、JRE 6.0, JRE 7.0 をサポートする旨の公開情報があります。

System Requirements for the JDBC Driver
http://technet.microsoft.com/en-us/library/ms378422.aspx

 

留意事項

JDK 7.0 (開発環境) で JDBC Driver 4.0 を使用することはサポートしていません。
JRE 7.0 で運用する場合は、JDK 6.0 で開発したアプリケーションを JRE 7.0 上で動作させることをご検討ください。

※ JDK 7.0  については、2013/9 現在、今後サポートする予定は立っておりません。

なお、JDBC 4.0 は JDK 6.0 でのテストを実施済みであるため、技術的な観点では、JDK 6.0 と 7.0 の互換性が保たれていれば、JDK 7.0 の新機能の利用を避けた JDK 7.0 での開発は問題ないと考えられます。

上記内容について、US の Blog でも紹介しております。よろしければご参照ください。

The Microsoft JDBC Driver now supports JRE 7
http://blogs.msdn.com/b/jdbcteam/archive/2012/10/19/the-microsoft-jdbc-driver-now-supports-jre-7.aspx

[ADO.NET] DataGridView 内のデータ編集とそのときのバインドした DataTable の動作

$
0
0

佐藤 美菜
SQL Developer Support Engineer

みなさん、こんにちは。今回は、DataGridView に DataTable をバインドしているときに DataGridView 内のデータを編集した際の動作について、少々注意が必要な場合をご紹介します。

現象

以下のような操作をします。

  1. DataGridView に DataTable をバインドして画面表示をしている
  2. DataGridView の値を変更する
  3. DataTable(DataSet) へ操作を行う ( 例えば、DataTable.Select、DataTable.Compute、DataTable.Copy 等)

この場合、DataGridView で変更した値は、明示的にカレント行を移動しないと DataTable には反映されません。
これは DataGridView の想定された動作です。

���細 

例えば、下記のように「全選択」ボタンで DataGridView のすべての行の col1 をチェックします。そして、チェックされた行数を DataTable.Compute メソッドでカウントします。すると、3 行選択されているにも関わらず、2 行しかカウントされません。

image

確認コード例(VB)  

Public ClassForm1

    Private Sub Form1_Load(sender As Object, e AsEventArgs) Handles MyBase.Load
       ‘ データソースから取得した値の DataTable を DataGridView へバインドします
       Me.TableAdapter1.Fill(Me.DataSet1.Table_1)
        DataGridView1.DataSource = Me.DataSet1.Table_1

    End Sub           
 
   Private Sub Button1_Click(sender As Object, e AsEventArgs) Handles Button1.Click
       For i As Integer = 0 To DataGridView1.RowCount - 1
            DataGridView1.Item("Col1DataGridViewCheckBoxColumn", i).Value = 1
        Next

      MessageBox.Show("選択数:"& DataSet1.Table_1.Compute("COUNT(col1)", "col1<>0") & "行選択されました。")
    End Sub

End Class


DataGridView の値を更新すると、カレント行を移動するまでその更新は保留のままになります。今回のように、DataGridView への更新が GUI からではなく、プログラム中から行われた場合はカレント行が移動されません。上記の例では、カレント行である DATA1 の行が保留のままになっています。変更が確定されていないため、DataTable からは意図した結果が得られない状況になります。

DataGridView のカレント行を移動すれば、保留だった行の変更が確定され、DataTable からも結果が確認できるようになるのですが、今回のようにプログラム中から更新する場合には少し対策が必要です。

対策

対策としては、以下の 3 つの方法が考えられます。

  • DataGridView の値を更新後、明示的に DataRow.EndEdit を実行する
  • DataGridView の値を更新後、明示的に DataTable.AcceptChanges ( または DataSet.AcceptChanges ) を実行する
  • DataGridView の値を更新する代わりに直接 DataRow を更新する

 

対策1: DataRow.EndEdit

DataRow.EndEdit をカレント行に対して行うことにより、この行で行われている変更を終了し確定します。

上記コードでの対策例   

Private Sub Button1_Click(sender As Object, e AsEventArgs) Handles Button1.Click
    For i As Integer = 0 To DataGridView1.RowCount - 1             
        DataGridView1.Item("Col1DataGridViewCheckBoxColumn", i).Value = 1
    Next

    '対処策1
    Me.DataSet1.Table_1.Rows(DataGridView1.CurrentCell.RowIndex).EndEdit()

    MessageBox.Show("選択数:"& DataSet1.Table_1.Compute("COUNT(col1)", "col1<>0") & "行選択されました。")
End Sub

 

対策2: DataTable.AcceptChanges

AcceptChanges を実行すると、カレント行を含めた、前回 AcceptChanges を呼び出した以降に行われた DataTable への変更を確定します。  このとき DataRowState も変更され、すべての Added および Modified 行は、Unchanged に変更され、Deleted 行は削除されます。

※ DataTable 全体に対して変更が確定され、RowState が Unchanged に変更される点が「対策1 : DataRow.EndEdit」 と異なる点です。    

上記コードでの対策例

Private Sub Button1_Click(sender As Object, e AsEventArgs) Handles Button1.Click
    For i As Integer = 0 To DataGridView1.RowCount - 1             
        DataGridView1.Item("Col1DataGridViewCheckBoxColumn", i).Value = 1
    Next

    '対処策2
    Me.DataSet1.Table_1.AcceptChanges()

    MessageBox.Show("選択数:"& DataSet1.Table_1.Compute("COUNT(col1)", "col1<>0") & "行選択されました。")
End Sub

 

対策3: DataRow を直接更新する

DataGridView の値を更新する代わりに直接 DataRow を更新すると、DataGridView で表示される値と DataTable の値との間で差が出ないため、意図した結果を得られます。

上記コードでの対策例   

Private Sub Button1_Click(sender As Object, e AsEventArgs) Handles Button1.Click
    '対策3
    'For i As Integer = 0 To DataGridView1.RowCount - 1
    '    DataGridView1.Item("Col1DataGridViewCheckBoxColumn", i).Value = 1
    'Next
    For i As Integer = 0 To Me.DataSet1.Table_1.Rows.Count - 1
        Me.DataSet1.Table_1.Rows(i)(0) = 1
    Next

    MessageBox.Show("選択数:"& DataSet1.Table_1.Compute("COUNT(col1)", "col1<>0") & "行選択されました。")
End Sub

 

どの対策を採用するかは、アプリケーションの要件に依存しますので、要件にあった方法をご選択ください。

 

<参考情報>
DataRowView クラス
http://msdn.microsoft.com/ja-jp/library/system.data.datarowview.aspx

DataRow.EndEdit メソッド
http://msdn.microsoft.com/ja-jp/library/system.data.datarow.endedit.aspx

DataTable.AcceptChanges メソッド
http://msdn.microsoft.com/ja-jp/library/system.data.datatable.acceptchanges.aspx

DataRowState 列挙体
http://msdn.microsoft.com/ja-jp/library/system.data.datarowstate.aspx

[SQL Connectivity] 名前付きパイプでの接続時トラブルシューティング

$
0
0

佐藤美菜
SQL Developer Support Engineer

SQL Server へのアクセスは各種プロトコル( TCP/IP、名前付きパイプ、共有メモリ) で行えます。 SQL Server 2000 以降、既定のプロトコルは TCP/IP となっており、TCP/IP での接続がメインとなっているのが昨今です。 TCP/IP に比べ、名前付きパイプは古いテクノロジーで忘れがちですが、忘れがちだからこそ、ということで、今回は、名前付きパイプでの接続時のトラブルシューティング方法を紹介します。接続できなかった場合にはチェックしてみてください。

 

問題箇所特定のための切り分け接続テスト

名前付きパイプでのトラブルシューティングに入る前に、まずは、問題箇所を特定するために、以下で案内している 「2-2. 再現性がある場合に、切り分けのために実施いただきたい接続テスト」を試してみてください。

Troubleshooting Connectivity #4 - 接続エラーの調査方法

名前付きパイプの接続時の問題かどうかを切り分けるには、接続テスト時のサーバー名に使用するプロトコルを指定して確認します。

TCP/IP での接続 :tcp:接続先SQLServerホスト名
名前付きパイプでの接続 :np:接続先SQLServerホスト名
共有メモリでの接続 :lpc:接続先SQLServerホスト名

接続テストの結果、名前付きパイプでの接続に問題があることが特定できたら、次に進みます。

 

名前付きパイプでの接続トラブルシューティング

はじめに : 名前付きパイプでの接続時の動作について

名前付きパイプ プロトコルによる通信では、サーバー側の IPC$ という共有名に対して接続要求を行います。ユーザー情報を渡し、適切であ���場合に接続が確立されます。クライアント上で動作しているアプリケーションの実行ユーザーが、このサーバーの共有にアクセスする権限を持っていないと名前付きパイプの接続が失敗します。

※ SQL Server 認証の場合でも、名前付きパイプを使用する場合は、Windows ユーザーの認証処理がプロトコル レベルで必要となります。

Windows Server 2003 以降の環境では、セキュリティの観点から IPC$ 共有へのアクセスを含め各種制限が行われていることにも注意が必要です。

 

トラブルシューティング ステップ

基本的に必要となるトラブルシューティングのステップは以下の 2 つです。

  • IPC$ 共有への接続確認
  • SQL Server の待ち受けプロトコルの確認

ただし、Workgroup 環境の場合、または SQL Server 2005 環境の場合には追加の作業が必要となります。
該当する場合には、上記 2 つの作業に加えて、トラブルシューティングの作業を行いましょう。

 

トラブルシューティング

<基本確認事項>

IPC$ 共有への接続確認

アプリケーションを実行しているユーザーで、IPC$ 共有へ接続ができるかどうか、クライアント上のコマンドプロンプトから以下を実行して確認します。

net view \\接続先SQLServerホスト名
net use \\接続先SQLServerホスト名\IPC$

失敗する場合は、アプリケーションを実行しているユーザーがサーバー上で権限を持っているかどうかを確認してください。

※ 接続確認が終わりましたら、以下コマンドで IPC$ への共有を解除しておいてください。

net use \\接続先SQLServerホスト名\IPC$ /delete

(確認例: 失敗時)

C:\>net view \\sqlhost01 /all
システム エラー 5 が発生しました。

アクセスが拒否されました。

C:\>net use \\sqlhost01\IPC$ /all
\\sqlhost01\IPC$のパスワードまたはユーザー名が無効です。

'sqlhost01' のユーザー名を入力してください: test
sqlhost01 のパスワードを入力してください:
システム エラー 1326 が発生しました。

ログオン失敗: ユーザー名を認識できないか、またはパスワードが間違っています。

 

(確認例: 成功時)

c:\>net view \\sqlhost01 /all
\\sqlhost01の共有リソース

 

共有名     タイプ  使用  コメント

-------------------------------------------------------------------------------
ADMIN$     Disk          Remote Admin
C$         Disk          Default share
CCMLOGS$   Disk          Public Share
ccmsetup$  Disk          Public Share
Dump       Disk
IPC$       IPC           Remote IPC
MCP        Disk
print$     Disk          プリンター ドライバー
Users      Disk
コマンドは正常に終了しました。

C:\>net use \\sqlhost01\IPC$
コマンドは正常に終了しました。

 

SQL Server の待ち受けプロトコルの確認

SQL Server の付属ツールである “SQL Server 構成マネージャー” (SQL Server Configuration Manager) で待ち受けプロトコルの状態が確認できます。該当のインスタンスのプロトコルの「名前付きパイプ」が有効になっていることを確認します。

有効になっていない場合は、状態を “有効” に変更します。設定を変更後は、SQL Server サービスの再起動が必要です。

image

 

<Workgroup 環境の場合のみ必要となる確認作業>

パススルー認証を使用した接続確認

クライアントとサーバーの両マシンに、同じ名前、パスワードの Windows ローカル ユーザーを用意し、サーバー側のファイル共有 IPC$ に接続できるようにし、接続確認をします。

ローカル ポリシーの設定確認

WORKGROUP 環境の場合は、クライアント ローカルにしか存在しないユーザーでアクセスする場合、匿名や GUEST ユーザーとしてサーバーにアクセスします。ローカル ポリシーの設定で IPC$ 共有へのアクセスが拒否される場合があります。

クライアントのどのユーザーも IPC$ 共有へアクセスできるようにするには、以下の手順でサーバーのローカル ポリシーの設定を有効化することが有効な場合もあります。この方法で接続できるようになるか試してみてください。

<手順>

  1. サーバー側の管理ツールで、[ローカル セキュリティ ポリシー] を選択する。
  2. セキュリティの設定のツリーで、[ローカル ポリシー] - [セキュリティ オプション] を選択する。
  3. 「ネットワーク アクセス : Everyone のアクセス許可を匿名ユーザーに適用する」は既定で [無効] になっていることを確認する。
  4. 「ネットワーク アクセス : Everyone のアクセス許可を匿名ユーザーに適用する」を右クリックし、[プロパティ] を選択する。
  5. [有効] に変更し、[OK] を選択する。

 

<SQL Server 2005 を利用している場合のみ必要となる確認作業>

SQL Server 2005 の場合は、セキュリティ構成の設定で名前付きパイプでの接続待ち受けができていることを確認します。

<手順>

  1. SQL Server セキュリティ構成を起動し、[サービスと接続のセキュリティ構成] をクリックします。
  2. [サービスと接続のセキュリティ構成] ボックスの [インスタンス別に表示] ボックスに、コンピュータにインストールされているデータベース エンジン インスタンスの一覧が表示されます。[インスタンス別に表示] ボックスで、構成するインスタンスを展開し、[データベース エンジン] を展開して、[リモート接続] をクリックします。
  3. [ローカル接続およびリモート接続] において名前付きパイプが有効になっていることを確認します。

image      image

※ SQL Server 2008 以降では、リモート接続は既定で許可されています。この設定は、SQL Server Management Studio より、[サーバーのプロパティ] – [接続] – [リモート サーバー接続] で確認できます(下画面参照)。また、待ち受けプロトコルの設定は、 “SQL Server 構成マネージャー” から設定します。そのため、上記に該当する確認作業は必要ありません。

image

 

以上です。

お役に立てていただけますと幸いです。


[SSRS] Reporting Services サービスが起動しない

$
0
0

小林 真治
SQL Developer Support Escalation Engineer


みなさん、こんにちは。
これまで起動していた SQL Server Reporting Services サービスが急に起動しなくなってしまった、というお問い合わせを何件かいただきましたので、この場を借りて対処方法についてお知らせします。
全て(SQL Server 2005, 2008, 2008 R2, 2012) の Reporting Services のバージョンで発生し得る問題です。


要因について

Reporting Services サービスが起動しなくなるタイミングは、修正プログラムや Service Pack の適用後など様々ですが、サービス起動の失敗は、サービス コントロールマネージャのタイムアウト時間である 30秒以内に、 Reporting Services サービスが自身のステータスをサービスコントロールマネージャへ通知できないことに起因しています。

尚、タイムアウトである応答時間までに応答を返せない原因として、Reporting Services の起動時の証明書関連のチェック処理に時間を要している可能性が想定されます。
Reporting Services は、 .NET Framework ベースのアプリケーションとなりますが、 .NET Framework のアセンブリに、 Authenticode の署名をもつ場合、 ロード時に CRL (証明書失効リスト) をダウンロードし、Authenticode の署名が失効していないかどうかの確認を行います。
この確認において、インターネットにアクセスできない環境や参照先 URL に接続を行う際に時間を要すると、サービス起動処理に許容された時間内に処理が収まらずタイムアウトに達し、この結果、 Reporting Services サービスの起動がキャンセルされます。
この現象は、同様の構成をしたサーバーにおいても発生する/しないの差違が見られることがあります。


合致しているかの判断基準
前述の要因に合致している場合、イベントログのシステムログに下記のイベントが発生していることを確認できます。
下記のイベントは既定のインスタンス(MSSQLSERVER)におけるイベントログとなりますので、現象が発生しているインスタンスによってインスタンス名は異なります。

イベント1 

種類 : エラー
ソース : Service Control Manager
分類 : なし
イベント ID : 7000
説明 :
" SQL Server Reporting Services (MSSQLSERVER) サービスを、次のエラーが原因で開始できませんでした:
そのサービスは指定時間内に開始要求または制御要求に応答しませんでした。"

イベント2

種類 : エラー
ソース : Service Control Manager
分類 : なし
イベント ID : 7011
説明 :
SQL Server Reporting Services (MSSQLSERVER) サービスの接続を待機中にタイムアウト(30000 ミリ秒) になりました。


本現象の対処策について
本現象の対処策として、下記の二つの対処策が有効です。

  a. Reporting Servicesのアセンブリの証明書のチェックを無効にする
  b. サービスコントロールマネージャ のタイムアウトを延ばす

それぞれの詳細を以下に記載致します。

a. Reporting Servicesのアセンブリの証明書のチェックを無効にする
Reporting Services はアセンブリのチェック処理を必須としないため、Reporting Services のみアセンブリの証明書関連のチェック処理を無効にすることで、証明書関連のチェックの時間を省きサービス起動時間に応答を返すようにします。
この動作変更により、Reporting Services に影響を与えることはありません。また、この操作による OS の再起動は必要としません。

Reporting Servicesのアセンブリの証明書関連のチェック処理を無効にするには、ReportingServicesService.exe.config ファイルに以下を追加します。

<generatePublisherEvidence enabled="false"/>

下記に、一例を紹介します。

1). ReportingServicesService.exe.config をコピーしバックアップします。
既定では、下記のパスに存在いたしますが、環境に合わせてパスをご変更ください。
この時点の設定ファイルをバックアップすることで、不測の事態が生じた際に、該当バックアップファイルをもとに戻して対応します。

- SQL Server 2005: C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\bin

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

- SQL Server 2008 R2: C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin

- SQL Server 2012: C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\ReportServer\bin

2). ReportingServicesService.exe.config をメモ帳などで開きます。
該当パス上の ReportingServicesService.exe.config ファイルをメモ帳で開きます。

3). <runtime> タグの配下に下記を追加します。

<generatePublisherEvidence enabled="false"/>

例えば、下記のような形で追記します。

----------------------------------------------------------------------------
              <runtime>
                           <generatePublisherEvidence enabled="false"/>
----------------------------------------------------------------------------

4). ReportingServicesService.exe.config への変更を保存します。

5). Reporting Services サービスを起動します。

b. サービスコントロールマネージャ のタイムアウトを延ばす
本現象は、サービスコントロールマネージャのタイムアウト時間までに、 Reporting Services サービスの応答が通知されないために発生しています。
このため、サービスコントロールマネージャのタイムアウト時間を、 Reporting Services サービスからの応答時間まで延長することで回避することが可能です。
サービスコントロールマネージャのタイムアウト時間は、下記資料の「回避策」にある対処方法を実施ください。

Windows Server 2003 でサービスが開始されずイベント 7000 および 7011 が記録される
http://support.microsoft.com/kb/922918/ja

<考慮事項>
・x64 環境では、上記資料の [DWORD 値] の部分は [DWORD (32 ビット) 値] と表示されますので、[DWORD (32 ビット) 値] を追加します。
・タイムアウト値に指定する値は、環境により適切なタイムアウト値が異なりますが、 弊社実績から、まずは 1 分に相当する、60000に設定し、サービス起動可否をご確認ください。
・60000 にて回避できない場合は、値をさらに大きくしてお試しください。
・本対処策を実施した場合、全てのサービスに設定したタイムアウト値が設定されます点にご注意ください。
・変更を有効にするために、OS の再起動が必要です。


参考情報
MS12-070 の適用により SSRS が起動しない事象を説明した blog が公開されています。

Reporting Services service doesn't start after the installation of MS12-070 security patch
http://blogs.msdn.com/b/mariae/archive/2012/11/12/reporting-services-service-doesn-t-start-after-the-installation-of-ms12-070-security-patch.aspx

 

 

バックアップからのリストアによるリカバリ手順

$
0
0

みなさん、こんにちは。今回は バックアップからのリストアによる SQL Server のリカバリ手順についてご紹介します。

本手順では SQL Server 2012 を使用して、下記 の2 通りのリカバリ手順について記載しています。

  A. 障害発生直前までのリカバリ手順

  B. ある特定の時点までのリカバリ手順 

■前提条件 

障害発生直前、またはある特定の時点までデータベースを復旧するためには、下記 の 3 つの条件を満たしていることが必要です。 

  1. 完全バックアップを取得済みであること。

  2. トランザクション ログが破損していないこと。

  3. データベースの復旧モデルが「完全」であること。

  ※ 本手順は ServerA という名前のサーバー上にインストールされた SQL Server の test データベースについて、2013 年  9  月 18 日に下記のバックアップを取得済みであることを前提として記載しています。

 No時間バックアップの種類バックアップ ファイル名
 102:00完全バックアップc:\work\full.bak
 202:30ログバックアップc:\work\log1.bak
 312:00差分バックアップc:\work\diff.bak
 4 12:30ログバックアップc:\work\log2.bak

 

A.  障害発生直前までのリカバリ手順

ディスク障害等でデータファイル (.mdf) が破損してしまった場合に、障害発生直前までデータベースを復旧する手順を下記にご紹介します。

1. コマンド プロンプトを起動し、下記のコマンドを実行して、残ったトランザクション ログ(まだバックアップしていないログ)を、NO_TRUNCATE オプションを使用してバックアップします。

    ---------------------------------------------------------------------------------------  

      C:\> sqlcmd -E -SServerA
      1> BACKUP LOG test TO DISK = 'C:\work\log3.bak' WITH NO_TRUNCATE
      2> go
 

    ---------------------------------------------------------------------------------------  

    ※このログは、’ログ末尾’ や ’TAIL ログ’ とも呼ばれます。

    ※ NO_TRUNCATE オプションは、ログ末尾をバックアップするとともに、ログを切り捨てないという効果もあります。

 2. 下記のコマンドを実行して、02:00 に取得した完全バックアップをリストアします。

    --------------------------------------------------------------------------------------------------------
      1> RESTORE DATABASE test FROM DISK = 'C:\work\full.bak' WITH NORECOVERY, REPLACE

      2> go  
    --------------------------------------------------------------------------------------------------------

    ※NORECOVERY  オプションは、まだリストアすべきバックアップがある場合に使用するオプションです。NORECOVERY  を指定してリストアを行った場合は、データベースが「復旧中」(リストア中)となり、ユーザーからの接続を一切できないようにブロックします。

    ※REPLACE  オプションは、指定したデータベースと同じ名前のデータベースが既に存在している場合でも、データベースとその関連ファイルが作成されます。その場合、既存のデータベースは削除されます。

3. 下記のコマンドを実行して、12:00 に取得した差分バックアップをリストアします。

    -----------------------------------------------------------------------------------------------
      1> RESTORE DATABASE test FROM DISK = 'C:\work\diff.bak' WITH NORECOVERY

      2> go 
    -----------------------------------------------------------------------------------------------
    

4. 下記のコマンドを実行して、12:30 に取得したログ バックアップをリストアします。

    --------------------------------------------------------------------------------------- 
      1> RESTORE LOG test FROM DISK = 'C:\work\log2.bak' WITH NORECOVERY

      2> go 
     --------------------------------------------------------------------------------------

 5. 下記のコマンドを実行して、上記手順 1 で取得した TAIL ログをリストアします。

   ------------------------------------------------------------------------------------- 
     1>RESTORE LOG test FROM DISK = 'C:\work\log3.bak' WITH RECOVERY

     2> go 
   -------------------------------------------------------------------------------------
  

   ※RECOVERY  オプションは、リストア後にデータベースを完全復旧した状態にします。これは、リストアが完了したことの合図になり、残りのバックアップをリストアすることはできません。

 6. 下記のコマンドを実行して、test データベースに接続します。

   ------------------ 
     1> USE test

     2> go 
   ------------------

接続できればリカバリは完了です。 test データベースは、障害発生直前の状態まで復旧しています。

 

B.  ある特定の時点までのリカバリ方法

データを誤って削除してしまった場合等に、ある特定の時点までデータベースを復旧する手順を下記にご紹介します。

本手順では、2013 年 9 月 18 日 の 12 時15 分 00 秒  に誤ってデータを削除してしまい、2013 年 9 月 18 日 の 12 時 14 分 59 秒  の時点までデータベースを復旧することを想定しています。

1. 上記 ‘A.  障害発生直前までのリカバリ手順’ の手順 1 から 手順 3 までを実行します。

2.  下記のコマンドを実行して、12:30 に取得したログ バックアップをリストアします。

     -------------------------------------------------------------------------------------------------------------------- 
      1> RESTORE LOG test FROM DISK = 'C:\work\log2.bak' WITH RECOVERY, STOPAT = '2013-09-18 12:14:59'

      2> go 
     --------------------------------------------------------------------------------------------------------------------

    ※STOPAT  オプションは、特定の時間までのデータへ復元したいという場合に使用するオプションです。

3. 下記のコマンドを実行して、test データベースに接続します。

   ------------------
     1> USE test

     2> go 
   ------------------

接続できればリカバリは完了です。 test データベースは、データが削除される直前の状態まで復旧しています。

 

< 参考情報 >

自習書シリーズ 

    - バックアップと復元

       http://www.microsoft.com/ja-jp/sqlserver/2012/technology/self-learning.aspx

 

[Windows XP] 暗号化された SQL Server Compact Edition データベースに対してアクセス遅延が発生することがある

$
0
0

.NET Framework 4.0 ベースのアプリケーションにおいて、暗号化された SQL Server Compact Edition データベースに対するデータアクセス処理を行った際、Windows XP 環境で処理が遅くなることがあります。

1. 問題発生要因

SQL Server Compact Edition プロバイダは、暗号化されたデータベースを参照する際に初回に CryptAcquireContext メソッドをコールします。暗号化されたデータの複合のためのキー コンテナーは、マシンコンテナに格納されているため(※)、下記フォルダ (以下 MachineKeys フォルダと呼称) を参照することになります。

C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

MachineKeys フォルダにアクセス出来ない場合、後処理ロジックに分岐しますが、この後続処理に時間を要し処理が遅くなります。従って、対処方法としてはアプリケーションを実行するユーザーに MachineKeys フォルダに対する参照権限を付与していただくことで、後続の処理ロジックを実行させないということになります。

2. 対処方法

事前に MachineKeys フォルダに対し、SQL Server Compact Edition を参照するユーザーに対してアクセス権限を付与します。これにより後続の処理ロジックを実行させないことにより遅延が抑止されます。なお、既に SQL Server Compact Database をインストールしている環境には、既に MachineKeys フォ ルダ以下にキーコンテナが存在します。他のアプリケーションが、SQL Server Compact Database を使用している場合などは、キーコンテナの権限を手動で編集し、他のアプリケーションに対しての影響がないか十分に評価を行っていただくことを推奨いたします

また、その際は、対象の環境に対し、管理者権限を持つユーザー アカ ウントでの作業が必要です。編集時、[セキュリティ] タブにおいて、所有者の取得のメッセージが表示されることがありますが、その場合は取得を選択し、編集を実施します。
(※ 参考 : 技術情報 978973) 


(※) Error message when you try to install Forefront Security for Exchange or Antigen 9.0 for Exchange:
"Setup failed to create the Antigen resource and configuration in the EVS"

http://support.microsoft.com/kb/978973/ja

3. この動作について

本現象は製品の設計上想定される動作となります。

NoteNote : 鍵コンテナについて

ユーザープロファイル単位と、マシンコンテナと二種類あります。ユーザープロファイルに鍵コンテナが格納されている場合、対象ユーザーがログオンしていない場合、どのユーザーも鍵コンテナを参照することが出来ません。そのため、特定のユーザープロファイルに依存しないマシンコンテナ (MachineKeys) に格納することにより、サービスからも鍵コンテナを参照できるようになります。 

付記 : MachineKeys フォルダのアクセス権を変更することの安全性  
まず、秘密鍵ファイルは、DPAPI (データ保護 API) によって、その秘密鍵を保持するアカウントのパスワードを使用して、暗号化されています。  つまり、MachineKeys フォルダ配下の秘密鍵ファイルから、鍵を取り出して利用できるのは、コンピューターアカウント (SYSTEM アカウント) であり、別のアカウントがその鍵の中身まで取り出すことはできません。 従いまして、MachineKeys フォルダに対して、"ユーザーのアクセス権" を追加した場合でも、(ユーザーは暗号化された鍵に触ることはできますが、鍵を取り出すことができないので)セキュリティ上の問題は発生しません。

DOPは並列クエリで使用されるスレッド数ではない

$
0
0

神谷 雅紀
Escalation Engineer


並列クエリの並列度または次数 (degree of parallelism, DOP) は、クエリを実行するために使用される総スレッド数もしくは最大スレッド数ではありません。

例えば、Gather Streams Parallelism オペレータをひとつ含むクエリが DOP = 4 で実行されると、クエリで使用されるスレッドは、Parallelism オペレータよりも上を担当するメインスレッド 1 つと下を担当する子スレッド 4 つの合計 5 スレッドになります。


DOP とは?

DOP は、個々の Parallelism オペレータに作用し、クエリ内の各 Parallelism オペレータが子スレッドを作成する場合のスレッド数を規定します。max degree of parallelism や MAXDOP クエリヒントによって、この各 Parallelism オペレータが生成できる子スレッドの最大値を設定することが可能です。子スレッドが実際にいくつ生成されるかは、論理オペレータと指定されている DOP に加えて、その時点でのインスタンス内のスレッド使用状況に依存します。


並列クエリで使用される論理オペレータ

Parallelism オペレータでは、子スレッド (Producer) から親スレッド (Comsumer) へのデータの受け渡しが行われます。受け渡し方法は、論理オペレータによって異なります。DOP により制限されるのは子スレッド (Producer) です。

Gather Streams

複数の子スレッドからデータを受け取り、ひとつの親スレッドにデータを渡します。

gather


Distribute Streams

ひとつの子スレッドからデータを受け取り、複数の親スレッドにデータを渡します。

dist


Repartition Streams

複数の子スレッドからデータを受け取り、複数の親スレッドにデータを渡します。

repart


Parallelism オペレータが 2 つ以上ある場合には、上位の Parallelism の子スレッドは、下位の Parallelism の親スレッドになります。

スレッド間でのデータの受け渡し方法については、以下の以前のポストを参照して下さい。スレッド数についても、図をベースに説明しています。最初の図は DOP 4 でのクエリ実行を表していますが、そのクエリによって使用されるスレッド数は 13 です。

CXPACKET 待ちは悪いことか?

http://blogs.msdn.com/b/jpsql/archive/2011/08/30/cxpacket.aspx

照合順序 - 文字の比較と並び順 (その 1)

$
0
0

神谷 雅紀
Escalation Engineer


照合順序が分かりにくいという意見がありましたので、今回は照合順序を取り上げます。

      

照合順序とは何か


SQL Server では、文字の大小関係を比較する場合の基準を照合順序 (collation) と呼んでいます。例えば、「朝」と「海」ではどちらが大きいのか、「あ」「ア」「ア」を大きい順に並べた場合どのように並ぶのかといった、文字の大小関係を決めているのが照合順序です。

言語としての日本語の観点では、「朝」と「海」のどちらが大きくても、さほど問題にはならないように思えるかもしれません。しかし、もしこれらの文字に大小関係がなかったら、データを大きい順に並べても毎回違った並び順になる可能性があります。さらに、もしこれらの文字に大小関係がなかったら、大きくも小さくもないということになります。大きくも小さくもないということは、

if (a < b) …
else if (a > b) …
else …

の式で最後の else に入るということであり、そこに入るのは a = b の場合だけです。つまり、等しいということです。「朝」と「海」が等しいとなると、それは言語としての日本語でも問題となってきます。

このように、照合順序 (文字の大小関係) は、データを扱う処理にとっては、重要な要素です。


照合順序はどのような場面で使われるのか


文字の比較を行うすべての場面で使われます。

例えば、インデックスを作成する際には、キー列の値順にインデックス行を並び替えるために使われます。select … from … order by Col1 のようなクエリでデータを並び替える際にも使われます。select … from … group by Col1 のようなクエリでグルーピングを行う際にも使われます。また、if (@a = @b) のような if ステートメントによる比較でも使われます。select … from … where Col1 > N’X’ のようなクエリの検索条件内での比較でも使われます。

つまり、使用する照合順序が違うと、文字の大小関係が異なるため、同じクエリでもその結果は違ったものになってきます。


SQL 照合順序


SQL Server の照合順序には 2 種類あり、ひとつが SQL 照合順序、もうひとつが Windows 照合順序です。照合順序の名前が “SQL_” から始まるものが SQL 照合順序、そうでないものが Windows 照合順序です。

SQL 照合順序では、非 Unicode データについては、Windows とは互換性のない SQL Server 独自の方法による大小比較が行われます。この方法は、Unicode データ型をサポートしていなかった SQL Server 6.5 以前のバージョンで行われていた方法です。また、非 Unicode データと Unicode データとで比較規則が異なるため、同じ文字を比較した場合であっても、非 Unicode データと Unicode データでは結果が異なる場合があります。

SQL 照合順序は、SQL Server 6.5 以前のバージョンとの互換性のみを目的としている照合順序であるため、SQL Server 6.5 以前のバージョンの動作に依存した、前世紀から存在するような古いアプリケーションを実行している場合を除けば、あえて SQL 照合順序を選択する必要性はありません。

そのため、以降は、特に記載していない限り、すべて Windows 照合順序についての内容です。


照合順序名の構成


SQL Server 2012 SP1 には、今確認してみたところ、サポートしている全言語で 3885 種類、日本語に限っても 138 種類の照合順序が用意されています。これら照合順序の比較結果がどうなるのかは、その名前から判断することができます。照合順序の名前には、次の規則があります。

日本語照合順序のひとつである Japanese_90_CS_AS_KS_WS_SC を例に見てみましょう。Japanese_90_CS_AS_KS_WS_SC は、 “_” で区切られる部分ごとに以下の意味があります。


意味

Japanese辞書順に並び変えた場合の並び順が、日本語辞書順であることを表しています。         
また、非 Unicode データ型の場合は、そのデータの言語 (コードページ, code page) が何であるのかを表します (後述します)。非 Unicode データ型では、言語によって同じ文字コード (文字を識別するための数値) に異なる文字が割り当てられているため、この部分が異なると同じ文字コードでも異なる文字になります。
90照合順序のバージョンを表しています。

90 はバージョン 9.0 である SQL Server 2005、100 はバージョン 10.0 である SQL Server 2008 を表しています。
CS辞書順に並べる場合に大文字小文字を区別するかどうかを CS または CI のいずれかの形で表します。

1 文字目の C は Case の意味です。
2 文字目の S または I は以下の意味です。
S (Sensitive) は区別する。
I (Insensitive) は区別しない。
AS辞書順に並べる場合に濁点や半濁点などの有無を区別するかどうかを AS または AI のいずれかの形で表します。

1 文字目の A は Accent (アクセント) の意味です。
2 文字目の意味は C (大文字小文字) と同じです。
KS辞書順に並べる場合に平仮名カタカナを区別するかどうかを KS または KI のいずれかの形で表します。

1 文字目の K は Kana (カナ) の意味です。
2 文字目の意味は C (大文字小文字) と同じです。
WS辞書順に並べる場合に全角半角を区別するかどうかを WS または WI のいずれかの形で表します。

1 文字目の W は Width (幅) を表しています。
2 文字目の意味は C (大文字小文字) と同じです。
SCSQL Server 2012 以降で、辞書順に並べる場合に補助文字を認識するかどうかを区別します。

SC は
Supplementary Character (補助文字)の意味です。
SC が付いている照合順序は補助文字を認識し、文字列の文字数を返す LEN 関数などの動作に影響します。


並び順は、辞書順ではなくバイナリ順 (ビット配列順、文字コード順、コードポイント順) もあります。バイナリ順の照合順序の名前は、Japanese_90_BIN や Japanese_90_BIN2 のように CS_AS_KS_WS の部分が BIN または BIN2 となります。


意味

BIN文字列中の最初の一文字のみコードポイント (各文字に割り当てられたビット配列) による比較を行い、以降はバイトごとの比較を行います。

SQL Server 2000 以前の古いバージョンとの互換目的での使用を除いて、使用する必要性はありません。
BIN2すべての文字をコードポイントによる比較を行います。


日本語照合順序の違い


これを読んでいる人のほとんどは、日本語を扱っていると思いますので、ここでは、複数ある日本語の照合順序の違いについて説明します。

SQL Server 2012 SP1 では、「照合順序名の構成」で説明した “Japanese” にあたる部分には、Japanese の他に、Japanese_XJIS, Japanese_Bushu_Kakusu, Japanese_Unicode の合計 4 種類があります。

日本語の照合順序は以下のステートメントで一覧できます。


select collationproperty(name,'LCID') as LCID,
  cast(collationproperty(name,'ComparisonStyle') as varbinary(4)) as ComparisonStyle,
  name
from sys.fn_helpcollations()
where cast(collationproperty(name,'LCID') as int) & 0xFFFF = 0x0411
order by name


余談ですが、Windows の LCID は言語 ID とソート ID から構成されていて、上位 12 ビットは現状使用されておらず、次の 4 ビット (16 ~ 19 ビット) がソート ID、下位16 ビット (0 ~ 15 ビット) が言語 ID です。言語 ID 0x0411 は日本語です。SQL Server での LCID も Windows のものと全く同じです。ComparisonStyle についても、プログラム (今となってはアンマネージドもしくはネイティブというべきでしょうか) を書く人は、上のステートメントの実行結果を見て何となく気づいたのではないかと思いますが、CompareString APIの dwCmpFlags パラメータに指定する値と同じです。例えば、日本語環境でよく使われている Japanese_CI_AS の ComparisonStyle は 196609 (0x00030001) ですので、これは、NORM_IGNORECASE | NORM_IGNOREKANATYPE | NORM_IGNOREWIDTH ということになります。

話を元に戻して、各照合順序の LCID を見てみます。 ソート ID 欄の ( ) 内の “SORT_” は、winnt.h での定義です。


照合順序

LCID

ソート ID (16 ~ 19 ビット目)

Japanese0x00000411 (1041)0x0 (SORT_JAPANESE_XJIS)
Japanese_XJIS0x00000411 (1041)0x0 (SORT_JAPANESE_XJIS)
Japanese_Bushu_Kakusu0x00040411 (263185)0x4 (SORT_JAPANESE_RADICALSTROKE)
Japanese_Unicode0x00010411 (66577)0x1 (SORT_JAPANESE_UNICODE)


これを見て分かるように、照合順序の名前は、LCID、言い換えれば、言語とソート方法に対応しています。つまり、Japanese_XJIS と Japanese_Bushu_Kakusu の何が違うかと言えば、言語はどちらも日本語ですが、ソート順、つまり、文字の大小関係の定義が違うのです。

では、Japanese と Japanese_XJIS は同じソート ID を持っていますが、これは何が違うのでしょうか?

ここで、上で説明したバージョンが関連してきます。Japanese_XJIS にはバージョン 100 しかありません。一方、Japanese には、バージョンなし (バージョン 80 の意味)、バージョン 90 があります。つまり、これらは、バージョンが違うのです。

では、バージョンが違うと何が違うのでしょうか?

答えは、カバーしている文字です。

SQL Server は、その時々の Windows が対応する Unicode バージョンに対応してきました。Unicode バージョンは、バージョンが上がるほど含まれる文字数が多くなってきています。つまり、これらの照合順序は、同じソート ID なのですが、より上位の照合順序バージョンは、より上位の Unicode バージョンに対応しており、より上位の Unicode バージョンはより多くの文字を含んでいるのです。

以下は、照合順序バージョンと Unicode バージョンの対応です。

※ 各バージョンの Unicode で定義されている文字の一覧に興味がある場合は、Unicode Consortium のサイトで探してみて下さい。


照合順序バージョン

SQL Server バージョン

Unicode バージョン

記載なしSQL Server 2000Unicode 2.0
90SQL Server 2005Unicode 3.2
100SQL Server 2008Unicode 5.0

     

ちなみに、日本語照合順序 Japanese と Japanese_XJIS_100、Japanese_Bushu_Kakusu_100 の比較で解説されているように、Japanese_XJIS と Japanese_Bushu_Kakusu は、Windows Vista/2008 で追加された並び順です。

このように SQL Server の辞書順は、Windows に準じています。Windows 照合順序と呼ばれるのも、これが理由です。


Japanese_Unicode に関する注意

Japanese_Unicode は、SQL Server 7.0 との互換性のためだけに残されています。SQL Server 7.0 との互換が必要なアプリケーションが存在している場合を除いて、この照合順序を使用する必要性はありません。


なぜバージョン?

なぜ SQL Server はひとつの照合順序、例えば、Japanese を新しい Unicode バージョンに対応させるのではなく (既存の照合順序に対応文字を加える) のではなく、別の新しい照合順序、Japanese_90 や Japanese_XJIS_100 を追加しているのでしょうか?

その答えを考える前提として、Unicode バージョンが対応していない文字の扱いを見てみましょう。


対応していない文字の扱い


Unicode バージョンによって対応する文字数が増えているのは、上で説明したとおりです。では、対応していない文字は全く扱えないのでしょうか?例えば、Unicode 3.2 に含まれない文字は、Japanese_90 照合順序の列に格納できないのでしょうか?

そんなことはありません。対応していない文字であっても、データベースに格納することはでき、また、取り出すこともできます。

では、何ができないのでしょう?

それは、比較です。

対応していない文字であっても、データベースに格納したり取り出したりすることはできますが、比較はできません。

なぜ比較ができないでしょうか?

それは、文字に重み (weight) がないからです。

Books Onlineにも「これまでは重み付けがなく、等価として比較されていた文字に、重み付けが追加されました。(Weighting has been added to previously non-weighted characters that would have compared equally.) 」といった記載があります。


文字の重み (weight)

辞書順の照合順序の場合、文字は、文字もしくはその文字のコードポイント (文字に割り当てられた特定のビット配列、文字コード) を比較するのではなく、その文字に割り当てられた「重み」(weight) を比較することで、大小関係を判断します。

「重み」とは、その文字の属性です。例えば、”A”, “a”, “A” はどれもアルファベットの最初の文字という属性を持っています。また、”A” と “A” は大文字、”a” は小文字という属性を持っています。さらに��”A” と “a” は半角、”A” は全角という属性も持っています。

ここまで説明すると、多くの人は気づいたのではないかと思います。これら属性は、辞書順照合順序の Case, Accent, Kana, Width と対応しています。文字の比較は、このような、各文字に割り当てられたこれらの属性を比較します。その比較時に、指定されている照合順序によって、どの属性を比較し、どの属性を比較しないかが決まります。

この「重み」がない文字は、実質的に比較対象となる値がないため、比較を行うことができなくなります。

これまでのところ、「重み」のない文字は便宜的に重みが 0 と見なされるため、異なる文字であっても、同じ文字と見なされます。これが、上で抜粋した Books Online の記載「これまでは重み付けがなく、等価として比較されていた文字」です。

簡単なサンプルです。

何と読む字なのか知りませんが、コードポイント 18240 (0x4740) と 18241 (0x4741) の文字を以下のように比較すると、バージョン 80 では同じ、90 では異なる文字と判断されます。


if N'䝀' = N'䝁' collate Japanese_ci_as
print '80 - true'
else
print '80 - false'
go
if N'䝀' = N'䝁' collate Japanese_90_ci_as
print '90 - true'
else
print '90 - false'
go


再び余談ですが、Windows には LCMapStringという API があります。この API に LCMAP_SORTKEY を指定すると、指定した文字のソートキーが返されます。このソートキーが指定した文字の「重み」です。もし興味があれば、実際の値を見ることができます。


なぜバージョン?

改めて、なぜ SQL Server はひとつの照合順序、例えば、Japanese を新しい Unicode バージョンに対応させるのではなく (既存の照合順序に対応文字を加える) のではなく、別の新しい照合順序、Japanese_90 や Japanese_XJIS_100 を追加しているのかを考えてみます。

もし、そうしなかったらどうなるか考えてみましょう。もし、新しい照合順序ではなく、既存の照合順序を拡張していったらどうなるか。

新しい文字が追加されている (「重み」を持った文字が増えている) ということは、そうでなかった時とは文字の大小関係が変わっているということです。文字を並べ替えた時の順番も変わっている可能性があるということです。

これは、データベースにとっては大きな問題です。既存のインデックスは、そのインデックスが作成された時の文字の大小関係に従って並べられています。その後は、データが追加変更された時の文字の大小関係に従って決定された場所に格納されます。もし、インデックス作成後に文字の大小関係が変わってしまったら、インデックス内のデータは一定の並び順ではなくなってしまいます。インデックスは一定の並び順が保たれているから、それを使ったデータの絞り込みが可能なのであって、一定の並び順になっていないのであれば、意味はありません。もし、インデックス作成後に文字の大小関係が変わったら、既存のインデックスはすべて再構築しなければなりません。

Windows では、照合順序は SQL Server のようにバージョン管理されていないため、文字が追加されて大小関係が変わっているかどうかを確認することのできる API GetNLSVersion が用意されています。文字の大小比較を Windows に完全に依存して行っている場合は、この API を用いて、インデックス作成時と現在の文字の大小関係が変わっていないかどうか (NLS バージョンが変わっていないかどうか) を確認し、変わっている場合には、インデックスの再構築を行う必要があります。

SQL Server の場合は、上のとおり、照合順序をバージョン管理しており、Windows に完全には依存していないため、異なる Windows バージョン上でデータベースを移行したとしても、インデックスを再構築する必要はありません。

※ SQL Server でも、SQL Server for Windows CE は、文字の大小比較を Windows の機能を用いて行っています。そのため、NLS バージョン (Windows の照合順序バージョン) が変わると、データベースオープン時にインデックスはすべて再構築されます。その結果、データベースのオープンに時間を要する場合があります。どのバージョンの Windows 間で NLS バージョンが変わるのかは、実際に各 Windows 上で GetNLSVersion を呼び出してみると分かります。


照合順序の適用対象


照合順序は、インスタンス、データベース、列、式に指定できます。明示的に照合順序を指定しない場合、データベースはインスタンスの、列はデータベースの、式はデータベースの照合順序を継承します。

例えば、インスタンスの照合順序が Japanese_CI_AS であれば、他の照合順序を明示的に指定して作成しない限り、そのデータベースに作成されるテーブル内の列は、Japanese_CI_AS になります。明示的に指定すれば、列ごとに照合順序を変えることもできます。

式への指定は、式に対して直接 collate 句を指定することで行えます。例えば、select … where c1 = @a collate Japanese_BIN2 と指定すれば、c1 列の照合順序が Japanese_CI_AS と定義されていたとしても、この select に関しては、Japanese_BIN2 を用いて比較が行われます。collate 句は、if (@a = @b) collate Japanse_BIN2 といったように、クエリではないステートメントでも使用可能です。
一時的に照合順序を変更したい場合や、ストアドプロシージャや関数などでどのデータベースで実行された場合も同じ照合順序を使いたい場合などに便利です。


長くなってきましたので


長くなってきましたので、このあたりで一旦区切りたいと思いますが、ここに書いた内容が理解できていれば、ほとんどの場合、どの照合順序をどのように使えばいいのかを判断できるのではないかと思います。

もし、「いや、まだこれが漏れている」「照合順序を選ぶためには、これも知っている必要がある」といった内容があれば、この Blog にメールもしくはコメントして下さい。

次は、照合順序に関わる考慮点などについて書こうと思っています。

Viewing all 293 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>