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

マイクロソフトの星川です。   SQL Server 2008リリース時に日本独自にパートナー様と共同実施したCQI (Center of Quality Innovation) の成果がホワイトペーパーだけでなくさらなる有益な情報を加えて書籍となりました。日経BPソフトプレス様より順次出版とのことですので、書店等でぜひご覧いただければと思います。技術者の方にはじっくり読める書籍もまだまだ重要と位置づけております。     徹底検証 SQL Server 2008 コンプライアンス&情報セキュリティ 徹底検証 SQL Server 2008 移行・アップグレード&データベースサーバー統合 徹底検証 SQL Server 2008 データウェアハウス構築 (近日公開) 改めまして、ご協力していただいた皆様、本当にありがとうございました。

1

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 変更のあったデータの履歴をレコード内に保持し、変更があった日付を追加する方法です。レコードのサイズにより、保持できるデータ履歴の数が制限されます。複数の列が更新されるシナリオではレコードサイズが大きくなります 店舗コード 店舗名称(現) 店舗名称(履歴) エリアコード(現) エリアコード(履歴) 更新日時…

0

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

マイクロソフトの笹瀬です。   SQL Server 徹底検証シリーズ、ご活用されていますか? 弊社では、SQL Server の製品出荷前から、各機能の多岐にわたる検証作業をフィールドから集めたシナリオをベースに行っています。 この検証作業は、CQI(Center of Quality Innovation)というプロジェクトで、マイクロソフト調布技術センター (東京都調布市) にて、マイクロソフトの製品開発担当部門、SE 部門、コンサルティング部門、サポート部門の各担当者およびマイクロソフトのパートナー各社との共同プロジェクトとして実施されています。 その検証結果をホワイトペーパーにまとめ、「SQL Server 2008 徹底検証シリーズ」として公開させていただいております。   既にご好評をいただいている 「コンプライアンス実現のためのガイドライン」に加え、新たに以下の3種類のホワイトペーパーを追加いたしました。   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…

1

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

マイクロソフトの平山です。 前回、前々回と続けてきた SQL Server 2008 からの新機能「透過的なデータ暗号化」を、他の機能の組み合わせて使うときの注意点を紹介するというテーマの最終回です。今回は「ログ配布」、「データベースミラーリング」、「フェールオーバークラスタリング」を取り上げてみます。 それぞれ機能の基本的な動作を考えてみると、注意点や必要な事前準備を推測することができると思います。 まず「ログ配布」について考えてみます。通常の場合は初期同期のための作業として、プライマリデータベースをセカンダリサーバーに復元します。その際に、プライマリデータベースが暗号化されていると、セカンダリサーバーへの復元が失敗してしまいます。 次に「データベースミラーリング」の場合です。ミラーリングの設定の事前準備として、プリンシパルサーバーのデータベースをミラーサーバーに復元しておく必要があります。その際に、プリンシパルサーバーのデータベースが暗号化されていると(ログ配布の場合と同様に)、ミラーサーバへの復元時にエラーが発生してしまいます。 さて、この問題を回避するには、どうすればよいでしょうか?その答えは前々回のエントリで紹介してあります。それぞれの場合の事前準備として、「ログ配布」の場合はセカンダリサーバーで、「データベースミラーリング」の場合はミラーサーバーで、サービスマスターキーの作成と証明書の復元を行っておく必要があります。それ以外は、通常の設定方法と同じです。 最後に「フェールオーバークラスタリング」について紹介します。フェールオーバークラスタリングが構成されている SQL Server インスタンスに暗号化されているデータベースが存在したとしても、特に事前準備はありません。クラスタリング環境では、複数のノードのうちのいづれかひとつのノードで SQL Server インスタンスが稼働することができます。しかし、実体としてのデータベース (ユーザデータベースおよびシステムデータベース) は複数のノード分存在するのではなく、全ノードで共有しています。そのため、サービスマスターキーや証明書も、どのノードで SQL Server インスタンスが起動しても同じものを使用していることになります。ということで、事前に特別な考慮をすることなくクラスタ環境で暗号化されたデータベースを使用することができます。

0

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

マイクロソフトの平山です。「透過的なデータ暗号化」を使用して暗号化されたデータベースの使い勝手を追求するシリーズの 2 回目の今回は、レプリケーションとの関連を紹介します。 レプリケーションでパブリッシュしようとするデータベースが暗号化されていても、サブスクライバへレプリケートを行うときに必要となる情報は、暗号化されていない状態で distribution データベースに格納されています。つまり、レプリケート実行時にデータを復号化する必要がないため、サブスクライバ側でのサービスマスターキーの作成や証明書のリストアは必須ではありません。また、この動作はいずれレプリケーションのタイプにも当てはまります。 といった前提のもとに、暗号化されたデータベースをレプリケートする場合の注意点は次のようになります。 注意点 1:パブリッシャデータベースが暗号化されていたとしても、サブスクライバデータベースが自動的に暗号化されることはありません。必要に応じて個別に暗号化を行ってください。サブスクライバの暗号化の際には、必ずしもパブリッシャと同じ証明書を使用する必要はありません。 注意点 2:パブリッシャデータベースが暗号化されていても、スナップショットレプリケーションや他のタイプのレプリケーションの初期化時に使用されるデータベースの初期スナップショットは暗号化されていません。つまり、ネイティブ形式のファイルとして出力されていても、バイナリエディタなどで展開されてしまうと、ファイルの内容をのぞき見られてしまう危険性があります。そのため、スナップショットファイルを配置するフォルダの権限を適切に管理することで対処する必要があります。 注意点 3:レプリケーションに関連するサイト間の通信を、より堅牢にするためにパブリッシャ、ディストリビュータ、サブスクライバ間の伝送経路の暗号化を検討してください。

0

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

マイクロソフトの平山です。これから数回にわたり「透過的なデータ暗号化」を使用して暗号化されたデータベースの使い勝手について紹介していきたいと思います。  SQL Server 2008 から導入された、「透過的なデータ暗号化」のメリットのひとつとして、データベースの物理ファイルやバックアップが流出したり盗難にあってもデータをのぞき見されることがない、ということが挙げられます。それは次のような理由によります。 データベース全体が暗号化されるため、流出したファイルをバイナリエディタなどで展開しても、ファイルの中身を理解することができない データベースの復元(あるいはアタッチ)には証明書が必要なので、バックアップファイルのみが流出しても不正にリストアされてしまうことはない SQL Server オンラインブックなどのドキュメントには、データベースを暗号化するための方法は親切に解説してありますが、暗号化したデータベースを復元する方法をわかりやすくまとめている箇所がありません。そこで今回のエントリでは、暗号化されたデータベースを別インスタンスに復元する方法を紹介したいと思います。 ●まずはデータベースの暗号化までのおさらい 1. データベースとテーブルを作成しますcreate database TDE_DBgouse TDE_DBgocreate table t1 (c1 nvarchar(500))go2. サービスマスターキーを作成しますuse mastergocreate master key encryption by password = ‘secret!masterKey1’go3. 証明書を作成しますcreate certificate TDE_TEST with subject = ‘Test Certificate’go3. データベース暗号化キーを作成しますuse TDE_DBgocreate database encryption key with algorithm = AES_256encryption by server certificate TDE_TESTgo4. データベースを暗号化しますalter database TDE_DB set encryption…

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

0

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

マイクロソフトの星川です。   仮想化技術は現在の 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…

0

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…

0