SQL Server 開発チームブログ : SQL Server 2008

SQL Server 2008 CQI 書籍 (MS-Press) 出版

thoshi — Wed, 13 May 2009 05:29:00 GMT

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

SQL Server 2008リリース時に日本独自にパートナー様と共同実施したCQI (Center of Quality Innovation) の成果がホワイトペーパーだけでなくさらなる有益な情報を加えて書籍となりました。日経BPソフトプレス様より順次出版とのことですので、書店等でぜひご覧いただければと思います。技術者の方にはじっくり読める書籍もまだまだ重要と位置づけております。

徹底検証 SQL Server 2008 コンプライアンス＆情報セキュリティ
徹底検証 SQL Server 2008 移行・アップグレード＆データベースサーバー統合
徹底検証 SQL Server 2008 データウェアハウス構築 (近日公開)

改めまして、ご協力していただいた皆様、本当にありがとうございました。

CQI 徹底検証シリーズにデータウェアハウスシナリオのホワイトペーパーが追加されました

koheiu — Sat, 29 Nov 2008 09:00:00 GMT

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

たびたび予告させていただいていました、SQL Server 2008データウェアハウスシナリオのホワイトペーパーが公開されました。

SQL Server BIBLE（技術者必読情報）, SQL Server 徹底検証

非常に規模の大きな検証となり、ホワイトペーパーも複数あります。大きく2つのカテゴリーがあり、環境構築編と運用管理編があります。

環境構築編

データウェアハウスDBの設計からキューブの設定方法、レポートの作成/アップロード手順、および、ExcelからAnalysis Servicesキューブに対する自由検索、レポートアクションの設定などがカバーされています。「大規模データウェアハウス実践ガイド（環境構築編）」では概要が説明され、細かな設定方法などは「詳細編」に、なるべくわかりやすいように記載させていただきました。概要編を読んで興味のある部分を掘り下げるために詳細編を読む、といったように活用いただけると幸いです。アクセス制御の実装に関しては弊社コンサルタントを交えて、なるべく実践的な内容になるよう心がけました。

運用管理編

データウェアハウスDBやAnalysis Servicesキューブのメンテナンス（日次データロード、バックアップ、ディメンジョンテーブルの更新、キューブの更新、など）から障害時の対応手順などがカバーされています。こちらは実際の検証で得られたデータを元に、SQL Server 2008のパフォーマンスに関する考察などを盛り込みました。特にSQL Server 2008の新機能である、データ圧縮/バックアップ圧縮に関しては大変有意義なデータが得られたと思っていますので興味のある方は、是非ご一読ください。こちらも概要編と詳細編に分かれておりますので、まずは概要編をさらっとお読みになることをお勧めします。なお、本検証で使用したSQL Server Integration Servicesのサンプルパッケージもダウンロード可能です。全ての環境で動作する保障は出来かねますが、何かの参考になれば幸いです。

ご意見やご感想を持たれた方はお気軽にポストしていただけると嬉しいです。

よろしくお願いします。

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 2008 CQI 徹底検証シリーズ　ホワイトペーパー追加のお知らせ

yukihs — Tue, 18 Nov 2008 06:32:00 GMT

マイクロソフトの笹瀬です。

SQL Server 徹底検証シリーズ、ご活用されていますか？

弊社では、SQL Server の製品出荷前から、各機能の多岐にわたる検証作業をフィールドから集めたシナリオをベースに行っています。

この検証作業は、CQI（Center of Quality Innovation）というプロジェクトで、マイクロソフト調布技術センター (東京都調布市) にて、マイクロソフトの製品開発担当部門、SE 部門、コンサルティング部門、サポート部門の各担当者およびマイクロソフトのパートナー各社との共同プロジェクトとして実施されています。

その検証結果をホワイトペーパーにまとめ、「SQL Server 2008 徹底検証シリーズ」として公開させていただいております。

既にご好評をいただいている 「コンプライアンス実現のためのガイドライン」に加え、新たに以下の３種類のホワイトペーパーを追加いたしました。

l データベースサーバー統合実践ガイド

l ISMS/ISO27001 コンプライアンスのためのガイドライン

l 旧バージョンからの移行とアップグレード実践ガイド

「データベースサーバー統合実践ガイド」は、分散されたデータベースサーバー環境を SQL Server 2008 に統合するための実践ガイドです。データベースサーバー統合を三種類の手法で解説しています。関連する SQL Server の各機能、性能測定の結果を解説しながら各手法のメリット、デメリットも解説しています。本シナリオは、日本ヒューレット・パッカード株式会社(日本HP)殿と共同検証を行い、その結果をホワイトペーパーにまとめたものです。一方で、現在、日本HP殿で性能測定の検証結果を詳細にまとめたホワイトペーパーを作成中です。

「ISMS/ISO27001 コンプライアンスのためのガイドライン」は、SQL Server 2008 を利用したデータベース運用環境において、情報セキュリティのマネジメントサイクルを確立し、ISMS (ISO27001) コンプライアンスを実現するためのガイドです。ISMS 規格 (ISO/IEC 27001:2005) からデータベース運用に深く関わる 31 の管理策を選んで、管理策ごとに ISMS 運用の Plan (計画)、Do (実行)、Check (評価)、Act (改善) を実現するための手順を解説しています。なお、長年 ISMS 運用に取り組まれてきた「東芝セミコンダクター社」様における SQL Server 2008 のセキュリティ運用事例も掲載しています。

「旧バージョンからの移行とアップグレード実践ガイド」は、SQL Server 2000、SQL Server 2005 で構築されたシステムを SQL Server 2008 へ移行またはアップグレードするための実践ガイドです。データベースエンジン、Analysis Services, Integration Services、Reporting Services の旧バージョンからの移行手順、性能の比較などを解説しています。

本シナリオは、日本ユニシス株式会社殿と共同検証を行い、その結果をホワイトペーパーにまとめたものです。

いずれも約数か月の期間、社内の各部門とパートナー様でバーチャルチームを編成して、検証と議論を重ねた結果をホワイトペーパーにまとめました。

ぜひ、ご活用いただければと思います。

まだ、 「大規模データウェアハウス実践ガイド」の作業が若干残っていて、現在、最後のレビューを行っているところです。

近日公開できると思いますので、こちらもご期待ください。

笹瀬

暗号化されたデータベースとログ配布、ミラーリング、クラスタリング

osamuhir — Thu, 13 Nov 2008 08:11:00 GMT

マイクロソフトの平山です。

前回、前々回と続けてきた SQL Server 2008 からの新機能「透過的なデータ暗号化」を、他の機能の組み合わせて使うときの注意点を紹介するというテーマの最終回です。
今回は「ログ配布」、「データベースミラーリング」、「フェールオーバークラスタリング」を取り上げてみます。

それぞれ機能の基本的な動作を考えてみると、注意点や必要な事前準備を推測することができると思います。

まず「ログ配布」について考えてみます。
通常の場合は初期同期のための作業として、プライマリデータベースをセカンダリサーバーに復元します。
その際に、プライマリデータベースが暗号化されていると、セカンダリサーバーへの復元が失敗してしまいます。

次に「データベースミラーリング」の場合です。
ミラーリングの設定の事前準備として、プリンシパルサーバーのデータベースをミラーサーバーに復元しておく必要があります。
その際に、プリンシパルサーバーのデータベースが暗号化されていると(ログ配布の場合と同様に)、ミラーサーバへの復元時にエラーが発生してしまいます。

さて、この問題を回避するには、どうすればよいでしょうか?
その答えは前々回のエントリで紹介してあります。それぞれの場合の事前準備として、「ログ配布」の場合はセカンダリサーバーで、「データベースミラーリング」の場合はミラーサーバーで、サービスマスターキーの作成と証明書の復元を行っておく必要があります。
それ以外は、通常の設定方法と同じです。

最後に「フェールオーバークラスタリング」について紹介します。
フェールオーバークラスタリングが構成されている SQL Server インスタンスに暗号化されているデータベースが存在したとしても、特に事前準備はありません。
クラスタリング環境では、複数のノードのうちのいづれかひとつのノードで SQL Server インスタンスが稼働することができます。しかし、実体としてのデータベース (ユーザデータベースおよびシステムデータベース) は複数のノード分存在するのではなく、全ノードで共有しています。
そのため、サービスマスターキーや証明書も、どのノードで SQL Server インスタンスが起動しても同じものを使用していることになります。
ということで、事前に特別な考慮をすることなくクラスタ環境で暗号化されたデータベースを使用することができます。

暗号化されたデータベースとレプリケーション

osamuhir — Thu, 06 Nov 2008 09:10:00 GMT

マイクロソフトの平山です。
「透過的なデータ暗号化」を使用して暗号化されたデータベースの使い勝手を追求するシリーズの 2 回目の今回は、レプリケーションとの関連を紹介します。

レプリケーションでパブリッシュしようとするデータベースが暗号化されていても、サブスクライバへレプリケートを行うときに必要となる情報は、暗号化されていない状態で distribution データベースに格納されています。
つまり、レプリケート実行時にデータを復号化する必要がないため、サブスクライバ側でのサービスマスターキーの作成や証明書のリストアは必須ではありません。また、この動作はいずれレプリケーションのタイプにも当てはまります。

といった前提のもとに、暗号化されたデータベースをレプリケートする場合の注意点は次のようになります。

注意点 1:
パブリッシャデータベースが暗号化されていたとしても、サブスクライバデータベースが自動的に暗号化されることはありません。必要に応じて個別に暗号化を行ってください。
サブスクライバの暗号化の際には、必ずしもパブリッシャと同じ証明書を使用する必要はありません。

注意点 2:
パブリッシャデータベースが暗号化されていても、スナップショットレプリケーションや他のタイプのレプリケーションの初期化時に使用されるデータベースの初期スナップショットは暗号化されていません。つまり、ネイティブ形式のファイルとして出力されていても、バイナリエディタなどで展開されてしまうと、ファイルの内容をのぞき見られてしまう危険性があります。
そのため、スナップショットファイルを配置するフォルダの権限を適切に管理することで対処する必要があります。

注意点 3:
レプリケーションに関連するサイト間の通信を、より堅牢にするためにパブリッシャ、ディストリビュータ、サブスクライバ間の伝送経路の暗号化を検討してください。

暗号化されたデータベースを別インスタンスに復元する方法

osamuhir — Wed, 22 Oct 2008 08:28:00 GMT

マイクロソフトの平山です。これから数回にわたり「透過的なデータ暗号化」を使用して暗号化されたデータベースの使い勝手について紹介していきたいと思います。

SQL Server 2008 から導入された、「透過的なデータ暗号化」のメリットのひとつとして、データベースの物理ファイルやバックアップが流出したり盗難にあってもデータをのぞき見されることがない、ということが挙げられます。それは次のような理由によります。

データベース全体が暗号化されるため、流出したファイルをバイナリエディタなどで展開しても、ファイルの中身を理解することができない
データベースの復元(あるいはアタッチ)には証明書が必要なので、バックアップファイルのみが流出しても不正にリストアされてしまうことはない

SQL Server オンラインブックなどのドキュメントには、データベースを暗号化するための方法は親切に解説してありますが、暗号化したデータベースを復元する方法をわかりやすくまとめている箇所がありません。そこで今回のエントリでは、暗号化されたデータベースを別インスタンスに復元する方法を紹介したいと思います。

●まずはデータベースの暗号化までのおさらい

1. データベースとテーブルを作成します
create database TDE_DB
go
use TDE_DB
go
create table t1 (c1 nvarchar(500))
go
2. サービスマスターキーを作成します
use master
go
create master key encryption by password = 'secret!masterKey1'
go
3. 証明書を作成します
create certificate TDE_TEST with subject = 'Test Certificate'
go
3. データベース暗号化キーを作成します
use TDE_DB
go
create database encryption key with algorithm = AES_256
encryption by server certificate TDE_TEST
go
4. データベースを暗号化します
alter database TDE_DB set encryption on
go

●続いてデータベースと証明書のバックアップ

1. データベースのバックアップ
backup database TDE_DB to disk='C:\TDE_DB.bak'
go
2. 証明書のバックアップ
backup certificate TDE_TEST to file = 'C:\TDE_TEST.cer'
with private key (file = 'c:\TDE_TEST_KEY.pvk',encryption by password = 'secret!masterKey1')
go

●いよいよ別インスタンスへの復元です。データベースと証明書のバックアップファイルは復元先のマシンにコピーしておいてください。

1. 復元先のインスタンスでも独自のサービスマスターキーを作成しておく必要があります
create master key encryption by password = 'tdetest!tdetest1'
go
2. データベースの復元に先駆けて、証明書を復元します
create certificate TDE_TEST
from file = 'c:\TDE_TEST.cer'
with private key (file = 'c:\TDE_TEST_KEY.pvk', decryption by password ='secret!masterKey1')
go
3. これで別インスタンスへのデータベースの復元が可能になります
restore database TDE_DB from disk='C:\TDE_DB.bak'
go

ちなみに上記の手順ではなく、単にデータベースの復元のみを行うと次のようなエラーが発生します。

メッセージ 33111、レベル 16、状態 3、行 1
拇印 '0xC31E2828C900C230B2BC1E9BEBE5B66DCAB9EFXX' でサーバー証明書が見つかりません。

また、データベースの復元の際にとても重要な意味を持つ、サービスマスターキーのパスワード、証明書のバックアップの管理には細心の注意を払うようにしてください。

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を使用したデータロードのトピックを取り上げたいと思っています。よろしくお願いします。

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

SQL Server 2008 RTM (開発完了)!

thoshi — Wed, 06 Aug 2008 14:07:00 GMT

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

約3年の開発期間をかけたSQL Server 2008の全開発工程が終了しました。

改めて、製品開発に関わっていただいた社内・社外の多くの皆様、ありがとうございました。いろいろな方と一緒にいい仕事ができたと思っております。ある程度長く製品開発に参加すると、対象は「ソフトウェア」ではありますが愛情が芽生えかわいく思えるときがあります。今回、すでに実績のあるSQL Server 2005のコードベースに開発を進めてきたことは、製品品質が重視される今日において正しい選択だったと思っております。同時に魅力的な機能追加とSQL Server 2005リリースから3年以内というスケジュールを守ることが我々の使命であったわけですが、社内の開発プロセスの大規模な変更と継続的なカイゼンによりいい成果が出せたのではと考えております。

自信をもって製品を出荷したとはいえ、今後の市場の反応がどう出るかは非常に気になるところです。今年に入って特に日本市場も含め世界経済の先行きの不透明さが増し、企業のIT投資が厳しくなっているように思えます。エンタープライズ製品の結果が出るのは場合によっては1年以上かかると思います。しかしながら、ポジティブな側面としてデータに関する市場は情報量増加のトレンドとストレージデバイスなどのコスト減により爆発的に伸びております。より大規模環境にも対応できるデータベースの役割、それら蓄積された大規模なデータ (データウェアハウス) を経営に活用するためのBI市場が非常に伸びており、我々の製品も年々2桁成長を続けております。SQL Server 2008の登場により、コンプライアンスや既存のSQL Server 2000/2005のユーザー様からの移行シナリオを含めて成長を期待しております。

我々の日本の開発メンバーは日本独自の取り組みであるCQIで蓄積した一部のノウハウを反映したホワイトペーパー公開にむけての活動、TechEd 2008での準備作業などがあり、9月あたりまではフィールド、パートナー様と一緒に活動する予定です。ちなみに、より深い広範囲なノウハウは関わった社内・社外のエンジニアの方に蓄積されております。また、すでに次期バージョンの計画を始めており、それにあわせてUS本社開発側と共同チームを編成し、日米往復しながら着々と準備を進めております。

横浜で行われる弊社のイベントTechEd 2008会場で皆様にお会いできることを楽しみにしております。私自身も含め、SQL Server 2008の開発に関わったメンバーが最終日のPeerTalk Lunchには顔を出す予定ですので、気軽に声をおかけください。

日本のSQL Server 2008 サイト

http://www.microsoft.com/japan/sql/2008/

(20本以上の質の高い自習書を含め、この時点でのコンテンツの充実振りは驚くはずです。)

TechEd 2008 サイト

http://www.microsoft.com/japan/teched/2008/

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

日本語照合順序 Japanese と Japanese_XJIS_100、Japanese_Bushu_Kakusu_100　の比較

Akio Jose — Mon, 16 Jun 2008 12:45:00 GMT

はじめまして、マイクロソフト保瀬です。SQL Server 開発部門でテスターをしております。日本のSQL Serverチームがブログを開設してから1年以上が経ちますが、遅れ馳せながら今回はじめて書きます。これを機にできる限り、継続的かつ頻繁に情報発信できればと思います。よろしくお願いします。

初回は、トピックとしてあまり取り上げられないSQLの照合順序についていろいろと見ていこうと思います。CTP版やRC版等をお試しになっている方はお気づきと思いますが、新たに２つ照合順序が追加されています。

SQL Server に新規に照合順序が追加されることなった背景に Windows Server 2008 と足並みをそろえるという目的がありました。Windows Vistaを既にご使用の方は、お気付きと思いますが、コントロールパネルの「地域と言語のオプション」のところで並べ替えの設定ができます（下図参照）。ここで「XJIS」または「部首／画数」の何れかを指定できるようになっています。今回 SQL Server に新たに追加された日本語の照合順序名である Japanese_XJIS_100 及び Japanese_Bushu_Kakusu_100 はWindows Vista と Windows Server 2008 で指定可能となった「並べ替え」の内容に沿うような形で追加されています。

Japanese_XJIS_100 の照合順序で何が変わったか、特に以前からあるJapanese 照合順序などと比較した場合の文字の並び替えなど動作について見ていきましょう。まずは「論より証拠」で、実際にそれぞれJapanese_XJIS_100とJapaneseの照合順序でソートした場合の結果を比べていくことにします。尚、今回は一文字単位の比較としました。例えば、「は」と「ば」を比較するのであれば、where 句の内容として "where N'は' < N'ば' collate Japanese_XJIS_100_CI_AS" といった具合で比較していくことにしました。２文字以上の文字列を含む比較となると、内部エンジンの文字列ソートについて触れておく必要が出てくるので、それはまた別の機会にしておきます。

比較内容として、今回は平仮名・片仮名の文字（単一文字のみ）を使って比較してみました。全ての五十音文字を使用するとかなりのテストパターンになるので、今回は清音、濁音、半濁音、平仮名、片仮名等の観点から、Japanese と Japanese_XJIS_100／Japanese_Bushu_Kakusu_100 の各照合順序の比較結果の違い検証してみました。

下記表１にグループ分けされた五十音文字を示します：

表１（参考：JIS X 4061「日本語文字列照合順番」)

グループ	グループ文字	清音	大文字（L)・小文字（S)	平仮名 (H)/ 片仮名 (K)
1	あいうえおかきくけこさしすせとたちつてとなにぬねのはひふへほまみむめもやゆよらりるれろわゐゑをん	清音	L	H
2	がぎぐげござじずぜぞだぢづでどばびぶべぼ	濁音	L	H
3	ぱぴぷぺぽ	半濁音	L	H
4	ぁぃぅぇぉっゃゅょゎ	清音	S	H
（※）5	ゝ	清音	(繰り返し文字)	H
（※）6	ゞ	濁音	(繰り返し文字)	H
7	アイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワヰヱヲン	清音	L	K
8	ヴガギグゲゴザジズゼゾダヂヅデドバビブベボ	濁音	L	K
9	パピプペポ	半濁音	L	K
10	ァィゥェォヵヶッャュョヮ	清音	S	K
（※）11	ヽ	清音	(繰り返し文字)	K
（※）12	ヾ	濁音	(繰り返し文字)	K
（※）13	ー	清音	(長音)	K

（※）今回の検証では繰り返し文字を使用してのテストは除きました

比較方法の基本的な考え方は、上記表１のグループ間での比較を行います。たとえば、grp1 (グループ１）と grp2 （グループ２）を比較する場合、まず grp1の代表文字として「つ」、grp2 の代用文字として「づ」を対象となる比較文字として、さまざまな照合順序を使って比較します。T-SQL文的に記述すると、こんな感じです：

declare @ch1 nchar, @ch2 nchar

set @ch1 = N'つ'

set @ch2 = N'づ'

select case

when @ch1 = @ch2 collate Japanese_ci_as then 0

when @ch1 < @ch2 collate Japanese_ci_as then -1

else 1

end

尚、今回の検証ではグループ間内での比較は行っていません。例えば、grp1 にある「あ」と「い」との比較、grp2 にある「が」と「ぎ」の比較など。

各グループの代表文字は以下の内容で検証しました：

test ID	ch1	ch2	グループ間比較内容
1	つ	づ	grp1 vs grp2
2	は	ぱ	grp1 vs grp3
3	つ	っ	grp1 vs grp4
4	つ	ツ	grp1 vs grp7
5	つ	ヅ	grp1 vs grp8
6	は	パ	grp1 vs grp9
7	つ	ッ	grp1 vs grp10
8	ば	ぱ	grp2 vs grp3
9	づ	っ	grp2 vs grp4
10	づ	ツ	grp2 vs grp7
11	づ	ヅ	grp2 vs grp8
12	ば	バ	grp2 vs grp9
13	づ	っ	grp2 vs grp10
14	ぱ	ハ	grp3 vs grp7
15	ぱ	パ	grp3 vs grp9
16	っ	ツ	grp4 vs grp7
17	っ	ッ	grp4 vs grp10
18	ツ	ヅ	grp7 vs grp8
19	ツ	ッ	grp7 vs grp10
20	バ	パ	grp8 vs grp9
21	ヅ	ッ	grp8 vs grp10

さらに、検証で使用した照合順序名は、Japanese_xx_xx、Japanese_XJIS_100_xx_xx 及び Japanese_Bushu_Kakusu_100_xx_xx です。"xx_xx" の部分はいわゆる「Windows 照合順序サフックス」の部分で 18 通りありますが、今回は BIN系を除く16 通りのものを対象としました。ちなみに、こちらのT-SQL文でサフックスの内容を確認できます：

select name from fn_helpcollations() where name like 'Japanese_XJIS_100%'

実際のテストでは、テスト結果を格納するためのテーブルにテストパターンを挿入しておき、直接テーブルに結果を更新するようにテストしました。テスト結果の（一部抜粋）内容は下記の内容となりました

id	ch1	ch2	Collation	CompareResult	Notes
1	つ	づ	Japanese_CI_AI	0	grp1 vs grp2
2	は	ぱ	Japanese_CI_AI	0	grp1 vs grp3
3	つ	っ	Japanese_CI_AI	0	grp1 vs grp4
4	つ	ツ	Japanese_CI_AI	0	grp1 vs grp7
5	つ	ヅ	Japanese_CI_AI	0	grp1 vs grp8
6	は	パ	Japanese_CI_AI	0	grp1 vs grp9

結果テーブルの主な列の内容は

列	内容
ch1, ch2	比較対象文字
Collation	比較時に使用した照合順序名
CompareResult	結果比較(0, -1, 1)の何れか０：'つ' = 'づ' -1：'つ' < 'づ' 1：'つ' > 'づ'
Notes	比較対照グループ

以下に検証結果をまとめてみました：

(後述補足説明を参照）

グループ間比較	照合順序名 Japanese_xx_xx	照合順序名 Japanese_XJIS_100_xx_xx	照合順序名 Japanese_Bushu_Kakusu_100_xx_xx
grp1 vs grp2	Windows照合順序サフィックス（以下 CompStyle) に「AI」が指定されている場合、grp1 = grp2 となった CompStyle に「AS」が指定されている場合、grp1 < grp2 となった	常に grp1 < grp2 となった	同左
grp1 vs grp3	CompStyle に「AI」が指定されている場合、grp1 = grp3 となった CompStyle に「AS」が指定されている場合、grp1 < grp3 となった	常にgrp1 < grp2 となった	同左
grp1 vs grp4	CompStyle に「AI」が指定されている場合、grp1 = grp4 となった CompStyle に「AS」が指定されている場合、grp1 > grp4 となった	常に grp1 > grp4 となった	同左
grp1 vs grp7	CompStyleに「KS」げ指定されていない場合ｇrp1 = grp7 となった CompStyle に「KS」が指定されている場合に、grp1 > grp7 となった	同左	同左
grp1 vs grp8	CompStyle に「AI_KS」が指定されている場合に、grp1 > grp8 となった CompStyle に「AS」が指定されている場合に grp1 < grp8 となった上記以外は grp1 = grp8 となった	常に grp1 < grp8 となった	同左
grp1 vs grp9	CompStyle に「AI_KS」が指定されている場合に、grp1 > grp9 となった CompStyle に「AS」が指定されている場合に、grp1 < grp9 となった上記以外は grp1 = grp9 となった	常に grp1 < grp9 となった	同左
grp2 vs grp3	CompStyle に「AI」が指定されている場合に、grp2 = grp3 となった CompStyle に「AS] が指定されている場合に、grp2 < grp3 となった	常に grp2 < grp3　となった	同左
grp2 vs grp4	CompStyle に「AI」が指定されている場合、grp2 = grp4 となった CompStyle に「AS」が指定されている場合、grp2 > grp4 となった	常に grp2 > grp4 となった	同左
grp2 vs grp7	CompStyle にgrp2 = grp7 when CI_AI or CI_AI_WS grp2 > grp7 for other	常にgrp2 > grp7 となった	同左
grp2 vs grp8	CompStyle に「KS」が指定されていない場合に grp2 = grp8 となった CompStyle に「KS」が指定されている場合に、grp2 > grp8 となった	同左	同左
grp2 vs grp9	CompStyle に「KS」が指定されていない場合に grp2 = grp8 となった CompStyle に「KS」が指定されている場合に、grp2 > grp8 となった	同左	同左
grp2 vs grp10	CompStyle に「AI」が指定されている場合に、grp2 = grp10 となった CompStyle に「AS」が指定されている場合に、grp2 > grp10 となった	常に grp2 > grp10 となった	同左
grp3 vs grp7	CompStyle に「KS」が指定されていない場合に grp3 = grp7 となった CompStyle に「KS」が指定されている場合に、gr32 > grp7 となった	常に grp3 > grp7 となった	同左
grp3 vs grp9	CompStyle に「KS」が指定されていない場合に、grp3 = grp9 となった CompStyle に「KS」が指定されている場合に、grp3 > grp9 となった	同左	同左
grp4 vs grp10	CompStyle に「KS」が指定されていない場合に、grp4 = grp10 となった CompStyle に「KS」が指定されている場合に、grp4 > grp10 となった	同左	同左
grp4 vs grp7	CompStyle に「AS」が指定されているば場合に、grp4 < grp7 となった CompStyle に「AI」が指定され且つ「KS」が指定されていない場合に、grp4 > grp7 となった上記以外の場合は、grp4 = grp7 となった	常に grp4 < grp7 となった	同左
grp7 vs grp8	CompStyle に「AI」が指定されている場合に、grp7 = grp8 となった CompStyle に「AS」が指定されている場合に、grp7 < grp8 となった	常に grp7 < grp8 となった	同左
grp7 vs grp10	CompStyle に「AI」が指定されている場合に、grp7 = grp10 となった CompStyle に「AS」が指定されている場合に、grp7 > grp10 となった	常に grp7 > grp10 となった	同左
grp8 vs grp9	CompStyle に「AI」が指定されている場合に、grp8 = grp9 となった CompStyle に「AS」が指定されている場合に、grp8 < grp9 となった	常にgrp8 < grp9 となった	同左
grp8 vs grp10	CompStyle に「AI」が指定されている場合に、grp8 = grp10 となった CompStyle に「AS」が指定されている場合に、grp8 > grp10 となった	常に grp8 > grp10 となった	同左

補足説明

上記表の４列目の「Japanese_Bushu_Kakusu_100_xxx」の結果は結局のところ Japanese_XJIS_100 と同様の結果となった。

たとえば、「grp1 vs grp2 」のテスト結果では、以下の照合順序名においては、「つ」＝「づ」と比較される

Japanese_CI_AI

Japanese_CI_AI_WS

Japanese_CI_AI_KS

Japanese_CI_AI_KS_WS

Japanese_CS_AI

Japanese_CS_AI_WS

Japanese_CS_AI_KS

Japanese_CS_AI_KS_WS

また、同様に以下の照合順序名では「つ」＜「づ」と比較される

Japanese_CI_AS

Japanese_CI_AS_WS

Japanese_CI_AS_KS

Japanese_CI_AS_KS_WS

Japanese_CS_AS

Japanese_CS_AS_WS

Japanese_CS_AS_KS

Japanese_CS_AS_KS_WS

そして、更に以下の新規照合順序名では、常に「つ」＜「づ」と比較される

Japanese_Bushu_Kakusu_100_CI_AI

Japanese_Bushu_Kakusu_100_CI_AI_WS

Japanese_Bushu_Kakusu_100_CI_AI_KS

Japanese_Bushu_Kakusu_100_CI_AI_KS_WS

Japanese_Bushu_Kakusu_100_CI_AS

Japanese_Bushu_Kakusu_100_CI_AS_WS

Japanese_Bushu_Kakusu_100_CI_AS_KS

Japanese_Bushu_Kakusu_100_CI_AS_KS_WS

Japanese_Bushu_Kakusu_100_CS_AI

Japanese_Bushu_Kakusu_100_CS_AI_WS

Japanese_Bushu_Kakusu_100_CS_AI_KS

Japanese_Bushu_Kakusu_100_CS_AI_KS_WS

Japanese_Bushu_Kakusu_100_CS_AS

Japanese_Bushu_Kakusu_100_CS_AS_WS

Japanese_Bushu_Kakusu_100_CS_AS_KS

Japanese_Bushu_Kakusu_100_CS_AS_KS_WS

Japanese_XJIS_100_CI_AI

Japanese_XJIS_100_CI_AI_WS

Japanese_XJIS_100_CI_AI_KS

Japanese_XJIS_100_CI_AI_KS_WS

Japanese_XJIS_100_CI_AS

Japanese_XJIS_100_CI_AS_WS

Japanese_XJIS_100_CI_AS_KS

Japanese_XJIS_100_CI_AS_KS_WS

Japanese_XJIS_100_CS_AI

Japanese_XJIS_100_CS_AI_WS

Japanese_XJIS_100_CS_AI_KS

Japanese_XJIS_100_CS_AI_KS_WS

Japanese_XJIS_100_CS_AS

Japanese_XJIS_100_CS_AS_WS

Japanese_XJIS_100_CS_AS_KS

Japanese_XJIS_100_CS_AS_KS_WS

このほかに、「grp1 vs grp7」（表中の5行目の結果）の結果について見ますと、以下の照合順序名で、「つ」＝「ツ」と比較される

Japanese_CI_AI

Japanese_CI_AI_WS

Japanese_CI_AS

Japanese_CI_AS_WS

Japanese_CS_AI

Japanese_CS_AI_WS

Japanese_CS_AS

Japanese_CS_AS_WS

Japanese_Bushu_Kakusu_100_CI_AI

Japanese_Bushu_Kakusu_100_CI_AI_WS

Japanese_Bushu_Kakusu_100_CI_AS

Japanese_Bushu_Kakusu_100_CI_AS_WS

Japanese_Bushu_Kakusu_100_CS_AI

Japanese_Bushu_Kakusu_100_CS_AI_WS

Japanese_Bushu_Kakusu_100_CS_AS

Japanese_Bushu_Kakusu_100_CS_AS_WS

Japanese_XJIS_100_CI_AI

Japanese_XJIS_100_CI_AI_WS

Japanese_XJIS_100_CI_AS

Japanese_XJIS_100_CI_AS_WS

Japanese_XJIS_100_CS_AI

Japanese_XJIS_100_CS_AI_WS

Japanese_XJIS_100_CS_AS

Japanese_XJIS_100_CS_AS_WS

そして、更に以下の照合順序名で、「つ」＞「ツ」と比較される

Japanese_CI_AI_KS

Japanese_CI_AI_KS_WS

Japanese_CI_AS_KS

Japanese_CI_AS_KS_WS

Japanese_CS_AI_KS

Japanese_CS_AI_KS_WS

Japanese_CS_AS_KS

Japanese_CS_AS_KS_WS

Japanese_Bushu_Kakusu_100_CI_AI_KS

Japanese_Bushu_Kakusu_100_CI_AI_KS_WS

Japanese_Bushu_Kakusu_100_CI_AS_KS

Japanese_Bushu_Kakusu_100_CI_AS_KS_WS

Japanese_Bushu_Kakusu_100_CS_AI_KS

Japanese_Bushu_Kakusu_100_CS_AI_KS_WS

Japanese_Bushu_Kakusu_100_CS_AS_KS

Japanese_Bushu_Kakusu_100_CS_AS_KS_WS

Japanese_XJIS_100_CI_AI_KS

Japanese_XJIS_100_CI_AI_KS_WS

Japanese_XJIS_100_CI_AS_KS

Japanese_XJIS_100_CI_AS_KS_WS

Japanese_XJIS_100_CS_AI_KS

Japanese_XJIS_100_CS_AI_KS_WS

Japanese_XJIS_100_CS_AS_KS

Japanese_XJIS_100_CS_AS_KS_WS

さあ、結果としていかがでしたでしょうか？日本語の観点からこの結果が正しいか否かは、読者の主観にお任せします。

今回の検証で使用したビルドは RC0 相当のものでしたが、おそらくリリース時でも同様な動作になるものと思われます。

では、次回はJapanese＿Bushu_Kakusu_100 ついて、いろいろと探っていこうと思います。

ご参考までに、今回の検証で使用したスクリプトを載せておきます。

興味のある方、今回使用した「代表文字」以外の文字で是非試してみてください。

/*****************************************************/

set nocount on

if object_id('compChar') is not null

drop table compChar

create table compChar(id int identity, ch1 nchar(1), ch2 nchar(2), notes varchar(100))

insert compChar values(N'つ', N'づ', 'grp1 vs grp2')

insert compChar values(N'は', N'ぱ', 'grp1 vs grp3')

insert compChar values(N'つ', N'っ', 'grp1 vs grp4')

insert compChar values(N'つ', N'ツ', 'grp1 vs grp7')

insert compChar values(N'つ', N'ヅ', 'grp1 vs grp8')

insert compChar values(N'は', N'パ', 'grp1 vs grp9')

insert compChar values(N'つ', N'ッ', 'grp1 vs grp10')

insert compChar values(N'ば', N'ぱ', 'grp2 vs grp3')

insert compChar values(N'づ', N'っ', 'grp2 vs grp4')

insert compChar values(N'づ', N'ツ', 'grp2 vs grp7')

insert compChar values(N'づ', N'ヅ', 'grp2 vs grp8')

insert compChar values(N'ば', N'バ', 'grp2 vs grp9')

insert compChar values(N'づ', N'っ', 'grp2 vs grp10')

insert compChar values(N'ぱ', N'ハ', 'grp3 vs grp7')

insert compChar values(N'ぱ', N'パ', 'grp3 vs grp9')

insert compChar values(N'っ', N'ツ', 'grp4 vs grp7')

insert compChar values(N'っ', N'ッ', 'grp4 vs grp10')

insert compChar values(N'ツ', N'ヅ', 'grp7 vs grp8')

insert compChar values(N'ツ', N'ッ', 'grp7 vs grp10')

insert compChar values(N'バ', N'パ', 'grp8 vs grp9')

insert compChar values(N'ヅ', N'ッ', 'grp8 vs grp10')

if object_id('TestResult') is not null

drop table TestResult

create table TestResult (

id int identity,

ch1 nchar(1),

ch2 nchar(2),

Collation nvarchar(128),

CompareResult int,

Notes varchar(100))

insert TestResult

select ch1, ch2, name, -2, Notes

from compChar t, fn_helpcollations() c

where COLLATIONPROPERTY(name, 'version') <> 1 and name not like 'Japanese_Unicode%' and

name like 'japan%' and name not like '%bin%'

declare cur cursor for select id, ch1, ch2, Collation from TestResult

declare @id int, @ch1 nchar(1), @ch2 nchar(1), @colName nvarchar(128)

declare @cmd nvarchar(1000)

open cur

fetch cur into @id, @ch1, @ch2, @colName

while @@fetch_status = 0

begin

set @cmd = 'update TestResult set CompareResult = case

when N''' + @ch1 + ''' = N''' + @ch2 + ''' collate ' + @colName + ' then 0

when N''' + @ch1 + ''' < N''' + @ch2 + ''' collate ' + @colName + ' then -1

else 1

end where id = ' + convert(varchar(4), @id)

exec(@cmd)

fetch cur into @id, @ch1, @ch2, @colName

end

close cur

deallocate cur

select * from TestResult

SQL Server 2008 での開発プロセスの変更

thoshi — Fri, 23 May 2008 12:26:00 GMT

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

過去の私のブログで何度か触れておりますが、今回は SQL Server 2008 での開発プロセスの変更に関してより詳しく記述したいと思います。

背景として、我々 SQL Server 開発チームは過去の3つの製品リリース (7.0, 2000, 2005) を経て、市場のニーズや最新のハードウェア、インフラの変化に対応可能な複雑な製品開発、技術を扱うようになりました。それと同時に BI 市場への投資を含め、世界中に数千人クラスの大規模なチームに成長し、プロセス・コミュニケーションが複雑になってきたことが上げられます。SQL Server 2005 に予想以上の歳月をかけてしまったことの反省が大きくあるのですが、我々はその経験から学習し、SQL Server 2005 リリースの後どうすれば次期製品のリリースを高い品質を保ちながら、時代にあった機能追加を行い、リリーススケジュールが大幅に遅れることなく、この規模の開発チームの生産性を最大限に上げることが可能かをSQL Server 2008の開発が本格的に開始される前に考えました。

それが、SQL Server 2008 での新しい Improvementという単位での開発手法になります。メインラインである製品コード、ビルドと完全に分離され、ほとんどすべての開発プロセスであるコーディング、テスト作業を完了後、再度メインラインに組み込んでいきます。Improvementは新機能や機能強化の単位であり、社内的にも Improvement チーム、Improvement がメインラインに check-in されたなど普通に使用しております。同時に数十の Improvement が走り、ビルドも Improvement 毎に作られ、コードのcheck-in、機能テスト、パフォーマンステストなどを終えてメインラインに統合されます。さらにメインラインである製品ビルドで End to End の大規模なテストを社内や全世界の早期導入ユーザー、MVP などの非常に強力なパートナー様の方々と広範囲に行い、最終的に皆様に評価可能な CTP ビルドが作られます。

基本原則

メインラインは常に出荷可能に近い状態を保つ
メインラインへの反映は Improvement の開発完了後に行う

主要なプロセス変更

開発は Improvement 単位でチームが構成され進められる
Improvement はメインラインと分離して開発
コードが完成し広範囲にわたるテスト後、初めてメインラインに組み込まれる

Improvement 単位による開発が今回の開発プロセス変更の中のメインではありますが、実はそれを支える大規模なインフラである Lab、ビルドシステム、メインラインの check-in や CTP リリースをコントロールする Release Management のプロセス、チーム編成、ワークフロー、ドキュメントの整備なども非常に広範囲であり、組織の中で数ヶ月かけて整備、実行されました。最近読んだ本の Toyota Way にも書かれてましたが、一番時間がかかるのがカルチャーの改革だと考えております。SQL Server 2005 の開発スタイルから大幅に変更しているので現場は最初は戸惑いを感じながら、最終的に通常プロセスとして慣れるまでにはいろいろと苦労をしております。実際に Coding している Developer、そのコードをベースにTest Code、Tool を記述したり実際に Test を実行している Test Engineer、プロジェクト全体をドライブしている PM、それを後ろで支えている各マネージャたちが同じ方向を向いて、密に連携して取り組まないといいプロセスも機能しません。ソフトウェアは人間が作っているものであり、カルチャーの改革はとても重要であり時間がかかりますが、約3年という長い時間を経てSQL Server 2008 ではそれが実現に向かっています。

ひとつの具体例として、実際に SQL Server 2008 CTP6 の時点で現リリース製品である SQL Server 2005 以上のパフォーマンス結果が出ております。この結果は、2月のUSでのWindows Server 2008 / Visual Studio 2008 / SQL Server 2008共同ラウンチイベントの際に発表されました。これは SQL Server 2005 の開発中での同じ時期でのタイミングでは実現できなかったことです。我々は現状に満足せずにさらに改善を続けていく、それらのカルチャーを広く浸透させることが長期的に重要だと考えております。

日本でも4月の東京での同様なラウンチイベントを皮切りに、全国で順次イベントが開催され SQL Server 2008 の全貌が明らかになってきていると思います。我々開発チームも東京会場には足を運び、お客様やパートナー様と実際にお話することができました。特に初日のキーノートは立ち見が出るほどの盛況ぶりでした。日頃から一緒にプロジェクトを進めているメンバーもセッション等で活躍し社内のフィールド、パートナー様側の準備も順調に進んでいることを改めて感じました。また、新しい試みである Virtual Launch Experienceも楽しめるのではと思います。

SQL Server 2008日本語ホーム

http://www.microsoft.com/japan/sql/2008/default.mspx

SQL Server 2008 評価版を今すぐ評価いただきたい5つの理由 (開発プロセス編)

http://www.microsoft.com/japan/sql/2008/ctp/features1.mspx

HEROES happen {here} ポータルサイト

http://www.microsoft.com/japan/heroeshappenhere/portal/

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

SQL Server 2008 CTP6 をリリース

thoshi — Thu, 21 Feb 2008 12:07:00 GMT

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

昨日、CTP6である「Microsoft SQL Server 2008 CTP - 2008 年 2 月」版をリリースすることができました。これで SQL Server 2008 で予定されているほぼすべての機能が入ったことになります。今回のリリースにて Windows Server 2008 への対応、Side by Side のインストール、クラスタの機能強化 (制限事項あり) などが含まれます。また、SQL CQI (Center of Quality Innovation) プロジェクトや早期導入プログラムなど一部の日本のパートナー様、お客様にはすでに日本語版を使用して検証開始していただいておりましたが、本リリースで日本語版を含めた9言語のローカライズ版を全世界に公開させていただきました。ローカライズに関しては現在作業中ですので、まだ UI や Books Online (ヘルプドキュメント) には不完全な部分も残っているかと思います。今後様々なアプローチでの製品検証作業を進め、お客様のフィードバックをもとに製品品質を上げていきたいと考えております。

現在、製品リリースをターゲットに社内では世界規模で様々なチームが準備を行っております。そこで今回、日本マーケット向けに特別に用意させていただいているコンテンツとして自信を持ってご紹介したいのが「SQL Server 2008 自習書シリーズ」です。自習書シリーズは SQL Server 2008 を試す際の最初のステップとして、コンテンツ内容の質が高くお勧めです。各ドキュメントは画面ショット、サンプルコードを含め各100ページ以上のボリュームになっております。現在、日本のパートナー様と進めている CQI プロジェクトは今後これらの自習書を補完する実検証結果を反映したドキュメントになる予定です。

- SQL Server 2008 自習書シリーズ

http://www.microsoft.com/japan/sql/2008/self-learning/

1. SQL Server 2008 の注目の新機能をイチ早く試してみよう!

2. SQL Server 2008 Reporting Services 入門編

3. SQL Server 2008 Analysis Services 入門編 (new)

4. SQL Server 2008 Integration Services 入門編 (new)

自習書シリーズのドキュメントを参考にしていただき、評価ビルドを実際に触っていただき、SQL Server 2008のよさをすぐにでも体験していただければと思っております。注意点としては、その際は必ず、オンライン版の Readme ドキュメントをご覧ください。現在のビルドの制限事項などがspecificに記述されており、実際にインストール、確認したいエリアの情報を事前確認することで最終的には時間を節約できると思います。特に、ローカライズ版に関連する Known Issueとして以下の項目がありますので、インストールの際はご注意ください。

· SQL Server 2008 インストール前に

o .NET Framework 3.5 の setupと日本語等の対象言語の Language Pack の download/setup が正常に終了していること

· SQL Server 2008 インストール中に

o 規定の照合順序 (Collation) がLatinのため手動で日本語 (Japanese_XJIS_100) 等に変更 (自習書シリーズ No.1, STEP1 にて記述あり)

また、パートナー様向けではありますが、無償セミナーなどもぜひご活用していただければと思います。

- SQL Server 2008 無償トレーニング

http://www.microsoft.com/japan/sql/techinfo/seminar.mspx

1. SQL Server 2008 コンプライアンス・セキュリティ対策

2. SQL Server 2008 運用・パフォーマンスチューニング機能概要

3. SQL Server 2008 データベースアプリケーション開発の新機能概要

4. SQL Server 2008 ビジネスインテリジェンスのための新機能

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

SQL Server 2008 早期共同検証プロジェクト (CQI)

thoshi — Fri, 21 Dec 2007 10:53:00 GMT

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

９月から11月にかけてUS出張などがありとても忙しく、寝不足の毎日が続いておりました。最近やっと通常通りのペースになってきました。

現在、我々日本の開発チームは日本独自の SQL Server 品質向上プロセスである CQI (Center of Quality Innovation) を社内のフィールド、パートナー様と共同で推進しております。我々の部隊は米国本社の開発チーム直下ということもあり随時情報共有しており、この日本での取り組みは米国本社でも高く評価、期待されております。次期リリース予定の SQL Server 2008 では大きく４つのシナリオ (コンプライアンス、データウェアハウス、サーバー統合、旧バージョンからのアップグレード / 移行) にフォーカスし、それぞれのシナリオをパートナー様である NEC様、日本HP様、日本ユニシス様と共同で取り組んでおります。各パートナー様のエンジニアの方々には今後、我々開発チームがいる調布技術センターに常駐していただき、ラボでの深い実検証を通して製品品質を向上し、パートナー様・お客様が実際に製品を選択していただく際や展開する際に役立つノウハウを早期入手、またそれらの情報を技術文書として幅広く提供したいと思っております。今回名前が出てないパートナー様以外にも本当に様々な方のご協力を得ており、とても感謝しております。例えば、技術文書をお願いする方々もとても信頼しており、検証内容だけでなく技術文書もレベルの高いものが提供できると考えております。また、それと同時に人間的ですが、パートナー様を始め様々な方とは長期的なリレーションシップを育てていきたいと思っております。

この取り組みですが、実際には SQL Server 2005 から引き続き行っているプロジェクトであり、実績として徹底検証シリーズとして6本の技術文書をすでにリリースしております。今回の SQL Server 2008 のプロジェクトには前回の経験と知識を踏まえ、常に改善しております。また、より多くのリソースを集中させ来年度に予定している SQL Server 2008 の製品リリースを成功させたいと考えております。すでに幅広く国内の主要なメディアにてカバーされておりますが、先日発表されたパートナー様とのCQI に関する共同プレスリリース、特にその記者会見ではパートナー様からの力強いお言葉を頂くことができました。この場をお借りして、お礼を申し上げたいと思います。

SQL Server 2008 早期共同検証プロジェクト CQI に関するプレスリリース

http://www.microsoft.com/japan/presspass/detail.aspx?newsid=3271

日本語 SQL Server 2008 サイト

http://www.microsoft.com/japan/sql/2008/

SQL Server 2005 徹底検証シリーズ
http://www.microsoft.com/japan/technet/prodtechnol/sql/default.mspx#verify

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

SQL Server 開発チーム ブログ : SQL Server 2008

SQL Server 2008 CQI 書籍 (MS-Press) 出版

CQI 徹底検証シリーズにデータウェアハウスシナリオのホワイトペーパーが追加されました

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

SQL Server 2008 CQI 徹底検証シリーズ ホワイトペーパー追加のお知らせ

暗号化されたデータベースとログ配布、ミラーリング、クラスタリング

暗号化されたデータベースとレプリケーション

暗号化されたデータベースを別インスタンスに復元する方法

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

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

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

SQL Server 2008 RTM (開発完了)!

日本語照合順序 Japanese と Japanese_XJIS_100、Japanese_Bushu_Kakusu_100 の比較

SQL Server 2008 での開発プロセスの変更

SQL Server 2008 CTP6 をリリース

SQL Server 2008 早期共同検証プロジェクト (CQI)

SQL Server 開発チームブログ : SQL Server 2008

SQL Server 2008 CQI 徹底検証シリーズ　ホワイトペーパー追加のお知らせ

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

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

日本語照合順序 Japanese と Japanese_XJIS_100、Japanese_Bushu_Kakusu_100　の比較