SQL Server 2008 R2の修正プログラムで適用が必要になったものの記録

Windows Server 2008 R2 Enterprise Edition環境下で、SQL Server 2008 R2 Standard Editionを運用していて、問題に遭遇し修正プログラムを適用した記録を公開しておきます。
どなたかの参考になれば幸い。
ちなみに自分の管理下にあるのは50~60台なので、いろんな事象に遭遇します(^^;

SQL Server 2008 R2 SP1

Windows Server 2008 R2で高負荷環境下で運用していると、SQL Serverのプロセスがダウンしてしまう可能性があり適用した。
SQL Serverの高負荷時にTCP通信に使用するメモリ領域が使用中のまま解放される問題のようです。

自分の管理下にある50台のサーバーの内、2台のサーバーにおいて1回ずつプロセスがダウンした。

SQL Server 2008 R2 SP1 CU3

The client was unable to reuse a session with <SPID>, which had been reset for connection pooling. The failure ID is 29. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.
Error: 18056, Severity: 20, State: 29.

上記のようなエラーが記録される事象が発生。
How It Works: Error 18056 – The client was unable to reuse a session with SPID ##, which had been reset for connection pooling

http://support.microsoft.com/kb/2543687/en によると2008 R2 CU9で修正されたと情報がありました。2008 R2 CU9が、2008 R2 SP1 CU3に相当します。

SQL Server 2008 R2 SP1 CU6

次の問題に遭遇。

  • クライアントアプリケーションがMicrosoft SQL Server 2008またはMicrosoft SQL Server 2008 R2のインスタンスに接続している
  • SQL Serverが、SQL Server 2008またはSQL Server 2008 R2とクライアントアプリケーション間の接続をリセットしたとき、クエリタイムアウトが発生します。または、クライアントアプリケーションが SQL Serverのインスタンスへクエリをキャンセルする情報を送信します。

アプリケーションがSQL Serverと通信できなくなる問題に遭遇した。
調査すると次の問題に該当したので適用した。

FIX: Errors when a client application sends an attention signal to SQL Server 2008 or SQL Server 2008 R2
http://support.microsoft.com/kb/2543687/en

SP2

まだ適用していないけど、情報としてメモ。

SQL Server 2008 R2 SP2には、SQL Server 2008 R2 SP1 CU1~CU5
SQL Server 2008 R2 SP2 CU1には、SQL Server 2008 R2 SP1 CU6~CU7

SP1 CU6が適用されている必要があるから、SP2単体を適用する予定は無し。
適用するなら、SP2とSP2 CU1を同時に適用する。

SQL Server 2008 R2 SP1 
CU1 
CU2 
CU3 
CU4 
CU5SQL Server 2008 R2 SP2
CU6 
CU7CU1
CU8CU2(完全には一致していない)

参考

「蒼の王座indexView」バージョン0.01リリース

SQL Serverのインデックスが断片化し、再構築をすることがあります。
再構築をする際の課題として、どれぐらい再構築が完了したのかが不明で、イライラすることがあります。

「蒼の王座indexView」は、インデックスの再構築の進捗状況を概算表示させることができます。

機能

  • データベースのインデックスの断片化率、使用状況を表示できます。
  • インデックス個別に再構築を実行できます。
  • インデックス再構築の進捗状況を確認できます。

前提条件

  • .NET Framework 4 が必要です
  • SQL Server 2005、SQL Server 2008、SQL Server 2008 R2、SQL Server 2012で動作します
  • SQL Azureには対応していません。

制限事項

インデックスの再構築の進捗状況を確認したい場合には、以下の制限事項があります。

  • オフライン再構築であること
  • インデックスの再構築以外の処理をしていないこと
  • インデックス1つだけ再構築をしていること

手順

アプリケーション起動画面

image

接続したいSQL Serverインスタンスのサーバー名、ユーザ名、パスワードを入力します。

SNAGHTML687ab7c

インデックス一覧を表示したいデータベースを選択します。

SNAGHTML687f1bf

インデックス一覧が表示されますので、再構築したいインデックスを選択します。右クリックをし、コンテキストメニューから「再構築」を選択します。

image

インデックスの詳細が表示されるので、再構築ボタンをクリックします。

SNAGHTML688cca3

ダウンロード

  • ClickOnce版(IE9では上手く動作していないですね。。。)
  • Zip

SQL Server Agentのジョブをすべて一括でスクリプト化する方法

SQL Server Agentに、多数のジョブが登録されているサーバーのジョブを別サーバーに移行する場合、ジョブを再作成しなければなりません。
ジョブそのものは、システムデータベースのmsdbに登録されています。しかし、msdbを別サーバーに復元しても正常に動作しません。正常に移行するためには、ジョブを再作成する必要があります。

データベースを別のサーバー インスタンスで使用できるようにするときのメタデータの管理

移動先のサーバー インスタンスの master および msdb で、依存しているエンティティとオブジェクトのすべてのメタデータを再作成する必要があります。たとえば、データベース アプリケーションでサーバーレベルのトリガーを使用している場合、そのデータベースを新しいシステムでアタッチまたは復元するだけでは不十分です。このデータベースは、master データベース内のこれらのトリガーのメタデータを手動で再作成しない限り、正常に動作しません。

つまり、ジョブをスクリプト化して、新しいサーバに対して発行することでジョブを移行させることになります。

image

ジョブを選択して、右クリックしてコンテキストメニューから、ジョブをスクリプト化できます。

ジョブが多数ある場合・・・

下の図のように、ジョブが多数ある場合は、どうしたら良いのでしょうか?

image

一個一個、スクリプト化なんて対応は厳しいです。
ジョブをまとめて一括で、すべてスクリプト化できると好いですよね?
SQL Server Agentのジョブをまとめてスクリプト化するには、ジョブを選択して[F7]キーを押します。

image

[F7]キーを押すと、オブジェクトエクスプローラーの詳細が表示されます。

image

オブジェクトエクスプローラーの詳細ウィンドウで、Ctrl+Aもしくは、Shiftキーを押しながら選択します。

image

選択した状態で、右クリックをしコンテキストメニューからジョブをスクリプト化を選択すると、ジョブをまとめてスクリプト化することができます。

image

フィードバック

できれば、オブジェクトエクスプローラーで右クリックしたときにも、すべてをスクリプト化できる選択肢があると良いんですけどね。

image

SQL Server 2012 Express LocalDBのまとめ

SQL Server 2012 Expressエディションには2種類の製品が用意されています。従来通りのSQL Server 2012 ExpressとSQL Server 2012 Express LocalDBです。
今回は、SQL Server 2012 Express LocalDBについて調べたことをまとめてみたいと思います。

LocalDB RC0のインストーラー

SQL Server 2012 Express LocalDB RC0のインストーラーは、「ここ」からダウンロードできます。

RC0からインストーラーが改善されて、とてもシンプルで、とても小さいインストーラーとなりました。
32MBのMSIパッケージで、30秒ほどでLocalDBをインストールすることができます。

サイレントインストールに対応しており、LocalDBのサイレントインストールコマンド例は次のようになります。

msiexec /i SqlLocalDB.msi /qn IACCEPTSQLLOCALDBLICENSETERMS=YES

32ビット版LocalDBは、64ビット版Windowsでの動作をサポートしていません。また、LocalDBパッケージは、32ビット版も64ビット版も同じファイル名SqlLocalDB.msiで、MSIファイル名の変更をすることはできません。

LocalDBの概要

LocalDBは開発者向けに開発された製品です。
とても簡単にインストールでき、管理をする必要が無く、SQL Server Expressと同じT-SQL言語・プログラミングインターフェイス・プロバイダーを使用できます。
LocalDBはアプリケーション開発環境を対象にしたときのニーズを満たし、開発者は使用し続けることができ、とても素晴らしい組み込みデータベースです。

  • LocalDBは、SQL Server Expressと他のエディションと同じsqlserver.exeを使用します。アプリケーションは、接続するために同じクライアントプロバイダー(ADO.NET、ODBC、PDOなど)を使用でき、SQL Server Expressに提供されているのと同じT-SQLを使用してデータ操作ができます。
  • LocalDBは、マシン上に(SQL Serverのメジャーバージョン一つにつき)一つだけインストールされます。複数のアプリケーションが複数のLocalDBプロセスを開始することができますが、同じディスク上から同じsqlserver.exe実行ファイルから開始します。
  • LocalDBは複数のデータベースサービスを作成することはできません。LocalDBプロセスは、必要に応じて自動的にスタートし、ストップします。アプリケーションは、「Data Source=(localdb)\v11.0」に接続し、LocalDBプロセスは、アプリケーションの子プロセスとしてスタートします。このプロセスに最後に接続してから数分後、プロセスを閉じるためプロセスをシャットダウンします。
  • LocalDBは、AttachDbFileNameプロパティでの接続をサポートしており、開発者はデータベースファイルを指定することができます。LocalDBは指定したデータベースファイルをアタッチし、コネクションが作成されます。

背景

SQL Server Expressには、2つの異なるニーズがあります。

一つ目は、SQL Serverの無料エディションであること。SQL Server ExpressはほかのエディションのSQL Serverとインストール、管理、プログラミングで100%の互換性があります。SQL Server Expressは、学習、トレーニング、(DB容量10GB未満の)小さな製品データベースに使用することができます。SQL Server Expressからほかのエディションへのアップグレードは、ライセンスキーを登録するだけで実行でき、インストールは必要ありません。
二つ目は、SQL Server Expressは、SQL Serverを対象にしたアプリケーション開発に使用できるSQL Serverエディションです。ほかのSQL Server と100%の互換性を保ちながら、とても小さく、シンプルで、設定や管理が必要なく、管理者ユーザでも無く実行できることが期待されています。

SQL Expressは、両方の役割を担当できるように調整してきました。しかし、SQL Serverと互換性を保ちながら、小さくシンプルをじつげんすることは困難でした。そこで、アプローチを変え、開発者向けのSQL Express版、つまりAPIレベルでSQL Serverと互換性を持ち、シンプルなLocalDBを提供することにしました。

LocalDBインスタンス

LocalDBが必要なDLLはすべて一か所にまとめてインストールされます。
初期設定では、「C:\Program Files\Microsoft SQL Server\110\LocalDB\Binn」に配置されます。

(ADO.NETやODBC、PDOのような)クライアントプロバイダーから「Data Source=(localdb)\v11.0」に接続します。プロバイダーは最初にLocalDBインスタンスが起動しているかを確認します。すでに開始している場合は、アプリケーションに接続します。起動していない場合は、LocalDBインスタンスを起動してから接続します。
WindowsログオンユーザでLocalDBインスタンスを起動し、ほかのユーザのインスタンスとは分離されています。

LocalDBの接続文字列は、「Data Source=(localdb)\v11.0;Integrated Security=true」です。LocalDBに接続するには、SQL Server 2012のODBCやOLEDB、または.NET Framework 4 Update 4.0.2のADO.NETを使用する必要があります。

データベースファイル

LocalDBの接続文字列は、AttachDbFileNameプロパティをサポートしており、接続プロセス時にデータベースファイルをアタッチすることができます。

C:\MyData\Database1.mdfにデータベースファイルが配置されているとすれば、開発者は接続文字列を次のように指定します。

Data Source=(localdb)\v11.0;Integrated Security=true;AttachDbFileName=C:\MyData\Database1.mdf

LocalDBのシステムデータベースファイルは、隠しディレクトリのAppData「C:\Users\<user>\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\LocalDBApp1\」に格納されます。

ユーザデータベースは、特に配置場所を指定しない場合は、My Documentsディレクトリ「C:\Users\<user>\Documents\」直下に作成されます。

データベースの作成

次のようなクエリを実行します。

create database foo

My Documetフォルダーを参照すると、foo.mdfとfoo_log.ldfファイルが作成されていることを確認できます。また、データベースファイルの配置場所を指定したい場合は、次のようなクエリを実行します。

create database foo on (name='foo', filename='c:\DBs\foo.mdf')

LocalDBとSQL Server Express

LocalDBは、SQL Server Expressを置き換えるものではありません。

SQL Server Expressラインナップに追加されるものです。LocaDBは開発者向けで、SQL Server ExpressはSQL Serverの無料エディションであり続け、完全な互換性があり、簡単に上位エディションへアップグレードすることができます。

LocalDBとSQL Server Compact

「小さく、シンプルなデータベースで、ライトウェイトなインストール・データベースファイルへの接続」

これだけを見ると、SQL Server Compactを使用している開発者には同じに見えるかもしれません。この同一性はアクシデントではなく、LocalDBの目的はSQL Server Compactと同様に簡単に使用でき、一方でパワフルで、SQL Serverと完全な互換性があります。

LocalDBとSQL Server Compactの差異

  • 実行モード:SQL Server Compactはin-proc DLLですが、LocalDBは分離プロセスです
  • ディスク使用量:SQL Server Compactバイナリは4MBですが、LocalDBは140MBです。
  • 特徴:SQL Server Compactはクエリ機能のようなコアのRDBMS機能を提供しますが、LocalDBはストアドプロシージャ、幾何学、地理データ型のようなリッチな機能セットを提供します。

SQL Server Management Studioでの操作

SQL Server Management StudioとLocalDBと.NET Framework 4をインストールします。さらに、.NET Framework 4.0.2へアップデートします。SSMSから接続するさいには、図のように「(localdb)\v11.0」と指定します。

SNAGHTML2771a5bf

SSMSからデータベースの作成

SSMSからデータベースを作成するために、データベース作成ウィザードからデータベースを作成します。

情報を入力し、OKボタンをクリックするとエラーが発生します。

これは現時点でのバグです。

回避策としては、データベースの配置場所を「My Documents」にすることです。

 

参考情報

運用保守計画に、重大インシデント対応訓練を盛り込む

バックアップが・・・!!:データベース系SEの脳内データとインデックス」を読みました。
ディスクの多重障害が発生しバックアップからデータベースを復旧させようとしたが、バックアップが戻らなかった事例です。

データベースサーバは通常多重化されているので、バックアップから復旧しなければならないような事態は少ないので、運用開始後数年間あまりかえりみられることが無いのがバックアップです。

重大インシデント対応計画が誇りをかぶっているPJでは、誇りを払って重大インシデント対応訓練を実施する必要があると思います。
訓練をしていないと、重大インシデント発生時に的確な対応ができず、ヒューマンエラーによる障害の長期化につながる恐れがあります。