SE の雑記

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

ルーターの勉強用に YAMAHA の RTX1000 を購入しました。

ネットワークは苦手なので、この機会にいろいろと学習したいです。
まずは初期設定についてメモとして投稿しておきたいと思います。

RT シリーズのマニュアルは RTシリーズのマニュアル配布 で公開されています。
なお、最新のファームは ファームウェア配布ページ から入手可能です。
代表的な設定例に関しては 設定例集 が提供されています。

一通り、AD の移行が終わりましたので、今まで使用していた 2008 AD DS を撤去したいと思います。

[AD の降格]

AD の撤去は [dcpromo] から実施します。
AD CS 等、AD 関連の役割がインストールされている場合は事前に役割から削除しておく必要があります。

1. [ファイル名を指定して実行] から [dcpromo] を実行します。
   
2. [次へ] をクリックします。
   
3. [OK] をクリックします。
   
4. [次へ] をクリックします。
   
5. [このサーバーを指している DNS 委任を削除する] のチェックをはずして、[次へ] をクリックします。
   
6. パスワードを設定して、[次へ] をクリックします。
   
7. [次へ] をクリックします。
   
8. [完了時に再起動する] を有効にして、削除が終わるまで待ちます。
   

以上で既存ドメインコントローラーの降格は終了です。

この状態で Exchange Server 2010 RC に影響が出ないか確認をしてみたところ、以下のエラーが発生しました。

ひとまず、構成ドメイン コントローラーを変更してみました。

メールボックスの一覧等は表示できるようになったのですが、エラーが出る状況は変わらず。
どこかにドメインコントローラーの情報が残ってしまっているようです。

Exchange 2007 では正常に認識ができているのですが、2010 では NG です…。
仕方ないので、Exchange 2010 を再インストールしみたのですが状態は変わらず。

アンインストールしようとしたところいろいろと問題が発生して、以下の情報を参考にする必要がありました。
# メールボックスの削除とパブリックフォルダの削除がうまくできませんでした。

Exchange 2007 をコンピュータから削除する方法
Exchange 2010 – What is an arbitration mailbox?
Uninstall Exchange 2010

Exchange 2010 の RTM ももうじき TechNet からダウンロードできるようになると思いますので、
ダウロードできるようになったら RTM でも同様の現象が発生するのか試してみたいと思います。

検証環境のインフラ整備をそろそろしないといけないと思い、まずは AD の移行から着手してみました。
私の検証環境の AD は 2008 SP2 で構築してあるのですが、これを 2008 R2 に移行してみます。

ワークグループ環境の DNS として設定しているものもあるため、移行の方針としては

1. コンピュータ名は新規のもの
2. IP アドレスは最終的に現行の AD のアドレスに変更

で作業したいと思います。

[フォレストとドメインの準備]

2008 R2 を 2008 ドメインのドメインコントローラーとして追加するために、フォレストとドメインの準備をします。
下の画像は、フォレストの準備をする前 / 後 スキーマのバージョンになります。
# 左がコマンド実行前、右がコマンド実行後です。
[objectVersion] が [44] から [47] に変更されています。
?

1. 2008 のドメインコントローラーに Windows Server 2008 R2 のインストールメディアを挿入します。
2. 以下のコマンドを実行します。
   RODCPREP は以前実行していたか覚えていなかったので改めて実行しています。
   
   

   >DVD ドライブ >cd supportadprep >adprep.exe /forestprep >adprep.exe /domainprep /gpprep > adprep.exe /rodcprep 実行例) >D: >cd supportadrep >adprep.exe /forestprep ADPREP の警告: adprep を実行する前に、フォレスト内のすべての Windows 2000 Active Directory ドメイン コントローラーを Windows 2000 Service Pack 4 (SP4) 以降にアップグレードする必要があります。 [ユーザーによる操作] 既存の Windows 2000 Active Directory ドメイン コントローラーのすべてがこの要件を満たす場合は、C キーを押してから Enter キーを押して続行してください。中止するには、その他のキーを押してから Enter キーを押してください。 c xxxxxx への接続を開始しました SSPI 結合に成功しました 現在のスキーマのバージョン 44 スキーマをバージョン 47 にアップグレードしています ファイルの署名を検証しています "xxxxxx" に接続しています SSPI を使って現在のユーザーとしてログインしています ファイル "C:Windowssystem32sch45.ldf" からディレクトリをインポートしています エントリを読み込んでいます………………………………………………………… 66 個のエントリを正しく修正しました。 コマンドが正しく完了しました ファイルの署名を検証しています "xxxxxxx" に接続しています SSPI を使って現在のユーザーとしてログインしています ファイル "C:Windowssystem32sch46.ldf" からディレクトリをインポートしています エントリを読み込んでいます…. 3 個のエントリを正しく修正しました。 コマンドが正しく完了しました ファイルの署名を検証しています "xxxxxx" に接続しています SSPI を使って現在のユーザーとしてログインしています ファイル "C:Windowssystem32sch47.ldf" からディレクトリをインポートしています エントリを読み込んでいます….. 4 個のエントリを正しく修正しました。 コマンドが正しく完了しました "xxxxxx" に接続しています SSPI を使って現在のユーザーとしてログインしています ファイル "C:Windowssystem32PAS.ldf" からディレクトリをインポートしています エントリを読み込んでいます………….. 13 個のエントリを正しく修正しました。 コマンドが正しく完了しました ……………………………………………………………………. Adprep はフォレスト全体の情報を正しく更新しました。 >adprep.exe /domainprep /gpprep Domainprep を実行中… Adprep はドメイン全体の情報を正しく更新しました。 更新が必要なグループ ポリシー オブジェクト (GPO) はありません。または、GPO 情報は既に更新されています。 [状態/結果] Adprep はこの操作を再試行しませんでした。 >adprep.exe /rodcprep Adprep はドメイン FSMO に接続しました: xxxxxx。 Adprep は、パーティション DC=ForestDnsZones,DC=xxxxxx,DC=xxxxxに対して操作が実行されたことを検出しました。スキップして、次のパーティションに進みます。 =========================================================== Adprep は、パーティション DC=DomainDnsZones,DC=xxxxxx,DC=xxxxxx に対して操作が実行されたことを検出しました。スキップして、次のパーティションに進みます。 =========================================================== =========================================================== Adprep はパーティション DC=xxxx,DC=xxxx を検出しました。アクセス許可を更新しようとしています。 Adprep はインフラストラクチャ FSMO に接続しました: xxxxxx。 パーティション DC=xxxxx,DC=xxxxxx に対する操作は成功しました。 ====================================================== Adprep は問題なく完了しました。すべてのパーティションが更新されました。詳細については、C:Windowsdebugadpreplogs20091031130646 ディレクトリの ADPrep.log を確認してください。

[固定 IP と DNS の設定]

まずは、追加のドメインコントローラとして設定するために、既存の AD を参照先 DNS として設定して、
固定 IP を割り当てます。

最終的に、現行の AD の IP アドレスに変更するつもりですので、設定している IP は仮の IP になりますね。

では次に追加のドメインコントローラーとして設定します。

[ドメインコントローラーの追加]

1. [ファイル名を指定して実行] から [dcpromo] を実行します。
   
   サーバーマネージャで事前に、役割を追加していなくても dcpromo 実行時に自動でインストールをしてくれます。
   
2. [詳細モード インストールを使用する] を有効にして、[次へ] をクリックします。
   詳細モードは必ず有効にする必要があるわけではないですが、設定を確認したかったので今回は有効にしています。
   
3. [次へ] をクリックします。
   
4. [既存のフォレスト] [既存のドメインにドメイン コントローラーを追加する] を選択し、[次へ] をクリックします。
   
5. ドメイン名と追加のドメインコントローラーに設定するために使用するドメインアカウントの情報を入力し、
   [次へ] をクリックします。
   今回はワークグループの状態からドメインコントローラーとして追加しています。
   
6. 追加するドメインを選択し、[次へ] をクリックします。
   
7. 追加するサイトを選択して [次へ] をクリックします。
   
8. DNS と GC はデフォルトで有効になっているようです。
   今回は置き換えを目的としているので両方必要となります。
   デフォルト状態で [次へ] をクリックします。
   
9. [はい] をクリックします。
   
10. [次へ] をクリックします。
    
11. [次へ] をクリックします。
    
12. [次へ] をクリックします。
    
13. ディレクトリ復元モードのパスワードを設定し、[次へ] をクリックします。
    
14. [次へ] をクリックします。
    
15. [完了時に再起動する] を有効にしてインストールが完了するまで待ちます。
    

これでドメインコントローラーと DNS の追加が完了しました。

[FSMO の移行]

追加したドメインコントローラーに FSMO を移行します。
作業は追加したドメインコントローラー上で実行しています。

1. ドメイン名前付けマスターの移行
   1. [Active Directory ドメインと信頼関係] を実行します。
      
   2. [Active Directory ドメインと信頼関係] を右クリックして、[Active Directory ドメイン コントローラーの変更] を
      クリックします。
      
   3. 追加したドメインコントローラーを選択します。
      
   4. 再度右クリックして、[操作マスター] をクリックします。
   5. [変更] をクリックします。
      
   6. [はい] をクリックします。
      
   7. [OK] をクリックします。
      
   8. [閉じる] をクリックします。
2. RID / PDC / インフラストラクチャマスターの移行
   1. [Active Directory ユーザーとコンピューター] を実行します。
      
   2. ドメイン名を右クリックして、[操作マスター] をクリックします。
      
   3. [RID] タブを選択して、[変更] をクリックします。
      
   4. [はい] をクリックします。
      
   5. [OK] をクリックします。
      
   6. [PDC] タブを選択して、[変更] をクリックします。
      
   7. [はい] をクリックします。
   8. [OK] をクリックします。
   9. [インフラストラクチャ] を選択して、[変更] をクリックします。
      
   10. [はい] をクリックします。
   11. [OK] をクリックします。
3. スキーママスタの移行
   
   1. [ファイル名を指定して実行] で [regsvr32 schmmgmt.dll] を実行して、[OK] をクリックします。
      
   2. [mmc] を実行します。
   3. [ファイル] → [スナップインの追加と削除] をクリックします。
      
   4. [Active Directory スキーマ] を選択して、[追加] をクリックし、[OK] をクリックします。
      ?
   5. 右クリックして、 [Active Directory ドメイン コントローラーの変更] をクリックします。
      
   6. 追加したドメインコントローラーを選択して、[OK] をクリックします。
      
   7. [OK] をクリックします。
   8. [Active Directory スキーマ] を展開してから右クリックして、[操作マスター] をクリックします。
      
   9. [変更] をクリックします。
      
   10. [はい] をクリックします。
   11. [OK] をクリックします。
   12. [閉じる] をクリックします。

以上で FSMO の移行は完了です。

[IP アドレスの変更]

最初の AD の IP を変更して、追加した AD に割り当てられるようにしてみました。

1. 現行の AD の IP アドレスを変更します。
2. 現行の AD の 参照先 DNS を上で設定した IP に変更します。
3. 代替 DNS に変更前の IP を設定します。
   # このあと、追加した AD に変更前の IP を設定するため。
4. コマンドプロンプトで [ipconfig /registerdns] を実行します。

続いて追加した AD の IP を変更します。

1. 追加した AD の IP アドレスを、現行の AD の IP アドレスに変更します。
2. 追加
   した AD の参照先 DNS を上で設定した IP に変更します。

3. 代替 DNS に現行の AD の IP を設定します。
4. コマンドプロンプトで [ipconfig /registerdns] を実行します。

再起動後も AD DS のサービスは正常に動いているので、ひとまず変更は完了のようです。