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

マイクロソフトの植田です。    たびたび予告させていただいていました、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のサンプルパッケージもダウンロード可能です。全ての環境で動作する保障は出来かねますが、何かの参考になれば幸いです。   ご意見やご感想を持たれた方はお気軽にポストしていただけると嬉しいです。 よろしくお願いします。

1

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

マイクロソフトの植田です。    引き続き「大規模データウェアハウス」シナリオ検証で得られた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 変更のあったデータの履歴をレコード内に保持し、変更があった日付を追加する方法です。レコードのサイズにより、保持できるデータ履歴の数が制限されます。複数の列が更新されるシナリオではレコードサイズが大きくなります 店舗コード 店舗名称(現) 店舗名称(履歴) エリアコード(現) エリアコード(履歴) 更新日時…


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

マイクロソフトの植田です。    米国のSQL Server Customer Advisory Team (CAT) のWebサイト上で日本語に翻訳されたベストプラクティス トップ10のシリーズが追加されました。   今回追加された技術文書は以下になります。 ·           Analysis Servicesのクエリパフォーマンスに関するベスト プラクティス トップ10 ·           ストレージに関するベスト プラクティス トップ10 ·           大規模リレーショナル データウェアハウスを構築するためのベスト プラクティス トップ10 ·           SAP向けのSQL Serverのメンテナンスに関するベスト プラクティス ·           OLTPアプリケーションに関するSQL Server 2005パフォーマンスの最もよくある問題   これらはCATのサイトでは「TOP10リスト」と呼ばれるもので、それぞれのトピックについて注意しなければならないポイントを簡単にまとめてあります。読むのにそれほど時間はかかりませんので、入門、または、設計の際のチェックリストとして利用できるのではないかと思います。詳細な部分までの説明になると、別の技術文書を読む必要があり、中には英語の文書しかないといったケースもあります。これらの文章も日本語でお届けしたいと考えていますが、すべての翻訳を一度に行うことはできませんのでご理解いただけると幸いです。   なお、日本のSQL Server BIBLEのサイトでも日本語に翻訳された技術文書がダウンロードできますのでこちらも合わせて利用してみてください。   SQL Server BIBLE(技術者必読情報), SQL Server ベスト プラクティス    コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

1

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

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)…


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

ご無沙汰しております、マイクロソフトの植田です。    最近まで、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…


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

マイクロソフトの植田です。ご無沙汰しております。 少し間が開いてしまいましたが、引き続き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…


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

マイクロソフトの植田です。   今回は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  自動フェイルオーバー・オプションが利用可能…


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

ご無沙汰しております、マイクロソフトの植田です。    昨年より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)

マイクロソフトの植田です。   今回はレプリケーションに関する話題をご紹介したいと思います。 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…


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

マイクロソフトの植田です。   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.   大量の行の挿入/削除を行った時、クラスタ化インデックスを持つテーブルと、非クラスタ化インデックスを持つテーブルとでは、ディスクスペースの使用率(効率性)に違いがあるか 本ブログでは上記の1について説明させていただきます。   クラスタ化インデックスと、非クラスタ化インデックスの大きな違いは、クラスタ化インデックスでは、インデックス・ツリーの最下層の部分(リーフノード)に実際の行のデータが収められているデータ・ページ(行データはインデックスキーの順序でソートされている)がリンクされるのに対し、非クラスタ化インデックスでは、インデックス・ツリーのリーフノードにインデックスキーが存在する行の行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,…