SQL Server 開発チームブログ : Best Practice

SQL Server 2008 データウェアハウスシナリオ Tips and Tricks Part 3

koheiu — Thu, 20 Nov 2008 06:59:00 GMT

マイクロソフトの植田です。

引き続き「大規模データウェアハウス」シナリオ検証で得られたTipsや注意点についてご紹介していきたいと思います。

今回は「緩やかに変化するディメンジョン」への対処方法について説明したいと思います。

簡単に「緩やかに変化するディメンジョン」とは何かについて触れたいと思います。DWHシナリオでは、ディメンジョンの多くが時間の経過に伴って変化します。多くの場合それらの変化はファクトデータの変化に比べて緩やかで、徐々に起きる変化を反映するディメンジョンのことを、「緩やかに変化するディメンジョン」と呼びます。この時、ディメンジョンテーブルに生じた変化にどのように対処するか、によっていくつかのパターンがあります。主なパターンは以下に分類されます。例えば以下のようなレコードがあり、場所の移転に伴って店舗名称を「代々木店」から「新宿店」に変更するケースについて各パターンを考えてみます。

店舗テーブル

店舗コード	店舗名称	エリアコード
100	代々木店	1

1. タイプ1

変更があったデータを、新しいデータで上書きする方法です。変更後のレコードは以下のようになります。

店舗コード	店舗名称	エリアコード
100	新宿店	1

2. タイプ2

変更前と変更後の両方のデータを保持し、レコードの有効/無効を判断する列を追加する方法です。レコードの有効フラグ列を追加するパターンと、レコードの開始/終了日時を追加するパターンがあります。以下の例では、開始/終了日時の列に加え、一意性を表す代替キー（サロゲートキー）の列が追加されています。

店舗ID	店舗コード	店舗名称	エリアコード	開始日時	終了日時
1	100	代々木店	1	2005/10/1	2008/10/31
101	100	新宿店	1	2008/11/1

3. タイプ3

変更のあったデータの履歴をレコード内に保持し、変更があった日付を追加する方法です。レコードのサイズにより、保持できるデータ履歴の数が制限されます。複数の列が更新されるシナリオではレコードサイズが大きくなります

店舗コード	店舗名称（現）	店舗名称（履歴）	エリアコード（現）	エリアコード（履歴）	更新日時
100	新宿店	代々木店	1	1	2008/11/1

4. タイプ4

ディメンジョンテーブルは新しいデータで更新し、変更のあったレコードの履歴を別のテーブルで管理する方法です。このようにすると、保持できる履歴データの制限がなくなります。

店舗テーブル

店舗コード	店舗名称	エリアコード
100	新宿店	1

店舗履歴テーブル

店舗コード	店舗名称	エリアコード	更新日時
100	代々木店	1	2008/11/1

この他、全く対処しない場合（タイプ0）や、タイプ1, タイプ2, タイプ3を組み合わせたタイプ6（ハイブリッド）と呼ばれるものがあります。どのタイプを使用するべきか、についてはビジネス要件に依存します。そして、変化するディメンジョンへの対処方法によって、ディメンジョンテーブル、および、ファクトテーブルの設計に影響があります。例えばタイプ2を使用する場合はディメンジョンテーブルに、代替キーの列、および、開始/終了日時の列を追加する必要があります。加えて、ファクトテーブルのデータについても代替キーに変更する必要があります。上記の例では、ファクトデータの「店舗コード」を「店舗ID」で置き換える必要があります。

SQL ServerのIntegration Servicesを使用すると、上記のディメンジョンテーブルの変更をウィザードを利用して設定することができます。また、ファクトテーブルにおける代替キーとビジネスキーの変換も、「データフロータスク」において行うことが可能です。これらの設定方法に関する詳細は、公開予定のホワイトペーパーにて説明する予定です。今回、検証したシナリオでは変化するディメンジョンに対して、タイプ1とタイプ2を組み合わせたハイブリッド方式を採用しました。実装に関してはホワイトペーパーにて詳しく説明させて頂いているので、ここではどのようなビジネス要件が満たされるのか、簡単な例を見ていきたいと思います。

例えばファクトデータとして以下のようなレコードがあるとします。

売上テーブル

年月日	伝票番号	顧客ID	商品ID	店舗ID	担当者ID	売上高	支払コード
2007/12/23	1000235	302	50894	1	2024	200,000	1
2007/12/23	1000236	211	40031	2	3030	150,000	2
2007/12/24	1000237	512	8343	1	1113	320,000	2
：
2008/12/1	2100534	110	25211	101	1113	220,000	1
2008/12/1	2100535	25	76763	102	2350	150,000	1

ディメンジョンを表すテーブルとして前述の店舗テーブルを使用する場合、テーブルスキーマは以下のようになります。

店舗テーブル

店舗ID

店舗コード

店舗名称

（現）

店舗名称

（履歴）

エリアコード（現）

エリアコード（履歴）

開始日時

終了日時

100

新宿店

代々木店

2005/10/1

2008/10/31

101

100

新宿店

2008/11/1

NULL

上記のファクトデータを店舗ごとに集計する場合、移転があった店舗をどのように集計するかが問題となります。分析観点により複数の集計方法がありますが（例えば、移転の前後で別々の店舗として売り上げを集計する、または、同一の店舗とみなして集計する）、最も多い要望は、「移転の前後で分けた場合と、同一店舗とみなした場合の両方の集計を行う」というものです。この要望は上記の店舗テーブルの「店舗名称（現）」、「店舗名称（履歴）」をディメンジョンとする事で実現できます。

集計例

年度	店舗名称（現）	店舗名称（履歴）	売上合計
2007年度	新宿店	代々木店	40,782,050,000
2008年度	新宿店	代々木店	25,269,110,000
		新宿店	36,093,354,000
		合計	61,362,464,000

どのような観点に基づいてファクトデータを分析するかによって他にも方法があると思いますが、ここでは一例を取り挙げさせていただきました。ディメンジョンの変更に対して、どの方法を用いるのが良いかはディメンジョンのデータ特性、分析観点によると思いますが（例えば、顧客テーブルにおける名前の変更は集計に影響を当たる可能性が小さいのでタイプ1で処理する等）、今回説明させていただいた内容が何かの参考になれば幸いです。

SQL Server ベストプラクティス日本語版　Top 10 リストが追加されました（sqlcat.com）

koheiu — Thu, 30 Oct 2008 10:36:00 GMT

マイクロソフトの植田です。

米国のSQL Server Customer Advisory Team (CAT)　のWebサイト上で日本語に翻訳されたベストプラクティス　トップ１０のシリーズが追加されました。

今回追加された技術文書は以下になります。

· Analysis Servicesのクエリパフォーマンスに関するベスト　プラクティス　トップ１０

· ストレージに関するベスト　プラクティス　トップ１０

· 大規模リレーショナル　データウェアハウスを構築するためのベスト　プラクティス　トップ１０

· SAP向けのSQL Serverのメンテナンスに関するベスト　プラクティス

· OLTPアプリケーションに関するSQL Server 2005パフォーマンスの最もよくある問題

これらはCATのサイトでは「TOP10リスト」と呼ばれるもので、それぞれのトピックについて注意しなければならないポイントを簡単にまとめてあります。読むのにそれほど時間はかかりませんので、入門、または、設計の際のチェックリストとして利用できるのではないかと思います。詳細な部分までの説明になると、別の技術文書を読む必要があり、中には英語の文書しかないといったケースもあります。これらの文章も日本語でお届けしたいと考えていますが、すべての翻訳を一度に行うことはできませんのでご理解いただけると幸いです。

なお、日本のSQL Server BIBLEのサイトでも日本語に翻訳された技術文書がダウンロードできますのでこちらも合わせて利用してみてください。

SQL Server BIBLE（技術者必読情報）, SQL Server ベストプラクティス

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

SQL Server 2008 データウェアハウスシナリオ　Tips and Tricks Part 2

koheiu — Tue, 21 Oct 2008 08:41:00 GMT

I would like to introduce briefly how SSIS 2008 have achieved great performance on loading TB data into SQL Server database to Japanese users. Here is Japanese SQL Server development team’s blog…

マイクロソフトの植田です。

前回のポストに引き続き「大規模データウェアハウス」シナリオ検証で得られたTipsや注意点についてご紹介していきたいと思います。

今回はSQL Server Integration Serviceを使用したデータロードを取り上げたいと思います。データロードを行う局面はいろいろあると思いますが、ここでは初期ロードのパフォーマンスについてお話したいと思います。

米国のSQL Server パフォーマンスチームが今年の初めに行った検証では、わずか30分の間に1.18TBものデータをロードしたという結果が公開されています。

http://blogs.msdn.com/sqlperf/archive/2008/02/27/etl-world-record.aspx　

主なHW構成は以下のようになっています。

ü RDBMSサーバー（1台）

Ø Dual-coreのCPUを32機搭載（64コア）、256GB RAM

Ø 8ノードのハードウェアNUMA構成（1ノードあたりCPU8コア、32GB RAM）

Ø 各ノードが4GbitのDual-portのHBA、Giga-NICを搭載

Ø DB用ストレージには8スピンドルでRAID10を組んだLUNを17個使用

ü SSISサーバー（4台）

Ø Quad-coreのCPUを2機搭載（8コア）、4GB RAM

Ø 4Gbit Single-portのHBA×1、Giga-NIC×2

Ø フラットファイル用のストレージとして1GbitのFibre Channelで接続されたSANを使用

1TB、30分を実現するポイントは以下と考えています。

1. CPUコア数に応じて最適な同時実行多重度を決定し、CPUの利用効率をできるだけ高くする

2. SSISパッケージを別筐体で実行し、CPU負荷を分散させる

3. パーティション分割したテーブルを使用し、データロードをパーティション単位で行う

4. SSISサーバーと各NUMAノードを専用のネットワークで結び（1つのSSISサーバーは2つのNUMAノードに接続）、ノードの8つのCPU(コア)の内、1つをネットワーク処理専用に割り当て、ネットワーク負荷を軽減

Ø Soft-NUMAを構成し、1つのパーティションに対するデータロードが1つのCPU(コア)で行われるように設定する

ディスクの性能が低くない限り、一括データロードはCPUに負荷がかかる処理となります。一般的に、一つのデータロードプロセス（インスタンス）を一つのCPUで実行させるようにするのがベストプラクティスと言われています。上記の検証では56個のパーティションを用意し、56個のロードプロセスを同時に実行することにより最高のパフォーマンスを得ていました。64プロセスでない理由は、上記4に書かれているとおり、ノードあたり1つのCPU(コア)をネットワーク処理専用に割り当てているからです。また、SQL Server 以外にSSISパッケージを実行するDTExecのプロセスもCPUを消費します。従ってデータベースを保持するサーバーと、データロードを行うサーバーを分けた方がSQL Serverにより多くのCPUリソースを割り当てることができます。

データベースを保持するSQL Serverが動作するサーバーと、データロードを行うサーバーを別筐体に分けた場合、その間を結ぶネットワークがボトルネックになるケースが多く見られます。今回の検証では8つのネットワークインタフェースから効率的にデータが流れてくるように設計し、各ノードで1つのCPU（コア）がネットワーク処理（NICからの割り込み処理）を専門で行うように設定されています。この設定はWindows Server 2008、および、Interrupt-Affinity Policyツールを使用して行うことができます。Interrupt-Affinity Policyツールの詳細についてはWindows Hardware Developer CentralのWebサイトをご参照ください：Windows Hardware Developer Central。また、その他のCPU（コア）は同一ノード内のネットワーク処理専用CPU（コア）が受け付けたリクエストを処理するようにSoft-NUMAが設定されています。このように設定することにより、ネットワーク処理からローディング処理までを同一ノード内に局所化でき、オーバーヘッドが最小限に抑えられます。

Soft-NUMAの設定例

（CPUへのNUMAノードのマッピング）

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\NodeConfiguration\Node0]

"CPUMaks"=hex:01

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\NodeConfiguration\Node1]

"CPUMaks"=hex:02

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\NodeConfiguration\Node2]

"CPUMaks"=hex:04

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\NodeConfiguration\Node3]

"CPUMaks"=hex:08

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\NodeConfiguration\Node4]

"CPUMaks"=hex:10

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\NodeConfiguration\Node5]

"CPUMaks"=hex:20

：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\NodeConfiguration\Node62]

"CPUMaks"=hex:00,00,00,00,00,00,00,40

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\NodeConfiguration\Node63]

"CPUMaks"=hex:00,00,00,00,00,00,00,80

（TCP/IPポートへのNUMAノードのマッピング）

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.STAB1300_04\MSSQLSERVER\SuperSocketNetLib\Tcp\IPAll]

"TcpPort"="2000[0x00000001],2001[0x00000002],2002[0x00000004],2003[0x00000008],2004[0x00000010],2005[0x00000020],

…

2061[0x2000000000000000],2062[0x4000000000000000],2063[0x8000000000000000]"

"TcpDynamicPorts"=""

"DisplayName"="Any IP Address“

Soft-NUMAの設定方法の詳細についてはオンラインブックをご参照ください。

ソフトNUMAを使用するようにSQL Serverを構成する方法

NUMAノードにTCP/IPポートをマッピングする方法

上記のように設定することで、SSISパッケージにおいて接続先のTCPポートを指定することにより、データロードプロセスを実行するCPUを選択することができます。

SSISデータロードパッケージ実行例

(IPアドレス10．0．0．1のポート2001に接続)

DTExec.exe /Conn

ConnectionString;"Data Source=10.0.0.1,2001; Initial Catalog=TPCHdestination; Provider=SQLNCLI10.1; Integrated Security=SSPI; PacketSize=32767;AutoTranslate=False;"

/F "C:\SSISpackages\DataLoadStream.dtsx"

以上が1TBのデータを約30分でロード完了するためのポイントになりますが、これらの設定は今回のデータロードに特化してオプティマイズされており、実際の環境に適応するのはそれほど容易ではありません。また、インデックスの作成など、実際の運用では不可欠と思われる項目もカバーされていません。私たちが日本で行ったDWHの検証では構成を単純にし、データベースサーバーには4Way（Quad-core=16コア）の汎用的なマシンを使用して、SSISとSQL Server DBエンジンを同居させる構成でデータロードパフォーマンスを測定しています。詳しい内容については今後公開されるホワイトペーパーの中で扱う予定ですが、簡単に結果だけお伝えすると、1.12TB（12億件）のデータをロードする処理を97分で完了することができました。1秒あたりのパフォーマンスに換算すると約201KB/sec、約207,000件/secとなります。また、3つのクラスタ化インデックスを作成してデータロードを行う場合は、146分で全ての処理を完了することができました。

以上ご参考にしていただければ幸いです。

次回は「緩やかに変化するディメンジョン」を取り上げたいと思います。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

Hyper-V 環境における SQL Server 2008 のベストプラクティスとパフォーマンスの推奨事項

thoshi — Tue, 07 Oct 2008 14:12:00 GMT

マイクロソフトの星川です。

仮想化技術は現在の ITトレンドの中で非常に注目度が高く、その適用範囲もデスクトップ、サーバー、ネットワーク、ストレージと非常に幅広いです。様々なシナリオのひとつであるサーバー統合を例にとっても、管理コストの削減だけでなく、電力および冷房にかかるコスト削減につながります。また、開発・テストのシナリオは我々のような開発チームに効率化をもたらしてくれます。特に、最近は弊社から Windows Server 2008 Hyper-V をリリースし、SQL Server とHyper-Vを組み合わせた場合、実際のパフォーマンスはどうですか、という質問を受けるようになってきました。この疑問に対応するお勧めの技術ドキュメントが先日 US CAT Best Practice Testing チームから公開されたので紹介させていただきます。我々のチームと日頃から関係の深い部署になります。Appendixを含まなければ約30ページのボリュームで、現在ドキュメントの日本語翻訳を関係部署と進めております。今回は、参考までにイントロ部分の日本語翻訳を記述させていただきました。

Title: Hyper-V 環境における SQL Server 2008 のベストプラクティスとパフォーマンスの推奨事項

Published: 2008年10月

Writers: Lindsey Allen, Mike Ruthruff, Prem Mehra

Reviewers: Cindy Gross, Burzin Patel, Denny Lee, Michael Thomassy, Sanjay Mishra, Savitha Padmanabhan, Tony Voellm, Bob Ward

Download: Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations

ハイパーバイザーテクノロジをベースにする Windows Server 2008 オペレーションシステム (以下、OS) の仮想化機能である Hyper-V はハードウェアと OS との間のソフトウェアの薄いレイヤーであり、ホストコンピュータ上にて複数のOSを変更なしに同時に実行することが可能です。Hyper-Vは強力な仮想化テクノロジで、企業の IT 部門が使用頻度の低いサーバーを統合することで TOC の削減、サービスの品質を維持、向上させることが可能です。Hyper-V はその他の目的、例としてハードウェアが手元にないが、開発・テスト環境が必要な場合などにも有効です。一般的に現状のワークロードを統合し、将来のワークロード増加を考慮した正しいハードウェアのサイジングは困難です。仮想化が含まれる場合はさらに複雑になります。本ドキュメントの目的は Hyper-V 環境における Microsoft® SQL Server® を実行する以下2つのキーポイントにフォーカスし、それらの解決を手助けすることです:

· Hyper-V 環境にてSQL Serverを実行した場合のシステム・リソースのオーバーヘッドはどの程度か

· Hyper-VがどのようにSQL Server 2008をスケールさせるか

本ホワイトペーパーには Hyper-V環境にてSQL Server を使用する代表的なシナリオを実行した一連のテスト設定、結果、見解、推奨事項が含まれます。私たちのテスト結果では Hyper-V環境における SQL Server 2008は安定したパフォーマンスとスケーラビリティを提供することが確認できました。Windows Server 2008 の Hyper-VはSQL Server 2008の適切なワークロードにとって強力なプラットフォームを提供します。よって、Hyper-V環境において運用環境でのワークロードをゲスト仮想マシンの許容範囲にて実行することは実用的と言えます。

SQL Server 2008 技術情報 (SQL Server ベストプラクティス)

http://www.microsoft.com/japan/sqlserver/2008/bible/default.mspx

SQL Server 2008におけるハードウェア要件とソフトウェア要件 (仮想化の項目参照)

http://technet.microsoft.com/ja-jp/library/ms143506.aspx

Windows Server 2008 Hyper-V

http://www.microsoft.com/japan/windowsserver2008/technologies/hyperv.mspx

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

SQL Server 2008 データウェアハウスシナリオ　Tips and Tricks Part 1

koheiu — Tue, 30 Sep 2008 12:26:00 GMT

ご無沙汰しております、マイクロソフトの植田です。

最近まで、SQL Server 2008のシナリオ検証に長らく携わっておりましたがようやく落ち着きましたので、これから何回かにわたって検証の中で得られたTipsや注意点などについてお伝えできれば、と考えております。今回行われました検証の結果はすべて、以下のサイトで公開させていただく予定ですので、ここではドキュメントの中では詳しく紹介できていない注意点などについて綴っていきたいと思っています。

SQL Server 徹底検証シリーズ

私が主に参加していたのは「大規模データウェアハウス」シナリオですので、そのシナリオに関連したトピックをご紹介していく予定です。

今回は導入として、テストデータベースの構成などについてご紹介したいと思います。検証で使用したデータベースは以下のテーブルで構成されています。

テーブル名	種類（ファクト/ディメンジョン）	行数	サイズ(KB)
SalesFact	ファクト	2,400,000,000	2,348,810,000
MCalendar	ディメンジョン	4,748	744
MProduct	ディメンジョン	43,852	13,104
MStore	ディメンジョン	1,300	88
MCustomer	ディメンジョン	1,050,000	76,536
MAddress	ディメンジョン	122,483	8,312
MAge	ディメンジョン	68	8
MJob	ディメンジョン	97	8
MSalary	ディメンジョン	12	8
MCheck	ディメンジョン	6	8

※非クラスタ化インデックスは除外しています。サイズはデータ圧縮がかかっていない状態です。

大規模データウェアハウスを表す主な特徴としては以下になります。

ü ファクトテーブルの行数は24億件、サイズは約2TB

ü ファクトテーブルは月単位でパーティション分割されている

ü ファクトテーブルは10年分のデータを保持し、1か月（1パーティション）あたりの行数は約2000万件

大規模なテーブルをパーティション分割する利点はいくつかありますが、特に以下の2点が挙げられます。

1. データ管理における自由度が向上する

2. メンテナンス作業の効率化

1については、例えば一つのパーティションに1つのファイルグループを対応させることにより、パーティション分割されたテーブルの物理的なデータ配置を制御できます。典型的な例として、日時データをキーとしてテーブルをパーティション分割し、時間が経過して古くなったデータはファイル単位で移動や圧縮（シュリンク）、または、削除(*)することによりディスクスペースを制御する、と言ったシナリオが挙げられます。今回の検証ではストレージシステムを2つ用意し、最近5年分のデータはメイン（高性能）のストレージに保持し、それよりも古くなったデータはアーカイブ用のストレージに移動させるシナリオをテストしました。ホワイトペーパーの中では、データベースをオンラインのまま、データファイルを移動させる方法について説明させていただく予定です。

(*)パーティションスイッチを持いてパーティションのデータだけを削除した後にファイルを削除する

2に関しては、データベースのバックアップ/リストアや、SQL Server 2008から導入されたデータ圧縮の処理をパーティション単位で行うことができる点が挙げられます。データベース全体ではなく、パーティション単位でバックアップ/リストアを行うので、当然処理時間は短くなります。また、リストアに関しては、リストア対象のパーティション以外はオンラインで行えますので、特定のパーティションのみの復旧作業であれば、データベース全体をオフラインにする必要はない、などのメリットがあります。

データ圧縮はディスクの使用量を削減する素晴らしい機能ですが、システムの利用のされ方によってはパフォーマンスに影響を与える可能性があります。具体的には更新処理が多くなる場合はオーバヘッドが発生することが予想できます。テーブルがパーティション分割されている場合、データ圧縮を使用することによりメリットが得られる可能性が大きくなります。例えば、テーブルのパーティションの中で、頻繁に更新される領域と、頻繁に参照されるがあまり更新されない領域がある場合、更新されるパーティションにはデータ圧縮を用いず、更新があまり行われないパーティションにはデータ圧縮を適応する、と言った運用方法が考えられます。今回の検証では、最新月のパーティション以外は更新されないため、最新月以外のデータが保持されているパーティションにはデータ圧縮を行うシナリオをテストしました。

以上大規模なテーブルをパーティション分割するメリットについて説明してきました。最後に、パーティション単位でのメンテナンスにおける注意点を１つ紹介して今回のポストを締めたいと思います。

SQL Server 2005 SP2 以降からSQL Server 2008にUpgradeし、1つのパーティションを一つのファイルグループに割り当て、ファイルグループ単位でバックアップを行う運用をしている際には注意が必要です。データベースのバックアップを取得する際、事前にデータベースの整合性をDBCC CHECKDBでチェックする運用が一般的ですが、SQL Server 2005のSP2以降から、DBCC CHECKFILEGROUPによって、複数のファイルグループにまたがってパーティション分割されたテーブルに対して、指定ファイルグループのみにおける整合性チェックが行えるようになりました。詳しくはSQL Server 2005 Books Onlineをご参照ください：DBCC CHECKFILEGROUP（Transact-SQL）。この機能強化により、パーティション単位でバックアップをとる場合、データベース全体の整合性をチェックするのではなく、該当のパーティションが使用するファイルグループのみDBCC CHECKFILEGROUPを行うことにより、整合性チェックの時間を短縮することが可能になりました。しかしSQL Server 2008ではDBCC CHECKFILEGROUPで整合性をチェックできるのは指定したファイルグループにすべてのページが収まっているテーブルのみになるため、複数のファイルグループにまたがってパーティション分割されているテーブルの整合性チェックについてはDBCC CHECKDBを使用する必要があります。

複数のファイルグループにまたがってパーティション分割されているテーブルが使用している一つのファイルグループに対してDBCC CHECKFILEGROUPを実行すると以下のようなメッセージが返されます。

オブジェクト"salesfact" (ID 2105058535)、インデックス"salesfact" (ID 0) の行セットID 72057594038779904 を処理できません。未検証のファイルグループ"FG200401" (ID 2) に属しています。

CHECKFILEGROUP により、データベース'mscqidwh' に0 個のアロケーションエラーと0 個の一貫性エラーが見つかりました。

この場合は上記のオブジェクト（テーブル）salesfactの整合性チェックはスキップされるため、指定したファイルグループに整合性エラーがあるか否かは判断できません。

この機能についてはSQL Server の未来のバージョンで改善される予定です。

次回はSQL Server Integration Servicesを使用したデータロードのトピックを取り上げたいと思っています。よろしくお願いします。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

非ユニコードデータ型をユニコードデータ型に変換する際のベスト・プラクティス

koheiu — Wed, 30 Apr 2008 10:19:00 GMT

マイクロソフトの植田です。ご無沙汰しております。

少し間が開いてしまいましたが、引き続きSQL Serverのベストプラクティスに関して情報発信していきたいと思います。

今回はSQL Serverにおける、非ユニコードデータ型をユニコードデータ型に変換する際のベスト・プラクティスをご紹介させて頂きます。具体的には、char, varchar, textなどのデータ型をnchar, nvarcharに変換するための最も簡単、かつ、高速な方法や、それらに関する注意点をまとめたいと思います。

本内容は米国のSQL Customer Advisory Teamのサイトにて公開されております。

注）本内容に関する詳細については以下のWebサイトに掲載されているホワイトペーパー（Best Practice for Migrating Non-Unicode Data Types to Unicode）をご参照ください。

本ドキュメントは以下の方を対象としております。

l 開発者、テストエンジニア、データベース・アドミニストレータ

l データベース、および、Microsoft SQL Serverについて基本的な知識をお持ちの方

l Microsoft SQL Serverの照合順序について基本的な知識をお持ちの方
SQL Server 2005の照合順序オプションおよびインターナショナルサポート：http://technet.microsoft.com/ja-jp/library/ms143503.aspx

今回テストに使用したデータベースに含まれるテーブル、および、各テーブルのサイズは以下の通りでした（データベース全体の合計は約30GB）。

テーブル名	行数	テーブルサイズ	インデックスサイズ
REGION	5	8 KB	8 KB
NATION	25	8 KB	24 KB
PART	3,000,000	427 MB	800 KB
SUPPLIER	149,984	23 MB	1.8 MB
PARTSUPP	12,000,000	1.8 GB	132 MB
CUSTOMER	2,249,984	380 MB	728 KB
ORDERS	22,500,000	2.9 GB	628 MB
LINEITEM	89,987,373	14 GB	4.5 GB

テーブル1：テーブルサイズ

今回のデータ型の移行では以下の5通りの方法をテストし、結果を比較しました。

1. ALTER TABLE　T-SQL文を用いて、テーブルのデータ型をインプレースで変更する方法
(例)テーブルスキーマがt1 (c1 char(10),c2 varchar(20),…)の場合
alter table t1 alter column c1 nchar(10);
alter table t1 alter column c2 nvarchar(20);…

2. BCPを用いてデータをフラットファイルに落とし、新しいテーブルに一括挿入する方法
(例)
a) フラットファイルへのエクスポート
bcp testdb.dbo.t1 out E:\t1.dat –w –Slocalhost –T
b) 元のテーブルの削除
drop table t1
c) テーブルをユニコードデータ型で再作成
create table t1 (c1 nchar (10), c2 nvarchar(20),…)
d) テーブルへの一括挿入
bulk insert t1 from ’E:\t1.dat’ with (DATAFILETYPE=’widechar’)

3. INSERT SELECT　T-SQL文を用いて、一時テーブルにデータを格納し、テーブルを置き換える方法
(例)
a) 一時テーブルの作成
create table stg_t1 (c1 nchar (10), c2 nvarchar(20),…)
b) 一時テーブルへのデータ挿入
insert into stg_t1 select * from t1
c) 元のテーブルを削除
drop table t1
d) 一時テーブルの名前を変更
sp_rename ’stg_t1’, ’t1’

4. SELECT INTO　T-SQL文を用いて、一時テーブルにデータを格納し、テーブルを置き換える方法
(例)
a) 一時テーブルへのデータ挿入
select cast(c1 as nchar(10)) as c1, cast(c2 as nvarchar(20)) as c2,… into stg_t1 from t1
b) 元のテーブルを削除
drop table t1
c) 一時テーブルの名前を変更
sp_rename ’stg_t1’, ’t1’

5. SQL Server Management Studio(SSMS)からGUIを用いてテーブルのデータ型を変更する方法
(例)
a) SSMSのオブジェクト・エクスプローラー上でデータベースのツリーを開く
b) 変更対象のテーブルのアイコン上で右クリックし、「デザイン」をクリック
c) テーブル・デザイナーにおいて非ユニコード文字列型のカラムのデータ型をユニコードデータ型に置き換える
d) テーブル・デザイナーを閉じる

上記のホワイトペーパーでは、経過時間、リソース使用状況、照合順序の変更、および、可用性について議論していますが、ここではそれぞれの移行方法の経過時間、ディスク使用量、および、特徴、そして結論について要約させていただきます。

移行にかかる時間の比較

以下のテーブルはそれぞれの手順と、それに要した時間を表しています。

手順　方法	データ変換、または、移動に要した時間（分）	オブジェクト（Index等）再作成にかかった時間(分)	合計（分）
ALTER TABLE	137	61	198
フラットファイル	122	41	163
INSERT SELECT	18	43	61
SELECT INTO	18	41	59
SSMS	17	38	55

テーブル2：移行にかかる時間

上記の結果より、最も早くに移行を完了させることができた手順はSSMSを用いる方法であることがわかります。ただし、次に続いている、INSERT SELECT、SELECT INTOを用いる方法との差はわずかでした。プロファイラーを用いて、SSMSを使用した時にどのようなリクエストが内部で発行されているかを調べたところ、内部処理はINSERT SELECTと同じであることがわかりました。最も大きく異なる点は、SSMSを用いた場合は移行対象のテーブルにロックがかかり、移行が完了するまで（インデックスが再作成されるまで）テーブルにアクセスができなくなる点でした。

またフラットファイルを用いた移行では、データのインポート/エクスポート処理をCPU数分の並列スレッドで行うことにより処理を高速化できます。上記のデータは1プロセスでの処理時間ですが、8CPUのマシンで8プロセスの並列処理を行うことにより、約37%パフォーマンスが向上することが確認できました。さらに処理を高速化させる方法としては、インポート対象のテーブルをパーティション分割する方法が考えられますが、今回のテストではテーブルのパーティション化は行いませんでした。

移行にかかる時間の比較

以下のテーブルはそれぞれ移行方法について、ディスク使用量を表しています。「その他」に含まれる領域として、フラットファイルの領域、および、TempDBの領域があります。

使用用途方法	Data file (GB)	Log file (GB)	その他 (GB)	合計（GB）
ALTER TABLE	60	81	19	159
フラットファイル	48	57	67	172
INSERT SELECT	73	57	19	149
SELECT INTO	73	57	19	149
SSMS	67	57	0	127

テーブル3：ディスク使用量

上記の結果より、最もディスク容量を使用する移行方法はフラットファイルを利用する方法であることがわかりました。ただし、フラットファイルは、データベースが置かれているストレージとは別のストレージに配置することもできるため、ほかの方法に比べて自由度が高く、データファイルの容量に注目すると、最もディスク使用量が少ない点が特徴です。INSERT SELECT、SELECT INTOに関しては一時テーブルのための領域を確保しているため、ディスク使用量が大きくなっています。ただし、これら2つの方法は同時に、移行前のテーブルを保持することができるため、高い可用性を求められるケースでは有効です。SSMSではインデックス作成の際にTempDBを使用できないため、元のテーブルが存在するファイルグループに十分な容量があることを確認しておく必要があります。

移行手法の特徴

ALTER TABLE

この手法は移行に最も時間がかかる方法でした。また、ALTER TABLEを行うためには、テーブルに作成されたインデックスやトリガーなどのオブジェクトを削除しなければならず、テーブル変更後に再作成するという作業が必要になるため、手順が複雑になる恐れがあります。また一時テーブルのためのディスク容量は必要ありませんが、その分元のテーブルが大きくなってしまう点も考慮する必要があります。加えて、ログのサイズも肥大化するため、十分なディスク容量が必要となります。

フラットファイル

この手法は2番目に時間がかかる方法でした。ただし、移行元のテーブルが複数のファイルにエクスポート可能である場合、並列処理を行うことによって移行時間を短縮できます。移行に際してデータのクレンジングなどの処理が必要であるシナリオではこの方法は効果的です。だたし、フラットファイルのためのディスク領域を確保する必要があります。

INSERT SELECT

この手法は3番目に高速な方法でデータ移行を実現します。SELECT INTOとのもっとも大きな違いは、あらかじめテーブルを作成した上で移行を行えるため、パーティション化されたテーブルにも適応可能です。また旧データを保持しながら、データ移行を行えるので高い可用性を提供します。ただし、一時テーブルのためのディスク領域を確保する必要があります。

SELECT INTO

この手法は2番目に高速な方法でデータ移行を実現できます。なお、データ挿入時のログ書き込みが最も少ない手法でした（テーブル3のログファイルのサイズはインデックス作成時に膨張）。ただし、この手法ではテーブルをあらかじめ用意しないため、以下の2点の制限があります。

1．テーブルはデフォルト・ファイルグループ上に作成される

2．データ挿入先のテーブルをパーティション化できない

デフォルト・ファイルグループはALTER DATABASEコマンドで変更可能ですが、SELECT INTOではパーティションスキームを指定することができないため、2に関する制約はSELECT　INTOを利用不可にする可能性があります。可用性、および、ディスク使用量についてはINSERT SELECTと同様です。

SQL Server Management Studio

最も簡単に、最も早くデータ移行を行うことができます。ただし、移行中はテーブルが排他ロックされるため、その間テーブルはアクセスできなくなります。また、マニュアルでのオペレーションのため、人為的なミスにも配慮する必要があります。内部的にはINSERT SELECTと同様の処理が行われます。インデックスの作成にはTempDBが使用できないため、ファイルグループにインデックス作成のための十分な領域が必要です。

結論

非ユニコードデータ型のデータをユニコードデータ型に移行する際のベストプラクティスについて検証を行いました。その結果以下のような指針を得ました。

l データ移行の際はメンテナンスの時間を確保し、移行前にデータのバックアップを採取しておくことを推奨します。

l データ移行に関して、データファイル、ログファイル、TempDBのためのディスク容量が十分にあることをご確認ください。

l 移行するテーブルがパーティション分割されておらず、可用性を考慮する必要があり、最も短い時間で移行を完了させたい場合はSELECT INTOを使用してデータ移行することをお勧めします。

l 可用性を考慮する必要がなく、作業手順をスクリプト化する必要がない場合は、SQL Server Management Studioを使用することをお勧めします。

l 移行先のテーブルをパーティション分割する必要があり、ファイルグループに自由度を持たせたい場合はINSERT SELECTを使用してデータ移行することをお勧めします。

l データを一旦フラットファイルに落として移行を行いたい場合、可能であればフラットファイルをCPU数分、分割して並列処理を行うことをお勧めします。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

データベースミラーリングとログ配布を組み合わせた高可用ソリューション

koheiu — Thu, 07 Feb 2008 06:02:00 GMT

マイクロソフトの植田です。

今回はSQL Serverのデータベース・ミラーリングとログ配布の機能を組み合わせた運用に関するベスト・プラクティスをご紹介させて頂きます。

本内容は米国のTechNetのサイトにて公開されております。

注）本内容に関する詳細については以下のWebサイトに掲載されているホワイトペーパー（Database Mirroring and Log Shipping Working Together）をご参照ください。

本ドキュメントは以下の方を対象としております。

l 開発者、テストエンジニア、データベース・アドミニストレータ

l データベース、および、Microsoft SQL Serverについて基本的な知識をお持ちの方

l Microsoft SQL Serverのログ配布、および、データベース・ミラーリングについての知識をお持ちの方。ログ配布、および、データベース・ミラーリングの説明についてはSQL Server Books Onlineをご参照ください。
ログ配布：http://technet.microsoft.com/ja-jp/library/ms190016.aspx
データベース・ミラーリング：http://technet.microsoft.com/ja-jp/library/ms177412.aspx　

ご紹介する内容は主に以下の3点です。

1. ログ配布の構成をデータベース・ミラーリングの構成に変更する方法

2. ログ配布を用いて、データベース・ミラーリングのペアに待機系を追加する方法

3. ログ配布のペアとデータベース・ミラーリングのペアを切り替える方法

ログ配布からデータベース・ミラーリングへの変更

ログ配布の機能はディザスタ・リカバリのソリューションの一つとして比較的古くから（Microsoft SQL Server 7.0 Service Pack 2以降）利用可能でした。SQL Server 2005では、 Service Pack 1からデータベース・ミラーリングの機能が追加され、SQL Serverのユーザーに高可用性を実現するための新たな選択肢を提供しています。　ログ配布とデータベース・ミラーリングを比較した際、以下の点でデータベース・ミラーリングにはアドバンテージがあります。

l 完全同期オプションが利用可能

l 自動フェイルオーバー・オプションが利用可能

高可用性の指標としては目標復旧時点、および、目標復旧時間（Recovery Point Objective (RPO), Recovery Time Objective (RTO)）があります。運用されるシステムにおいてそれらの指標がより厳しい制約を持つ場合、ログ配布からデータベース・ミラーリングへの変更を検討する価値があると言えます。ただし、データベース・ミラーリングへ変更する場合、以下の点に注意してください。

ü データベース・ミラーリングの構成では、データベースの復旧モデルが「完全」でなければなりません。変更対象のデータベースが一括ログ復旧モデルで構成されている場合は、復旧モデルを変更する必要があります。

ü ログ配布の構成では、配布元となるサーバ上で動作するアプリケーションに対してログ配布の動作の影響はあまりありませんが（ただし、アプリケーションの動作に対するログの量に依存します）、データベース・ミラーリングではアプリケーションのパフォーマンスに対してデータベース・ミラーリングの動作が影響を与える場合があります。詳細は以下のホワイトペーパーを参照してください。データベース・ミラーリングにおけるベスト・プラクティス、および、パフォーマンスに関する考察（英語）。従って、使用するネットワークの帯域において、システムにかかる負荷が期待通り処理されるかどうかを事前に評価することをお勧めします。

手順

1. ログ配布が行われている２台のサーバをS1（プライマリ）、S2（セカンダリ）とした時に、S1とS2の間でログ配布が正常に行われていることを確認します。また、この時セカンダリ・サーバ上のデータベースが「復旧モードなし」の状態であることを確認してください（「スタンバイ」状態はNG）。確認はプライマリ・サーバ上のデータベースのプロパティから「トランザクションログの配布」-「セカンダリ　サーバ　インスタンスとデータベース」の設定から行えます。

2. データベース・ミラーリングのセキュリティ、エンドポイント、パーミッションなどの設定を行います。

3. プライマリ・サーバ上でログバックアップ・ジョブを停止（Disable状態に）します。この時、停止するまでに配布された全てのログがセカンダリ側で適応されるまで、しばらく待つようにしてください。
注意：プライマリ・サーバで採取された最新のトランザクションログ・バックアップと、セカンダリ・サーバ上で復旧された最新のログが異なっている場合、データベース・ミラーリングのセットアップ時に以下のようなエラーが発生します。

データベース“＜データベース名＞”のリモートコピーは、データベースログのローカルコピーに含められた時点までロールフォワードされていません。

4. 全てのログがセカンダリ・サーバのデータベースに適応されたら、セカンダリ・サーバ上でログコピー・ジョブとログ復旧のジョブを停止してください。

5. S1をプリンシパル、S2をミラーとしてデータベース・ミラーリングを有効にします。既定の設定ではデータベース・ミラーリングは同期モードで構成されるので、非同期モードでの運用を行う場合はトランザクションの安全性を変更してください。

6. S1とS2の間のログ配布の構成を削除します。

注意：一つのサーバにおいて、ログ配布のセカンダリとデータベース・ミラーリングのミラーの役割を兼ねる構成はサポートされていません。同一のデータベースに対してログ配布のセカンダリとデータベース・ミラーリングのミラーを一つのサーバで行っている場合、以下のようなメッセージがログ配布のリストアジョブの履歴に出力されます。

データベース '＜データベース名＞' で RESTORE 操作を実行できません。このデータベースは、データベースミラーリング用に構成されています。このデータベースを復元する場合は、ALTER DATABASE を使用してミラーリングの設定を削除してください。

このようにログ配布をデータベース・ミラーリングに変更することは、別のシナリオでもメリットを発揮します。たとえば、あるシステムでサーバS1とサーバS2の間でログ配布を行っていた場合、プライマリ・サーバにおいてメンテナンスを行う状況が考えられます。この場合、ログ配布のフェールオーバーを用いて停止時間を最小にするアプローチが一般的です（ログ配布のセカンダリへのフェールオーバー）。しかし、ログ配布のフェールオーバーでは、アプリケーション側で明示的に接続先を変更する必要があるため、場合によっては数分の停止時間が発生します。一方データベース・ミラーリングでは、アプリケーションから見て透過的なフェールオーバーを提供するため、停止時間が最小に抑えられます。通常はログ配布で運用し、メンテナンス時のみデータベース・ミラーリングを利用したいときは、まずログ配布をデータベース・ミラーリングに変更し、メンテナンスが終了したらフェールバックして業務をプライマリに戻し、再度ログ配布に構成し直すことも可能です。

ログ配布を用いて、データベース・ミラーリングのペアに待機系を追加

データベース・ミラーリングは可用性の面において多くの利点があります。ただし、現在（2008年2月）は2ノード構成に限定されています。一方、ログ配布の利点として複数の配布先を構成できる点が挙げられます。ログ配布を組み合わせることにより、データベース・ミラーリングに複数の待機系を追加することができます。例えば、データベース・ミラーリングを用いてローカルサイトで二重化されたシステムを災害時にも復旧できるように、遠隔地に待機系を設置したい、といった要求に対してこのソリューションが適応できます。

注意：データベース・ミラーリングのペアから、ログ配布先のセカンダリにフェールオーバーする場合はアプリケーション側において接続先を手動で切り換える必要があります。

手順

３台のサーバ、サーバS1、S2、S3の間でデータベース・ミラーリング、および、ログ配布を構成する手順について説明します。

1. S1をプリンシパル、S2をミラーとして、S1とS2の間でデータベース・ミラーリングを設定します。

2. S1においてフルバックアップを行い、それをS3においてNORECOVERYでリストアします。

3. S1をプライマリ、S3をセカンダリとしてログ配布を構成します。

(ア)SQL Server Management StudioのGUIを用いてログ配布を構成します（ログ配布を有効にする方法（SQL Server Management Studio））。

(イ)最後のダイアログで「OK」ボタンを押してログ配布を確立する前に、スクリプトを生成してローカルディスクに保存します。このスクリプトは後ほど使用します。

(ウ)「OK」ボタンを押してログ配布を確立します。

(エ)S1とS3の間でログ配布が行われていることを確認します。ログ配布のジョブのステータスにより状態を確認できます。

4. もしデータベース・ミラーリングが非同期モードで構成されている場合は同期モードに変更してください。S1からS2に手動でフェールオーバーを行います。この時、データベース・ミラーリングがホワイトペーパー（データベース・ミラーリング上でのアプリケーション・フェールオーバーの実装方法（英語））に従って構成されていればアプリケーションも自動的にフェールオーバー先のサーバに再接続します。

5. S2をプライマリ、S3をセカンダリとしてログ配布を構成します。

(ア)SQL Server Management StudioのGUIを使用しないでください。SQL Server Management Studioを用いた構成はデータベース・ミラーリングのプリンシパル側でのみ有効です。ここでは手順3-(イ)で生成したスクリプトを使用します。

(イ)手順3-(イ)で生成されたスクリプトには２つのセクションがあります。一つは「．．．プライマリ[＜サーバ名＞]で実行されるスクリプト．．．」とマークされているセクションで、もう一つは「．．．セカンダリ[＜サーバ名＞]で実行されるスクリプト．．．」とマークされているセクションです。ここでは「．．．プライマリ[＜サーバ名＞]で実行されるスクリプト．．．」とマークされている部分のみS2上で実行します。「．．．セカンダリ[＜サーバ名＞]で実行されるスクリプト．．．」とマークされている部分は手順3-(ウ)の際にすでにS3上で実行されているので再度実行する必要はありません。
注意：スクリプトに変更を加えないでください。S1からS3へのログ配布を構成したときに指定したトランザクションログのバックアップ先が、S2においても同じであることを確認してください。

(ウ)S2からS3へのログ配布が正常に行われていることを確認します。

6. S2からS1に手動でフェールオーバーを行います。

7. もし、手順4でデータベース・ミラーリングを同期モードに変更していた場合は、再度非同期モードへ変更します。

上記の手順は、サーバS1とS2の両方をログ配布のプライマリとして構成します。データベース・ミラーリングのフェールオーバーの際、新しいプリンシパルがログ配布のプライマリの役割を透過的に引き継ぎます。ログ・バックアップのジョブはサーバS1とS2の両方で作成されます。プリンシパル（S1）側では、ログ配布のセカンダリ・サーバがログを取得する先の共有フォルダにログのバックアップを作成します。一方、ミラー（S2）側ではログ・バックアップのジョブは動作しますが何も生成しません。ミラー側のジョブ・ステータスにおいて以下のようなメッセージが見られるでしょう。

トランザクションログのバックアップを生成できませんでした。データベースが NORECOVERY モードまたは STANDBY モードになっています。

上記のメッセージはミラー側において出力されるのは自明であり、問題ありません。

ログ配布のセカンダリ・サーバ（S3）側に置いて、S1またはS2のどちらのサーバがプライマリとして動作していても違いはありません。セカンダリ・サーバは同じ共有から必要となるログ・バックアップを取得しデータベースに適応します。

今回は一つのセカンダリ・サーバを持つ構成を紹介しましたが、複数のログ配布セカンダリ・サーバを持つことが可能です。

起こり得る問題

データベース・ミラーリングのペアから3番目のサーバにログ配布を行う際に、起こり得る問題があります。それはミラーリングされているデータベースと、ログ配布により作成されているデータベースの間にログ・シーケンス・ナンバー（Log Sequence Number: LSN）の不一致が発生する場合、ログ配布のセカンダリ・サーバにおいてエラーが発生する問題です。データベース・ミラーリングのLSNの詳細についてはBooks Onlineの以下のページをご参照ください。データベースミラーリングセッション。LSNの詳細についてはBooks Onlineの以下のページをご参照ください。ログシーケンス番号の概要。この問題は以下のようなケースおいて発生します。

l S1がLSN 9, 10, 11のログを記録

l S2がLSN9, 10のログを記録

l S2においてLSN11のログが記録していないため、アプリケーションはLSN11の処理に対するコミット完了をまだ受け取っていない

l S1において障害が発生し、ミラーリングの機能でS2にフェールオーバが行われる

l S1において最後に採取されたログ・バックアップはLSN11を含む

l 新たにS2で採取されるログ・バックアップはLSN10までで、LSN11を含んでいない

l ミラーリングされているデータベース（S2）と、ログ配布のセカンダリ・サーバ（S3）の間でLSNの不一致が発生

このとき以下のようなメッセージがログ配布のセカンダリ・サーバのリストアジョブの履歴に記録されます。

"＜ログ・バックアップファイル名＞" の末尾のバックアップデータのフォーマットが不適切です。メディアのバックアップセットが破損していて使用できない可能性があります。

ログ配布のセカンダリ・サーバはプライマリ・サーバと同期がとれていない状態に陥っているため、ログ配布の構成を再度作り直す必要があります。その際は、プライマリ・サーバ上で再度データベースのフルバックアップを採取して、ログ配布の構成を構築し直す必要があります。この問題はSQL Serverの将来のリリースにおいて修正される予定です。

ログ配布のペアとデータベース・ミラーリングのペアを切り替える方法

データベース・ミラーリングとログ配布を組み合わせたシステムを運用している場合、データベース・ミラーリングのペアリングと、ログ配布のペアリングを簡単に切り替える（スイッチング）ことができます。たとえば、サーバS1とサーバS2の間でデータベース・ミラーリングを行っており、ミラーリングのプリンシパルからサーバS3にログ配布を行っている場合、サーバS2をログ配布のセカンダリ・サーバに変更して、サーバS3をミラーリングのミラーに変更することができます。このような変更はローリング・アップグレードを行う際、メリットがあります。上記の例を行う場合の手順は以下のようになります。

手順

1. S2をログ配布のプライマリ・サーバから削除します。SQL Server Management Studioから変更は行わないでください。その代り、システムのストアドプロシージャを使用します。

(ア)S2上でsp_delete_log_shipping_primary_scondaryを実行します。
（例）
sp_delete_log_shipping_primary_scondary ‘<データベース名>’, ‘S3’, ‘<データベース名>’

(イ)S2上でsp_delete_log_shipping_primary_databaseを実行します。
（例）
sp_delete_log_shipping_primary_database ‘<データベース名>’

2. S1とS2の間のデータベース・ミラーリングを削除します。

3. 上記の「ログ配布の構成をデータベース・ミラーリングの構成に変更する方法」を用いてS1とS3の間のログ配布の構成をデータベース・ミラーリングに変更します。この時点でS1がデータベース・ミラーリングのプリンシパルに、S3がミラーになります。

4. 上記の「ログ配布を用いて、データベース・ミラーリングのペアに待機系を追加する方法」を用いて、S2をログ配布のセカンダリ・サーバとして手順３で作成したミラーリング・データベースからログ配布を行うように構成します。この時点でS1、S3がログ配布のプライマリ・サーバに、S2がセカンダリ・サーバになります。

なお、SQL Server 2005のデータベース・ミラーリングの機能に関する詳細な検証結果がホワイトペーパーにまとめてられてMicrosoft TechNet のSQL Server TechCenter上で公開されておりますので、ご興味ある方はこちらも是非ご参照ください。

SQL Server 2005 徹底検証シリーズ　

SQL Server 2005 データベースミラーリング検証

結論

SQL Server2005のログ配布とデータベース・ミラーリングの機能を組み合わせることによって、システムの可用性を高め、ディザスタ・リカバリに対するソリューションを提供することができます。ログ配布の構成はデータベース・ミラーリングの構成に変更可能です。また、データベース・ミラーリングは2ノードの構成しかサポートされていませんが、ログ配布を組み合わせることにより、待機系ノードを追加することができます。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

SQL Server Best Practice 日本語技術文書が公開されました

koheiu — Mon, 21 Jan 2008 09:09:00 GMT

ご無沙汰しております、マイクロソフトの植田です。

昨年よりSQL Serverのベスト・プラクティスに関する情報を発信しておりますが、本年も引き続き、できるだけたくさんの情報をご提供させていただきたいと思っておりますので、よろしくお願い申し上げます。

米国のMicrosoft TechNet, SQL Server TechCenter で公開されておりましたSQL Server Best Practiceのホワイト・ペーパーが日本語化され、日本のMicrosoft SQL Server ホームからリンクされている、SQL Server BIBLE（技術者必読情報）, SQL Server ベストプラクティスで公開されております。現在日本語化されている内容は以下になります。

TEMPDB の容量計画、およびインデックス作成と再構築の同時実行に関する考慮事項

（内容）

インデックスの作成や再構築の操作で使用できるさまざまなオプションについて説明します。またそれらのオプションが、パフォーマンス、同時実行、およびリソースの要件に対して与える影響についても説明します。

SQL Server 2005 Analysis Services パフォーマンス ガイド

（内容）

アプリケーション開発者が SQL Server 2005 Analysis Services オンライン分析処理 (OLAP) ソリューションに対して適用できるパフォーマンスチューニング手法とその適用方法について解説します。

その他、SQL Server BIBLEのサイトにリストアップされているドキュメントに関しても順次日本語化されていく予定です。どうぞご活用ください。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

SQL Server 2005 トランザクション・レプリケーションの最適化 (SubscriptionStreams)

koheiu — Tue, 16 Oct 2007 08:05:00 GMT

マイクロソフトの植田です。

今回はレプリケーションに関する話題をご紹介したいと思います。

http://blogs.msdn.com/sqlcat/archive/2007/05/07/sql-server-2005-transactional-replication-benefit-of-using-subscriptionstreams-for-low-bandwidth-high-latency-environments.aspx　

注：下記内容に関する詳細の確認をご希望される場合は上記のブログを参照いただけますようお願いします。

本ドキュメントは以下の方を対象としております。

l 開発者、テストエンジニア、データベース・アドミニストレータ

l データベース、および、Microsoft SQL Serverについて基本的な知識をお持ちの方

l Microsoft SQL Serverレプリケーションに関して基礎的な知識をお持ちの方

Microsoft SQL Serverレプリケーションに関する概要はSQL Server 2005のBooks Onlineをご参照ください（SQL Serverのレプリケーション：http://technet.microsoft.com/ja-jp/library/ms151198.aspx）。

SQL Server 2005 トランザクション・レプリケーション：帯域幅が狭く、遅延が大きい環境でSubscriptionStreamsオプションを設定する利点

Introduction

Microsoft SQL Server 2005のトランザクション・レプリケーションを使用する際、ログリーダー・エージェントはログを読み込み、パブリッシュされるアーティクルのためのSQLステートメントを構成し、それをディストリビューション・データベースに渡します。そしてディストリビューション・エージェントはディストリビューション・データベースを読み、その「パッケージ」をサブスクライバに配布／適応します。多くの場合、それらのパブリッシャ、ディストリビュータおよびサブスクライバはトータルの送信遅延が小さい高速ネットワーク上に存在します。しかし、地理的に離れた環境のような遅いネットワーク上では回線速度は大抵、遅延の大きい狭帯域となり、そのような環境ではトータルの送信時間に悪影響を与えることは明白です。（Pingコマンドで簡単に確認できる）ネットワーク遅延はパフォーマンス低下に大きな影響を与えますが、新しいオプション“SubscriptionStreams”を使用することにより劇的にパフォーマンスが向上することがあります。“SubscriptionStreams”オプションはSQL Server 2005と共にインストールされる実行ファイル“DISTRIB.exe”（ディストリビューション・エージェントの設定を行うユーティリティ）のオプションの一つです。“DISTRIB.exe”に関する詳細についてはSQL Server 2005のBooks Onlineをご参照ください（レプリケーション　ディストリビューション　エージェント：http://technet.microsoft.com/ja-jp/library/ms147328.aspx）

SubscriptionStreams NN

（過去のエディションのMicrosoft SQL serverでは）デフォルトでディストリビューション・エージェントはディストリビューション・データベースからサブスクライバ・データベースへトランザクションを送信するのに単一のストリームを使用します。Microsoft SQL Server 2005では、この設定はSubscriptionStreams NNパラメータを指定することにより上書きできます。NNには0（SQL Server以外のサブスクライバまたはピア・ツー・ピアトランザクション・サブスクリプションのための設定値）から64までの値を指定することができます。ただし、64という設定は、特に複数のディストリビューション・エージェントが同一サーバ上で同時実行している場合は、非現実的なスレッド数でしょう。そのパラメータは単一のディストリビューション・エージェントがサブスクライバに対してバッチ変更をパラレルで適応するために許可する接続数を表しています。たとえトランザクションがパラレル化されても、トランザクションの一貫性が維持される点が重要です。この点はプライマリ・キーにおいて効率的にハッシュ、および、分割を行い、サブスクライバでコミットする前に再度組み立てを行うことで実現できます。しかし、SQL Server Books Onlineに記載されている通り（レプリケーション　ディストリビューション　エージェント：http://technet.microsoft.com/ja-jp/library/ms147328.aspx）、もし一つの接続において実行、または、コミットが失敗したら、すべての接続は実行中のバッチ処理をアボートし、ディストリビューション・エージェントは失敗したバッチ処理をシングル・ストリームで再実行します。この再実行が完了するまでは、サブスクライバにおいて一時的にトランザクションの非整合が生じている可能性があります。失敗したバッチ処理が無事コミットされると、サブスクライバはトランザクションの一貫性が保たれた状態に戻ります。

The requirement（要件）

産業の先端を行く大規模なオンライン・ビジネスでは、世界中のインターネットを介して接続された地理的に分散しているオフィス間で、低遅延でも問題なく動作し、接続が切断さても24時間以内に復旧が可能であるように、データをレプリケートすることが求められます。基幹からブランチまでの「ラスト数マイル」の接続スピードは地域によって差がありますが、大抵品質の低い（遅延が大きい）、低速／狭帯域のものでした。平均的なオフィス（サブスクライバが存在する地点）は回線速度512kpbs、平均遅延200-600ミリ秒で接続されていました。パブリッシャ（例えばOLTP処理を行うサーバ）とディストリビュータは高速ネットワーク上に存在し、ディストリビュータ・サーバは4ソケットのデュアル・コアCPUを搭載しています。

テスト

OLTP処理を行うパブリッシャは最頻時に、5から10のコマンドを含むトランザクションを数百処理します。ログリーダー・エージェントはレプリケートされたトランザクションをディストリビューション・データベースに送ります。その後、ディストリビューション・エージェントが開始され、処理が終了するまでにかかった時間とスループットが測定されます。ディストリビュータとサブスクライバの間のネットワークは、帯域制御ソフトを使用して帯域を512kbpsから128kbps、遅延を300ミリ秒に制御しました。

テスト結果／発見

帯域512kbps、遅延300ミリ秒のネットワークにおいてデフォルトの1ディストリビューション・ストリームの設定を用いた場合、サブスクライバに配布される1秒あたりのコマンドのスループットは6.86でした。ストリーム数を8に増やした場合、スループットは488%向上し、40.34に到達しました。さらにストリーム数を16に増やした場合、スループットは718%向上し、56.11に到達しました、これはストリーム数8と比較して39%の性能向上です。

ネットワークの帯域を128kbpsに狭め、遅延は300ミリ秒のままにした場合、1ストリームでは1秒あたり5.9コマンドを配布し、8ストリームでは31.54コマンド／秒、16ストリームでは28.01コマンド／秒という結果になりました。Chart1はこれらの結果をグラフで表しています。

“SubscriptionStreams”オプションを使用することにより多大なスループット向上のメリットを受けることができる点も重要ですが、帯域を狭く、遅延を大きくした際の影響に着目することも重要です。今回のテスト結果ではネットワーク遅延の増加は、帯域幅の減少よりもパフォーマンスに与えるマイナスの影響が大きいことを示しています。なぜならば、すべてのトランザクションにおいてネットワークを通じてやり取りされるレスポンス／応答（ACK）に長い時間がかかるためです。また、今回のテストにおいて、狭帯域かつ大きな遅延があるネットワーク環境では、サブスクリプション・ストリームを16に設定してもスループットが向上しなかった（実際には多少悪くなっている）点も同様に重要です。このことは帯域幅の使用率が限界を超え、パラレル・スレッドを扱うコストがオーバーヘッドになっていることを示しています。

接続が切断さても24時間以内に復旧できる性能を含む要件に関して、Chart2はストリーム数の増加が復旧性能に与えるポジティブな効果を復旧時間で示しています。サブスクリプション・ストリームを設定せずに、遅いネットワーク上で復旧を行うと11時間かかるのに対して、ストリーム数を適切に設定することにより2時間程度での復旧が可能になります。このテストではネットワーク切断により24時間分のトランザクションまたは240,000コマンドが配布を待たされている状況を想定しています。

結論

SQL Server 2005のトランザクション・レプリケーションにおいて“SubscriptionStreams”を設定する機能は、特に遅いネットワークにおいて、パフォーマンスを大幅に向上させる効果を持ちます。しかし、多くのスレッドにおいて複数の接続が開かれているときにサブスクライバにおいてトランザクションのコミット、または、組み立て時にエラーが発生した場合、ストリームの数は一時的に1に削減され、その後設定された値に戻ります。ストリーム数の設定値を定期的に切り替えるのはコストのかかる処理です。システムを展開する前に、すべてのアプリケーション、環境について注意深くテストし、最適なストリーム数を見つけることを強く奨励します。

たとえ広帯域かつ低遅延な環境（例えば、1ギガビットの速度、0ミリ秒の遅延）であってもディストリビューション・エージェントが使用するサブスクリプション・ストリームを適切に設定することで顕著なパフォーマンス向上が見られることがあります、Chart3参照。この設定はテストして適応する価値のある特長です。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

パフォーマンス比較；クラスタ化インデックス　vs.　ヒープ

koheiu — Thu, 20 Sep 2007 11:24:00 GMT

マイクロソフトの植田です。

SQL Server 2005の特徴の一つに、Primary key制約を指定してテーブル作成するとデフォルトでクラスタ化インデックスが作成される点があります。基本的にSQL Server ではクラスタ化インデックスを作成するメリットがあるためこのような動作を行いますが、非クラスタ化インデックスのみのテーブルと比べてどれほどの性能差があるのでしょうか。

今回はこの点についてテストした結果をご紹介させて頂きます。

本内容は米国のTechNetのサイトにて公開されておりますが、ここでは要点をいくつかピックアップして解説したいと思います。

注）本内容に関する詳細は以下のWebサイトで取り扱われております。

http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/clusivsh.mspx

今回の検証の主な目的は以下を明らかにすることでした。

1. クラスタ化インデックスを持つテーブルと、非クラスタ化インデックスを持つテーブルに対してDML（SELECT, INSERT, UPDATE, DELETE）操作を行った時、パフォーマンスにどの程度差が生じるか

2. ID列を持つテーブルにクラスタ化インデックスを設定し、マルチスレッドで行の挿入を行った時、並列スレッド数とパフォーマンスの間にどのような関係があるか

3. 大量の行の挿入／削除を行った時、クラスタ化インデックスを持つテーブルと、非クラスタ化インデックスを持つテーブルとでは、ディスクスペースの使用率（効率性）に違いがあるか

本ブログでは上記の１について説明させていただきます。

クラスタ化インデックスと、非クラスタ化インデックスの大きな違いは、クラスタ化インデックスでは、インデックス・ツリーの最下層の部分（リーフノード）に実際の行のデータが収められているデータ・ページ（行データはインデックスキーの順序でソートされている）がリンクされるのに対し、非クラスタ化インデックスでは、インデックス・ツリーのリーフノードにインデックスキーが存在する行の行IDが格納されていて、実際の行データはデータ・ページ上でランダムに配置されている（インデックスキーの順序に沿って並んでいるわけではない）点です。両者の構造の詳細についてはSQL Server 2005のBook Onlineをご参照ください。

クラスタ化インデックスの構造：http://msdn2.microsoft.com/ja-jp/library/ms177443.aspx

非クラスタ化インデックスの構造：http://msdn2.microsoft.com/ja-jp/library/ms177484.aspx

テスト環境

テストでは以下のテーブルを使用しました。

CREATE TABLE Tab1

(

ORG_KEY BIGINT,

PROD_KEY BIGINT,

TIME_KEY BIGINT,

CST_NON FLOAT,

CST_RPL FLOAT,

RTL_NON FLOAT,

RTL_RPL FLOAT,

UNT_NON FLOAT,

UNT_RPL FLOAT,

UPDATE_DATE DATETIME

)

インデックス作成時のT-SQL文は以下の通りです。

CREATE CLUSTERED INDEX c_idx1 ON Tab1 (ORG_KEY, PROD_KEY, TIME_KEY)

CREATE INDEX nc_idx1 ON Tab1 (ORG_KEY, PROD_KEY, TIME_KEY)

テーブル、および、インデックスのサイズは以下の表のようになっています。

テーブル／インデックス	行数	ページ数	サイズ（MB）
クラスタ化インデックス	16,125,000	181,992	1,421
非クラスタ化インデックス	16,125,000	75,708	591
ヒープ	16,125,000	181,182	1,415

表１：テーブル／インデックスサイズ

注)ヒープとはクラスタ化インデックスが存在しないテーブルです。クラスタ化インデックスではデータ・ページがインデックスのツリー構造に含まれるためテーブルとインデックスを明確に区別していません。

ハードウェア、および、ソフトウェアのテスト環境は以下の通りです。

Server:　HP DL385, AMD Opteron 280 (2.4Ghz Dual Core) x 2, 8GM RAM

Storage: HP StorageWorks Modular Smart Array 30

OS: Windows 2003 Server Enterprise Edition (R2)

SQL Server: SQL Server 2005 Enterprise Edition for x86 with SP1

テスト方法

今回のテストでは以下の方法でパフォーマンスを計測しました。

No.	概要
1	INSERT Performance ランダムに値を作成した1,000,000行のデータをテーブルに挿入し、単位時間当たりの平均処理速度を測定します。1回のINSERTで1行挿入するため、INSERT文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。 INSERT INTO Tab1(ORG_KEY, PROD_KEY, TIME_KEY, UPDATE_DATE) VALUES (9717, 46273, 206, ‘2007-02-01 00:00:00:000’)
2	UPDATE Performance テーブル中のランダムに選んだ1,000,000行のデータを更新し、単位時間当たりの平均処理速度を測定します。1回のUPDATEで1行更新するため、UPDATE文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。 UPDATE Tab1 SET UPDATE_DATE=‘2007-02-01 00:00:00:000’ WHERE ORG_KEY=14517 AND PROD_KEY=19417 AND TIME_KEY=225
3	DELETE Performance テーブル中のランダムに選んだ1,000,000行のデータを削除し、単位時間当たりの平均処理速度を測定します。1回のDELETEで1行削除するため、DELETE文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。 DELETE Tab1 WHERE ORG_KEY=5718 AND PROD_KEY=18193 AND TIME_KEY=52
4	SELECT Performance a. テーブル中のランダムに選んだ1,000,000行のデータを抽出し、単位時間当たりの平均処理速度を測定します。1回のSELECTで1行選択するため、SELECT文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。 SELECT * FROM Tab1 WHERE ORG_KEY=2717 AND PROD_KEY=15385 AND TIME_KEY=3 b. テーブル中であるインデックスキーの範囲にあるデータを抽出し、その処理を1,000,000回行って単位時間当たりの平均処理速度を測定します。1回のSELECTで選択される行数は258行でした。サンプルT-SQL文は以下です。 SELECT * FROM Tab1 WHERE (ORG_KEY=117 OR ORG_KEY=118 OR ORG_KEY=119) AND PROD_KEY=45505

表２：テスト概要

上記のDML操作を行うためのクライアントとして、ODBCライブラリを使用してデータベースにアクセスする簡単なプログラムを用意しました。

テスト手順

パフォーマンス計測の手順は以下の通りです。

1．バックアップより新規作成したテーブルにデータをロードする

2．テーブルにクラスタ化インデックスを作成する

3．クライアントプログラムを走らせ、パフォーマンス測定を行う

4．テーブルを削除、再作成しバックアップよりデータのロードを行う

5．テーブルに非クラスタ化インデックスを作成する

6．クライアントプログラムを走らせ、3と同じDMLについてパフォーマンス測定を行う

7． 1－6を表2の全てのテストケースについて行う

テスト結果

今回得られた結果は以下の通りでした。

テストケース	クラスタ化インデックス付テーブル	非クラスタ化インデックス付テーブル（ヒープ）	差（％）
Test 1: INSERT Throughput (rows/sec)	4653	4515	-3.0
Test 2: UPDATE Throughput (rows/sec)	4683	4330	-7.5
Test 3: DELETE Throughput (rows/sec)	4610	3896	-15.5
Test 4-a: SELECT(row-by-row) Throughput (rows/sec)	4136	3564	-13.8
Test 4-b: SELECT(range scan) Throughput (selects/sec)	587	454	-22.7

結果の考察

このようにすべてのDML操作においてクラスタ化インデックス付テーブルの方が、非クラスタ化インデックス付テーブル（ヒープ）よりもパフォーマンスが良いという結果になりました。これらの差は、WHERE句で指定された行を検索する際に、クラスタ化インデックス付テーブルの場合は、インデックスを走査してそのまま行が格納されているデータ・ページにたどり着くのに対し、ヒープでは非クラスタ化インデックスを走査して行IDを取得し、その後データ・ページへアクセスする必要があるために生じていると考えられます。また、一定範囲に対するSELECT（Test 4-b）において特に顕著な差が生じているのは、このテストケースにおいて、（インデックスキーの順序でデータが並んでいる）クラスタ化インデックス付テーブルの利点が最も有効に活用されているためと考えられます。また、通常インデックスのメンテナンスコストが懸念されるINSERT処理においても、クラスタ化インデックス付テーブルにおけるパフォーマンスがヒープにおけるパフォーマンスよりも良い、という結果になりました。その理由は、クラスタ化インデックスのメンテナンスのコストがヒープにおけるデータページアクセスのコストよりも低かったためと考えられます。ただし、両者のコストはインデックスキーに指定する列のデータサイズ等に依存し、今回の検証結果においてもわずかな差しかないことを考慮すると、環境によっては逆の結果になる可能性もあります。

結論

1千万行程度のテーブルにおいて、クラスタ化インデックスを作成した場合と非クラスタ化インデックスを作成した場合でDML操作のパフォーマンスにどのような違いが生じるかを検証しました。その結果、すべてのDML操作においてクラスタ化インデックス付テーブルに対するパフォーマンスが、非クラスタ化インデックス付テーブルに対するパフォーマンスを上回ることを観測しました。

上記の結果は今回のテスト環境、および、テスト方法において得られたもので、他の環境やテスト方法において同様の結果が出るとは限りません。上記の結果はSQL Server 2005においてデータベースを設計する際の、基礎的なデータとして利用されることをお勧めします。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

スキーマ変更時のベスト・プラクティス　その２

koheiu — Mon, 20 Aug 2007 04:01:00 GMT

マイクロソフトの植田です。

今回は前回ご紹介した「スキーマ変更時のベスト・プラクティス」の第二弾をご紹介したいと思います。元になっているU.S.のサイトは以下です。

http://blogs.msdn.com/sqlcat/archive/2006/03/31/566046.aspx

注：下記内容に関する詳細の確認をご希望される場合は上記のブログを参照いただけますようお願いします。

本ドキュメントは以下の方を対象としております。

l 開発者、テストエンジニア、データベース・アドミニストレータ

l データベース、および、Microsoft SQL Serverについて基本的な知識をお持ちの方

スキーマ変更の制御（その２）

質問：SQL Server 2005においてスキーマ変更を行う際のベスト・プラクティスはなんでしょうか。最も早く、簡単な方法は何でしょうか？

答え：その１では、SQL Server 2005 におけるスキーマ変更の動作の要点をまとめました（「スキーマ変更時のベスト・プラクティス」参照）。その２では、データ型、および、ほとんどのデータ長の変更時に発生するバッチ更新要求を分離するベスト・プラクティス・テクニックについて見て行きたいと思います。この方法は10億行規模の大きなテーブルにおいてパフォーマンス、および、同時並行性に与える影響を最小限に保ちつつ、スキーマ変更を短時間で行うことを可能にします。

シナリオ：5文字の郵便番号が格納されている列があり、それを10文字のフォーマット、例えば12345-0001、に拡張するケースを考えましょう。以下のステートメントで郵便番号（Zip code）の長さをchar(5)からchar(10)に変更できます。

alter table alter column ZipCode Char(10)

しかし、10億行のテーブルにおいて列のデータ長を変更すると、同時並行性を著しく損なわせるバッチ更新処理（プロファイラーにて確認可能）が発生します。もしこの様子をプロファイラーで確認したいのであれば、「スキーマ変更時のベスト・プラクティス」を参照してください。

ベスト・プラクティス

NULLプロパティを使用すること（「DEFAULT WITH VALUES」句を使用するケースは除きます）は列を短時間で追加する場合のベスト・プラクティスです。その列に値を設定しなければならない場合においても、NULLプロパティを使用することで、Alter tableステートメントの場合とは異なり、更新処理を分離できるので自由度の高い方法を利用できます。

（更新処理の分離を）実現するためのアプローチ：

1. NewZipという名前の列を追加する

2. 分離する個々のバッチサイズを設定する

3. 詳細な住所コードに変更してNewZip列にデータを投入する

4. 古いZipCode列を削除する

5. NewZip列をZipCode列に変更する（任意）

ステップ1：新しい列の追加

alter table MyTable

add NewZip char(10) NULL

上記のAlter tableが一瞬で終わると（こちらのテストでは約1秒）、テーブルの全ての行のNewZip列はNULLになります。実際のケースでは他の列の値、または、その他の値をNewZip列に代入する必要があるかも知れません。ステップ2では、書き込みロックの取得によるデータ投入処理が同時並行性に与える影響を最小限にするために、一度に変更する行の数を制限する「SET ROWCOUNT」句が使用します。「SET ROWCOUNT」を設定する代わりの方法は「WHERE」句を用いて一度に変更する行の数をあるキーの範囲で限定することです。

ステップ2：更新処理のバッチサイズ設定

--- (2) set piecemeal batch size

set nocount on

SET ROWCOUNT 1000

次に、NewZip列にNULLの値がなくなるまで繰り返し、段階的な更新処理を流します。今回の例では全ての行にchar(5) ZipCode列の値を用いて、値を代入していきます。代替案として、「lookup」や「join」を使用して、選択的に追加した列に値を代入していくこともできます。

ステップ3：分離された個々の（段階的）更新

declare @rowcount int, @batchcount int, @rowsupdated int

select @rowcount = 1,@batchcount = 0, @rowsupdated = 0

while @rowcount > 0

begin

begin tran

update MyTable

set NewZip = ZipCode

where NewZip is NULL

set @rowcount = @@rowcount

select @rowsupdated = @rowsupdated + @rowcount

if @rowcount > 0 select @batchcount = @batchcount + 1

commit

end

ステップ4：char(5) ZipCode列の削除（任意）

alter table MyTable

drop column ZipCode

ステップ5：NewZip列の名前をZipCodeに変更（任意）

exec sp_rename 'MyTable.NewZip','ZipCode','COLUMN'

--- Observe the data type for ZipCode is now char(10)

sp_help MyTable

ZipCodeに対するトリガー

仮にユーザーがNewZipへの更新の後に顧客のZipCodeを変更すると、どのようなことが起こるでしょう。もしユーザーのアプリケーションが段階的な更新作業中、NewZipがすでに古い住所コードで置き換えられている時、にchar(5)のZipCodeを更新したら、このような場合ZipCodeとの整合性が崩れてしまいます。段階的な更新作業中は、ZipCodeとNewZipの整合性を保つために更新トリガーが利用できます。もし古いchar(5)のZipCodeを削除して（ステップ4）NewZip列の名前をZipCodeに変更する（ステップ5）予定であれば、段階的な更新処理の後ではその更新トリガーは必要なくなるでしょう。

明示的なデータ型の変更

いくつかのデータ型の変更は明示的な変換を必要とします。これは「alter table alter column」を使用した暗黙的なデータ型の変換が行えないケースです。例えば、DATETIMEデータ型をINTまたはYYYYMMDDフォーマットのnumeric(8)型に変更する時は、明示的なデータ変換が必要とされます。このシナリオは「convert (またはdatepart)」関数を使って、上記の段階的な更新シナリオを全く同じように実行することにより対処できます。

列の削除

列の削除はスキーマのみの操作になります。この場合は、削除される列からオブジェクトを再利用スペースに移動させない限り、同時並行性の問題は発生しません。

ユニーク、および、プライマリーキー制約

ユニーク、および、プライマリーキー制約の追加は読み込み処理、ソート処理、書き込み処理を含みます。既定では、プライマリーキー制約がクラスタ化インデックスを付加し、デフォルトのユニーク制約は非クラスタ化インデックスを付加します。すでにユニーク制約（非クラスタ化インデックス）を持っている大きなテーブルに対してプライマリーキー制約（そしてデフォルトのクラスタ化インデックス）を追加する場合、パフォーマンス、および、同時並行性の問題が発生することは明白です。これはプライマリーキー（クラスタ化インデックス）を追加することによって非クラスタ化インデックスの再構築が行われ、RID（列ID）がプライマリーキーに置き換えられるためです。

Alter table, create/alter indexはユニーク、および、プライマリーキー制約/インデックスを制御するためのONLINEオプションを持っています。可能であれば、最高のパフォーマンス、および、最高の同時並行性を実現するために、インデックス操作の際はONLINEオプションを使うべきです。もしくは、メンテナンス時間にこれらの操作を延期するのが賢明でしょう。

結論、および、ベスト・プラクティス

SQL Server 2005はスキーマの変更をサポートしています。しかし、いくつかのスキーマ変更は他のスキーマ変更と比べて高速に処理することができます。以下の場合、最も速くスキーマ変更を行うことができます：

1. NULLプロパティを設定して列を追加

2. NULL、および、デフォルトプロパティを設定して列を追加

3. NOT NULLプロパティをNULLに変更

4. デフォルト制約を追加

5. チェック、または、デフォルト制約を削除

パフォーマンス、および、同時並行性を最も高くするための、大きなテーブルにおけるスキーマ変更のベストプラクティスはNULLプロパティで列を追加することを含みます。新しく追加した列に値をセットしなければならない場合、列にまずNULLプロパティを設定することで「alter table」ステートメントで一括更新される代わりに、更新処理を小さな単位に分離する自由度が与えられます。大きなテーブルにおいて同時並行性に多大な影響を及ぼすバッチ更新処理を行うより、一度に更新する行数を制限して段階的に更新処理を行う方がパフォーマンスの面においてずっと望ましい方法です。更新する列の数を制限する一つの方法として「SET ROWCOUNT」を使用することが上げられます。この方法は段階的に更新処理を行うことにより、発生するブロッキングの影響を劇的に削減します。もし、この段階的な更新処理が完了した後、作成した列に対してNULL値を許可しないことが重要ならば、その列を使用するアプリケーションはこの方法を実施するべきでしょう。

チェック制約が含まれている場合、チェックを行うためにテーブル全体を読み込む必要があります。大きなテーブルでは、変更処理に付随して行われるテーブル走査は書き込み処理に影響を与える恐れがあります。

その他、大きなテーブルにおいて、変更に付随して生じるバッチ更新処理が、パフォーマンス、および、同時並行性に影響を与えるスキーマ変更として以下があげられます：

1. NULLプロパティの列を「DEFAULT」句、「WITH VALUES」句を使用して追加する

2. NOT NULLプロパティの列を追加する

3. NULLプロパティの列をNOT NULLに変更する

NULL列を利用して段階的な更新処理のベスト・プラクティスを採用することで、意図しない読み込み処理や書き込み処理などを避けることができ、高い同時並行性と最も速く、シンプルな方法を利用することができます。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

SQL Server 2005 パフォーマンス・チューニングツール；DMVStats 1.01

koheiu — Wed, 25 Jul 2007 11:22:00 GMT

今回はCodePlexで紹介されているDMVStatsについて説明したいと思います。

DMVStats：http://www.codeplex.com/sqldmvstats

注：下記内容に関する詳細な確認をご希望される場合は上記のサイトをご参照ください。CodePlexはMicrosoftのオープンソース・プロジェクトを掲載しているWebサイトです。CodePlexに関する詳細はこちらのページをご参照ください。

http://www.codeplex.com/CodePlex

DMVStatsはSQL Server 2005で提供される動的管理ビュー（DMV）の情報をデータベースに格納し、パフォーマンスの分析・レポートを行うためのアプリケーションです。動作環境はSQL Server 2005上で、それ以前のバージョンでは動作しません。また、分析した結果をレポートとして表示するためReportingサービスが必要になります。

このツールを使用することで、以下のことを調査できます。

l Waiting Timeの時系列な情報、および、Signal WaitとResource Waitの比率

l どのようなリソースがボトルネックとなっているか（Wait Type）

l どのリクエスト（クエリ）が、どのリソースのために待たされているか

l リソースを多く使用しているリクエスト（クエリ）はどれか

l ブロックされているリクエスト、および、ブロックしているリクエスト

インストール方法は以下の通りです。

1．上記サイトよりdmvstats_setup.zipをダウンロードする

2． Zipファイルの中のdmvstats.exeを実行し、適当な場所にファイルを展開する

3．コマンドプロンプトよりInstallDMVStatsDBProcs.cmdを実行する
分析対象のSQL Server インスタンスに合わせて以下のパラメータを変更する（デフォルトで動作している場合は変更の必要はありません）
SQLSERVER_MACHINE
SQLSERVER_INSTANCE

4．コマンドプロンプトよりDeployReports.cmdを実行する
レポートサーバーのURLが「http://localhost/reportserver」でない場合は以下の行を書き換えてください
set TargetServerURL=http://localhost/reportserver

インストールが終了したら、レポーティングサーバーに接続して設定を行います。

例：デフォルトの設定でインストールを行った場合、Webブラウザで”http://localhost/reportserver”のサイトを開き、DMVStatsのディレクトリをクリックすると下記のような画面が表示されます。

Fig1. DMVStats Top

まずはConfigure DMVstatsレポートを使って監視対象のデータベースを選択します。

DMVStatsはSQL ServerのAgentを使ってDMVの情報を取得しますが、初期設定ではDMVをサンプリングするJobがDisableになっているのでEnableにします。以下はtpccデータベースを監視対象に選んだ例です（監視を開始するためには”enable jobs”をクリックする必要があります）。

Fig2. DMVStats; Configure DMVStats

次のステップに進む前にデータの採取方法について簡単に説明させていただきます。DMVStatsは次の2つの方法でDMVのデータをサンプリングしています。それぞれの特徴は以下のようになっています。

1. Sample
統計されない逐次変化するデータを採取するのに適している。デフォルトでは20秒間隔でサンプリングを行う。インストール時に作成されたストアド・プロシージャを用いてサンプリング間隔を変更できるが15秒以上に設定することを推奨。
サンプリング間隔を30秒に設定する例：
　exec msdb.dbo.sp_update_schedule

@name=N'DMVstats Sample Schedule'

,@freq_subday_type=2,@freq_subday_interval=30
ここで@freq_subday_typeに指定されている‘2’は秒を表します。

2. Snapshot
統計的なデータをまとめて採取するのに適している。デフォルトでは5分間隔でスナップショットを採取する。インストール時に作成されたストアド・プロシージャを用いてサンプリング間隔を変更できる。
サンプリング間隔を10分に設定する例：
　exec msdb.dbo.sp_update_schedule

@name=N'DMVstats Snapshot Schedule'

,@freq_subday_type=4,@freq_subday_interval=10
ここで@freq_subday_typeに指定されている‘4’は分を表します。

次にBaselineを設定します。Baselineは採取されたデータをまとめて一つの単位として定義するものです。Baselineの設定はConfigure Baselinesレポートを使用します。Baselineを構成する単位はSnapshotです。何時から何時までに採取されたSnapshotを含めるかを指定します。「レポートの表示」ボタンを押すとBaselineが作成されます（Baselineを作成するためには少なくとも1つのSnapshotが作成されている必要があります）。

Fig3. DMVStats; Configure Baselines

以上で設定は終了です。以下はWait StatsレポートとAnalyze Block Infoレポートの例です。

以下のグラフからWaiting Timeの時系変化、および、Signal WaitとResource Waitの比率がわかります。

Fig4. Wait Stats; Signal vs. Resource

以下のグラフからWait Typeの比率がわかります。

Fig5. Wait Stats; Category waits detail snapshot

以下のレポートから、ブロックされているクエリと、そのクエリをブロックしているクエリがわかります。

Fig6. Analyze Block Info report

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

スキーマ変更時のベスト・プラクティス　その１

koheiu — Thu, 28 Jun 2007 11:51:00 GMT

マイクロソフトの植田です。

今回はテーブル・スキーマの変更に関する話題をご紹介したいと思います。

http://blogs.msdn.com/sqlcat/archive/2006/03/01/541550.aspx

注：下記内容に関する詳細の確認をご希望される場合は上記のブログを参照いただけますようお願いします。

本ドキュメントは以下の方を対象としております。

l 開発者、テストエンジニア、データベース・アドミニストレータ

l データベース、および、Microsoft SQL Serverについて基本的な知識をお持ちの方

スキーマ変更の制御（その１）

質問：SQL Server 2005においてスキーマ変更を行う際のベスト・プラクティスはなんでしょうか。最も早く、簡単な方法は何でしょうか？

回答：ビジネス要件は時間とともに変化していきます、その変化に合わせてスキーマ変更の要求が発生することは珍しくありません。SQL Server 2005はスキーマ変更（例えば、列や制約の追加/削除、列のデータ型やプロパティの変更）をサポートしていますが、本ブログでは大きなテーブルを操作する際に考慮しなければならないパフォーマンスと並行性の問題にフォーカスします。そしてパフォーマンスと並行性を最大限に活用するベスト・プラクティスについては次の機会（その２:http://blogs.msdn.com/sqljapan/archive/2007/08/20/4471435.aspx）で取り扱います。

では、現在ではかなり一般的になってきた、10億行規模のテーブルを想定して話を進めます。可用性の観点から、スキーマ変更はできるだけ早く、出来るだけ簡単な方法で行う必要があります。

いくつかのスキーマ変更ではバックグラウンドでの読み出し、書き込みが発生します。これらの処理はスキーマ変更の時間を引き延ばし、かつ、ロックを確保することによって（読み込み時には共有ロック、書き込み時には排他ロック）、並行性を低下させる恐れがあります。例えば、チェック制約を追加する際は、制約を施行するためにテーブル・スキャンを行います。NOT NULL制約、列のデータ型やサイズの変更を含むスキーマ変更はバックグラウンドでのアップデートを実行します。これらの暗黙的な読み出しや書き込みはプロファイラーによるステートメント・レベルのトラッキング、および、「SET STATISTICS IO ON」を使うことによって調べることができます。

これらの処理をプロファイラーで追跡するためには、以下の項目を選択してください。

1. TSQL イベント：SQL:StmtStarting、SQL:StmtCompleterd

2. ストアドプロシージャイベント：SP:StmtStarting、SP:StmtCompleted

列の追加 ― alter table MyTable add NewColumn……

＃	列のプロパティ	列につけられている制約	プロファイラーによるモニタ　(StmtStarting & StmtCompleted)	パフォーマンス、および、同時実行に対する影響
1	NULL	*N/A* alter table MyTable add MySSN numeric(9,0) NULL		最速。最高のパフォーマンス、および、並行性。メタデータの変更のみ。
2	NULL	*DEFAULT* alter table MyTable add MyDate2 datetime NULL default getdate()		最速。最高のパフォーマンス、および、並行性。メタデータの変更のみ。
3	NULL	*CHECK* alter table MyTable add MyPct3 numeric(4,1) NULL constraint MyChk3 check (MyPct3 between 0 and 100)	統計を採取し、その後チェック制約施行のため、テーブル全体を読み込み。	NOT NULLプロパティ設定時よりも高速、しかしチェック制約による読み込みが発生。大きなテーブルでは、チェック制約のための読み込み処理が書き込みをブロックする可能性がある。
4	NULL	*CHECK, DEFAULT* alter table MyTable add MyInt4 int NULL default 0 constraint myChk4 check (MyInt4 between 0 and 100)	統計を採取し、その後チェック制約施行のため、テーブル全体の読み込みを行う。	NOT NULLプロパティ設定時よりも高速、しかしチェック制約による読み込みが発生。大きなテーブルでは、チェック制約のための読み込み処理が書き込みをブロックする可能性がある。
5	NULL	*DEFAULT* *WITH VALUES* alter table MyTable add MyInt5 int NULL default 0 with values	テーブル全体をデフォルトの値で更新 UPDATE [Northwind].[dbo].[MyTable] SET [MyInt5] = DEFAULT	NULL & Default (#2)の場合よりも低速。「WITH VALUE」句によって存在するテーブルの全ての行が更新されるため。大きなテーブルでは、このバッチ更新処理は並行性の問題を引き起こす恐れがある。
6	NULL	*CHECK, DEFAULT* *WITH VALUES* alter table MyTable add MyInt6 int NULL default 0 with values constraint myChk6 check (MyInt6 between 0 and 100)	テーブル全体をデフォルトの値で更新し、統計を採取、その後チェック制約施行のため、テーブル全体の読み込みを行う。 UPDATE [Northwind].[dbo].[MyTable] SET [MyInt6] = DEFAULT	最も遅い。「WITH VALUE」句によって存在するテーブルの全ての行が更新され、かつ、チェック制約のための読み込みが行われるため。デフォルトの値によるバッチ更新処理、および、チェック制約のための読み込み処理が発生するため、大きなテーブルでは顕著な並行性の問題が発生する可能性がある。
7	NOT NULL	*DEFAULT* alter table MyTable add MyDate7 datetime NOT NULL constraint myDft7 default getdate()	NOT NULL制約によりテーブル全体のデフォルト値による更新処理が要求される。 UPDATE [Northwind].[dbo].[MyTable] SET [MyDate7] = DEFAULT	NULL & Default (#2)の場合よりも低速。「NOT NULL」制約が、デフォルトの値による更新を要求するため。大きなテーブルでは、このバッチ更新処理が排他ロックを握るため、並行性の問題を引き起こす可能性がある。
8	NOT NULL	*CHECK, DEFAULT* alter table MyTable add MyInt8 int NOT NULL constraint myDft8 default 0 constraint myChk8 check (MyInt8 between 0 and 100)	テーブル全体をデフォルトの値で更新し、統計を採取、その後チェック制約施行のため、テーブル全体の読み込みを行う。 UPDATE [Northwind].[dbo].[MyTable] SET [MyDate7] = DEFAULT	最も遅い。デフォルトの値による更新処理、および、チェック制約のための読み込み処理のため。このデフォルトの値によるバッチ更新処理、および、チェック制約のための読み込み処理により、大きなテーブルでは顕著な並行性の問題が発生する恐れがある。

大きなテーブルに新しい列を追加する最も速い方法は（DEFAULT制約のありなしに因らず）NULLプロパティを使ったやり方です（上記の例の#1、#2参照）。#2の例ではDEFAULT制約がありますが、MyDate列の値は全ての行でNULLになります。

大きなテーブルにチェック制約を含めると、チェック制約を施行するためにテーブル全体の読み込み処理が発生します（上記の例の#3、#4、#6、#8参照）。#3、#4の例ではそれぞれ新規に追加したMyPct3列とMyInt4列にNULLの値が含まれますが、NULL値はチェック制約で不正とならないことに注意してください。NULLはただ単にその値が分からないということを意味します。しかし、もしその値を分かっているものであればチェック制約は強制的にその値をチェックの条件に適応させます。

#5から#8の例ではバッチ更新処理が発生します。もしNULLおよびDEFAULTプロパティに加えてWITH VALUES句が指定されていれば（#5、#6参照）、全ての行がデフォルトの値で更新されます。NOT NULLとDEFAULTの組み合わせによりバッチ更新処理が発生します。バッチ更新処理は排他ロックを保持し、並行性を低下させるので、これらのケースは理想的なパフォーマンス、および、可用性の目標には到達できません。

書き込み処理が発生するケースにチェック制約を加えた場合、#6：NULLプロパティのケース、#8：NOT NULLプロパティのケースともにチェック制約のための読み込み処理が発生し、パフォーマンス、および、可用性が最も低くなります。

列のデータ型、デフォルト制約、チェック制約、NULLプロパティの変更

alter table alter columnステートメントを使って列のデータ型やデータ長（numeric型の場合はスケール、および、精度が含まれる）を変更することができます。これらのケースでは変更に付随して行われるバッチ更新処理によって、パフォーマンス、および、並行性が影響を受けます。もし、NULLプロパティがNOT NULLに変更されると、バッチ更新処理が発生します。例外はNOT NULLプロパティがNULLに変更される時です。これはメタデータのみの高速な処理で行われます。

列プロパティの変更、データ型、および、データ長、列制約の追加　－　alter table MyTable alter column

変更		プロファイラーによる観察
プロパティ　変更	NOT NULLからNULL alter table MyTable alter column MyDate7 datetime NULL		高速メタデータのみ変更
プロパティ　変更	NULLからNOT NULL alter table MyTable alter column MyDate7 datetime NOT NULL	バッチ更新処理実行 UPDATE [Northwind].[dbo].[MyTable] SET [MyDate7] = [MyDate7]	大きなテーブルでは、変更に引き続き起こるバッチ更新処理により並行性の問題が発生する恐れがある。
デフォルトプロパティ追加	ALTER TABLE MyTable ADD CONSTRAINT MyDft DEFAULT 0 FOR MySSN		高速メタデータのみ変更
デフォルトプロパティ削除	ALTER TABLE MyTable DROP CONSTRAINT MyDft		高速メタデータのみ変更
チェック制約追加	ALTER TABLE MyTable ADD CONSTRAINT MyDtChk Check (MyDate2 <= getdate())	統計を採取し、その後チェック制約施行のため、テーブル全体の読み込みを行う。	大きなテーブルでは、変更に引き続き起こるチェック制約のための読み込み処理により並行性の問題が発生する恐れがある。
チェック制約削除	ALTER TABLE MyTable DROP CONSTRAINT MyDtChk		高速メタデータのみ変更
データ長の　拡張	NUMERIC(9)から(11) ALTER TABLE MyTable ALTER COLUMN MySSN numeric(11,0)	更新処理実行 UPDATE [Northwind].[dbo].[MyTable] SET [MySSN] = [MySSN]	大きなテーブルでは、変更に引き続き起こるバッチ更新処理により並行性の問題が発生する恐れがある。
データ型の　変更	NUMERICからINT ALTER TABLE MyTable ALTER COLUMN MySSN int	更新処理実行 UPDATE [Northwind].[dbo].[MyTable] SET [MySSN] = [MySSN]	大きなテーブルでは、変更に引き続き起こるバッチ更新処理により並行性の問題が発生する恐れがある。
データ型の　変更	INTからVarchar(9) ALTER TABLE MyTable ALTER COLUMN MySSN varchar(9)	更新処理実行 UPDATE [Northwind].[dbo].[MyTable] SET [MySSN] = [MySSN]	大きなテーブルでは、変更に引き続き起こるバッチ更新処理により並行性の問題が発生する恐れがある。
データ長の　拡張	Varchar(9)からVarchar(15) ALTER TABLE MyTable ALTER COLUMN MySSN varchar(15)		高速メタデータのみ変更
データ長の　縮小	Varchar(15)からVarchar(10) ALTER TABLE MyTable ALTER COLUMN MySSN varchar(15)	更新処理実行 UPDATE [Northwind].[dbo].[MyTable] SET [MySSN] = [MySSN]	大きなテーブルでは、変更に引き続き起こるバッチ更新処理により並行性の問題が発生する恐れがある。
データ型の　変更	Varchar(15)からChar(15) ALTER TABLE MyTable ALTER COLUMN MySSN char(15)	更新処理実行 UPDATE [Northwind].[dbo].[MyTable] SET [MySSN] = [MySSN]	大きなテーブルでは、変更に引き続き起こるバッチ更新処理により並行性の問題が発生する恐れがある。
データ長の　拡張	Char(15)からchar(20) ALTER TABLE MyTable ALTER COLUMN MySSN char(20)	更新処理実行 UPDATE [Northwind].[dbo].[MyTable] SET [MySSN] = [MySSN]	大きなテーブルでは、変更に引き続き起こるバッチ更新処理により並行性の問題が発生する恐れがある。

列の削除

列の削除はスキーマのみの操作になります。この場合は、削除される列からオブジェクトを再利用スペースに移動させない限り、並行性の問題は発生しません。

ユニーク、および、プライマリーキー制約

ユニーク、および、プライマリーキー制約の追加は読み込み処理、ソート処理、書き込み処理を含みます。既定では、ユニーク制約は非クラスタ化インデックスを付加し、プライマリーキー制約はクラスタ化インデックスを付加します。すでにユニーク制約（非クラスタ化インデックス）を持っている大きなテーブルに対してプライマリーキー制約（そしてデフォルトのクラスタ化インデックス）を追加する場合、パフォーマンス、および、並行性の問題が発生することは明白です。これはプライマリーキー（クラスタ化インデックス）を追加することによって非クラスタ化インデックスの再構築が行われ、RID（列ID）がプライマリーキーに置き換えられるためです。

Alter table, create/alter indexはユニーク、および、プライマリーキー制約/インデックスを制御するためのONLINEオプションを持っています。可能であれば、最高のパフォーマンス、および、最も高い並行性を実現するために、インデックス操作の際はONLINEオプションを使うべきです。もしくは、メンテナンスの時間を別途設けてこれらの操作を行うのが賢明でしょう。

結論、および、ベスト・プラクティス

SQL Server 2005の動作を理解することにより、効果的にスキーマの変更を制御することができます。このナレッジによって、スキーマの変更に付随して起こる望ましくない処理、例えば意図しない読み込み処理、書き込み処理など、を回避することができ、高い並行性、および、可用性を実現する、最も速く、最も簡単な方法を利用することができます。

以下の場合、最も速くスキーマ変更を行うことができます：

1. NULLプロパティを設定して列を追加

2. NULL、および、デフォルトプロパティを設定して列を追加

3. NOT NULLプロパティをNULLに変更

4. デフォルト制約を追加

5. チェック、または、デフォルト制約を削除

以下の場合は変更に付随して読み込み、または、書き込み処理が発生するため、スキーマ変更の処理は最も遅くなります。

1. チェック制約はチェックを行うためにテーブルの全ての行の読み込みが発生

2. NULLプロパティの列にデフォルト制約と「WITH VALUES」句の組み合わせを適応するとバッチ更新処理が発生

3. NOT NULL制約を（デフォルト制約と共に）追加するとバッチ更新処理が発生

4. NULLプロパティをNOT NULLに変更するとバッチ更新処理が発生

5. データ型、または、データ長を変更するとバッチ更新処理が発生。唯一の例外はvarchar型の長さを拡張した場合。

結論として、パフォーマンス、および、並行性を最も高くするための、大規模なテーブルにおけるスキーマ変更のベストプラクティスはNULLプロパティで列を追加することからスタートします。もし、NULL値を許容できないのであれば、そのアプリケーションはNOT NULLで列を追加しなければならないでしょう。「スキーマ変更の制御（パート2）」では、NULLプロパティで追加された新しい列のバッチ更新処理を分離することによって、パフォーマンスと並行性を最大限に高めること方法を紹介します。そのバッチ更新処理は、パフォーマンス、および、並行性を高くするために、複数の部分的な更新処理に置き換えられます。これは並行性を損なわずに列のデータ型やデータ長を変更するためのテクニックです。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

パーティション・テーブルにおけるパフォーマンスの考察

koheiu — Wed, 13 Jun 2007 06:30:00 GMT

マイクロソフトの植田です。

今回はパーティション分割とパフォーマンスに関する話題をご紹介したいと思います。

http://blogs.msdn.com/sqlcat/archive/2005/11/30/498415.aspx

注：下記内容に関する詳細の確認をご希望される場合は上記のブログを参照いただけますようお願いします。

本ドキュメントは以下の方を対象としております。

l 開発者、テストエンジニア、データベース・アドミニストレータ

l データベース、および、Microsoft SQL Serverについて基本的な知識をお持ちの方

パーティション・テーブルにおける並列度、パフォーマンスの考察

質問：SQL Server 2005でパーティション分割されたテーブルに対してクエリを行ったとき、どの程度の並列度が期待でき、パフォーマンスにどのように影響するのでしょうか。

答え：まず背景として、SQL Server 2005のパーティション分割は管理、および、可用性の観点で大きな機能改善がされています。管理面ではメタ・データのスイッチ・イン／スイッチ・アウトのみでパーティション分割されたデータの挿入、削除が可能になりました（挿入／削除先のテーブルがスライディング・ウィンドウ・シナリオの要求を満たしている場合。スライディング・ウィンドウ・シナリオについてはBooks Onlineの以下の記述が参考になります「データのサブセットを管理するためのパーティション設計」）。可用性においては、インデックス構築、並列処理、および、ファイルグループ含まれる個々のファイル単位でのリストアが行えるようになりました（詳細は以下のblog「SQL Server 2005 Online Piecemeal Restore シナリオによる可用性向上」をご参照ください。

では、テーブルをパーティション分割することによって、どのようにパフォーマンスが影響を受けるか見ていきましょう。パーティショニングを使っているか否かにかかわらず、並列実行プランの選択はCPU数、クエリのコスト、利用可能なメモリと現在の業務負荷によって決定されます。ここで述べられる以下の考察は、想定される環境が並列実行を行う条件を満たしているときのみ有効です（例えばCPUが複数存在し、十分な容量のメモリを搭載している等）。

あるクエリが一つのパーティションのみ使用する場合、例えば一つのパーティションを除いて他は全て排除されるとき、SQL Server 2005の内部パーティション並列機構はsp_configureの最大並列度（Maximum Degree of Parallelism: MAXDOP）の値を最大として、複数のスレッドを使用して行の取得処理を並列化します。MAXDOPはたいていデフォルトの値0に設定されており、その場合、MAXDOPは総CPU数と等しくなります。クエリが2つ以上のパーティションにまたがる時、一つのパーティションにつき、スレッドを一つだけ用いて値が取得されます。

もしパーティションの数がMAXDOP以下であれば、データ取得処理は、スレッドがCXPACKET待ちになるまで、複数のスレッドで並列化されるでしょう。パーティションの数がMAXDOPよりも多い場合、SQL Server 2005のオンデマンド並列化は、あるスレッドが一つのパーティションにおいて処理を完結した後、次のパーティションについての処理が順次自動的に開始されることを意味します。例えば、16パーティション存在していてMAXDOPが8の場合、最初のスレッドがパーティション1-8に対して処理を行います。最初に処理を完了したスレッドは、次はパーティション9において処理を開始し、その次のスレッドはパーティション10、といった具合に処理が行われます。

8個以上のたくさんのCPUを持った大規模なマシンで、クエリ・パフォーマンスが最低となるケースは2つのパーティションにまたがる一つの「SELECT」文を実行するケースです（テーブル1参照）。行を取得するサブ・シーケンスの手順においてはMAXDOPの値が適応されていますが（テーブル2の緑のハイライトの部分参照）、一つのパーティションに対して一つのスレッドのみが行を取得するのに使用されます（テーブル2の黄色でハイライトされた、パーティション80、81、および、実行スレッド数列参照）。

テーブル1：2週間分のデータを取得

SELECT

SUM(Sales_Qty) as Sales_Qty,

SUM(Sale_Amt) as Sales_Amount

FROM SalesDB.dbo.Tbl_Fact_ Sales –- Partitioned by week

WHERE date_id between '20050703' and '20050716'

テーブル2：プロファイル統計：MAXDOP = 12

Rows	Executes	StmtText
1	1	SELECT SUM([Sales_Qty]) [Sales_Qty],SUM([Sale_Amt]) [Sales_Amount] FROM [SalesDB].[dbo].[Tbl_Fact_Sales] WHERE [date_id]>=@1 AND [date_id]<=@2
0	0	\|--Compute Scalar(DEFINE:([Expr1002]=CASE WHEN [globalagg1008]=(0) THEN NULL ELSE [globalagg1010] END, [Expr1003]=CASE WHEN [globalagg1012]=(0) THEN NULL ELSE [globalagg1014] END))
1	1	\|--Stream Aggregate(DEFINE:([globalagg1008]=SUM([partialagg1007]), [globalagg1010]=SUM([partialagg1009]), [globalagg1012]=SUM([partialagg1011]), [globalagg1014]=SUM([partialagg1013])))
2	1	\|--Parallelism(Gather Streams)
2	12	\|--Stream Aggregate(DEFINE:([partialagg1007]=COUNT_BIG([SalesDB].[dbo].[Tbl_Fact_Sales].[Sales_Qty] as [ss].[Sales_Qty]), [partialagg1009]=SUM([SalesDB].[dbo].[Tbl_Fact_Sales].[Sales_Qty] as [ss].[Sales_Qty]), [partialagg1011]=COUNT_BIG([SalesDB].[dbo].[Tbl_Fact_Sales].[Sale_Amt] as [ss].[Sale_Amt]), [partialagg1013]=SUM([SalesDB].[dbo].[Tbl_Fact_Sales].[Sale_Amt] as [ss].[Sale_Amt])))
20577235	12	\|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1006]) PARTITION ID:([PtnIds1006]))
2	12	\|--Parallelism(Distribute Streams, Demand Partitioning)
2	1	\| \|--Constant Scan(VALUES:(((80)),((81))))
20577235	2	\|--Index Seek(OBJECT:([SalesDB].[dbo].[Tbl_Fact_Sales].[IX_Tbl_Fact_Sales_SKDteItmStrIDSalQtySalAmtDiscMkd] AS [ss]), SEEK:([ss].[SK_Date_ID] >= (20050703) AND [ss].[SK_Date_ID] <= (20050716)) ORDERED FORWARD PARTITION ID:([PtnIds1006]))

例えば、月ごとにパーティション分割されている、テラバイトサイズのセールス・テーブルがあったとします。よくあるクエリ・パターンは今月のデータを先月、または、去年の同月のデータと比較することでしょう。以下、月ごとにパーティション分割した場合と週ごとにパーティション分割した場合における、クエリと並列度の関係を示します。

テーブル3：月ごとにパーティション分割

WHERE句

パーティション数

取得の並列度

単一SELECT文

SELECT …. WHERE DateCol BETWEEN ’10/1/2005’ and ‘11/30/2005’

1パーティションあたり1スレッド

SELECT

UNION SELECT

[UNION SELECT]

Select …. Where DateCol between ’10/1/2005’ and ‘10/31/2005

UNION

Select …. Where DateCol between ’11/1/2005’ and ‘11/30/2005

１SELECT文あたり１つ

パーティションあたりMAXDOP個のスレッド

テーブル4：週ごとにパーティション分割：11月1-15日までの売り上げ

WHERE句

パーティション数

取得の並列度

単一SELECT文

SELECT SUM(Sales) from WKSales

WHERE DateCol BETWEEN ’11/1/2005’ and ‘11/15/2005’

1パーティションあたり1スレッド

SELECT

UNION SELECT

[UNION SELECT]

SELECT SUM(Sales) from WKSales

WHERE DateCol BETWEEN ’11/1/2005’ and ‘11/5/2005’

UNION

SELECT SUM(Sales) from WKSales

WHERE DateCol BETWEEN ’11/6/2005’ and ‘11/12/2005’

UNION

SELECT SUM(Sales) from WKSales

WHERE DateCol BETWEEN ’11/13/2005’ and ‘11/15/2005’

１SELECT文あたり１つ

パーティションあたりMAXDOP個のスレッド

一つの大きなモノリシックなテーブルにおいては、管理性、および、可用性に関しては課題があるかも知れませんが、よいパフォーマンスが得られるケースがあります。例えば、2つのパーティションにまたがった、1TBのテーブルにクエリを発行する場合、それぞれのパーティションから行を取得するために、一つのパーティションに１つのみスレッドを割り当てることができます。対照的に、モノリシックな1TBのテーブルから行を取得する場合は、MAXDOP数分のスレッドを割り当てることができます（テーブル5参照）。

テーブル5：モノリシックなBigSalesTable

	WHERE句	パーティション数	取得の並列度
単一SELECT文	SELECT …. WHERE DateCol BETWEEN ’10/1/2005’ and ‘11/30/2005’	N/A	MAXDOP

ベスト・プラクティス

上記ではパーティション分割、および、並列処理はデータ・ウェアハウスの業務、バッチ処理、および、レポーティングに最も適したパフォーマンスを発揮します（全てのデータ･ウェアハウスの環境において全てのクエリを並列化することがいつも望ましいとは限りませんが）。特に、並列化はシステムが同時に2,3のクエリを発行していて、それらのクエリの実行時間を最短にして出来る限り多くのリソースを利用可能にしたいとき最も効果的です。もし、そのデータ・ウェアハウスがすでに多くの処理を同時並行で行っている場合、複数の単一スレッド・クエリによって利用可能なリソースをすでに消費してしまっている恐れがあるため、並列化はスループットの向上や応答時間の短縮に寄与しないでしょう。同様の理由で、同時並行で多くの処理が行われるOLTP業務では、パフォーマンス向上のために並列化することは望まないでしょう。

パーティショニングの粒度（例えば、日にち単位、週単位、月単位）を決定する時は、ユーザーのよく使うクエリ・パターンを考慮してください。8CPU以上の大規模なマルチ・プロセッサ・マシンで最も高い並列パフォーマンスを得るためには、クエリの並列化を最大限にするのが望ましいでしょう、例えば最低でもパーティションごとにMAXDOP数にしてください。テーブル3、および、テーブル4で示しているように、単一パーティションごとにクエリを発行して、その集合（ユニオン）を要求するSQL文に書き換えることにより、パフォーマンスは向上します。

結論として、SQL Server 2005 におけるパーティション分割されたテーブルに対する並列問い合わせで最もよいパフォーマンスを得る方法は、単一のパーティションそれぞれに「SELECT」文を発行する（内部パーティション並列化を得る）、または、一つの「SELECT」文に対して多くのパーティションを設定する（パーティションごとにスレッドを一つ割り当てる）ことです。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

No.	概要
1	INSERT Performance ランダムに値を作成した1,000,000行のデータをテーブルに挿入し、単位時間当たりの平均処理速度を測定します。1回のINSERTで1行挿入するため、INSERT文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。 INSERT INTO Tab1(ORG_KEY, PROD_KEY, TIME_KEY, UPDATE_DATE) VALUES (9717, 46273, 206, ‘2007-02-01 00:00:00:000’)
2	UPDATE Performance テーブル中のランダムに選んだ1,000,000行のデータを更新し、単位時間当たりの平均処理速度を測定します。1回のUPDATEで1行更新するため、UPDATE文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。 UPDATE Tab1 SET UPDATE_DATE=‘2007-02-01 00:00:00:000’ WHERE ORG_KEY=14517 AND PROD_KEY=19417 AND TIME_KEY=225
3	DELETE Performance テーブル中のランダムに選んだ1,000,000行のデータを削除し、単位時間当たりの平均処理速度を測定します。1回のDELETEで1行削除するため、DELETE文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。 DELETE Tab1 WHERE ORG_KEY=5718 AND PROD_KEY=18193 AND TIME_KEY=52
4	SELECT Performance a. テーブル中のランダムに選んだ1,000,000行のデータを抽出し、単位時間当たりの平均処理速度を測定します。1回のSELECTで1行選択するため、SELECT文を1,000,000回処理して平均を求めます。サンプルT-SQL文は以下です。 SELECT * FROM Tab1 WHERE ORG_KEY=2717 AND PROD_KEY=15385 AND TIME_KEY=3 b. テーブル中であるインデックスキーの範囲にあるデータを抽出し、その処理を1,000,000回行って単位時間当たりの平均処理速度を測定します。1回のSELECTで選択される行数は258行でした。サンプルT-SQL文は以下です。 SELECT * FROM Tab1 WHERE (ORG_KEY=117 OR ORG_KEY=118 OR ORG_KEY=119) AND PROD_KEY=45505

SQL Server 開発チーム ブログ : Best Practice

SQL Server 2008 データウェアハウスシナリオ Tips and Tricks Part 3

SQL Server ベストプラクティス 日本語版 Top 10 リストが追加されました（sqlcat.com）

SQL Server 2008 データウェアハウスシナリオ Tips and Tricks Part 2

Hyper-V 環境における SQL Server 2008 のベストプラクティスとパフォーマンスの推奨事項

SQL Server 2008 データウェアハウスシナリオ Tips and Tricks Part 1

非ユニコードデータ型をユニコードデータ型に変換する際のベスト・プラクティス

データベース ミラーリングとログ配布を組み合わせた高可用ソリューション

SQL Server Best Practice 日本語技術文書が公開されました

SQL Server 2005 トランザクション・レプリケーションの最適化 (SubscriptionStreams)

パフォーマンス比較；クラスタ化インデックス vs. ヒープ

スキーマ変更時のベスト・プラクティス その２

SQL Server 2005 パフォーマンス・チューニングツール；DMVStats 1.01

スキーマ変更時のベスト・プラクティス その１

パーティション・テーブルにおけるパフォーマンスの考察

SQL Server 開発チームブログ : Best Practice

SQL Server ベストプラクティス日本語版　Top 10 リストが追加されました（sqlcat.com）

SQL Server 2008 データウェアハウスシナリオ　Tips and Tricks Part 2

SQL Server 2008 データウェアハウスシナリオ　Tips and Tricks Part 1

データベースミラーリングとログ配布を組み合わせた高可用ソリューション

パフォーマンス比較；クラスタ化インデックス　vs.　ヒープ

スキーマ変更時のベスト・プラクティス　その２

スキーマ変更時のベスト・プラクティス　その１