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

Windows Live Translator について

マイクロソフトの星川です。   インターネットの普及とともに情報は世界レベルで発信され、特にITにおける新しいテクノロジー、モデルなどの情報は英語で記述される場合が多いのが現状です。我々はできる限り日本語での情報をオリジナルからの作成を含め、有効な情報をセレクトして翻訳・レビュー等の後提供しているのですが、やはりそのプロセスの間には人が入っており、コンテンツの品質を保つためには時間とコストがかかります。   タイムリーな情報収集には原文をできる限り読むことをお勧めしますが、英語が得意でない方は、Windows Live Translator という翻訳ツールをご利用いただくとよいかもしれません。このツールには Side-by-Sideで2つの言語を同時に表示可能な機能があり原文を比較しながら読み進めることができます。ページはダイナミックに読み込まれ、少し反映するまでに時間を要しますが、随時翻訳されたテキストに変更されていきます。選択したセンテンスをハイライト表示もできます。個人的な感想ですが、英語から日本語の自動翻訳は言語的構造がその他の欧米諸国の言語と比べて複雑なためまだまだ発展途上といえるでしょう。特に文脈や前後関係が不明な場合などは不自然で理解困難な日本語を返してきたりします。このあたりはページ内のFAQ (一部引用) を一読することをお勧めします。   – 翻訳の品質が期待どおりでないのはなぜですか?  語句の意味は、文脈や文化的背景によって左右されるため、言語翻訳のプロセスは非常に複雑です。文の構造や文法が 2 言語間で大きく異なることも、機械翻訳をより困難なものにしています。現在ではまだ、正しい翻訳には人の手を介する必要があり、最先端の翻訳ソフトウェアでも、プロの翻訳者のレベルには達していません。このため、意味をなさない文も多く生成されます。研究者は継続して品質の向上に取り組んでいますが、高精度の翻訳を提供できるようになるには、まだ時間がかかることが予想されます。Translator では、原文と翻訳の両方が表示されるため、それぞれを照らし合わせて内容を理解しながらページを読み進めることができます。   ずいぶん前にUS出張中にMS Research チームにデモを見せてもらった時を思い出しました。それから1年以上経ちますが、ユーザー インターフェースとレスポンス スピードなどがよくなっております。彼らのブログもお勧めであり、IE8など今後の製品統合へのアイディアなどが語られております。以下、使用方法になりますが、簡単です。   1.     http://www.windowslivetranslator.com にアクセスします。 2.     [Web ページの翻訳] のテキストボックスに対象のURLを入力します。 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

SQL Server Team および個人の Blog List

マイクロソフトの星川です。   前回のブログで記述しましたが、以下社員でチーム or 個人単位で運営するSQL Serverに関するブログのリストです。ほとんどがUS本社開発チームからの情報発信ですが、それ以外の部署やUS以外のチームもあります。ブログという性質上今回発見できなかったり、今後増えたり、何らかの理由でしばらく更新が止まっているものもあると思いますのでご了承ください。URLのほかにタイトルと補足情報を追加させていただいております。個人のブログに関してはトピックがさまざまなため実際に見ないとわからないかも知れませんが、参考にしていただければと思います。ブログはそれぞれの人間のカラーが出ますので、本当に社内にも幅広くいろいろなチーム・人がいるなと実感してます。   マイクロソフト SQL Server 関連チームが運営しているブログ (A-Z順) ·         http://blogs.msdn.com/adonet – ADO.NET team blog ·         http://blogs.msdn.com/astoriateam – Project Astoria Team Blog ·         http://blogs.msdn.com/data – Data Platform Development ·         http://blogs.msdn.com/efdesign – Entity Framework Design ·         http://blogs.msdn.com/jdbcteam – Microsoft JDBC Driver Team Blog ·         http://blogs.msdn.com/mssqlisv – Microsoft SQL ISV Program Management Team ·        …

1

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

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

0

SQL Server チームが運営する Blog お勧めリスト

マイクロソフトの星川です。   最近社内の world-wideのコミュニティにてSQL Server に関するブログ リストをまとめてくれた人がおり、マイクロソフト社員からSQL Server をメインで情報発信しているブログの数は個人を含めるとなんと60程ありました。後日、アクティブな状態を確認できたリストを公開したいと考えておりますが、今回はその中で個人的にお勧めのものをピックアップしたいと思います。   ·         Microsoft SQL Server Development Customer Advisory Team (SQLCAT) http://blogs.msdn.com/sqlcat/, http://sqlcat.com 技術系の中でDeepで常にお客様視点で活動を続ける SQLCATメンバーが運営しているブログとそのポータルです。メンバーはNASDAQに代表される大規模データベース構築を10年以上経験しているなど社内でも有名な技術者で構成されており、彼らのノウハウが集積されている Best Practice 関連の情報はお勧めです。いくつかの Best Practice Testingや最近ではTop10リストなど人気の高いコンテンツの日本語化と技術レビューに我々のチームが参加しております。日本にも頻繁に来てくれます。   ·         Microsoft SQL Server News Blog – Data Platform Insider http://blogs.technet.com/dataplatforminsider/ Microsoft’s Data Platform official news マーケティング チームが運営しているブログです。製品開発チームと常に密接に動いているチームです。技術系ではないですが、製品アップデート、イベントやプレスリリースなどに関連する情報が入手可能です。   ·         Microsoft PSS SQL Support http://blogs.msdn.com/psssql/…

1

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 から導入された、「透過的なデータ暗号化」のメリットのひとつとして、データベースの物理ファイルやバックアップが流出したり盗難にあってもデータをのぞき見されることがない、ということが挙げられます。それは次のような理由によります。 データベース全体が暗号化されるため、流出したファイルをバイナリエディタなどで展開しても、ファイルの中身を理解することができない データベースの復元(あるいはアタッチ)には証明書が必要なので、バックアップファイルのみが流出しても不正にリストアされてしまうことはない 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