SE の雑記

Windows Server 2008 SP2 で AD DS と Exchange Server 2007 の共存環境を構築しようとした場合、
環境によってはインストール中に以下のエラーが発生することがあります。
# SP2 でなくてもエラーにはなると思います。私が試した環境はたまたま、OS が SP2 でした。

[Microsoft Exchange Transport] サービスが起動できないためにエラーとなるようです。

最初は以下の現象が発生したのかと思ったのですが、Exchange Server 2007 SP2 の場合は、対象のアセンブリの
構成ファイルで [<generatePublisherEvidence enabled="false" />] は設定されているみたいなんですよね。
Exchange Server 2007 用更新プログラムのロールアップをインストールすると Exchange Server 2007 マネージ コード サービスが開始されない

いろいろ調べていたところ、TechNet Magazine? 2008 年 11 月の以下の記事に解決策が載っていました。
# 最後の QA が今回の現象に該当します。

Outlook Anywhere と IPv6、リモート接続アナライザなど

ドメインコントローラーと Exchange Server 2007 を共存させたときは、IPv6 を有効にしておく必要があるようですね。
今回は Exchange Server 2007 SP2 をインストールしようとしたのですが、本現象は発生しました。
OS の基本セットアップ終了後は IPv6 を無効にするようにしているのですがそれが裏目に出てしまったようです。
IPv6 を有効にするとインストールも正常に完了します。

最初はドメインコントローラーと Exchange Server 2007 の共存がサポートされていないのかと思っていたのですが、
この構成はセキュリティの面から推奨はされないがサポートされる構成のようです。

Exchange 2007 のシステム要件

記載されている内容が微妙なんですよね…。
以下のように記載されているので一見、NG なのかと思えば、

Windows Server 2008 を実行するサーバーに Exchange 2007 RTM をインストールすることはできませんが、 Exchange 2007 RTM は Windows Server 2008 ディレクトリ サーバーとの併用をサポートしています。同様に、Exchange Server 2003 Service Pack 2 (SP2) は、Windows Server 2008 を実行するコンピュータには ンストールできません。 ただし、Windows Server 2008 ディレクトリ サーバーとの併用はサポートされています。

?

セキュリティとパフォーマンス上の理由から、Exchange 2007 をメンバ サーバーにのみインストールし、 Active Directory ディレクトリ サーバーにはインストールしないことをお勧めします。 ディレクトリ サーバーへの Exchange 2007 のインストールはサポートされていますが、 インストールしないことを強くお勧めします。

?

と記載されている個所も。
併用というのはおそらく、Windows Server 2008 のドメインコントローラーを認証基盤として使えるかということだと
思うのですが、表現がいまいちわかりにくいです。
# Exchange 2000 が併用不可となっているので有効なドメインコントローラーになりえるかということだとは思うのですが。

以下の KB もあるようですので、再起動時にサービスの手動起動が必要になる可能性もあるようですね。

グローバル カタログ サーバーに Exchange 2007 または Exchange Server 2010 をインストールすると、Exchange 2007 または Exchange Server 2010 のサービスが自動的に開始できない

できればドメインコントローラーと Exchange は別立てにしたいですがお客様の費用や規模によっては共存せざるを得ないことも
あるかと思います。
# EBS 2008 での提案というのもありかとは思うのですが。

そのようなときの注意事項のメモとして。

2010/4/21 追記

ドメインコントローラー以外でも IPv6 が無効になっていると現象が発生しますね…。
本現象は AD DS にかかわらず以下の KB が当てはまるようです。

Windows Server 2008 ベースのコンピューターで、Exchange Server 2007 のハブ トランスポートの役割または Microsoft Exchange Server 2010 のハブ トランスポートの役割のインストールが失敗する

AD DS でも上記 KB の対応をすれば、IPv6 が無効でもインストールできます。

ここまでの設定でデータベース可用性グループを設定して対象のサーバーを追加するところまでは作業が完了しました。

最後にメールボックスデータベースを DAG でレプリケーションされるように設定します。

1. 対象のメールボックスデータベースを右クリックして、[メールボックス データベース コピーを追加] をクリックします。
   今回は、EXCHANGE-01 に MB01 を EXCHANGE-02 に MB02 を配置しています。
   
2. [参照] をクリックします。
   
3. サーバーを選択して、[OK] をクリックします。
   
4. [追加] をクリックします。
   
5. [終了] をクリックします。
   

これで DAG の設定は完了です。
データベースコピーにサーバーが 2 台設定されているのが確認できます。

?

データベース コピーは両サーバーで同一のディレクトリに設定されるようです。
コピーを作成するサーバーで同一のディレクトリが作成できない場合は、エラーになるようです。

EXCHANGE-02 にしか存在していない E ドライブに設定しているメールボックスデータベースを EXCHANGE-01 にコピーとして
設定した場合の画像が以下になります。

DAG の設定は以上で終了です。

DAG ですが WSFC の技術を使っていますので、AD 上にコンピュータアカウントと、DNS の登録がされるようです。
?

クラスタサービスとしてはメールボックス等は登録されておらず、フェールオーバークラスタの管理から見れるのは、
クラスタコアリソースだけのようですね。
クラスタの管理は、フェールオーバー クラスタ マネージャからではなく Exchange 管理コンソール (EMC) から行う形になるかと。

DAG 内のメールボックスのレプリケーションに使用するネットワークの設定は (EMC)? からできるようです。
ネットワーク負荷を考慮するとサービス用 / レプリケーション用 / WSFC ハートビート用の NIC が必要になるかもしれないですね。
?

Exchange Server 2010 から、可用性をもつ MBX と CAS / HUB が共存できるようになったのですが、WSFC と NLB は
共存できないため、機能の共存環境で CAS を冗長化させるためにはハードウェアロードバランサが必要となりそうです。

Exchange 2007 と比較して簡単に可用性を持つメールボックスデータベースを構築できますが、ディスク容量やネットワークに関しては
2010 用に考える必要がありそうですね。

時間がある時に CAS アレイも勉強したいとは思いますが DAG の設定はここまでで。

今回の環境は自習書を参考にしながら構築してみました。
Exchange Server 2010 自習書シリーズ

作成したデータベース可用性グループにメンバーを追加したいと思います。

1. 作成した DAG を右クリックして、[データベース可用性グループのメンバーシップの管理] をクリックします。
   
2. [追加] をクリックします。
   
3. 追加するサーバーを選択して、[OK] をクリックします。
   
4. [管理] をクリックし、サーバーを登録します。
   
5. [終了] をクリックします。
   

これで DAG のメーンバーにサーバーを追加できました。

構成を何度か試していたのですが、たまにメンバーの追加で 2 台目のサーバーだけエラーになることがあるんですよね。

US の TechNet のフォーラムでもエラーになることはあることが投稿されていました。
?Problem adding a second server to DAG (Error: Cluster API ‘"AddClusterNode() (MaxPercentage=12) failed with 0x80070005. )

可用性グループの再作成、Exchange 管理コンソールを再起動したりと何度かやり直していたところ、正常に追加できるようになりました。
[Organization Management] グループのユーザーだと駄目なのかと思っていたのですが、権限は特に付与しなくても
追加できたので権限系でエラーになっているわけでもなさそうなのですが。

メンバーを追加するタイミングで監視サーバーにディレクトリが作成されます。

共有ディレクトリも設定されていますね。

監視サーバーは WSFC の [ノードおよびファイル共有マジョリティ] で使用される、[ファイル共有監視] として使用されます。
WSFC の設定状況は、DAG の設定が一通り完了したら改めてみてみたいと思います。

これでメンバーの設定は完了です。

最後にメールボックスデータベースのコピーを設定します。
こちらは次の投稿で。

2 台構成の Exchange 環境ができましたので DAG を設定します。

Exchagne Server 2007 では高可用性のソリューションがいくつかありましたが Exchange Server 2010 では、
Database Availability Group (DAG) 1 種類となりました。

WSFC とメールボックスのレプリケーションを組み合わせた設定になるようですね。
設定をしながらクラスタがどのように構築されているのか確認していきたいと思います。

今回は AD 1 台 （EXCHANGE-AD) と Exchange 2 台 (EXCHANGE-01 / EXCHANGE-02) の環境で構築をしています。
DAG の監視サーバーとしては、AD を使用したいと思います。

?

1. ドメインの [Exchange Servers] [Exchange Trusted Subsystem] に [EXCHANGE-AD] を追加します。
   
2. ドメインの [Builtin] コンテナ の [Administrators] に [Exchange Trusted Subsystem] グループを追加します。
   # 監視サーバーの [BUILTINAdministrators] に [Exchange Trusted Subsystem] を追加する必要があります。

   各Exchange の [Administrators] グループにはインストール時に [Exchange Trusted Subsystem] と
   [Organization Management] ドメイングループが追加されているようですね。

   

3. Exchange Management Console を起動します。
4. [組織の構成] → [メールボックス] を選択します。
5. [データベース可用性グループの新規作成] をクリックします。
   
6. [データベース可用性グループ名] を入力し、[新規作成] をクリックします。
   ?
   監視ディレクトリを明示的に設定しないと、[C:DAGFileShareWitnesses<DAG 名の FQDN>] が
   設定されるようです。
7. [終了] をクリックします。
   

まずは管理グループの作成が終了しました。

この時点では監視サーバー上にディレクトリは作成されないようです。

続いてクラスタ IP を設定します。

1. [Exchange Management Shell] を実行します。
   
2. 以下のコマンドを実行して作成し、DAG に対して IP アドレスを設定します。
   

   Set-DatabaseAvailabilityGroup -Identity DAG01 -DatabaseAvailabilityGroupIpAddresses 172.23.0.10

上記コマンドを実行し、IP を設定していないと DAG にメンバーを追加した際に以下のエラーとなります。

Error 0x6f7 (スタブは正しくないデータを受信しました。) from cli_RpccCreateCluster

これで DAG にメンバーを追加するまでの設定は完了です。
次の投稿でメンバーの追加作業をまとめたいと思います。

Exchange 2010 の DAG を勉強しようと思い、Exchange 2010 の新規インストールをしてみました。
最近はアップグレードばかりで新規インストールの方法をすっかり忘れていました…。

今回は、AD / Exchange 共に Windows Server 2008 R2 で構築しています。
コマンドは基本的に管理者として実行します。

1. Active Directory の準備
   Exchange? Server 2010 のインストールメディアを AD DS にセットし、以下のコマンドを実行します。
   [Schema Admin] と [Enterprise Admin] の権限が必要かと。
   
   

   setup.com /ps setup.com /p /OrganizationName:<組織名>

2. Exchane Server 2010 に必要な役割 / 機能のインストール
   Exchange Server 2010 のインストールメディアを Exchange 用サーバーにセットし、以下のコマンドを実行します。
   Windows Server 2008 R2 では ServerManagerCmd は推奨されていませんが、一括で役割をインストールできるのは
   便利ですね。
   役割 / 機能のインストールが終了したら再起動します。
   
   

   ServerManagerCmd ?inputpath D:ScriptsExchange-Typical.xml

3. Net.Tcp Port Sharing Service の自動化
   Net.Tcp Port Sharing Service がデフォルトでは [手動] となっているので、[自動] に設定します。
   SC コマンドで自動化してみました。?
   

   sc config NetTcpPortSharing start= auto

4. 2007 Office System コンバータ：Microsoftフィルタ パック のインストール
   以下の URL から 2007 Office System コンバータ：Microsoftフィルタ パック をダウンロードしインストールします。
   http://go.microsoft.com/fwlink/?LinkId=123380

   

5. 言語パックバンドルのダウンロード
   今回の環境はインターネットに接続されていない環境のため、以下の URL から言語パックバンドルをダウンロードしておきます。
   http://go.microsoft.com/fwlink/?LinkId=147077
   
6. Exchange Server 2010 のインストール
   Exchange Server 2010 をインストールします。
   Exchange のインストールを実施するアカウントは [Organization Management] または [Domain Admins]
   ドメイングループのメンバーの必要があります。
   
   1. [Exchange 言語オプションの選択] をクリックします。
      
   2. [言語バンドルからすべての言語をインストールする] をクリックします。
      
   3. [ハード ドライブまたはネットワーク共有上の言語ファイルのパスを指定する] を選択して、
      ダウンロードした言語パックを参照し、[次へ] をクリックします。
      
   4. [完了] をクリックします。
      
   5. [Microsoft Exchange のインストール] をクリックします。
      
   6. [次へ] をクリックします。
      
   7. [使用許諾契約書に同意します] を選択し、[次へ] をクリックします。
      
   8. エラー報告を設定し、[次へ] をクリックします。
      
   9. [Exchange Server のカスタム インストール] を選択して、[次へ] をクリックします。
      
   10. インストールする役割を選択して、[次へ] をクリックします。
       まずは 1 台構成でインストールをします。
       2010 からフェールオーバークラスタのインストールはセットアップで実行しなくなっているんですよね。
       mstep で Exchange 2010 を受講したときに始めて知りました。
       
   11. Outlook 2003 の使用有無の設定をして、[次へ] をクリックします。
       
   12. CAS の外部ドメイン名を設定して、[次へ] をクリックします。
       
   13. CEIP の設定をして、[次へ] をクリックします。
       
   14. 前提条件の確認が終了したら、[インストール] をクリックします。
       
   15. [終了] をクリックします。
       ?

以上で、インストール完了です。
今回は DAG の構成を作りたいため、同様の作業をもう一台のサーバーで実行して Exchange を追加します。

まずは 2 台構成の環境ができました。
これで DAG を設定するための下準備は完了です。
次の投稿で DAG を設定してみたいと思います。

SQL Server のクラスタ構成では Is Alive のチェックで定期的な間隔 (デフォルトは 1 分) で

SELECT @@servername

が実行され、クラスタリソースの起動状況の確認がされます。

Windows Server 2003 上で SQL Server を MSCS で構築した場合は、Is Alive のチェックには、
クラスタサービスのサービスアカウント (ドメインユーザー) が使用されていました。
そのため、SQL Server のログインからクラスタのサービスアカウントを消してしまうとリソースが
起動できなくなります。

Windows Server 2008 の WSFC では、クラスタのサービスの起動アカウントはドメインユーザーではなく、
ローカルシステムアカウントで起動されます。

Windows Server 2008 だと、Is Alive のチェックはローカルシステムアカウントで実行されているのか
気になって調べてみました。

手っ取り早く調べるため、SQL Server Profiler を実行して確認してみました。

WSFC + SQL Server ではローカルシステムアカウントで Is Alive のチェックが実行されているようですね。

クラスタのサービスアカウントでチェックがされるという動作は WSFC でも変わらないようです。

すこし時間が空いてしまいましたが、件数を絞って削除するパターンで時間を計測してみたいと思います。

今回のテスト用のテーブルには date 型のフィールドを設定しています。

レコード削除時に日付を指定して削除を実行してみます。

– TOP を指定しないで範囲削除 –

SET NOCOUNT ON USE [WORK] DELETE FROM ??? [dbo].[Tbl1] WHERE ??? [Col3] BETWEEN ‘2040-01-01’ AND ‘2100-12-31’

– 削除の処理時間 –

1 回目	11 秒
2 回目	10 秒
3 回目	14 秒

?

続いて TOP と ROWCOUNT を指定して削除してみます。

– 10,000 件ずつ削除 –

SET NOCOUNT ON USE [WORK] WHILE(0=0) BEGIN ??? DELETE TOP(10000) ??? FROM ??????? [dbo].[Tbl1] ??? WHERE ??????? [Col3] BETWEEN ‘2040-01-01’ AND ‘2100-12-31’ ??? IF @@ROWCOUNT = 0 ??? BEGIN ??????? BREAK ??? END END

?

– 削除の処理時間 –

1 回目	28 秒
2 回目	23 秒
3 回目	20 秒

特定件数ずつ削除したほうが遅いですね。

単純復旧モデルでチェックポイントを明示的に発生させながら、ログを切り捨てる場合以外は、
件数を指定して削除させるメリットはないかもしれないですね。

今まで処理効率が良いのかなと考えていたのですが違っていたようで。

SQL Server 2005 以降では DELETE TOP と ROWCOUNT を使用してループの中で指定した件数ずつ
削除することができるようになっています。
# 2000 では SET ROWCOUNT で実施できますね。

一度の DELETE で一括削除した場合と TOP で指定した件数ずつ削除していった場合でどれくらい
処理時間に差がでるか気になったので試してみました。

まずは全件削除をした場合から。
# TRUNCATE でページのビットマップを解除するのが一番早いですが。

今回使用するテーブルのスクリプトは以下になります。

– テストテーブルのスクリプト –

USE [WORK] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[Tbl1]( ??? [Col1] [uniqueidentifier] NOT NULL, ??? [Col2] [nchar](4000) NULL, ??? [Col3] [date] NULL, CONSTRAINT [PK_Tbl1] PRIMARY KEY CLUSTERED ( ??? [Col1] ASC )WITH (PAD_INDEX? = OFF, STATISTICS_NORECOMPUTE? = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS? = ON, ALLOW_PAGE_LOCKS? = ON) ON [PRIMARY] ) ON [PRIMARY] GO CREATE NONCLUSTERED INDEX [IX_Tbl1] ON [dbo].[Tbl1] ( ??? [Col3] ASC )WITH (PAD_INDEX? = OFF, STATISTICS_NORECOMPUTE? = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS? = ON, ALLOW_PAGE_LOCKS? = ON) ON [PRIMARY] GO

?

今までは GUID と nchar の単純なテーブルだったのですが、今回は date を追加して、非クラスタ化インデックスを
設定しています。

こちらのテーブルデータを挿入します。
# 復旧モデルを単純にしてログを自動切り捨てにし、断片化を解消しています。

– データの挿入 –

SET NOCOUNT ON USE [WORK] ALTER DATABASE [WORK] SET RECOVERY SIMPLE TRUNCATE TABLE [dbo].[Tbl1] DECLARE @i INT = 0 DECLARE @date date = ‘2000-01-01’ WHILE (@i < 50000) BEGIN ??? INSERT INTO [dbo].[Tbl1] VALUES (NEWID(), NCHAR(@i), DATEADD(day, @i, @date)) ??? SET @I += 1 END ALTER INDEX [PK_Tbl1] ON [dbo].[Tbl1] REBUILD ALTER INDEX [IX_Tbl1] ON [dbo].[Tbl1] REBUILD

?
各削除の処理を実行する前に、チェックポイントとキャッシュのクリアしてから処理時間を計測しています。

– チェックポイントとキャッシュのクリア –

CHECKPOINT DBCC FREEPROCCACHE DBCC DROPCLEANBUFFERS

?

この状態でデータを一括削除してみます。

– データの一括削除 –

SET NOCOUNT ON USE WORK DELETE FROM [dbo].[Tbl1]

?

実行にかかった時間が以下になります。
処理時間は3 回計測しています。

– データの一括削除の処理時間 –

1 回目	16 秒
2 回目	15 秒
3 回目	13 秒

?

次は TOP と ROWCOUNT を使用して 1,000 件ずつ削除してみます。

– 1,000 件ずつ削除 –

SET NOCOUNT ON USE WORK WHILE(0=0) BEGIN ??? DELETE TOP(1000) FROM [dbo].[Tbl1] ??? IF @@ROWCOUNT = 0 ??? BEGIN ??????? BREAK ??? END END

?

– 1,000 件ずつ削除した場合の処理時間 –

1 回目	1 分 41 秒
2 回目	1 分 42 秒
3 回目	1 分 39 秒

?

1,000 件ずつ削除するとかなり処理が遅くなっていますね。

削除件数を増やして試してみました。

– 10,000 件ずつ削除した場合の処理時間 –

1 回目	13 秒
2 回目	13 秒
3 回目	21 秒

– 20,000 件ずつ削除した場合の処理時間 –

1 回目	9 秒
2 回目	14 秒
3 回目	15 秒

– 30,000 件ずつ削除した場合の処理時間 –

1 回目	13 秒
2 回目	17 秒
3 回目	15 秒

– 40,000 件ずつ削除した場合の処理時間 –

1 回目	7 秒
2 回目	13 秒
3 回目	16 秒

今まで、件数を絞って複数回削除したほうが早いのかとなんとなく思っていたのですがそれほど差は出ないみたいです。
# あまりにも細かい件数で削除すると処理時間が劣化するのはわかっていたのですが。

途中でトランザクションログを切り捨てるためにチェックポイントを発生させたい場合や、トランザクションの
セーブポイントを作りたい場合以外は件数を絞る必要はないかもしれないですね。

次は件数を絞って削除した際の比較をしてみたいと思います。

SQL Server のデータベースバックアップですが、完全バックアップではトランザクションログの切り捨てはされません。
トランザクションログの切り捨てを行うためには、トランザクションログのバックアップまたは、復旧モードを [単純] に
設定する必要があります。
ただし例外が一つだけあり、初回のデータベースバックアップ時にはトランザクションログが切り捨てられるようです。
まずはデータを挿入して、トランザクションログが使用されている状態にしてみました。
– トランザクションログの使用状況の取得 –

DECLARE @logspace TABLE( ??? DatabaseName sysname, ??? LogSize int, ??? LogSpaceUsed int, ??? Status int ) INSERT INTO @logspace EXEC (‘DBCC SQLPERF(”LOGSPACE”)’)SELECT * FROM @logspace WHERE DatabaseName = ‘WORK’

?
– 実行結果? –

DatabaseName	LogSize	LogSpaceUsed	Status
WORK	110	77	0

?
現在は 110 MB のトランザクションログに対して 77 % が使用されている状況です。
完全バックアップはまだ取得していませんので、差分バックアップのベース LSN も設定はされていません。
– 差分バックアップのベース LSN の取得 –

SELECT ??? [file_id], ??? [name], ??? [differential_base_lsn] FROM ??? [sys].[master_files] WHERE ??? [database_id] = DB_ID(N’WORK’)

?
– 実行結果? –

file_id	name	differential_base_lsn
1	WORK	NULL
2	WORK_log	NULL

?
それでは初回の完全バックアップを取得してみます。
– 完全バックアップの取得 –

BACKUP DATABASE [WORK] TO? DISK = N’C:Program FilesMicrosoft SQL ServerMSSQL10.SQL2008MSSQLBackupWORK.bak’ WITH FORMAT, INIT,? NAME = N’WORK-完全 データベース バックアップ’, SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10 GO

?
バックアップ取得後に DBCC SQLPERF(‘LOGSPACE’) を実行して再度、トランザクションログの使用状況を取得します。
– 実行結果 –

DatabaseName	LogSize	LogSpaceUsed	Status
WORK	110	3	0

?
初回のバックアップではログが切り捨てられているのが確認できます。
# 77 % の利用から 3 % の利用となっています。
完全バックアップを取得したので、差分バックアップのベース LSN も設定がされています。
– 実行結果? –

file_id	name	differential_base_lsn
1	WORK	62000000412300000
2	WORK_log	NULL

?
この状態で再度データを挿入して、データベースのバックアップを取得し、ログの使用状況を確認してみます。
– 実行結果 (バックアップの取得前) –

DatabaseName	LogSize	LogSpaceUsed	Status
WORK	110	79	0

?
– 実行結果 (バックアップの取得後) –

DatabaseName	LogSize	LogSpaceUsed	Status
WORK	110	79	0

?
– 実行結果 (バックアップ取得後の差分バックアップのベース LSN) –

file_id	name	differential_base_lsn
1	WORK	100000000353400043
2	WORK_log	NULL

?
2 回目以降の完全バックアップではトランザクションログの切り捨てはされていないことが確認できます。
差分バックアップのベース LSN は完全バックアップを取得したので更新されています。
# バックアップを取得したことをあらわそうと思い情報を取得しています。
トランザクションログのバックアップは完全バックアップが存在していない状況では取得することができません。
初回の完全バックアップではそれまでのトランザクションログのバックアップが存在しておらず、トランザクション
ログの切り捨てが行われてもログチェーンとしては問題がないためこのような動作になっているのかと。
SQL Server に慣れていない人が完全バックアップでトランザクションログが切り捨てられると考えてしまう理由が、
この動きにあるのかな～と電車の中でふと思ったので投稿してみました。
2010/12/9 追加
SQL CAT のブログで本件について記載されていました。
Transaction Log size does not match the size of the data being loaded.

ページの情報を確認するための DBCC コマンドとして、[DBCC PAGE] があります。

このコマンドですが、非公開 DBCC コマンドですのでヘルプを確認するためには以下のコマンドを実行します。

– ヘルプの確認 –

DBCC TRACEON(2588) DBCC HELP(‘PAGE’) DBCC TRACEOFF(2588)

?

– ヘルプの内容 –

dbcc PAGE ( {’dbname’ | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])

?

プリントオプションの設定は以下のなります。

• 0 : ページヘッダのみ表示
• 1 : ページヘッダ + データ部を表示
• 2 : ページヘッダ + データ部を 16 進数のダンプで表示
• 3 : 各行を個別に出力

DBCC PAGE でページ情報を出力するためには、トレースフラグ 3604 を有効にする必要があります。

試しに DCM のページ情報を出力してみたいと思います。

– ページ情報の取得 –

DBCC TRACEON(3604) DBCC PAGE (N’WORK’, 1, 6, 1) DBCC TRACEOFF(3604)

?

– 実行結果 –

PAGE: (1:6) BUFFER: BUF @0x00000000AAFD2A00 bpage = 0x00000000AA4A8000?????????? bhash = 0x0000000000000000?????????? bpageno = (1:6) bdbid = 5??????????????????????????? breferences = 0????????????????????? bUse1 = 33908 bstat = 0x2c00009??????????????????? blog = 0x9a212159??????????????????? bnext = 0x0000000000000000 PAGE HEADER: Page @0x00000000AA4A8000 m_pageId = (1:6)???????????????????? m_headerVersion = 1????????????????? m_type = 16 m_typeFlagBits = 0x0???????????????? m_level = 0????????????????????????? m_flagBits = 0x200 m_objId (AllocUnitId.idObj) = 99???? m_indexId (AllocUnitId.idInd) = 0??? Metadata: AllocUnitId = 6488064 Metadata: PartitionId = 0??????????? Metadata: IndexId = 0??????????????? Metadata: ObjectId = 99 m_prevPage = (0:0)?????????????????? m_nextPage = (0:0)?????????????????? pminlen = 90 m_slotCnt = 2??????????????????????? m_freeCnt = 6??????????????????????? m_freeData = 8182 m_reservedCnt = 0??????????????????? m_lsn = (15522:2954:10)????????????? m_xactReserved = 0 m_xdesId = (0:0)???????????????????? m_ghostRecCnt = 0??????????????????? m_tornBits = -1654911162 Allocation Status GAM (1:2) = ALLOCATED??????????????? SGAM (1:3) = NOT ALLOCATED?????????? PFS (1:1) = 0x44 ALLOCATED 100_PCT_FULL DIFF (1:6) = CHANGED???????????????? ML (1:7) = NOT MIN_LOGGED??????????? DATA: Slot 0, Offset 0x60, Length 94, DumpStyle BYTE Record Type = PRIMARY_RECORD???????? Record Attributes =????????????????? Record Size = 94 Memory Dump @0x000000000B2EA060 0000000000000000:?? 00005e00 00000000 00000000 00000000 †..^…………. 0000000000000010:?? 00000000 00000000 00000000 00000000 †……………. 0000000000000020:?? 00000000 00000000 00000000 00000000 †……………. 0000000000000030:?? 00000000 00000000 00000000 00000000 †……………. 0000000000000040:?? 00000000 00000000 00000000 00000000 †……………. 0000000000000050:?? 00000000 00000000 00000000 0000††††††…………..?? Slot 1, Offset 0xbe, Length 7992, DumpStyle BYTE Record Type = PRIMARY_RECORD???????? Record Attributes =????????????????? Record Size = 7992 Memory Dump @0x000000000B2EA0BE 0000000000000000:?? 0000381f ffffffff ffffffff ffffffff †..8…………. 0000000000000010:?? ffffffff ffffffff ffffffff ffffffff †……………. 0000000000000020:?? ffffffff ffffffff ffffffff ffffffff †……………. ～ 省略 ～ 0000000000001F10:?? ffffffff ffffffff ffffffff ffffffff †……………. 0000000000001F20:?? ffffffff ffffffff ffffffff ffffffff †……………. 0000000000001F30:?? ffffffff ffffffff †††††††††††††††††††……..????????

?

[m_type = 16] となっていますので、このページは DCM です。

通常運用でページ情報を確認することはないと思いますが、差分バックアップや一括ログ操作の動作を確認するときには、
ページ情報を確認すると理解しやすくなります。
バックアップに関してはどこかのタイミングで投稿したいと思っていますので、その際に DCM / BCM についても
記載していきたいと思っています。