SE の雑記

SQL Server 2008 R2 November CTP の UCP を少し触っているのですが、このバージョンでも、
SQL 2000 ～ 2008 のサポートはされていないみたいです。

UCP を使用するためには以下のクエリで、実行結果として [2] が取得できないといけないようです。

SQL Server 2008 R2 では実行結果が [2] となるため、有効なエディションとして認識されるのですが、
それ以外のバージョンですと [-1] (VALUE_ERROR) となってしまい、エディションのチェックではじかれます。

[3090395820] が何についての値を取得するための設定値なのかがつかめていないのですが、
現在は、SQL Server 2008 R2 でのみ有効な設定として値が返ってくるようです。

値が [2] 以外の場合は、以下のメッセージを返すようですので、エディションのチェックのような気がしますが、
UCP で管理可能なエディションは制限があるのでしょうか？？
Tech Ed では特にエディションの指定については言及していなかった気もするのですが。

?

xp_qv という拡張ストアドプロシージャの存在は今回知りました。
といってもどのように使うものなのかがピンと来ていませんが…。

ドキュメントとしては以下のものに少し記載がされています。

Guidance Addendum
Guidance Addendum / Installation / Startup

xp_qv でのチェックに至るまでには SQL Server 2008 の msdb に UCP で必要となるストアド等を
手動で登録してあげないといけませんでしたが。かなり無理やりこの状態まで持っていっています。
xp_qv のリターン値を無視するように細工して、UCP の管理対象として追加することはできたのですが、
情報のアップロードはうまくいきませんでした。

?

UCP に関しては TechNet Forum でも投稿があったみたいですね。
Can SQL Server 2008 (non-R2) instances by managed by a UCP?

CTP2 の時は R2 のみ追加できるということだったようですが、CTP3 でも同様のようです。
現状の仕組みでは、管理対象の msdb を拡張しないと情報は取得できないようですので、
簡単に統合管理できるというわけでもなさそうですね。

UCP 用のデータアップロードのステップは Power Shell のステップとして登録されているので、
2000 / 2005 では Active X スクリプトタスクあたりになるのでしょうか？

使えるようになる場合は何かしらのアップデートモジュールが提供されるのではないでしょうか。

今回、調べている中で、[xp_msver] という拡張ストアドプロシージャの存在を知りました。
実行すると以下のような情報が取得できます。

?

環境情報を一括で取得するものとして便利そうです。
[FileVersion] に [KJ] と出力されているところ [Kilimanjaro] のコードネームが見受けられますね。
SQL Server 2008 で実行すると [Katmai] が出力されたりします。

DBCC IND の再構成 / 再構築その 2 は明日以降に書くとして、その前に R2 の最新の CTP を
インストールしてみたいと思います。

現在、SQL Server の検証で使用している、2005 / 2008 がインストールされている環境に
名前付きインスタンスとしてインストールしたいと思います。
OS はまだバージョンアップしていないので Windows Server 2008 を使用しています。

1. インストールメディアをいれてインストーラーを起動します。
2. [インストール] → [新規インストールを実行するか～] をクリックします。
   ?
3. [OK] をクリックします。
   
4. [次へ] をクリックします。
   選択できるエディションは、[Enterprise Evaluation] [Express] [Express with Advanced Services] の
   3 種類となっています。
   今回は [Enterprise Evaluation] で。
   
5. [使用許諾契約書に同意する] を有効にして、[次へ] をクリックします。
   ?
6. [インストール] をクリックします。
   
7. [OK] をクリックし、手動で再起動します。
   
8. 再起動後、再度インストーラーを起動して、セットアップを継続します。
9. [次へ] をクリックします。
   
10. エディションを選択して、[次へ] をクリックします。
11. [使用許諾契約書に同意する] を有効にして、[次へ] をクリックします。
12. [SQL Server 機能のインストール] を選択して、[次へ] をクリックします。
    
13. インストールする機能を選択して、[次へ] をクリックします。
    ?
14. [次へ] をクリックします。
    
    今回は共存環境ですので共有コンポーネントで警告が発生しています。
    
15. インスタンス名を入力して、[次へ] をクリックします。
    
16. [次へ] をクリックします。
    
17. サービスアカウントと照合順序を選択して、[次へ] をクリックします。
    ??
    照合順序はデフォルトが [Japanese_CI_AS] となっています。
    最新の日本語の照合順序は SQL Server 2008 と同じで [Japanese_XJIS_100] みたいです。
18. 管理者アカウントと、ディレクトリ、FILESTREAM の設定をして [次へ] をクリックします。
    
    
19. 今回は Reporing Services もインストール対象としていたので設定画面が表示されます。
    Reporting Services は後で構成したいので、[レポート サーバーを構成せずにインストールする] を選択して、
    [次へ] をクリックします。
    
20. [次へ] をクリックします。
    
21. [次へ] をクリックします。
    
22. [インストール] をクリックします。
    
23. [OK] をクリックします。
    
24. [閉じる] をクリックします。
    
25. [OK] をクリックして、手動で再起動します。
    

以上でインストール完了です。

UCP の設定画面も日本語になっていますね～。

?

機能は少しずつ確認していきたいと思います。

SQL Server のインデックスのメンテナンスには

• 再構成 (REORGANIZE / DEFRAG)
• 再構築 (REBUILD)

の 2 種類があります。

2 種類の違いを 2 回の投稿に分けてまとめていきたいと思います。

まずは、前回使用した SQL データを挿入して、DBCC IND でページの情報を取得してみました。
# 一度 Truncate でデータをクリアして再挿入しています。

– 結果 1 –

?

この状態で、前回使用したクラスタ化インデックス更新の SQL を実行して断片化を発生させます。

– 結果 2 –

?

[PagePID] が 3976 ～3990 , 4040 ～ 4056 が使用されているのが確認できます。

この状態で再構成と再構築を実行して違いを確認したいと思います。

[インデックスの再構成]

以下の SQL を実行してインデックスを再構成してみます。

再構成後に DBCC IND を実行して、ページの情報を取得します。

– 結果 3 –

?

[PagePID] 3976 ～ 3987 を使用して断片化が解消されています。

それでは再度断片化を発生させて、インデックスの再構築をしてみたいと思います。
断片化を発生させたところ、[PagePID] 3976 ～ 3989 , 4064 ～ 4079 が使用されていました。

[インデックスの再構築]

以下の SQL を実行してインデックスを再構築します。

DBCC IND を実行してページの情報を取得します。

– 結果 4 –

?

[PagePID] 4080 ～ 4098 を使用して断片化が解消されています。

?

インデックスの再構成と再構築では、既に割り当てられている領域を使用するか、新規に領域を割り当てるかの違いがあります。

インデックスの再構成では既に割り当てられている領域を利用して断片化の解消を行います。
そのため、断片化が発生した際に割り当てられていた [PagePID] と同様のページが使用されています。
断片化解消のために新たなエクステントが割り当てられることがありません。

それに対してインデックスの再構築は新規のページを使用して断片化の解消が行われます。
インデックスの再作成に近い形で断片化の解消が行われていたはずです。
新規のエクステントに断片化解消後のインデックスを作成し、作成が終了したらそれまで使用していた領域を
空きページとして解放するようです。

再構成も再構築も断片化の解消により、未使用になったページは他のオブジェクトでも使用可能なように解放されますが、
既存ページの利用か新規ページの割り当てかの違いがありますので、処理終了後の未使用領域には差が出てきます。

?

再構成は既存のページ内での並び替えですが、再構築は再作成を行います。
そのため、再構成と再構築では処理終了後に使用している [PagePID] に違いが出てきます。
あまりにも断片化が発生していると再構成の並び替えに時間がかかり、再構築のほうが早い場合もあったりします。

再構成と再構築の違いは領域の再利用だけでなく、エクステントの並び替えでの動作に関しても違いがあります。
これに関しては次回の投稿でまとめたいと思います。

朝、TechNet / MSDN の会員向けサイトの RSS を確認していたところ、提供が開始されていました。

今回の CTP では日本語版のダウンロードも可能となっています。

帰ったら自宅の SQL Server 検証環境にインストールしてみたいです。

TechNet / MSDN の会員向けサイトで Exchange 2010 がダウンロード可能になりました！！

時間がある時に検証環境を Exchange 2007 から 2010 に移行してみたいと思います。

Windows Server 2008 R2 上で Exchange 2007 の実行に関しては更新プログラムが提供されたら、
別の環境を構築して試してみようかな。

ここ数日は SQL Server の基礎から勉強しなおそうと思い、インデックスの再構築 / 再構成について調べていました。
データの更新を行っているとデータページの断片化が発生し、断片化解消のためにインデックスの再構築 (REBUILD)、
再構成 (REORGANIZE) が必要となります。

ページの連続性が確認できないかなと思い、いろいろと本を眺めていたところ、[DBCC IND] があったなと思い、
少し試してみました。
# SQL Server の投稿に関しては SQL Server 2008 で検証をしていきたいと思います。

まずはテスト用として以下のテーブルを作成しました。

GUID と NCHAR で構成された単純なテーブルです。
このテーブルに以下の SQL でデータを挿入して、インデックスを再構築して断片化を解消した状態にします。

?

この状態で DBCC IND を実行して、ページの連続性を確認してみました。

?

以下の実行結果が取得できます。

– 結果 1 –

?

ここで確認したい内容が [NextPagePID] と [PrepPagePID] です。
この値が対象のページに対しての前後のページ ID となります。

クラスタ化インデックスの再構築後の状態を取得していますので、データの連続性が保たれています。

この状態でクラスタ化インデックスを更新して断片化を発生させます。

再度、DBCC IND を実行してページの情報を取得します。

– 結果 2 –

断片化の発生により、ページ数が倍以上に増えています。
PagePID 3338 のレコードを見てみると、次のページが [3347] となっています。
他にも前後のページが連続していないレコードがちらほらと見受けられます。
この状態が断片化が発生している状態ですね。

ALTER INDEX ～ REBUILD を実行して、ページを確認してみます。

– 結果 3 –

結果 1 と同じレコード数となり、ページ番号も連続しています。
断片化が解消されているのがページ数とページの連続性から確認ができますね。

DBCC IND を使用すると、インデックスの再構築と再構成の動作の違いを確認することも可能です。
こちらについては次回投稿したいと思います。
# 結果 2 と結果 3 ではPagePID が変わっているのですが、これがインデックスの再構築と再構成の違いでもあります。

SQL Server のデータベースは自動拡張設定を使用することで、データベースの割り当て領域が不足した際に、
自動的に拡張するように設定することができます。

SQL Server のソート等で使用される tempdb にもこの設定は適用することが可能です。

tempdb の領域が不足するとソート時などに以下のエラーが発生します。

# tempdb にはソートの一時結果が保存されますので、これはメモリ上でソートができる場合でも保存されますので、
　 メモリが足りていても tempdb が足りていないとソートに失敗します。

保険のために自動拡張を有効にして領域不足を解消するのは有効だと思います。

ただし、tempdb はサービスが再起動するタイミングで再作成されています。
自動拡張がされていても、サービスが再起動されると、明示的に設定をしていたサイズで再作成され、
自動拡張後のサイズはクリアされてしまいます。

[自動拡張前の tempdb のサイズ]

現在は 8.5MB 割り当てられています。

この状態で 600MB 程度のデータが入っているテーブルをソートしてみます。

[自動拡張後の tempdb のサイズ]

671MB まで拡張されました。

今の設定では 10% 単位で拡張がされるようになっています。
自動拡張のイベントを確認してみると、データファイルの自動拡張イベントが大量に出力されています。

今回の自動拡張イベントの処理時間の合計だけで、[34,939 ミリ秒] かかっています。
自動拡張の発生で 30 秒。処理時間としてはもったいないですね。
# 瞬時初期化ありの状態でこの秒数です。

今回はクエリエディタから実行しているのでタイムアウトしていませんが、プログラムから実行した場合は、
クエリタイムアウトの秒数に引っ掛かりエラーとなる可能性も。

この状態で、SQL Server のサービスを再起動してみます。

[再起動後の tempdb のサイズ]

再起動後は初期サイズの 8.5MB になってしまっています。

これは、ユーザーデータベースの場合は自動拡張が発生すると、初期サイズが変更されるのですが、tempdb に関しては
自動拡張が発生しても初期サイズが変更されないためです。

自動拡張後にデータベースのプロパティを確認してみると、600MB 超のサイズが初期設定にはなっておらず、
明示的に設定したサイズとなっています。
?

サーバーの定期メンテナンス等で SQL Server を再起動する前に、tempdb の現在のサイズを確認して、
初期サイズの見直しが必要かの判断は重要かな～と思います。

前回の投稿でシステムテーブルの更新には、専用管理者接続 (Dedicated Administrator Connection : DAC) を
使用すると書きました。

DAC は SQL Server 2005 からの機能で、SQL Server の応答が無くなった時に、トラブルシューティング等を
するために使用します。

デフォルトでは SQL Server をインストールしているサーバー (127.0.0.1) からのみ接続ができるようになっています。
以下の SQL を実行することで、リモートからも DAC による接続が可能となります。

?

DAC ですがクラスタ環境の場合、ローカルの接続でもリモート DAC が有効になっていないと接続することができません。
このことは BOL にも記載されています。

?

DAC の接続ですが、SQL Server Browser サービスが起動しているかによって接続方法が変わってきます。

[SQL Server Browser サービスが起動している場合]

こちらは前回の投稿で記載した接続方法になります。
接続先のサーバーとして、[ADMIN:<サーバー名><インスタンス名>] を指定することで接続ができます。

[SQL Server Browser サービスが起動していない場合 ]

SQL Server Browser サービスが起動していない状態で [ADMIN:～] で接続をすると、以下のエラーとなります。

ADMIN: での接続は DAC で使用しているポートを SQL Server Browser サービスに問い合わせています。
# DAC のポートは動的ポートのため、起動毎にポートが変更されます。
サービスが起動していないとポートがわからないため接続することができません。

DAC に割り当てられているポートは [ERRORLOG] ファイルに出力されています。
# ERRORLOG は SQL Server のインスタンスのインストールディレクトリの [Log] ディレクトリに出力されています。

このファイルをテキストエディタで開くと以下のような出力があります。

この行に DAC のポート番号が出力されています。
今回の場合は [50743] となっています。

ローカルから接続する場合、サーバー名の指定は [127.0.0.1,<ポート番号>] になります。
# 対象インスタンスの DAC のポートを直接指定するため、インスタンス名は不要です。

リモートから接続する場合は、[<サーバー>,<ポート番号>] になります。

DAC を使用して何か障害を解決したということは今のところないのですが、接続方法は知っておくと
障害発生時に便利かと。

このところ SQL Server をインストール以外触っておらず、データベース管理者としてのスキルが右肩下がりです…。
このままでは SQL Server のデータベース管理者としてお先真っ暗となってしまいますので、小さなことでもコツコツと
投稿していきたいと思います。

思い立った初回は SQL Server 2005 以降でシステムテーブルを直接更新する方法を投稿したいと思います。

SQL Server 2000 までは sp_configure で [allow updates オプション] を設定することでシステムテーブルを
直接更新することが可能でした。

SQL Server 2005 以降の Books Online では allow update オプションの説明は以下のように記載されています。
# 今回は SQL Server 2008 で検証をしていますが、2005 でも同様の動作となります。

?

実際に SQL Server 2008 で? allow updates を設定すると以下の実行結果となります。

?

RECONFIGURE をするとエラーとなります。
RECONFIGURE WITH OVERRIDE することで設定ができます。

この状態で、sysdatabases のようなシステムテーブルに更新をかけると以下のようなエラーとなります。
# SQL Server 2005 以降では sysdatabases は下位互換のシステムビューで実体は master.sys.sysdbreg だったりしますが。

?

SQL Server 2005 以降でシステムテーブルを更新するには以下の手順を実行して SQL Server に接続する必要があります。

1. SQL Server をシングルユーザーモードで起動
2. 専用管理者接続 (DAC) で接続

[シングルユーザーモードで起動する方法]

シングルユーザーモードで起動する前に、SQL Server 関連のサービスをすべて停止しておきます。
シングルユーザーモードはその名の通り、一人しか接続ができないモードですので SQL Server Agent や、
SSRS / SSIS / SSAS が起動していると、それらのサービスが SQL Server に接続してしまい、データベースエンジンクエリで
接続ができなくなってしまいます。
シングルユーザーモードで起動した後に、接続をしようとして エラー 18461 が発生する場合は、SQL Server 以外の
関連サービスを停止して確認をした方がよいと思います。

シングルユーザーモードはコマンドプロンプトで SQL Server を実行することで起動できます。

?

[DAC で接続]

DAC で接続する場合は接続時にサーバー名に [ADMIN:] をつけて接続をします。
今回はサーバーで直接作業をしています。
# リモートで DAC を使用することも可能ですがその場合は別の設定をする必要があります。

これでシステムテーブルを更新する準備は完了です。
allow updates は SQL Server 2005 以降では無効なオプションですので、設定をしなくてもシステムテーブルを
更新することが可能です。

試しにシステムテーブルを直接更新してデータベースをエマージェンシー (緊急) モードに設定したいと思います。
sysdatabases / sys.database はビューですので、各ビューの実体である sysdbreg テーブルを直接更新しています。
# use mssqlsystemresource を実行してリソースデータベース上で更新をしようとするとエラーとなりますので
　 カレントデータベースは master データベース等で実行する必要があります。

# ビット演算で status にエマージェンシーモードに対応するビットを有効にしています。

下が SQL 実行後の状態になります。
ALTER DATABASE ではなく、システムテーブルの直接更新でエマージェンシーモードに切り替わっています。

確認ができたのでシステムテーブルを更新できる状態にして以下の SQL を実行して正常な状態に戻しておきます。

?

以上でシステムテーブルの更新方法は終了です。
使うことがあるかはわかりませんが、奥の手として知っておくと便利な時があるかも知れません。

Windows Server 2008 AD DS を Windows Server 2008 R2 AD DS に移行し、2008 AD DS を
降格させたときに Exchange Server 2010 RC の管理コンソール (EMC) を開くと Active Directory の
0x51 のエラーが発生してしまう件ですが、Exchange 2010 を OS 毎入れなおしたところ、
エラーが発生しなくなりました…。

再度 2008 AD DS をインストールして、降格させたところ現象が再現。

Set-ExchangeServer コマンドレットの、StaticDomainControllers / StaticConfigDomainController
StaticExcludedDomainControllers / StaticGlobalCatalogs を設定しても解決しませんでした。

また、AD の構成パーティションに情報が残っているのかと思って ldifde で構成パーティションを
エクスポートして一通り調べてみたのですが、2008 AD DS の情報は残っていませんでした。

他のユーザーで EMC を実行したところ、エラーが発生しなかったのでユーザー固有の問題かと思って、
エラーが発生しているユーザーのプロファイルを削除して、再度 EMC を実行したらエラーが発生しなくなりました。

Exchange や AD 側の問題ではなく、ユーザープロファイルの中に何か情報が残ってしまっていたのでしょうか？？
具体的な解決策までたどり着いていないのですがメモとして残しておきたいと思います。