福原 宗稚
SQL Developer Support Engineer

Visual Studio 2008、 Visual Studio 2010のクエリビルダーで、珍しい現象ではありますが、遭遇してしまうと不便だと思われる現象がありましたので、ご紹介します。

クエリ ビルダーとは

まず、クエリ ビルダーとは、SQL Server 等データベースへのクエリを GUI を使って定義できる便利なツールです。(Visual Studio で一例としては、データセット デザイナーでTableAdapter 構成ウィザードを使用する際に使用されます。)

TableAdapter 構成ウィザードでは、「SQL ステートメントの入力」画面から、「クエリ ビルダー」ボタンをクリックすることで、「クエリ ビルダー」画面が起動します。ここで、結合するテーブルを追加したり、列を追加したり、絞り込み条件を追加するという操作を GUI で操作することができます。

現象

「SQL ステートメントの入力」画面でクエリを記述した後、追加で修正等行う際、クエリ ビルダーを使用することがあります。

クエリ ビルダーの動作の一つとして、必ずしも必要ではない、列名につけている [ ] や “ “ を削除し、クエリを整形するという操作があります。下図のクエリは SQL Server 2008 や SQL Server 2008 R2 に接続している場合、通常 [ ] がなくても正常にクエリが実行できます。そのため、「SQL ステートメントの入力」画面で列名につけている [ ] は、クエリ ビルダーを開いたタイミングで削除されます。[ ] が削除されたクエリを実行する際に、SQL Server 側の設定によって、エラーとなる場合があります。

• 通常の場合

  「クエリの実行」をクリックすると、正常に結果が返ってきます。

• エラーになる場合

  「クエリの実行」をクリックすると、列名に含まれる中点 「・」 (もしくは中黒とも言います) に関して、構文エラー「Incorrect syntax near ‘・’.」が発生する場合があります。

原因

クエリを実行しているデータベースの互換性レベルが 80 (SQL Server 2000 相当) の場合にエラーが発生します。

列名に使用できる文字はデータベース識別子として定義されており、SQL Server 2000 と SQL Server 2005 以降で大きな違いがあります。

• SQL Server 2000 :
  Unicode 規格 2.0 に含まれる文字が使用可能であり、中点はまだ識別子として使用することができない。
  中点を含む列名(例えば、「部門・グループコード」) は、[ ] や " " で囲まない場合には、構文エラーが発生する。

• SQL Server 2005 以降のバージョン :
  Unicode 規格 3.2 に含まれる文字が使用可能であり、中点も識別子として使用することが可能である。
  中点を含む列名(例えば、「部門・グループコード」) は、[ ] や " " で囲まなくても正常に実行できる。

 
列名に使用できる文字は、データベースの互換性レベルに応じて判断されるため、SQL Server 2008 R2 だったとしても、
互換性レベル 80 (SQL Server 2000 の互換性レベル) に設定されたデータベースであれば、上記の「SQL Server 2000」の場合と同様の動作となります。

クエリ ビルダーでは、データベースの互換性レベルまでは判断していないため、対象のデータベースが互換性レベル 80 でも [ ] は不要と判断し、[ ] を削除します。その結果、構文エラーが発生します。

対処方法

下記のいずれかで対処できます。

1. クエリ ビルダーを使用しない
2. 互換性レベルを 90 (SQL Server 2005) 以上に設定する

1. クエリ ビルダーを使用しない

せっかくの便利なツールを使用しないというのは残念ですが、クエリ ビルダーを使用せず、「SQL ステートメントの入力」画面ですべてクエリを記述することで回避できます。

2. 互換性レベルを 90 (SQL Server 2005) 以上に設定する

こちらはやや長期的な検討が必要な対処方法となります。

互換性レベルは、以前のバージョンとの互換性を設定できるため、以前のバージョンからデータベースを移行された場合には、よく使用される機能かと思います。しかしながら、あくまでも移行時の暫定的な手段として用意している機能のため、長期的には使用されている SQL Server のバージョンと同じ互換性レベルを使用するよう検証を実施いただくことを推奨します。 (参考 : ALTER DATABASE 互換性レベル (Transact-SQL) )

森  隆博
SQL Developer Support Engineer

Reporting Services のレポートで印刷を実施した場合に以下のエラーが発生することがあります。

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

Reporting Services の印刷は RSClientPrint という ActiveX コントロールを使用します。
RSClientPrint は印刷を操作するクライアントにインストールされ、実行されますが、RSClientPrint がうまくインストールできなかったり、インストール済みの RSClientPrint に問題があった場合にこのエラーが発生します。
エラーが発生するパターンは複数ありますので、トラブル時に注目すべき点を考慮し、各種パターンを紹介します。

RSClientPrint ActiveX コントロールの killbit 設定

<要因>
ActiveX 用の累積的なセキュリティ更新プログラムのインストールに関係して、本現象が発生することがあります。
ActiveX 用の累積的なセキュリティ更新プログラムによって、古いバージョンの RSClientPrint ActiveX コントロールに killbit が設定されるため、レポート印刷時に ActiveX コントロールをロードできないことに起因しています。

<回避策>
この原因に起因している場合、killbit が設定される古いバージョンの RSClientPrint ActiveX コントロールを使用せずに、新しいバージョンの RSClientPrint を使用すれば問題が解決できます。
ご利用の Reporting Services に対して最新の更新プログラムを適用することをお勧めします。

RSClientPrint はサーバーの Reporting Services に配置されており、Reporting Services の更新プログラムに RSClientPrint のモジュールが含まれている場合、更新プログラムの適用によりサーバー上の RSClientPrint が置き換わります。
クライアントから印刷を行おうとする際、サーバーに新しい RSClientPrint が存在していていれば新たにダウンロード画面が表示され、クライアントに RSClientPrint をインストールすることができます。

<参考情報>
http://support.microsoft.com/kb/967511/en-us

IE の 64-bit/32-bit と Reporting Services のバージョンの組み合わせに起因している

<要因>
RSClientPrint は ActiveX コントロールであり、IE のアドオンとして実装されています。
Internet Explorer のアドオンとは、Internet Explorerに追加でインストールされるプログラムのことです。
IE に追加でインストールされるため、IE が 64-bit の場合は 64-bit 用の RSClientPrint が必要になります。

64-bit 用の RSClientPrint には SQL Server 2008 のバージョンから対応しています。
SQL Server 2008 は接続してきたクライアント IE が 64-bit なのか 32-bit なのかを判断し、適切な RSClientPrint を返す仕組みを実装しました。

<回避策>
上記要因に起因している場合、以下のいずれかで回避することができます。

・32-bit の IE を使用する。
・64-bit の IE にも対応した Reporting Services 2008 以降のバージョンを使用する。

<注意事項>
レポートの参照方法には以下のパターンがあります。

a) レポートサーバー（http://MachineName/ReportServer）やレポート マネージャー（http://MachineName/Reports）を利用する。
b) ReportViewer コントロールを VB や C# のアプリケーションに組み込んで利用する。

先の要因と回避策は、a) の場合について説明しています。
b) の ReportViewer Web コントロールを組み込んだ Web アプリケーションに対してクライアントから接続し、レポートを印刷する場合は注意が必要です。
Visual Studio 2008 までの ReportViewer Web コントロールには、アプリケーションを利用するクライアントの環境を判断する機能がないため、64-bit IE から Web アプリケーションへ接続した場合、印刷を行うことができません。
Visual Studio 2010 の ReportViewer コントロールではその機能が実装されましたので、64-bit IE からの印刷機能利用の場合には、Visual Studio 2010 での開発が必要です。

GDI+ のバージョンが古い

<要因>
IE を起動するクライアント OS が Windows 2000 だった場合 GDI の dll が古いことが考えられます。
GDI は Windows でグラフィック処理を行うプログラムです。
印刷実行時、GDI に対して処理を依頼しますが、この dll が古いバージョンであると印刷を処理できずにエラーが発生することが報告されています。

<回避策>
新しいバージョンの GDI+ を使用します。

GDI+ は以下の URL からダウンロードすることができます。

http://www.microsoft.com/downloads/details.aspx?FamilyId=6A63AB9C-DF12-4D41-933C-BE590FEAA05A

ダウンロードした exe ファイルを実行すると、自動解凍がはじまるので回答先のフォルダを指定します。
解凍したフォルダ配下の \asms\10\msft\windows\gdiplus から 「gdiplus.dll」をコピーし、以下のフォルダに貼り付けます。
 
c:\WINNT\system32
 
※すでに c:\WINNT\system32 配下に同名のファイルがある場合、もともと存在するファイルをバックアップすると後で元に戻すことができます。

<参考情報>
Windows 2000 は、すでにプロダクト サポート ライフサイクル期間を終了しております。
詳細につきましてはマイクロソフト プロダクト サポート ライフサイクルの情報をご覧ください。

マイクロソフト プロダクト サポート ライフサイクル
http://support.microsoft.com/lifecycle/?c1=509

平素よりマイクロソフトサポートサービスをご利用いただき誠にありがとうございます。この度、多くのご要望を頂いていた朝およびお昼時間帯のサポート対応にお応えするため、弊社の技術サポート窓口時間を下記の通り変更することとなりましたので、ご案内申し上げます。

※ 適用開始日： 2012 年 7 月 2 日 （月） から (http://support.microsoft.com/gp/BusinessHourAnnounce/ja)

17 時 30 分以降にお問い合わせ頂いた場合、翌営業日の対応となります。あらかじめご了承ください。尚、緊急案件のサポートはこれまで通り 24 時間 365 日提供致します。

適用契約

プレミア サポート

• パートナー アドバンテージ
• ファウンデーション
• コア

プロフェッショナル サポート

• プロフェッショナル サポート
• ビジネス クリティカル サポート 24
• アドバイザリー サービス
• すべてのプログラム特典
  • ソフトウェア アシュアランス
  • MPN プロフェッショナル サポート インシデント
  • MSDN サブスクリプション プログラム特典
  • TechNet サブスクリプション プログラム特典
  • BizSpark 特典サポート
  • WebsiteSpark 特典サポート
  • DreamSpark 特典サポート

パートナー サポート

• MPN パートナー ビジネス支援サービス
• MPN パートナー オンライン テクニカル コミュニティ

適用外

• Office 365/BPOS のスタンダード サポート
• FAST Maintenance 契約で締結されたサポート
• パーソナルサポート

窓口時間変更に関する Q&A

1. サポート料金に変更はありますか？
料金に変更はありません。

2. 今回の「技術サポート」の対象になっているコマーシャル テクニカル サポートとパートナー サービス以外のサポート窓口時間に変更はありますか？
コンシューマ テクニカル サポートの窓口時間に変更はございません。カスタマー サービスの一部窓口は変更になる予定です(サポート契約センター)。

3. 「サポート契約センター」の窓口時間も変更になりますか？
サポート契約センターも同様、9:00 から 17:30 までの営業になります。

4. サポート契約の購入は今まで通り出来ますか？
サポート契約の購入は「サポート契約センター」で受け付けております。「サポート契約センター」の窓口時間内で受付可能です。

5. MPN、MSDN、TechNet といったプログラム特典サポート有効化の受付時間に変更はありますか？
現時点で各プログラムの特典サポート有効化の受付窓口時間に変更はございません （9:30 から 19:00）。ただし、お問い合わせのお時間によってエンジニアの対応が翌営業日になる場合がございます。

6. MPN、MSDN、TechNet といったプログラム特典サポート有効化の受付時間は今後変更されるのでしょうか？
特典サポートの有効化のみならず、法人・個人のサポート窓口の適正時間については現在検討中です。

高橋 理香
SQL Developer Support Escalation Engineer

またまたご無沙汰してしまいました。もしお待ちくださっていた方がいらしたならすみません。

前回の 「Troubleshooting: Connectivity #2 - エラー情報からわかる失敗原因」では、SQL Server へ接続できない場合に発生するエラーについてご紹介しました。そのエラーの対処も済み、確立した接続を使ってクエリの実行もできる状態であったとしても、いまだ接続エラーは発生する可能性はあります。そこで、SQL Server へのアクセスにおける接続関連エラーのトラブルシューティング 3 回目の今回は、前回予告した「一度確立した接続が切断される場合」について解説します。

SQL Server への接続が成功した後に切断される主な原因は？

「Troubleshooting: Connectivity #1 - SQL Server への接続」で説明したように、SQL Server へのログインやデータベースへのアクセスは、TCP/IP や名前付きパイプなどの OS レベルのセッションが確立できている状況で初めて可能となります。以降の SQL 文の実行やその結果の受け取りなども、必ずこのセッションが確立している状況でなければなりません。つまり、SQL Server への接続確立後にセッションが失われると、以降の SQL Server へのアクセスは失敗することになります。

では、一度確立した接続が失われるのはどのような原因によるのでしょうか。お問い合わせで判明した原因を大別すると、だいたい以下の 6 点が原因で切断されているようです。

A. ネットワーク中継機器に何らかの問題があり、一定時間内に必要な応答が得られなかった。

ネットワーク中継機器の問題に関しては、Scalable Network Pack (SNP) やチェックサムオフロード機能が有効となった Windows Server 2003 SP2 以降で非常に多くの報告があがっています。SNP は NIC 等のハードウェアの機能を使用して CPU リソースの過負荷を招くことなくネットワーク トラフィックの増大に対応するための機能です。また、タスクオフロード機能は TCP/IP での通信に必要なチェックサムの計算を NIC 等で肩代わりする機能です。OS ではこれらの機能が有効であるものの NIC 等のハードウェアがその機能に対応していない場合、予期せぬリセットの送出 (RST パケット送信) 等が行わることがあります。またこの結果として接続の切断が発生し、アプリケーションではエラーが発生するに至ります。

また、SNP 等の影響ではなく、中継機器の問題で切断が発生するまでのパターン例として次のような場合もあります。

1) クライアント アプリケーションから SQL Server に SQL 文を送信し、実行結果待ちの状態となる。
2) SQL Server では SQL 文の処理を完了したために結果をクライアントに送信する。
3) NIC やルーター等の問題によって結果セットを含むパケットがクライアントへ到着せず、再転送もすべてタイムアウトする。
4) SQL Server 稼動サーバー側ではピアであるクライアントが応答できる状態にないと判断し、セッションを切断する。この切断はクライアントには通知されない。
5) クライアントでは結果が到着しないためにクエリタイムアウトに到達し、SQL 文のキャンセル要求を送信する。ここで、セッションが切断されていることを検知し、接続エラーとなる。

上記の 3) における、結果が期待通りに到着しないような環境であることが問題といえます。

B. ネットワークやマシンの負荷によって一定時間内に必要な応答を得られなかった。

先の A のパターンと同様です。中継機器には問題がない場合でも、パケット送受信に時間を要したことで応答がないと判断され、切断に至る可能性があります。そして、クライアントがその接続を使用しようとしたタイミングで接続エラーが発生します。

C. SQL Server を実行しているマシンをシャットダウンした場合や、SQL Server サービスを停止した。

SQL Server やマシンをシャットダウンすることで、TCP/IP や名前付きパイプの通信も終了となります。この終了時には、その旨はピアであるクライアントには通知されません。そのため、先の A のパターンにおいて、SQL 文実行結果待ちの間にサーバー側でシャットダウンがあると、キャンセル要求送信時にサーバーとのセッションが失われていることを検知することになり、接続エラーが発生します。

クラスタ構成、もしくは、データベース ミラーリング構成の SQL Server がフェールオーバーした場合に発生するエラーもこちらです。

D. SQL Server 上のプロセスを管理者 (sysadmin) が強制的に Kill した。

SQL Server の Management Studio の利用状況モニタを使用したり、Kill コマンドを使用して SQL Server 上のプロセスを強制終了した場合、セッションは終了となりますが、その旨はクライアントに通知されません。そのため、強制終了された後にクライアントがその接続を使用しようとすると、切断を検知して、エラーとなります。

E. SQL Server との TCP レベルでのセッション確立後、Windows 認証の処理過程でタイムアウトが発生した。

接続過程の認証処理中に先の確立済みの OS レベルのセッションが切断されることがあります。切断の原因としては、先の A ～ C に起因している可能性もありますが、それ以外の原因として、認証処理過程の一部に時間を要したことに伴うタイムアウトもあげられます。そのため、接続処理中であっても、Troubleshooting: Connectivity #2 でご紹介したのとは異なる切断を示すエラーが発生することがあります。

F.クライアントからの SQL Server への接続要求が短時間内に集中したため DoS 攻撃とみなされ、切断された。

こちらも接続処理過程で発生する問題です。Windows Server 2003 SP1 以降の環境では DoS (Denial Of Service) 攻撃対策のために既定で TCP/IP スタックが強化されています。具体的には、SynAttachProtect と呼ばれるレジストリ値が有効化されています。この場合、短時間内に接続要求が集中する (SYN パケット受信) と、DoS 攻撃の可能性があると判断し、接続をリセットします。(RST パケット送信) このパケットによって、クライアントでは切断を示すエラーとなります。

接続エラーのうち、どのようなエラーが接続が切断されたことを示すエラー メッセージか？

エラーメッセージはトラブルシューティングを行うのに非常に重要であることをお伝えしました。接続の切断についても同様です。エラーメッセージからそれが接続切断に起因したものかどうかを判断することができます。

以下は接続の切断を示すエラーメッセージ例です。

SQL Server Native Client/.NET Framework Data Provider for SQL Server の場合:

OLE DB Provider for SQL Server/SQL Server ODBC Driver の場合:

例) 次のような C# のアプリケーションを実行します。

メッセージボックスが表示された状態で SQL Server を停止します。
その後、メッセージボックスで [OK] をクリックすると、ExecuteNonQuery メソッド実行時にエラーが発生します。
以下は、SqlException.ToString() で取得した情報から抜粋したものです。

予期せぬ接続の切断に対してはどのような対処があるか？

接続切断のエラーの対処方法を考える場合、事前の対処と事後の対処の 2 種類があります。

事後の対処

予期せぬ切断は完全に抑止することはできないため、事後の対処はアプリケーションの堅牢性の面からも必要不可欠です。例えば以下のようなアプリケーションは、仮に切断があっても対処できる仕組みを持っていると言えます。

• 切断によるエラーが発生してもエラーハンドラの実装があるのでアプリケーションが異常終了しない。
• バッチ処理などの場合、エラーハンドラによって処理の再実行が自動的に行われ、中断されない。
• 発生したエラーの詳細や発生ステップなどがログに記録される仕組みがあり、後日にそのエラーの妥当性などを確認できる。

具体的な実装方法はアプリケーションで使用している API やシステム要件によって異なりますが、もしも接続エラー発生後のリトライの仕組みを実装する場合には、以下の点を踏まえて検討するようにしてください。

• エラーとなった際に使用していた接続オブジェクトのインスタンスは破棄し、再度新規に作成する

もしも一度エラーとなった接続のオブジェクトを使用し続けると、接続エラーが発生し続けたり、オブジェクト インスタンスが存在しないなどの別のエラーが発生するなどの問題が発生します。

事前の対処

事前に対処できる可能性があるか、それとも情報採取によって原因特定してからの対処が必要かについては、以下の順で評価することをお勧めします。

1) 原因 C や D の影響かどうかを判断する。

エラー発生時間帯に定期メンテナンス等で SQL Server サービスを停止していないか、誰か管理者権限のあるユーザーがプロセスを強制終了していないかを確認しましょう。もし該当する場合には、メンテナンス時間をずらしたり、それが困難な場合にはアプリケーションには事後の対処の実装を行うなどが対処になります。また、SQL Server サービスが予期せず終了していた場合には、接続観点ではなく、SQL Server データベース エンジン観点で別途調査する必要があります。

2) 原因 F の影響の可能性がないか判断し、結果によっては E の調査を検討する。

Windows Server 2003 SP1 以降の OS 上で SQL Server が稼動している環境への接続処理中にエラーが発生する場合、エラー発生時間帯が多数のユーザーからの接続要求が集中する時間帯であるかどうか、ユーザーの利用状況等を把握しましょう(例: 朝 9:00 業務開始以降 30 分間は全社員 1,000 人が一斉にログインする可能性がある等)。もしも集中的に接続要求が発生する可能性がある場合には SynAttackProtect の影響が考えられますので、その設定を無効化することが対処となる可能性があります。(無効化の方法については後述します)

接続要求の集中等は発生するようなシステムではない、または、SynAttackProtect の設定を無効化しても改善が見られない場合には、原因 E に該当している可能性もありますので、ネットワーク モニタによるトレース採取等で遅延発生箇所を特定した上で適切な対処について調査する必要があります。

3) 原因 A の SNP 等の影響かどうかを判断し、結果によって A と B についての調査を検討する。

SNP やチェックサムオフロード機能等はレジストリ設定によって制御できます。つまり、これらの設定を無効化することで、影響を受けているかを判断できるとともに、事前の対処にもなる可能性があります。サポートに問い合わせいただく接続切断に関するエラーの多くはこの方法が対処となることからも、接続切断を示すエラーの発生頻度が高い場合には、まずは設定を無効化することをお勧めします。(無効化の方法については後述します)

設定を無効化してもいまだ問題が生じる場合には、ネットワークやサーバーが高負荷な状況下で接続エラーが発生しやすい傾向にないかを把握します(例: 数時間置きのバッチで実行されるクエリの負荷が高い、同一環境で動作するほかのプロセスの CPU使用率が高い時間帯がある等)。もし高負荷との関連性があると認められる場合には原因 B に該当する可能性があるため、負荷分散やリソース増強などのチューニングを視野に入れた調査について検討する必要があります。具体的には、パフォーマンス モニタやネットワーク モニタによる情報採取による調査です。

負荷の影響の可能性は低い場合、ネットワーク関連機器の問題の可能性が残りますので、メーカーなどに問い合わせいただき、アップデートがあれば適用することが事前の対処になります。

<TCP/IP 関連設定の無効化方法>

SynAttackProtect、SNP、チェックサムオフロード機能の無効化はすべて以下のレジストキー配下の値で制御できます。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

無効化のための設定値はそれぞれ以下の通りです。設定変更後には OS の再起動が必要となります。

• SynAttackProtect 関連レジストリ値:

名前: SynAttackProtect
種類: REG_DWORD
値: 0

• SNP 関連レジストリ値:

名前: EnableRSS
種類: REG_DWORD
値: 0

名前: EnableTCPA
種類: REG_DWORD
値: 0

名前: EnableTCPChimney
種類: REG_DWORD
値: 0

• チェックサムオフロード関連レジストリ値:

名前: DisableTaskOffload
種類: REG_DWORD
値: 1

なお、Windows Server 2003 環境の SNP 関連レジストリ設定に関しては、以下のサイトから入手できる更新プログラムを使用して一括で無効化することもできます。

Windows Server 2003 用の更新プログラム (KB948496)

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

Windows Server 2003 x64 Edition 用の更新プログラム (KB948496)

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

<参考情報>

Windows Server 2003 SP2 がインストールされているコンピュータの TCP 通信で断続的に通信障害が発生する

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

Windows XP または Windows Server 2003 を実行しているコンピュータの断続的な通信障害が発生します。

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

http://support.microsoft.com/kb/904946/ja (機械翻訳)

Windows Server 2003 を実行しているサーバー上の SQL Server にアプリケーションが接続するときにエラー メッセージ "一般的なネットワーク エラーです"、"コミュニケーション リンクが失敗しました"、または "トランスポート レベルのエラーが発生しました" が表示される

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

予期せぬ挙動が!? 新機能 Scalable Networking Pack をご存知ですか?

http://blogs.technet.com/b/jpntsblog/archive/2010/03/23/scalable-networking-pack.aspx

今回の予期しない接続の切断に関しては以上です。

次回はさらに踏み込んで、エラー発生時にどのような情報を採取するとよいか、採取した情報からどんなことがわかるか、についてご紹介したいと思っています。

[このエントリについて]

SQL Server のブロッキングを調査する為の情報、いわゆるブロッキング情報の採取手順を紹介します。

SQL Server サポートでは、ブロッキング発生が疑われる際に、一般的に以下の手順で情報採取をお願いしています。

[手順概要]

事前に情報採取の準備を行い、ブロッキングが発生する前に情報採取を開始し、現象発生を確認後に情報採取を停止し、出力情報を採取します。

おおまかな情報採取の流れは以下となります。

1. sp_blocker_pss80 ストアド プロシージャの作成を作成する

2. ストアドプロシージャを定期的に呼び出すスクリプトを作成する

3. ブロッキング情報の採取を開始

4. 調査対象の処理を実行

5. 現象(クエリ遅延など)発生を確認

6. ブロッキング情報の採取を停止

7. 出力情報を採取

[手順詳細]

それでは、実際の手順について順を追って説明します。

1. sp_blocker_pss80 ストアド プロシージャの作成を作成する

以下のサイトにアクセスし、sp_blocker_pss80 ストアド プロシージャ作成用スクリプトを入手します。

<タイトル : SQL Server 2005 および SQL Server 2000 のブロッキングを監視する方法>

URL : http://support.microsoft.com/kb/271509/ja

※URL の公開情報は SQL Server 2005 、SQL Server 2000 を対象としていますが、SQL Server 2008 、 SQL Server 2008 R2 においても、同一手順で情報を取得できます。

※スクリプトはサイト中の 「以下は、sp_blocker_pss80 ストアド プロシージャを作成するためのスクリプトです。 」の下に記載しています。

SQL Server Management Studio などから調査対象のインスタンスに接続し、入手したスクリプトを実行します。

注：スクリプトを実行すると下記のエラーが発生しますが、 これはスクリプトの構成上発生する可能性のあるエラーとなります。対処は必要ありませんので、無視してください。

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

メッセージ 2714、レベル 16、状態 3、プロシージャ sp_blocker_pss80、行 271

データベースに 'sp_blocker_pss80' という名前のオブジェクトが既に存在します。

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

スクリプト実行後、master データベースに、sp_blocker_pss80 ストアドプロシージャが作成された事を確認します。

2. ストアドプロシージャを定期的に呼び出すスクリプトを作成する

メモ帳などで任意の場所に checkblk.sql ファイルを作成し、次のスクリプトを入力し、保存します。

---ここから---

WHILE 1=1

BEGIN

EXEC master.dbo.sp_blocker_pss80

WAITFOR DELAY '00:00:15'

END

GO

---ここまで---

WAITFOR DELAY に設定した間隔で sp_blocker_pss80 ストアドプロシージャが繰り返し実行されます。

現象発生の期間の間、ブロッキング情報を少なくとも 3 回程度取得したいので、例えば処理の実行時間が 60 秒の現象を調査する場合、15 秒程度に設定します。

上記クエリでは 15 秒間隔で実行するように指定しています。
-------------
WAITFOR DELAY '00:00:15'
-------------

3. ブロッキング情報の採取を開始

いよいよ情報採取を開始します。

先の手順 2. で作成した checkblk.sql を、SQLCMD ユーティリティもしくは OSQL ユーティリティから実行します。

対象マシン上でコマンドプロンプトを開き、以下のコマンドを実行します。

※Vista、Windows7 では「管理者として実行」でコマンドプロンプトを起動します。

<SQLCMD ユーティリティの場合>

sqlcmd -E -S <インスタンス名> -i <パス名>checkblk.sql -o <出力先パス名>checkblk.out -w 2000

<OSQL ユーティリティの場合>

osql -E -S <インスタンス名> -i <パス名>checkblk.sql -o <出力先パス名>checkblk.out -w 2000

実行例)

インスタンス名：Ryo01\SQLSERVER2008R2

checkblk.sql のパス：C:\Blocking\checkblk.sql

checkblk.out のパス：C:\Blocking\checkblk.out

上記条件の場合のコマンドは以下となります。

sqlcmd-E –S VRyo01\SQLSERVER2008R2 –i C:\Blocking\checkblk.sql –o C:\Blocking\checkblk.out -w 2000

コマンドプロンプトは開いたままにしておきます。

4. 調査対象の処理を実行

ブロッキング情報の採取が開始された事を確認した上で、調査対象の処理を実行します。処理の開始時刻をメモしておきます。

5. 現象(クエリ遅延など)発生を確認

クエリ遅延など調査対象の現象が発生した事を確認します。

6. ブロッキング情報の採取を停止

コマンドプロンプトで CTRL+C キー を押し、ブロッキング情報の採取を停止します。

7. 出力情報を採取

ブロッキング情報の採取開始時に -o 引数で指定した出力先パスから、アウトプットファイル checkblk.out を採取します。

[参考]

メモ帳などのテキストエディタで checkblk.out を開いてみましょう。

どうやら SPID55 のトランザクションが SPID 58 のトランザクションをブロックしているようです。

ブロッキング情報の採取手順は以上です。

★ SQL Server トラブルシューティング 6 回シリーズのご案内 ★

※本記事は、当初第6回でのご案内を予定しておりましたが、第5回に先行してご案内いたします。

他の記事は以下をご参照ください。
http://blogs.msdn.com/b/jpsql/archive/2012/03/30/sql-server-6.aspx

第1回 SQL Server のログ、イベントログの確認方法 (03/30 UP)
第2回 パフォーマンスログの採取方法 (04/20 UP)
第3回 パフォーマンスログの確認方法 (05/07 UP)
第4回 サーバートレースの解析方法 1 (05/18 UP)
第5回 サーバートレースの解析方法 2 (02/18 UP)
第6回 ブロッキング情報の確認方法 (★ 07/24 UP 本記事)

神谷 雅紀
SQL Server Escalation Engineer

リンクサーバーなど複数のサーバー間で資格情報の受け渡しが必要となる処理を行おうとした場合、Kerberos を用いた認証が必須になります。しかし、Kerberos 認証を行うためには、いくつかの設定が必要です。それらの設定が正しく行われていない場合には、資格情報の受け渡しが行えず、正常に機能しません。

先日、Kerberos の設定に関わるトラブルシューティングを行うためのツールを公開しました。

ツールは、以下の URL よりダウンロードすることができます。

Microsoft® Kerberos Configuration Manager for SQL Server®

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

使い方は非常に簡単で、KerberosConfigMgr.exe を実行した後、Connect メニューで対象サーバーへ接続します。サーバー名やユーザー名を指定せずに接続すると、ローカルサーバーに接続します。設定の確認に必要な操作はこれだけです。

接続すると、以下のように、そのサーバー上の SQL Server インスタンスとサービスアカウントに関して、SPN の登録状態や委任 (Delegation) の設定状態が表示されます。

表示されている内容を確認し、不足していたり、誤った設定が報告されている場合には、それを正します。

委任の設定については手動で行う必要がありますが、SPN に関しては、ツール実行者に権限があれば、ボタン一つで必要な SPN 設定を行うことができます。

横井 羽衣子
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 側まで着目せず、惑わされやすいパターンと言えます。

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

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

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

- 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 トレースについては、今後ブログに書いていこうと思います。

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

高橋 理香
SQL Developer Support Escalation Engineer

みなさん、こんにちは。

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

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

接続タイムアウトとは？

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

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

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

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

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

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

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

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

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

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

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

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

それとも・・・

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

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

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

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

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

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

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

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

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

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

• 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 の続きとして、接続エラーとしてどのようなものが発生しうるかのご紹介ができればと思っています。

山崎 実久
SQL Developer Support Engineer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Regsvr32 c:\temp\rsclientprint.dll

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

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

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

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

山崎 実久
SQL Server Developer Support Engineer

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

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

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

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 + 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 に関するエラー発生の際の切り分けに是非ご活用ください。

森  隆博
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] ボタンをクリックします。

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

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

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

山崎 実久 
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 Processing、Data Processing、Report Renderingの 3 つの工程を経てレポートを出力します。

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

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

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

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

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

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

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

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

皆さん、こんにちは。

SQL Server をアンインストールする場合、通常は、コントロールパネルから削除します。

SQL Server の既存のインスタンスのアンインストール (セットアップ)
http://technet.microsoft.com/ja-jp/library/ms143412.aspx

しかし、SQL Server のインストールを強制終了してしまったり、アンインストールが失敗したりして、通常の手段でアンインストールができなくなってしまった場合には、SQL Server を手動でアンインストールする必要に迫られることがあります。

そのような場合の手順をご案内いたします。

以下の例では SQL Server 2012 を対象としていますが、SQL Server 2005 以降であれば同じ手順でアンインストール可能です。
64bit と 32bit の環境ではパスなどが異なる場合がありますので適宜ご確認ください。

※注意事項※
以下の手順は弊社にて検証した手順ではございますが、必ずしもアンインストールが成功することを保証しているものではございません。状況によりましては、オペレーティング システムの再インストールが必要になることがあります。
手順の実施につきましては、自己の責任において行ってください。

1. 事前準備

以下の前提条件を満たしていることをご確認ください。

A. OS の再起動
B. リモートデスクトップ接続確認
C. セットアップに使用する OS(Windows) のログオンアカウント
D. サードパーティ社様製アプリケーション・サービスについて

A.  OS の再起動
----------------------------------------------------------------
アンインストール前に、OS 再起動を行います。

B. リモートデスクトップ接続確認
----------------------------------------------------------------  
ターミナルセッションはすべて切断されており、リモートデスクトップ接続が存在する場合は全てログアウトしていることを確認します。

リモートデスクトップ接続を使用してセットアップを実施することは可能です。
セットアップを実施するためにリモートデスクトップ接続を使用する際は、[スタート] -> [ファイル名を指定して実行] にて、
mstsc /admin (環境によっては mstsc /console) とタイプし、 OK後アクティブノードへ接続します。

C.  セットアップに使用する OS(Windows) のログオンアカウント
----------------------------------------------------------------
SQL Server セットアップを実施する際の OS(Windows) ログオンアカウントがローカルの Administrators グループに所属していることを確認します。

D.  サードパーティ社様製アプリケーション・サービスについて
----------------------------------------------------------------
フィルタドライバを使用するサードパーティ社様製 ウィルス対策ソフトや暗号化/セキュリティソフトのサービス・アプリケーションは一時的に停止してください。

2. MsiExec.exe /x によるコンポーネントアンインストール

レジストリ エディタを起動し、次のレジストリ キーを展開します。（[スタート] -> [ファイル名を指定して実行] にて regedit とタイプし、OK）

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

左側のウィンドウで、各 GUID (Globally Unique Identifier：グローバル一意識別子) をクリックします。
クリックした各 GUID について、右側のウィンドウで DisplayName 値のデータを確認し、"SQL" が含まれているものをみつけます。
存在するキーをすべてメモ帳等に控えてください。（右クリック –> [キー名のコピー] でクリップボードにコピーされます）

※注意事項※    
レジストリ エディタまたは別の方法を使用してレジストリを誤って変更すると、深刻な問題が発生することがあります。
最悪の場合、オペレーティング システムの再インストールが必要になることがあります。
マイクロソフトは、レジストリの変更により発生した問題に関しては、一切責任を負わないものとします。
レジストリの変更は、自己の責任において行ってください。

同様に以下のキーを展開し、DisplayName 値に"SQL" を含む GUID を控えます。

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

コマンドプロンプトを管理者権限にて起動し、以下のコマンドを実行してコンポーネントのアンインストールを行います。

msiexec /x GUID

   (例) msiexec /x {202AAF1F-69AA-442A-B59F-6B54B1AD07C6}

依存関係に関するエラーが生じた場合は、エラー内容にしたがって削除する順序を変更します。

その後、レジストリの対象フォルダを最新の状態に更新し、上記のキーが存在しないことを確認します。

3. GAC の削除

次の内容のバッチ ファイルを使用し、アセンブリを削除します。
※改行がないように注意してください。

REM =======================
if exist "%windir%\assembly\GAC\*SQLServer*" del /s /q /f "%windir%\assembly\GAC\*SQLServer*"
if exist "%windir%\assembly\GAC_32\*SQLServer*" del /s /q /f "%windir%\assembly\GAC_32\*SQLServer*"
if exist "%windir%\assembly\GAC_64\*SQLServer*" del /s /q /f "%windir%\assembly\GAC_64\*SQLServer*"
if exist "%windir%\assembly\GAC_MSIL\*SQLServer*" del /s /q /f "%windir%\assembly\GAC_MSIL\*SQLServer*"
REM =======================

グローバル・アセンブリ・キャッシュ（GAC）は、マシン全体でグローバルに参照可能なアセンブリの配置場所です。
GAC は特殊なフォルダ構造なので、エクスプローラで「%windir%\assembly」フォルダを見てみると、アセンブリの名前を一覧表示するシェル拡張が起動されます。
コマンド・プロンプトでフォルダを参照すると、GAC の内部的なフォルダ構造を確認できます。

4. レジストリ削除

現時点で残っているレジストリを削除します。

以下のキーを展開し、”Microsoft SQL” または"MSSQL" を含むレジストリを確認します。

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft

  HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft

コマンドプロンプトを管理者権限にて起動し、以下のコマンドを実行してレジストリを削除します。

reg delete “レジストリキー”

例） reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server 2012 Redist"

レジストリエディタで該当のキーを右クリック - "キー名のコピー" を選択すると、レジストリキーがクリップボードにコピーされます。

/f オプションを使用すると、プロンプトなしで強制的に削除されます。

reg delete "レジストリキー" /f

また以下のキーを展開し、ProductName 値に “SQL Server” を含むキーが存在しないことを確認します。

  HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products

ProductName 値に “SQL Server” を含むキーが存在している場合は、手順 2 から再度、確認してください。

5. フォルダ・ファイルの削除

次の内容のバッチ ファイルを使用し、ドライブから SQL Server 関連ファイルを削除します。

※ファイルが使用中の場合は OS を再起動してから再度実施します。

※改行がないように注意してください。（if exist が先頭になります）

REM =======================
if exist "%USERPROFILE%\Local Settings\Application Data\Microsoft\Microsoft SQL Server" rmdir /S /Q "%USERPROFILE%\Local Settings\Application Data\Microsoft\Microsoft SQL Server"
if exist "%USERPROFILE%\Application Data\Microsoft\Microsoft SQL Server" rmdir /S /Q "%USERPROFILE%\Application Data\Microsoft\Microsoft SQL Server"
if exist "%USERPROFILE%\All Users\Application Data\Microsoft\Microsoft SQL Server" rmdir /S /Q "%USERPROFILE%\All Users\Application Data\Microsoft\Microsoft SQL Server"
if exist "%ProgramFiles%\Microsoft SQL Server" rmdir /S /Q "%ProgramFiles%\Microsoft SQL Server"
if exist "%ProgramFiles(x86)%\Microsoft SQL Server" rmdir /S /Q "%ProgramFiles(x86)%\Microsoft SQL Server"
REM =======================

6. TEMP 内のリソース削除

TEMP フォルダ内のサブフォルダ・ファイルを削除します。

   %TEMP%
   %systemroot%\temp

実行例：
>cd %TEMP%
> del *.* /S /Q

※ファイルが使用中の警告が出力されたものは無視して問題ありません。

7. OS再起動

以上で終了です。

お疲れ様でした。

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

まずは 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

佐藤美菜
SQL Developer Support Engineer

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

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

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

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

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

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

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

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

名前付きパイプ プロトコルによる通信では、サーバー側の 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

(確認例: 失敗時)

(確認例: 成功時)

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

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

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

<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. [ローカル接続およびリモート接続] において名前付きパイプが有効になっていることを確認します。

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

以上です。

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

小林 真治
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

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

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

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

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

■前提条件 

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

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

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

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

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

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

データベースが破損しエラーが返されたり、アクセスできないといった状況が発生した場合、バックアップからリストアするという対処がもっとも一般的かつ確実な対応であり、SQL Server サポートでは、通常、バックアップからのリカバリ手順をご案内しております。しかしながら、バックアップを採取していなかったり、バックアップからのリストアに失敗したという場合もあります。 今回は、そのようなバックアップからのリストアが行えない場合のデータベースの修復方法を紹介します。

※ 注意事項 ※  

• 以下の手順は検証済みの手順ですが、必ずしもデータベースの復旧を保証しているものではありません。手順の実施につきましては、自己責任において行ってください。  
  

• データベースの破損状況によっては、以下で紹介する修復手順を実施しても、データベースに接続でき、アプリケーションが実行できるまでの状態に復旧できない場合もあります。その場合はデータベースの再作成が必要となります。      
  

• 本手順を実施すると、トランザクションの一貫性が失われる場合があります。トランザクションの一貫性が保たれているかどうかの確認は、対象データベースに格納されているデータ間の関連性を熟知している方、もしくは、この手順を実施する方の責任において実施する必要があります。トランザクションの一貫性が保たれているかどうかの確認が行えない場合には、この手順を実施しないで下さい。
       
  

また、SQL Server サポートサービスにて、可能な限りデータベースを復旧するサポートを承っております。必要に応じてご利用下さい。

■修復手順

1. 対象データベースのファイルコピーを行います。

SQL Server サービスを停止し、対象データベースファイルのファイルバックアップ（別フォルダにデータベースファイルをコピー）を行います。

データベースファイル、ログファイルのファイルパスは以下のクエリにて確認可能です。以降の手順で予期しない問題が発生した場合、このファイルを用いて手順 1. の状態まで戻すことができます。バックアップ完了後、SQL Server サービスを再起動します。

         
select d.name as databasename,f.name as filename ,f.physical_name as filepath           
from sys.master_files f,sys.databases d where d.database_id = f.database_id 
GO       

2. Microsoft SQL Server Management Studio を起動し、sa 等の管理者権限をもつ sysadmin ロールメンバとして SQL Server へ接続します。

3. [新しいクエリ] を選択します。

4. 下記のコマンドを実行し、整合性を確認します。

DBCC CHECKDB([データベース名])           
GO                  

データベースが「未確認」状態、「復旧待ち」状態である場合は、上記コマンドは実行できません。 その場合は、下記のように、対象データベースを緊急モードに変更後、DBCC CHECKDBコマンドを実行します。     

USE master      
GO      
ALTER DATABASE [データベース名] SET EMERGENCY      
GO      
DBCC CHECKDB([データベース名])    
GO        

緊急モードに変更することにより、システム管理者はデータベースに読み取り専用でアクセスできるようになります。

5. 出力された結果を確認します。

DBCC CHECKDB コマンド結果に、エラーメッセージが含まれる場合は、そのエラーに対する対処が必要です。

repair_rebuild、repair_allow_data_loss を指定した DBCC CHECKDB による修復については、以下の点に注意が必要です。

   1. テーブル間に制約があっても考慮されない。

   3. repair_allow_data_loss オプションを指定した場合、トランザクションの一貫性が失われる可能性がある。破損したデータは削除され、DBCC CHECKDB では、どのデータが削除されたかは示されない。

以上のとおり、DBCC CHECKDB により修復を行ったとしても、必ずしも元通りの状態になるわけではありません。上記オプションを使用してデータベースの修復を行い、データベース自体の整合性エラーがなくなったとしても、そのデータベースをアプリケーションで利用できるとは限りません。修復したデータベースを用いて問題なくアプリケーションが利用可能かどうかは、ユーザー自身で確認する必要があります。 アプリケーションで利用できなかった場合はデータベースの再構築が必要となる場合もあります。

そのため、DBCC CHECKDB に修復オプションを指定したデータベース修復は、バックアップ等も用いた復旧が行えない場合の最後の手段であり、テーブル間の関連性やデータの内容を熟知しており、DBCC CHECKDB による修復後、その結果を確認できる方が責任を持って行う必要があります。

削除されたデータについてマイクロソフトに問い合わせいただいても、どのようなデータが削除されたのかについては確認することはできません。

6. DBCC CHECKDB 結果に出力されたオプションを利用して、データベースの修復を実施します。

まず、シングルユーザーモードに変更します。

ALTER DATABASE [データベース名] SET SINGLE_USER           
GO            

その後、修復オプションを指定した DBCC CHECKDB を実行します。DBCC CHECKDB に指定する修復オプションは、手順 4. で確認したオプションです。

DBCC CHECKDB('データベース名','REPAIR_ALLOW_DATA_LOSS')             
GO

または

DBCC CHECKDB('データベース名','REPAIR_REBUILD')          
GO

データベースが緊急モードの状態で REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB を実行すると、トランザクション ログが壊れている場合には、トランザクション ログが再構築されます。ただし、トランザクション ログの再構築の結果、トランザクションの一貫性が失われる場合があります。

また、DBCC CHECKDB が正常に終了した場合は、データベースの状態は ONLINE に設定されますが、データベースにはトランザクション上、一貫しない部分が 1 つ以上含まれる可能性があります。

DBCC CHECKDB がエラーなく実行完了したとしても、次の手順 7. でエラーが検出される可能性があります。必ず、手順 7. の整合性確認チェックを行ってください。

DBCC CHECKDB はすべてのエラーを修復できるわけではありません。DBCC CHECKDB が修復処理自体のエラーを報告した場合は、DBCC CHECKDB ではデータベースを修復することはできません。

7. DBCC CHECKDB を修復オプションなしで実行し、エラーが存在しないことを確認します。

DBCC CHECKDB('データベース名')               
GO             

DBCC CHECKDB コマンドにてエラーが検出された場合は、メッセージで示された修復オプションを指定した DBCC CHECKDB により、手順 6. および 7. をエラーがなくなるまで繰り返します。ただし、修復を繰り返しても報告されるエラー内容に変化がみられない場合、そのエラーは修復不可能なエラーです。

8. DBCC CHECKDB コマンドでエラーが 0 になったことを確認後、下記のコマンドを実行し、制約に関する整合性をチェックします。

USE [データベース名]           
GO      
DBCC CHECKCONSTRAINTS      
GO                 

上記手順 7. の DBCC CHECKDB は、データフォーマットに関するチェックは実施されますが、制約に関するチェックは行われません。そのため、修復対象のデータベースで FOREIGN KEY 制約や CHECK 制約を使用している場合は、データベースの修復完了後、DBCC CHECKCONSTRAINTS コマンドを実行し、制約の整合性についても確認する必要があります。

9. データベースをマルチユーザーに戻します。

ALTER DATABASE [データベース名] SET MULTI_USER           

10. 必要に応じて下記のコマンドを実行し、該当のデータベースの復旧モデルを「完全」に戻します。

上記手順 6. で REPAIR_ALLOW_DATA_LOSS 句を指定して DBCC CHECKDB コマンドを実行し、破損個所の復旧をおこなった場合、該当のデータベースの復旧モデルが「単純」へと変更されます。そのため、必要に応じてデータベースの復旧モデルを元の復旧モデルに戻します。      

     
ALTER DATABASE [データベース名] SET RECOVERY FULL           
GO             

「一括ログ」モデルに戻す場合は、'ALTER DATABASE [データベース名] SET RECOVERY BULK_LOGGED' を実行します。

以上でデータベースの修復作業は完了です。

その後、削除されたデータの特定や、クライアントからの接続可否、アプリケーションからの使用に問題がないかどう可能かなど、そのシステムおよびアプリケーションの観点で問題がないかどうかについて確認します。

また、必ず「バックアップ」をご採取ください。

前回ご案内したバックアップが存在しない、または、バックアップからのリストアが行えない場合のデータベース復旧手順では、バックアップを採取していなかったり、バックアップからのリストアに失敗したという場合のデータベースの修復方法をご案内しました。その中では、DBCC CHECKDB コマンドの修復オプションを用いてデータベースの修復を行いましたが、DBCC CHECKDB の修復オプションを用いてもデータベースを修復できない場合もあります。そのような場合は、データを抜き出して、そのデータを元にデータベースを再構築する以外にはありません。今回は DBCC CHECKDB コマンドの修復オプションでも復旧できない場合に、破損したデータベースから可能な限りのデータを抜き出すための方法をご案内します。

※ 注意事項 ※  

• 以下の手順は検証済みの手順ですが、必ずしもデータをすべて抜き出せることを保証しているものではありません。手順の実施につきましては、自己責任において行ってください。  
  

• 本手順を実施した後、インデックスの作成や外部キー（FK）の設定を行う必要がある場合もあります。そのため、本作業は、対象データベースに格納されているデータ間の関連性を熟知している方、もしくは、この手順を実施する方の責任において実施する必要があります。データ間の関連性が保たれているかどうかの確認が行えない場合には、この手順を実施しないで下さい。           
  

■抜き出し手順

1. 移行先となる新規データベースを作成します。

Create Database データベース名               
GO
Use データベース名
GO
Alter database 'データベース名' set RECOVERY FULL 
GO          

3.  すべてのテーブルにインポートが完了したら、DBCC CHECKDB コマンドを実行し、整合性に問題がないことを確認します。

以上でデータの抜き出し作業は完了です。

その後、クライアントからの接続可否、アプリケーションからの使用に問題がないかどう可能かなど、そのシステムおよびアプリケーションの観点で問題がないかどうかについて確認します。

また、必ず「バックアップ」をご採取ください。

Backup Database データベース名 to disk = ‘バックアップ先ファイル.bak'

皆さんこんにちは。 SQL Server/SQL Database サポートを担当しております藤野です。
今回は、SQL Server 2005 Management Studio にて、[ログインをロックアウトする] のチェックを外した際の注意点についてご案内いたします。
[ログインをロックアウトする] の設定箇所は、 SQL Server 2005 Management Studio のオブジェクト エクスプローラに表示される [セキュリティ] 配下の [ログイン] に登録されたログインユーザのプロパティにある [状態] の項目となります。
 

1. アカウントのロックについて
===========================================
SQL Server 認証のアカウントにて、パスワードポリシーが有効となっている場合、アカウントロックポリシーが適用されます。
アカウント ロックアウトポリシーは指定された期間内で間違ったパスワードを指定された回数入力された場合にアカウントをロックする機能です。
WORKGROUP 環境ではローカルポリシー、ドメインの場合は、ドメインのグループポリシーに応じて、この機能が使用されます。
このアカウントロック操作は、SQL Server のバージョンに関わらず、共通です。
 
  SQL Server 2005 Books Online
  タイトル : パスワード ポリシー
  http://msdn.microsoft.com/ja-jp/library/ms161959(SQL.90).aspx
  

2. アカウントのロック解除方法
===========================================
アカウントがロックされた場合は、パスワードをリセットし、ロックを解除する対処を行います。
以下の方法で、SQL Serverユーザーのロックを解除します。
 
ログインのロックを解除する
http://msdn.microsoft.com/ja-jp/library/ms189828.aspx
 
 
―――――――
SQL Server ログインのロックを解除するには、**** を必要なアカウントのパスワードに置き換えて、次のステートメントを実行します。

ALTER LOGIN [Mary5] WITH PASSWORD = '****' UNLOCK ;
GO
―――――――

※パスワードを変更したくない場合は一時的にパスワードポリシーを解除する方法にて対処する方法もあります。

―――――――
ALTER LOGIN [Mary5] WITH CHECK_POLICY = OFF;
ALTER LOGIN [Mary5] WITH CHECK_POLICY = ON;
GO
―――――――

3. SQL Server 2005 の[ログインをロックアウトする] チェックを外した際の注意点について
===========================================
SQL Server 2005 Management Studio の[ログインをロックアウトする] チェックを外した際、対象アカウントのパスワードのリセットが実行されます。
そのため、チェックを外す操作を行った後、以前のパスワードを使用してログインできなくなります。
この場合、GUI からではなく、 「2. アカウントのロック解除方法」と同じとコマンドを使用してロックを解除し、新しくパスワードを設定する必要があります。

4. SQL Server 2008 以降の[ログインをロックアウトする] チェックを外した際の動作につい���
===========================================
SQL Server 2008 以降では Management Studio の [ログインをロックアウトする] チェックを外した際、ロックを解除するためにユーザーがパスワードを更新することが必要である旨の警告のみを出し、ロックの解除操作は行わないよう動作を変更致しました。
 
具体的には以下の警告を出力します。
 

－－－－－－－－－－－－－－－－－－－－－－－
ロックの解除中にログインのパスワードをリセットします。 (SqlManagerUI)
－－－－－－－－－－－－－－－－－－－－－－－
 
[ログインをロックアウトする] チェックを外す操作では、上記警告を出すのみでロックの解除は行いません。
ロックの解除を行うためには、[ログインをロックアウトする] チェックを外す操作とは別に、警告に従って、パスワード更新とロックの解除操作を行っていただく必要があります。
操作内容は 「2. アカウントのロック解除方法」と同じです。