SQL Server Product Manager チームブログ

Posts

| |

3/12 実施 SQL Server コミュニティ第0回勉強会のお知らせ

Posted over 3 years ago

by Jun Matsuzawa
こんにちは。日本マイクロソフトの松澤です。

東京地方、今日はとても暖かいです。コートが要らない陽気ですね。ただ、夜は普通に冷えるらしいとも聞いています。花粉もすごいようです。

といっても、天気予報をお伝えしたいわけではありません。

今日は、SQL Server のコミュニティの第0回勉強会のお知らせをさせていただきます。

札幌に、SQLDO という SQL Server の技術者のコミュニティがあります。私も一度、出張の際に勉強会にお邪魔させていただいたことがあります。

このコミュニティの代表者が一定期間東京に滞在されているということで、Twitter や弊社のセミナーを介して知り合った数人の技術者達が SQLTO というコミュニティを立ち上げました。

（実はこのコミュニティ誕生の瞬間!? に私も立ち会っております。）

松澤もこのコミュニティを日本マイクロソフトの一員としてサポートしていこうということで、勉強会の実施をお手伝いさせていただいています。

また、SQL CAT (Customer Advisory Team) の多田典史（ただ・よりひと）も、勉強会の中でセッションを持ち、SQL CAT って何ぞや？といった話から、非常に deep な技術情報まで、コミュニティの皆様にお伝えしていきます。

第0回勉強会は3月12日（土）13:30から（開場 13:00）です。

詳細は SQLTO のページをご覧ください。

また、お申込みはこちらからどうぞ。

皆様のご参加をお待ちしております。

***

本イベントは、コミュニティー主催のイベントであり、日本マイクロソフトが主催するものではありません。日本マイクロソフトは、会場提供などのコミュニティ支援をしておりますが、本イベントの全体内容について関与するものではありません。

参考：マイクロソフト社員のコミュニティ参加について

http://www.microsoft.com/japan/communities/msp.mspx
今週予定されていたセミナーは中止となりました

Posted over 3 years ago

by Jun Matsuzawa
立て続けの Blog 投稿ですが、ご容赦ください。

明日15日（火）に予定されておりました、SQL Server 関連セミナーは2つとも中止となりました。

15日（火）10:00-12:00

[マイクロソフトソリューションセミナー] SQL Server と Excel を使えばこんなに簡単。見える化と分析でビジネスにスピードを～SQL Server 2008 R2 の標準機能でここまでできるビジネスインテリジェンス基礎編～

申込みページ：https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032475099&Culture=ja-JP

15日（火） 14:00-17:15

マイクロソフトソリューションセミナー] 大きな声では言えない！ BI プロジェクト失敗談」セミナー～「見える化」と「分析」を実現するためにビジネスインテリジェンス実践編～

申込みページ：https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032475106&Culture=ja-JP

お申込みくださっていた方には個別にご連絡差し上げる予定ですが、メール配信の遅延などもありうるため、こちらでもお知らせさせていただきました。

よろしくお願い申し上げます。
動画シリーズ第2弾完結 & 事例公開のお知らせ

Posted over 3 years ago

by Jun Matsuzawa
こんにちは。日本マイクロソフトの松澤です。

東京では今週、寒い日が続いています。

でももう3月なんですよね。早いものです。

さて、お知らせです。SQL Server を使ったソリューションや機能、そしてライセンスなどについて紹介している SQL Server の動画シリーズですが、第2弾として制作しました全5本、全てが Web に公開されました！

動画でわかる SQL Server 2008 R2

2月、3月に公開をしてきました全5本をご紹介します。

(1) 予算平準化ができるコスト削減にも効く EAP とは？

EAP というライセンスプログラムが3分で理解できる動画です。

(2) ビジネスに重要なのは攻め? 守り? マイクロソフトなら両方できる

グローバルの CIO と日本の CIO が注目しているビジネスとテクノロジの優先事項から、その実現を助けるマイクソフトのソリューションを紹介しています。

(3) クラウドともシームレスに連携! 社内設置 SQL Server とクラウド上の SQL Azure

マイクロソフトは、社内設置サーバーとクラウドのサービス、両方を提供しています。SQL Server から分岐した SQL Azure なら、同じツールで管理、開発ができます。

(4) SQL Server で実現するデータウェアハウス 2 つの選択肢

コストを抑えて容易に導入できる Fast Track Data Warehouse と、大規模もしくはパフォーマンスを優先する方向けの SQL Server 2008 R2 Parallel Data Warehouse。マイクロソフトは DWH に 2つの選択肢を用意しています。

(5) SQL Server 2008 R2 Enterprise エディションのチカラを再確認

エンタープライズ向けデータプラットフォーム、SQL Server 2008 R2 Enterprise のパフォーマンス、新機能をハイライトでご紹介しています。

さらに、最近続々と公開されているのが、この SQL Server を利用されている企業様の導入事例です。

■日本電気株式会社様（2011/2/24 公開）

グループ 12 万人を支える世界最大規模の SAP システムのバックで動いているのは Microsoft Windows Server と Microsoft SQL Server!

■株式会社セブン銀行様（2011/2/28 公開）

全国に 15,000 台以上の ATM を持つセブン銀行様では、勘定系システムに Windows Server 2008 enterprise と SQL Server 2008 Enterprise を利用されています。

■三井物産株式会社様（2011/3/3 公開）

新基幹システムとして、Windows Server 2008 R2 Hyper-V を活用したプライベートクラウド環境を構築し、SAP ECC 6.0 および SQL Server 2008 を利用されています。

その他、SQL Server の事例は SQL Server 2008 R2 事例ページにまとめております。
明けましておめでとうございます。新カタログと連載記事を公開しました。

Posted over 4 years ago

by Jun Matsuzawa
マイクロソフトの松澤です。

2011 年、あけましておめでとうございます。

年も改まり、新たな気持ちで頑張りたいと思います。本年もよろしくお願い致します。

さて、年明け早々に、弊部にうれしいニュースが飛び込んできました！が、まだ皆様に発表できる段階ではないので、もう少しお待ちください。必ずここでも発表させていただきます。

ということで、新年1つ目の update ですが、SQL Server 2008 R2 Enterprise エディションの新しいカタログができました！

"SQL Server 2008 R2 Enterprise のチカラ" カタログ（PDF 版 / XPS 版）

SQL Server 2008 R2 Enterprise エディションがもつ強力な機能をまとめて掲載。ビジネスのスピードを up し、コストを削減し、セキュリティ対策も万全な、まさに鉄板の機能が盛りだくさんの Enterprise エディション。ご活用いただいているお客様の事例も合わせて紹介しています。ダウンロードしてご覧ください。

* * *

そしてもう1つ、Microsoft SQL Server ULB (Urban Legend Busters) の新しいストーリーその6 が公開されました！

すべてのエディションが中小企業情報基盤強化税制対象の SQL Server。〜 7 パーセントの謎〜

データベースを実質的に 7% 値引いた価格で購入できる、なんてカラクリがあるんでしょうか？どのデータベースでもそうなのでしょうか？

このストーリーを読めば、この 7% の謎が解けます。

Web では ULB の技術連載を展開していますが、連載に連動したセミナーも実施しています。

その名も、SQL Server "Get The Fact" セミナー。

エンジニアの皆様が参加しやすいように、月に1度、夜19時からの実施です。

次回は1月20日（木）、弊社新宿オフィスでの開催です。参加はもちろん無料です。

奮ってご参加ください。

SQL Server "Get The Fact" セミナーデータベースアップグレードは今!! 中小企業情報基盤強化税制を活用しよう。～ SQL Server で税法上の優遇措置が受けれる～

ちなみに、2月からは品川オフィスでの開催となります。

新宿オフィスで SQL Server のセミナーを開催するのも、今回が最後です。なんとなく感慨深いです…。
SQL Server ログインに Windows のパスワードポリシーを適用するには

Posted over 5 years ago

by T.Kitagawa
マイクロソフトの北川です。

SQL Server では SQL Server ログイン、Windows ログインなどを利用することができます。もし、SQL Server のシステムにおいて、SQL Server ログインを使用する場合には、SQL Server ログインにおいても、Windows パスワードポリシーを適用することができることを覚えておいてください。Windows パスワードポリシーを設定することにより、より効果的にログインアカウントを保護することが可能となります。

詳しくは

SQL Server オンラインブック: CREATE LOGIN (Transact-SQL)
SQL Server オンラインブック: パスワードポリシー

をご一読いただければと思います。
SQL Server Reporting Services を体験する

Posted over 5 years ago

by ysaito9613
- 1 Comment
マイクロソフトの斎藤です。

SQL Server には標準の機能として Reporting Services というレポート作成・管理・配信サービスが付属しています。この Reporting Services の機能を使用すれば、SQL Server はもちろん、Oracle、SAP、Teradata など既存の Data Wahrehouse に蓄積されたデータをグラフィカルに可視化することが可能です。

グラフィカルに可視化？と思われた方は、実際に Reporting Services によって作成されたレポートを直接参照することができる「Rporting Services 体験サイト」を是非ご訪問ください。
Reporting Services 体験サイトでは、皆様のブラウザから直接 Reporting Services のレポート画面を参照することが可能です。

Reporting Services 体験サイトはこちら: http://www.microsoft.com/japan/sqlserver/2008/rs/default.mspx (Windows Live ID によるユーザー登録が必要です。)
「中堅企業向けオラクル都市伝説シーズン2: 其の一」への反論

Posted over 5 years ago

by T.Kitagawa
マイクロソフトの北川です。

本日とあるページが日本オラクル社のウェブサイトに掲載されていることを確認しました。このブログ記事をアップすることで、当該ページが削除されてしまうと何に対しての反論なのかわからなくなりますので、魚拓へのリンクを作っておきました。

日本オラクル社ウェブサイト：2009年8月27日取得ウェブ魚拓
中堅企業向けオラクル都市伝説シーズン2: 其の一

要は、SQL Server のトランザクションログが自動拡張されることを揶揄した記事なのですが、本文中には「本当に SQL Server の運用を理解して書かれたのか」また「ディスクミラーリングの仕組みを理解して書かれたのか」が疑問な箇所があります。

以下疑問点と、SQL Server の運用に関しての補足を行いたいと思います。
1. トランザクションログファイルの肥大化について
  SQL Server では、ログを循環利用しますが、トランザクションの量によっては再利用ができず、トランザクションログファイルの拡張を行います。SQL Server が自習書をはじめとしてその運用方法としてガイドしている内容は
  
  運用監視を行い、1日当たりのトランザクションログファイルの増加量を確認したうえで、トランザクションログファイルの自動拡張が不要なサイズのトランザクションログファイルを確保することと合わせて、定期的なトランザクションログファイルのバックアップを計画する
  
  というものです。こうすることで、トランザクションログファイルの肥大化を防止し、日本オラクルのサイトに書かれているようなトラブルを防止することができます。また、その設定に関しても下記のように「メンテナンスプランウィザード」を使用して簡単に設定することが可能です。
  
  図1: メンテナンスプランウィザードによるバックアップの設定
  
  図1 の画面で「データベースのバックアップ(完全)」「データベースのバックアップ(トランザクションログ)」を選択して自動処理させるように設定しておけば、肥大化は防止できます。また、もし肥大化してしまったとしても、上記処理を実行した後で「データベースの圧縮」を実行することで、縮小を行うことも可能です。
  
  なお、上記日本オラクルのサイトに書かれているような状況は、Oracle Database において、アーカイブログを書き込む領域がいっぱいになってしまったときと同じ状況です。アーカイブログを作成できない場合、Oracle Database であっても処理が止まってしまいます。
  
  Oracle Database をアーカイブログモードで運用する際には、アーカイブログを適宜削除して領域を確保する必要があります。これは、Oracle Database の運用管理にも描かれている事項です。なぜ、Oracle Database の運用では上記処理を想定していながら、SQL Server では上記のようなガイドがなされているにもかかわらず、それが「行えない」ような記載をされているのか理解に苦しみます…。
  　
2. 壊れたログファイルがそのまま二重化されていた(ミラーディスクに壊れたトランザクションログファイルが書き込まれていた)
  今回の記事で最も納得がいかない部分です。
  SQL Server にとって、トランザクションログファイルを多重化できないという弱点があることは事実です。ですので、RAID 1 構成のディスク上にトランザクションログファイルを格納することをガイドしています。
  
  今回の日本オラクル社の記事では、RAID 1 ディスク上にトランザクションログファイルを置いていたにもかかわらず、ログファイルが破損し、多重化されたディスクにその破損したログファイルが書き込まれたことになっています。
  
  RAID 1 の構成では、ディスクに書き込まれた内容がミラーディスクにも反映されることになっていますので、上記想定は「SQL Server が論理的に誤ったトランザクションログをディスクに書き込んだ」ということを意味しています。
  
  これはひどい誹謗中傷です。
  製品に関して事実無根の誹謗中傷を行い、ユーザーに対して誤った事実を植え付けようとする姿勢は容認できるものではありません。
  機能的に不十分であるという印象を与えようとしているのかもしれませんが、SQL Server において、トランザクションログファイルの論理障害が発生するようなことはありません。もしこれが「論理障害が発生する可能性」に関しての言及なのであれば、Oracle Database でも発生し得ますし、その場合、Oracle Database のログの多重化でも対応することはできません。
  
  上記を踏まえると、トランザクションログの障害は特定のディスクにおける物理障害であるはずですので、ミラーディスクから無事に復旧できることになります。
  
  注：
  Oracle Database の例によると、ログファイルの障害は多重化されたログにより解決されるとのことですので、おそらく本記事を書かれた方の想定は「物理障害」だったのでしょう。とすると、記事を書かれた方は RAID 1 の仕組みを正しく理解されていないのですね…。SQL Server ではログファイルの論理障害を想定し、Oracle Database では物理障害。同じ条件での比較にしてほしいものです。
上記サイトにはまとめとして下記の文言が記載されています。

ログファイルが肥大化しないOracle Databaseを選択すれば、この地獄から無事生還することは容易だ。それどころか、地獄を経験せずに済む仕組みが随所に施されている。

Oracle Database では確かにログファイルの肥大化は発生しないかもしれません。ただし、ユーザーが削除しない限りアーカイブログが蓄積され、ディスク容量を圧迫します。アーカイブログが取得できなければ Oracle Database といえども停止してしまいます。そのため、Oracle Databsae はその運用方法としてバックアップ取得後にアーカイブログの削除を行うようにガイドしています。

同じく、SQL Server にもログファイルの肥大化を防ぎ、無用な障害を防止するためのガイドや仕組みが用意されています。Oracle Database の運用と同じく、これらのガイドに従えば、日本オラクル社のページに記載されているようなことは発生しないということをご理解ください。

このような「本当にあった怖い話」として事実無根の誹謗中傷に近い記事が掲載されたままになるのであれば、明らかな不実告知に当たりますので、何らかの手段を講じる必要があるのかもしれません。

都市伝説シーズン2に関してはこれからも十分な注意を払い、事実と異なる情報を流布されないようにしたいと思います。
SQL Server の Build 番号を確認する方法

Posted over 5 years ago

by T.Kitagawa
マイクロソフトの北川です。

CSS SQL Server Engineer ブログ(英語)で "Trying to keep up with Version Numbers..." という興味深い記事がポストされましたので紹介いたします。

SQL Server にサービスパック (SP) や累積的な更新プログラム (CU) を適用した場合、SQL Server の Build 番号が更新されます。この Build 番号を、下記の表と照らし合わせることで、SQL Server にどのサービスパックや累積的な更新プログラムが適用されているかを確認することができます。

確認は下記の SQL 文で行います。

SELECT SERVERPROPERTY ('productversion'), SERVERPROPERTY('productlevel')

10.0.2531.0 SP1

この結果と下記一覧表と対比することで、SQL Server に適用されているサービスパックや累積的な更新プログラムを確認することが可能です。

SQLTeam.com - SQL Server Version

多数導入された SQL Server のバージョン管理を効率的に実施するうえで有用かと思いますので、ぜひご確認いただければと思います。
SQL Server 2008 Enterprise SP1 (x86/x64) が IPA の "相当製品一覧 - データベース管理ソフトウェア" に掲載されました

Posted over 5 years ago

by T.Kitagawa
マイクロソフトの北川です。

ISO/IEC15408 情報セキュリティ評価・認証(EAL1) を取得していた SQL Server 2008 Enterprise (x86/x64) ですが、昨日付で IPA で公開されている「相当製品一覧 > データベース管理ソフトウェア一覧」に掲載されました。

情報処理推進機構：情報セキュリティ：情報基盤税制について
http://www.ipa.go.jp/security/tax/index.html

相当製品一覧 > データベース管理ソフトウェアの一覧
http://www.ipa.go.jp/security/tax/self-ccra-db.html

SQL Server 以外で ISO/IEC15408 情報セキュリティ評価・認証を取得しているマイクロソフト製品に関しては下記にまとめてあります。

情報基盤強化税制においけるマイクロソフト製品の ISO/IEC15408 取得状況について
http://www.microsoft.com/japan/technet/security/news/isoiec15408.mspx

上記 IPA サイトと合わせてご確認いただければと思います。
セルフサービスBIって何？という疑問に応えるコンテンツのご紹介

Posted over 4 years ago

by ysaito9613
マイクロソフトの斎藤です。

JBPress に、SQL Server 2008 R2 によるセルフサービス BI に期待される成果と結果について分かりやすく解説する連載コンテンツが掲載されています。

その名も「こんな悩みにさようなら！明日から使えるシーン別データ活用法」。 SQL 商事という架空の企業を舞台に展開されるドタバタストーリー!?

セルフサービス BI もそうだけど、そもそも BI って何？という方にも非常に分かりやすい内容になっていますし、ストーリー展開になっていますので読みやすいです。

ぜひご覧ください。

http://jbpress.ismedia.jp/ts/00085/SQL/index.html
SQL Data Serviceでも使われることになったTDS（Tabular Data Stream）プロトコル

Posted over 5 years ago

by TechNet Archive
マイクロソフトの太田です。

前回のSQL Data Serviceの記事のポストの後でTDS(Tabular Data Stream) を検索しましたが、見つかり難いことが分かりましたので、簡単にTDSを紹介しておきました。

http://blogs.technet.com/sqlpm-j/pages/sds-tds.aspx

ご一読いただければと思います。
[Sample] えす！エス！レスキュー SQL Server -どっぷりリファレン中！！- Vol. 1

Posted over 5 years ago

by T.Kitagawa
◆◇◇◆━━━━━━━━━━━━━━━━━━━━2009.06.10━━━・‥… えす！エス！レスキュー SQL Server -どっぷりリファレン中！！- ・‥…━━━━━━━━━━━━━━━━━━━━━Vol. 1━━━━◆◇◇◆ <<目次>> ■SQL Server リファレン中！！　その１ ■お知らせ・・・○ご質問について ■編集者より ┏─────────────────────────────────┓ ┃SQL Server リファレン中！！ ┃ ┗─────────────────────────────────┛ インサイトテクノロジーがお送りする、 SQL Serverのメルマガ「えす！エス！レスキュー SQL Server -どっぷりリファレン中！！-」第1弾をお届けします!! このメルマガでお送りする情報は以下のエディションをターゲットにし、記載しております。ターゲット： SQL Server 2008 Enterprise Edition x86 Enterprise Editionが高い!と思われるかも知れませんが、 180日間限定のトライアル版を、以下のサイトからダウンロードできますのでぜひ、メルマガを見つつ、色々と試していただけたらと思います。 SQL Server 2008 の評価版ダウンロードページ http://www.microsoft.com/japan/SQLServer/2008/downloads/default.mspx このSQLServerのメルマガは、夏椰(かや)がお送りします。最初なので、簡単に自己紹介をさせてください。歳は30歳です。(2009年06月現在) 身長は166cm、基礎代謝が1400kcalぐらいです。ソフトテニスと一眼レフが趣味です。データベースも趣味だったのですが、インサイトテクノロジーに入社し、お仕事になりました♪ そして、こうして皆様にメルマガという形で私の知っていることや、チャレンジしたことをお届けする機会を得る事が出来、嬉しく思っています。では、本題へ。今回のSQL Server - どっぷりリファレン中では、 SQL Serverにおける「データファイル」と「ページ」、「エクステント」について見ていきます。 ====================================================================== アジェンダ ====================================================================== 今回のメルマガでは以下の内容をお伝えします。 1) データファイルとページ 2) データベースとデータファイル・ページ・ページの種類・ページとエクステントの関係・テーブルとページの関係 4) データファイルとエクステント ====================================================================== データファイルとページ ====================================================================== SQL ServerでもOracleでも、データはデータファイルに格納されていきます。そのデータファイルの中身はどうなっているんでしょうか? まず最初に、接続中のインスタンスが使っているファイルの一覧を取得し、表示します。 << SQL文 >> /********************************************************************/ SELECT * FROM sys.master_files; /********************************************************************/ # sys.master_filesについては MSDNライブラリ参照。 # http://msdn.microsoft.com/ja-jp/library/ms186782.aspx << 実行結果(抜粋) >> /********************************************************************/ database_id file_id type type_desc name ----------- ----------- ---- ---------- ------------------------------ 1 1 0 ROWS master 1 2 1 LOG mastlog 2 1 0 ROWS tempdev 2 2 1 LOG templog 3 1 0 ROWS modeldev 3 2 1 LOG modellog 4 1 0 ROWS MSDBData 4 2 1 LOG MSDBLog 5 1 0 ROWS ReportServer 5 2 1 LOG ReportServer_log 6 1 0 ROWS ReportServerTempDB 6 2 1 LOG ReportServerTempDB_log 7 1 0 ROWS test 7 2 1 LOG test_log /********************************************************************/ # 実行結果 http://www.insight-tec.com/mailmagazine/SQL_ref/sys.master_files.png /********************************************************************/ この結果を見て分るように、・行データが入るファイル・ログデータが入るファイルの2種類のファイルが存在していることが分るかと思います。 sys.master_filesが出力する列数は多く、様々な情報が入っていますのでファイルサイズと必要な情報がある程度見えるように、出力列を絞って、SQLを実行していきます。また、4つの列に対し、式を入れていきます。 max_size列が-1の場合、ファイルの最大値は可能サイズまで増加するという"無制限"指定なので、 max_size列が0以下の場合は、"無制限"と表示されるようにしました。 growth列は0の場合、サイズの増減がない固定ファイルサイズになりますのでその場合には、"固定"と表示されるようにしました。そして、growth列の値はis_percent_growthの値が1の場合はパーセント(%)、それ以外はページ数を示していますので、 is_percent_growth列の値を見て、growthの増え方がどちらなのか、 "%"と"page(s)"という"単位"を付加して表示するようにしました。 DB_NAMEという関数を使い、 database_idに対応するデータベースの名前が表示されるようにしました。 # MSDN http://msdn.microsoft.com/ja-jp/library/ms189753.aspx それでは、組みあがったSQL文と実行結果を記載します。 << SQL文 >> /********************************************************************/ SELECT DB_NAME(database_id) dbname, name, file_id, file_guid, physical_name, size, case when max_size < 0 then N'無制限' else CAST(max_size as nvarchar) end max_size, case when growth = 0 then N'固定' else CAST(growth as nvarchar) end + case when is_percent_growth = 1 then N'%' else N'page(s)' end growth FROM sys.master_files ; /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ dbname physical_name ------ ------------------------------------------------------------ master C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\master.mdf master C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\mastlog.ldf tempdb C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\tempdb.mdf tempdb C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\templog.ldf model C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\model.mdf size max_size growth ----- -------- ---------- 512 無制限 10% 160 無制限 10% 1024 無制限 10% 64 無制限 10% 288 無制限 128page(s) /********************************************************************/ # 実行結果 http://www.insight-tec.com/mailmagazine/SQL_ref/sys.master_files_change1.png /********************************************************************/ ここから、結果の中にある1つのファイルをピックアップして情報を見ていきます。 1行目にあるmasterというデータベースのsizeには"512"と出力されています。しかし、physical_nameで指定されているファイルのプロパティをみると、実際のファイルサイズは4,194,304 バイトです。 # http://www.insight-tec.com/mailmagazine/SQL_ref/master.mdf.png では、SQLの結果で出力された"512"は何を示しているのでしょうか？ sys.master_filesの説明を見ると "size列は、現在のファイルサイズ (8 KB ページ単位) "とあります。よってこの512は、「8KBのページ数が512個はいっています。」といっているわけです。試しに、先ほどのsize部分がバイトで出力されるように修正します。 << SQL文 >> /********************************************************************/ SELECT DB_NAME(database_id) dbname, name, file_id, file_guid, physical_name, cast(size as decimal) *8*1024 [size], case when max_size < 0 then N'無制限' else CAST(max_size as nvarchar) end max_size, case when growth = 0 then N'固定' else CAST(growth as nvarchar) end + case when is_percent_growth = 1 then N'%' else N'page(s)' end growth FROM sys.master_files ; /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ dbname physical_name ------ ----------------------------------------------------------- master C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\master.mdf master C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\mastlog.ldf tempdb C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\tempdb.mdf tempdb C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\templog.ldf model C:\SQL ServerData\MSSQL10.MSSQL Server\MSSQL\DATA\model.mdf size max_size growth ------- -------- ---------- 4194304 無制限 10% 1310720 無制限 10% 8388608 無制限 10% 524288 無制限 10% 2359296 無制限 128page(s) /********************************************************************/ # 実行結果 http://www.insight-tec.com/mailmagazine/SQL_ref/sys.master_files_change2.png /********************************************************************/ これで、ファイルのプロパティで表示されていたファイルサイズと SQL出力結果のsizeが一致し、 SQL Serverのページが8KBである事を実感できたかと思います。 ====================================================================== データベースとデータファイル・ページ ====================================================================== 先ほどまでの検証にて、データファイルの中には"ページ"というものが存在している事を感じていただけたかと思います。今度はそのページとは何かをみていきます。事前準備として、使用するデータベースとテーブルを作成します。 << SQL文 >> /********************************************************************/ USE [master] GO CREATE DATABASE mini ON PRIMARY ( NAME = N'miniPri', FILENAME = N'C:\SQL ServerData\miniPri.mdf' , SIZE = 3MB , FILEGROWTH = 1KB ), FILEGROUP miniSec DEFAULT ( NAME = N'miniSec', FILENAME = N'C:\SQL ServerData\miniSec.mdf' , SIZE = 512KB , FILEGROWTH = 1KB ) LOG ON ( NAME = N'log', FILENAME = N'C:\SQL ServerData\mini.ldf' ) Go USE [mini] GO CREATE TABLE [tb1]( [id] [decimal](18, 0) NOT NULL, [col1] [nvarchar](4000) NULL, [col2] [nvarchar](max) NULL, [col3] [nvarchar](max) NULL, CONSTRAINT [pktb1] PRIMARY KEY CLUSTERED ( [id] ASC )ON [miniSec] ) ON [miniSec] GO /********************************************************************/ ここでさらっと"エクステント"について記述します。詳しくは、これ以降に記載しますが、 CREATE DATABASEで指定するFILEGROWTHの値は、『指定したサイズを、最も近い 64 KB 単位の値に切り上げた数値』が実際の設定値として適用されます。領域の増加は"エクステント単位"で行われるのですが、 8ページ=1エクステント、1ページ=8KBと決まっているからです。よって、増加の最小値が 8KB * 8 = 64KB になる・・・ということを暗に示しています。さて、話を元に戻しまして、作成しただけの状態で、このデータベースのサイズを調べてみます。次のSQLはデータベースに割り当てられたデータ領域を表示するSQLです。 << SQL文 >> /********************************************************************/ USE [mini] GO SELECT * FROM sys.data_spaces; /********************************************************************/ # MSDN http://msdn.microsoft.com/ja-jp/library/ms190289.aspx << 実行結果 >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- PRIMARY 1 FG ROWS_FILEGROUP 0 miniSec 2 FG ROWS_FILEGROUP 1 /********************************************************************/ この結果により、CREATE DATABASEのON以下で指定した "PRIMARY"というファイルグループと "miniSec"というファイルグループが表示されます。次に、このデータベースのアロケーションユニットの一覧を取得してみます。 # アロケーションユニットについてはMSDNライブラリ参照 # MSDN http://msdn.microsoft.com/ja-jp/library/ms189051.aspx << SQL文 >> /********************************************************************/ USE [mini] GO SELECT * FROM sys.allocation_units ; /********************************************************************/ # MSDN http://msdn.microsoft.com/ja-jp/library/ms189792.aspx << 実行結果(抜粋) >> /********************************************************************/ allocation_unit_id type type_desc container_id ------------------ ---- ----------------- ------------------ 72057594039828480 1 IN_ROW_DATA 72057594038779904 72057594039894016 3 ROW_OVERFLOW_DATA 72057594038779904 72057594039959552 2 LOB_DATA 72057594038779904 data_space_id total_pages used_pages data_pages ------------- ----------- ---------- ---------- 2 0 0 0 2 0 0 0 2 0 0 0 /********************************************************************/ このSQL結果は100件強出力されているかと思います。この出力結果が、ページの集合体であるアロケーションユニットの一覧結果になるのですが、これだけを見ていても、情報がよく見えないと思いますので、 SQLを改変し、実行します。 << SQL文 >> /********************************************************************/ USE [mini] GO SELECT sys.allocation_units.allocation_unit_id, sys.allocation_units.type_desc, sys.allocation_units.total_pages, sys.allocation_units.used_pages, sys.allocation_units.data_pages, sys.partitions.object_id, OBJECT_NAME(sys.partitions.object_id) object_desc, sys.partitions.index_id, sys.partitions.rows FROM sys.data_spaces join ( sys.allocation_units left outer join sys.partitions ON container_id = CASE WHEN sys.allocation_units.type % 2 = 1 THEN sys.partitions.hobt_id WHEN sys.allocation_units.type = 2 THEN sys.partitions.partition_id END ) ON sys.data_spaces.data_space_id = sys.allocation_units.data_space_id ORDER BY object_id ; /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ allocation_unit_id type_desc total_pages used_pages -------------------- ----------------- ----------- ----------- 72057594039828480 IN_ROW_DATA 0 0 72057594039894016 ROW_OVERFLOW_DATA 0 0 72057594039959552 LOB_DATA 0 0 data_pages object_id object_desc index_id rows ---------- ----------- ----------- -------- ----- 0 2105058535 tb1 1 0 0 2105058535 tb1 1 0 0 2105058535 tb1 1 0 /********************************************************************/ これでどのオブジェクトが、どれぐらいの行数があり、どれぐらいページを使用しているかが分るようになりました。さらに突っ込んで、これをファイル/ファイルグループと繋げてみます。 << SQL文 >> /********************************************************************/ USE [mini] GO SELECT sys.data_spaces.*, sys.allocation_units.allocation_unit_id, sys.allocation_units.type_desc, sys.allocation_units.total_pages, sys.allocation_units.used_pages, sys.allocation_units.data_pages, sys.partitions.object_id, OBJECT_NAME(sys.partitions.object_id) object_desc, sys.partitions.index_id, sys.partitions.rows FROM sys.data_spaces join ( sys.allocation_units left outer join sys.partitions ON container_id = CASE WHEN sys.allocation_units.type % 2 = 1 THEN sys.partitions.hobt_id WHEN sys.allocation_units.type = 2 THEN sys.partitions.partition_id END ) ON sys.data_spaces.data_space_id = sys.allocation_units.data_space_id ORDER BY object_id ; /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 0 0 0 72057594039894016 ROW_OVERFLOW_DATA 0 0 0 72057594039959552 LOB_DATA 0 0 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 0 2105058535 tb1 1 0 2105058535 tb1 1 0 /********************************************************************/ これで、ファイル/ファイルグループに格納されているページ数がいくつか、格納されているオブジェクトが何で、どれ��らいの行数あるのかが見えるようになりました。ここでテーブルに1行データをいれて、先ほどのSQLを再度実行してみたいと思います。 << SQL文 >> /********************************************************************/ insert into tb1 values ( 1, null, null, null); /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 2 2 1 72057594039894016 ROW_OVERFLOW_DATA 0 0 0 72057594039959552 LOB_DATA 0 0 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 1 2105058535 tb1 1 1 2105058535 tb1 1 1 /********************************************************************/ データを1行追加した事で、tb1のIN_ROW_DATAが使用しているページの数が2に増えました。行データで1ページ、 nvarcharが格納されるページで1ページ使用しているので、計2ページの使用になります。さらに、1行追加して再実行します。 << SQL文 >> /********************************************************************/ insert into tb1 values ( 2, null, null, null); /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 2 2 1 72057594039894016 ROW_OVERFLOW_DATA 0 0 0 72057594039959552 LOB_DATA 0 0 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 2 2105058535 tb1 1 2 2105058535 tb1 1 2 /********************************************************************/ 今度は格納行数が2行に増えましたが、使用ページ数は増えていません。よって、1ページには複数行のデータが格納されていることが分ります。次に、tb1.col1に大きいバイト数のデータをUpdateをして、再実行します。 << SQL文 >> /********************************************************************/ USE [mini] GO UPDATE tb1 SET col1 = REPLICATE(N'～', 4000) ; GO SELECT DATALENGTH(col1) col1_len FROM tb1 WHERE id = 1 ; USE [mini] GO SELECT id, DATALENGTH(col1) col1_len FROM tb1 ; SELECT sys.data_spaces.*, sys.allocation_units.allocation_unit_id, sys.allocation_units.type_desc, sys.allocation_units.total_pages, sys.allocation_units.used_pages, sys.allocation_units.data_pages, sys.partitions.object_id, OBJECT_NAME(sys.partitions.object_id) object_desc, sys.partitions.index_id, sys.partitions.rows FROM sys.data_spaces join ( sys.allocation_units left outer join sys.partitions ON container_id = CASE WHEN sys.allocation_units.type % 2 = 1 THEN sys.partitions.hobt_id WHEN sys.allocation_units.type = 2 THEN sys.partitions.partition_id END ) ON sys.data_spaces.data_space_id = sys.allocation_units.data_space_id ORDER BY data_space_id ; /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 4 4 2 72057594039894016 ROW_OVERFLOW_DATA 0 0 0 72057594039959552 LOB_DATA 0 0 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 2 2105058535 tb1 1 2 2105058535 tb1 1 2 /********************************************************************/ 今度はtb1.col1のバイト数8,000バイト×2になったので、 1ページ(8KB)に格納きしれず、 tb1のIN_ROW_DATAが使用しているページ数が増えました。同様にtb1.col2に大きいバイト数のデータをUpdateをして、再実行します。 << SQL文 >> /********************************************************************/ UPDATE tb1 SET col2 = REPLICATE(N'～', 4000) ; USE [mini] GO SELECT id, DATALENGTH(col1) col1_len, DATALENGTH(col2) col2_len FROM tb1 ; SELECT sys.data_spaces.*, sys.allocation_units.allocation_unit_id, sys.allocation_units.type_desc, sys.allocation_units.total_pages, sys.allocation_units.used_pages, sys.allocation_units.data_pages, sys.partitions.object_id, OBJECT_NAME(sys.partitions.object_id) object_desc, sys.partitions.index_id, sys.partitions.rows FROM sys.data_spaces join ( sys.allocation_units left outer join sys.partitions ON container_id = CASE WHEN sys.allocation_units.type % 2 = 1 THEN sys.partitions.hobt_id WHEN sys.allocation_units.type = 2 THEN sys.partitions.partition_id END ) ON sys.data_spaces.data_space_id = sys.allocation_units.data_space_id ORDER BY data_space_id ; /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 4 4 2 72057594039894016 ROW_OVERFLOW_DATA 0 0 0 72057594039959552 LOB_DATA 3 3 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 2 2105058535 tb1 1 2 2105058535 tb1 1 2 /********************************************************************/ 今度はtb1.col2のバイト数8,000バイト×2になったので、 1ページ(8KB)に格納きしれず、 tb1のLOB_DATAが使用しているページ数が増えました。これは、tb1.col1 = nvarchar(4000) と定義されているのに対して、 tb1.col2 = nverchar(max)と定義されている違いです。 max指定をするとLOBと同じ様にデータが扱われ、 LOBとしてページが確保されることが分ります。同様にtb1.col3の値も同じ様にUpdateすると、結果が以下のようになります。 << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 4 4 2 72057594039894016 ROW_OVERFLOW_DATA 3 3 0 72057594039959552 LOB_DATA 5 5 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 2 2105058535 tb1 1 2 2105058535 tb1 1 2 /********************************************************************/ この様に、ページには複数行格納されているものもあれば、複数ページで1つのデータを格納しているものもあります。このあたりの詳細はMSDNを参照すると、より理解できるかと思います。ページとエクステントについて MSND http://msdn.microsoft.com/ja-jp/library/ms190969.aspx 参照：8 KB を超える場合の行オーバーフローデータ MSND http://msdn.microsoft.com/ja-jp/library/ms186981.aspx ====================================================================== データファイルとエクステント ====================================================================== ここで話を最初のデータファイルの方に戻します。このminiというデータベースを作成し、tb1というテーブルを作成、レコード2件登録、col1, col2, col3とUpdateしてきました。ここまでの状態で、mini.dbo.tb1がデータを格納するために使用しているファイルのサイズは524,288 バイトになっていました。この状態から、データをこのままで1件ずつ増やしていきたいと思います。 << SQL文 >> /********************************************************************/ INSERT INTO tb1 SELECT id + 1, col1, col2, col3 FROM tb1 WHERE id = ( SELECT MAX(id) FROM tb1 ) ; /********************************************************************/ このSQLを何度も発行し、最初にデータの増減があった17行目でデータファイルのサイズやデータベースのページ数を取得してみます。 << SQL文 >> /********************************************************************/ SELECT sys.data_spaces.*, sys.allocation_units.allocation_unit_id, sys.allocation_units.type_desc, sys.allocation_units.total_pages, sys.allocation_units.used_pages, sys.allocation_units.data_pages, sys.partitions.object_id, OBJECT_NAME(sys.partitions.object_id) object_desc, sys.partitions.index_id, sys.partitions.rows FROM sys.data_spaces join ( sys.allocation_units left outer join sys.partitions ON container_id = CASE WHEN sys.allocation_units.type % 2 = 1 THEN sys.partitions.hobt_id WHEN sys.allocation_units.type = 2 THEN sys.partitions.partition_id END ) ON sys.data_spaces.data_space_id = sys.allocation_units.data_space_id ORDER BY data_space_id ; SELECT DB_NAME(database_id) dbname, name, file_id, file_guid, physical_name, cast(size as decimal) *8*1024 [size], case when max_size < 0 then N'無制限' else CAST(max_size as nvarchar) end max_size, case when growth = 0 then N'固定' else CAST(growth as nvarchar) end + case when is_percent_growth = 1 then N'%' else N'page(s)' end growth FROM sys.master_files ; /********************************************************************/ << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 4 4 2 72057594039894016 ROW_OVERFLOW_DATA 25 18 0 72057594039959552 LOB_DATA 41 35 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 17 2105058535 tb1 1 17 2105058535 tb1 1 17 ====================================================================== dbname physical_name size max_size growth ------ ---------------------------- ------- -------- ---------- mini C:\SQL ServerData\miniSec.mdf 655360 無制限 8page(s) /********************************************************************/ ファイルサイズが524288バイトから655360バイトへ増加しました。これによって増加したページ数は128ページ、増加したエクステント数は16エクステントだと分ります。 (655360 - 524288)/8192 = 16ページ 16 / 8 = 2 エクステント次はINSERTのデータを少なくして、増加をみてみます。 << SQL文 >> /********************************************************************/ INSERT INTO tb1 SELECT id + 1, col1, null, null FROM tb1 WHERE id = ( SELECT MAX(id) FROM tb1 ) ; /********************************************************************/ このSQLを何度も発行し、最初にデータの増減があった状態は以下のようになります。 << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 7 7 5 72057594039894016 ROW_OVERFLOW_DATA 25 18 0 72057594039959552 LOB_DATA 41 35 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 20 2105058535 tb1 1 20 2105058535 tb1 1 20 dbname physical_name size max_size growth ------ ---------------------------- ------- -------- ---------- mini C:\SQL ServerData\miniSec.mdf 720896 無制限 8page(s) /********************************************************************/ ファイルサイズが655360バイトから720896バイトへ増加しました。これによって増加したページ数は8ページ、増加したエクステント数は1エクステントだと分ります。これまでの、データ増加は1ページより大きいデータを追加してきました。では、1ページ未満のデータを数件いれて増加量を見てみようと思います。 << SQL文 >> /********************************************************************/ INSERT INTO tb1 SELECT ( SELECT MAX(id) FROM tb1 ) + 1, REPLICATE(N'0',1000), null, null ; /********************************************************************/ このSQLを何度も発行し、最初にデータの増減があった状態は以下のようになります。 << 実行結果(抜粋) >> /********************************************************************/ name data_space_id type type_desc is_default ------- ------------- ---- -------------- ---------- miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 miniSec 2 FG ROWS_FILEGROUP 1 allocation_unit_id type_desc total_pages used_pages data_pages ------------------ ----------------- ----------- ---------- ---------- 72057594039828480 IN_ROW_DATA 17 10 8 72057594039894016 ROW_OVERFLOW_DATA 25 18 0 72057594039959552 LOB_DATA 41 35 0 object_id object_desc index_id rows ----------- ----------- -------- ---- 2105058535 tb1 1 29 2105058535 tb1 1 29 2105058535 tb1 1 29 dbname physical_name size max_size growth ------ ---------------------------- ------- -------- ---------- mini C:\SQL ServerData\miniSec.mdf 786432 無制限 8page(s) /********************************************************************/ ファイルサイズが720896バイトから786432バイトへ増加しました。これによって増加したページ数は8ページ、増加したエクステント数は1エクステントだと分ります。なぜ、この8ページで増加するのかというと、 CREATE DATABASEで指定したFILEGROWTH=1KBが SQL Serverによって、1KBから最も近い64 KB 単位の値に切り上げられて増加するからです。よって、ファイルサイズの最小増加は8ページ単位になります。 ====================================================================== まとめと考察 ====================================================================== ・データベースにはデータが格納されるデータファイルと、ログが格納されるログファイルとを持っている。 -> これによって、SQL Serverはデータベースごとにログファイルを持つ構造になっていることがわかる。よって、インスタンス毎ではなく、データベース毎のバックアップ & 復旧が行われる必要がある。・データベースはページという単位を持っていてページはデータファイルの中に書きこまれる最小単位である。また、ページにはテーブルのデータが格納されていて、 1ページに複数行格納されている。ただし、8KBを超えるデータの場合、ページをまたがってデータが格納される。 -> 1ページは8KBという制限があるので、列長を8KBよりも大きくするときは、性能面での考慮が必要。 (ページ毎にバッファへのデータ入出力が行われるため) ・データが格納できるページが無くなると、ファイルの拡張が発生する。また、データファイルは最小64KB単位で増えていく。よって、8ページ=1エクステント単位で増えていく。 -> SQL Serverのデータファイルを格納するディスクがデータ増加により、知らない間に圧迫されないか気を払う必要がある。特に、無制限拡張をしている場合は使えるだけどんどんファイルサイズが増加するので注意が必要。・データファイルには、ファイルとグループの2種類があ��。 -> ファイルグループを使い、実ファイルを複数ディスクに分散させることが出来る。 ┏─────────────────────────────────┓ ┃ご質問について ┃ ┗─────────────────────────────────┛ ＜皆様からのご質問を受付けております＞皆様のご質問にはできるだけ、お答えしたいと思っています。すべてのご質問にお答えすることはできないかもしれませんが、適宜メルマガ内でとりあげていく予定ですので、是非お気軽に下記アドレスまでお寄せください。ご意見、ご感想などもお待ちしておりますっ！！ wlmailhtml:{FFB7FEE3-FD66-4A13-AECC-755EBDF825BF}mid://00000000/!x-usc:mailto:letter@insight-tec.co.jp ┏─────────────────────────────────┓ ┃編集者より ┃ ┗─────────────────────────────────┛ 初めまして！！この度は、どっぷりリファレン中をご購読いただきまして、本当に！本当に！ありがとうございますっ♪初回はいかがでしたでしょうか？？感想＆ご質問等ありましたらご遠慮なくお知らせいただけると、とても、とても、嬉しいですっ！！不定期の配信となりますが、次回の配信を首をながーくしてお待ちくださいね☆ by TI ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＜えす！エス！レスキュー SQL Server -どっぷりリファレン中！！-＞発行／編集：株式会社インサイトテクノロジー http://www.insight-tec.com wlmailhtml:{FFB7FEE3-FD66-4A13-AECC-755EBDF825BF}mid://00000000/!x-usc:mailto:letter@insight-tec.co.jp 本メールマガジンに掲載された記事を許可なく転載することを禁じます。 Copyright(c) 2009, Insight Technology, Inc., All Rights Reserved. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ※本メールマガジンは株式会社インサイトテクノロジーより許諾を受けて、紹介のために掲載しています。
SQL Server on Windows 7 / Windows Server 2008 R2

Posted over 5 years ago

by T.Kitagawa
マイクロソフトの北川です。

本日から東京ビッグサイトにて IT Pro Expo が開幕となっております。マイクロソフトのエリアに SQL Server も出店しており、会場では NEC 様の協力を得て Fast Track Data Warehouse の説明を行っております。

ご興味のある方がいらっしゃいましたら是非足をお運びいただければと思います。プロダクトマネージャー一同会場で皆様とお話しできるのをお待ちしております。

以前「SQL Server の Windows 7 RC / Windows Server 2008 R2 RC 上での利用について」として本ブログでもご案内させていただきましたが、正式にブックスオンラインでの案内が出ておりますので、下記にまとめておきます。

Windows 7 / Winodws Server 2008 R2 上で SQL Server を利用するためには、下記のサービスパック (SP) を適用いただく必要があります。

SQL Server 2005 ： SP3 以降
SQL Server 2008 ： SP1 以降

詳細な情報に関しては下記をあわせてご確認ください。

技術文書

Windows 7 または Windows Server 2008 R2 に SQL Server をインストールする場合は、既知の問題の一覧
 SQL Server 2008 on Windows 7 / Windows Server 2008 R2 (英語 - オンラインブック)
SQL Server 2005 on Windows 7 / Windows Server 2008 R2 (英語 - オンラインブック)

ダウンロード

Microsoft SQL Server 2008 Service Pack 1
Microsoft SQL Server 2005 Service Pack 3

上記ご確認いただければ幸いです。
PASSJ (SQL Server ユーザーグループ) 休会について

Posted over 5 years ago

by T.Kitagawa
マイクロソフトの北川です。

PASSJ サイトに掲載されておりますように、PASSJ が6月30日をもって休会となる連絡を受けました。これまで9年間 PASSJ を運営されてこられた理事の方にとっては、休会という決断は苦渋の判断であったと思います。

PASSJ には秀逸な技術コンテンツが掲載されております。こういった技術資料に関してはマイクロソフトの IT Pro / Developer 向けコミュニティサイトである TechNet / MSDN フォーラムへの移管を含めて、今後も PASSJ に参加されていた方々に参照いただけるよう、力添えさせていただければと考えております。

PASSJ 運営にご尽力いただいた方々に深く感謝すると同時に、今後は「TechNet SQL Server フォーラム」をエンジニア間の情報交換の場としてご活用いただければ幸いです。
都市伝説 (Urban Legends) を読み解く - データが読み込めないのは「文レベル読取り一貫性」によるものなのか!?

Posted over 4 years ago

by T.Kitagawa
マイクロソフトの北川です。

都市伝説には「ニュース性」「真実味」「オチ」という特徴があり、起源や根拠が全く不明なものが多いとされています。また、何かしらの根拠があるものに関しても、なんでもない事実に尾ひれがついて伝説化したとされています。この都市伝説の問題はそれが「真実」であるかのように語られる点にあります。特定の都市伝説が広く普及した原因は、広く信頼されているソースにより紹介されたことにあるとされています。

閑話休題

日本オラクル社のウェブサイトにおける「オラクル都市伝説」で揶揄されている「あのデータベース」ですが、今回は「PowerPivot と相性がいい」とされているようです。この PowerPivot は、提示されている UI を見るとマイクロソフトが5月1日より提供開始した SQL Server 2008 R2 PowerPivot for Excel (以降 PowerPivot) のようです。

「データの活用」という観点でエンジンでは競合する両社がともに「セルフサービス BI」の重要性を訴求するといういいお話では残念ながらないようです。では、今回はこの「都市伝説」を読み解いてみましょう。

本文中から読み取れる前提とゴール

[ゴール]　売上分析レポートを作成する

[前提]
1. 事業部 X (Oracle Database), Y (あのデータベース) のシステムは別
2. 「売上分析レポート」という提携で準備されていそうなレポートであるにもかかわらず、定型レポートには含まれていないため、アドホックにレポートを作成する必要がある
3. レポートで使用する対象のテーブルは「仕入先」「社員」「受注」「受注明細」「商品」「商品区分」「都道府県」「得意先」
4. 月末のため、事業部のほぼ全員がデータベースにアクセスして「顧客毎の営業ステータスを更新する」ために更新処理を行っている
5. 上記で更新されているテーブルはレポートで使用する対象のテーブルに含まれている (レポート作成のために読み取る必要があるとされている)
6. 「あのデータベース」では「文レベル読取り一貫性」が有効になっておらず、デフォルトの分離レベルで稼働している
7. レポートで使用する対象のテーブルはサイズが大きい (朝6時から9時の3時間で取得が終わらないほどに)
　

データが読み込めないのは「文レベル読取り一貫性」によるものなのか!?

まず最初に「あのデータベース」では「一個目のテーブル(仕入先)から一向にデータが取得でいない」とされています。それに対して Oracle Database ではデータ取得が短時間で終わっているとされています。では、「あのデータベース」が SQL Server と見なして上記前提と照らし合わせて考えてみましょう。なお、この都市伝説のコンテンツは Oracle Database と「あのデータベース」との比較を行っていることから、上記前提は等しく両者のデータベースを使用したシステムに適用されるものと仮定します。(でなければ公平な比較はできませんよね。)

システムは別、とされていますが、読み込みを行おうとしている SQL Server 2008 R2 PowerPivot for Excel の画面からすると、テーブル構造は同じのようです。また、今回「あのデータベース」に対しては「ダーティーリード」を実行していないようです。つまり、SQL Server 2008 R2 PowerPivot for Excel で SQL 文を NOLOCK ヒント付きで実行するようなことは「あえて」していないようです。

前述の「前提」と合わせて考慮すると「あのデータベース (SQL Server)」は Read Committed で稼働しているようです。SQL Server ではレコードのデータが更新された場合、当該レコードの更新がコミットされるまで排他ロックを持ちます。そのため、データの取得のための共有ロックを取得することができず、ロックの競合が発生し、データの取得がブロックされます。これが SQL Server のデフォルトの動作です。

一向に読み込めないということは、(a) ロックの競合が解決しない、もしくは (b) テーブルのすべてのレコード (n) に対して少なくとも1回の更新が連続的に発生しているため、ロックの競合に連続してあたってしまい、読取りが完了できない、という状況が想定されます。

もし (a) の場合、問題は「あのデータベース (SQL Server)」ではなく、アプリケーションの作り方にあります。きちんと更新のためのトランザクションが終了していれば、ロックの競合が解決されデータの取得が行われます。Oracle Database では「文レベル読取り一貫性」が適用されていますので、データの取得を正常に行うことが可能です。

もし (b) の場合、「あのデータベース (SQL Server)」では、更新処理に1秒かかるとすると、少なくとも n 秒後にはデータの取得が行われます。Oracle Database では「文レベル読取り一貫性」が適用されていますので、データの取得は行えていますが、レポートとして利用するべきものにもかかわらずそのデータは「SELECT 文発行時点」のものであり「最新ではない」データに基づいたレポートになります。

もし (a) & (b) の場合、お手上げです。「あのデータベース (SQL Server)」ではロックの競合が解消されず、データの取得が行えません。Oracle Database では、n の数にも依存しますが、 ORA-01555 のエラーが発生する危険性がかなり高くなります。

前提では「事業部のほぼ全員があのデータベースにアクセスし更新処理を行っている」かつ「Oracle ではデータ取得がサクサクと短時間で終わっている」かつ「あのデータベースではデータ取得が進まない」とされていますので、条件は (a) & (b) といえるでしょう。つまり
- 「あのデータベース (SQL Server)」
  未コミットのデータが存在するため、ロックの競合が解消されずデータが取得できない。ただし、これはアプリケーション側でデータの更新後にコミットを行わないことが原因である。コミットが行われていれば n 秒後にはデータ取得が完了する。
- Oracle Database
  「文レベル読取り一貫性」により、SELECT 文発行時点のデータが取得される。ただし、多数実行されている更新の結果は反映されていないレポートになる。
ということができます。もし Oracle Database から作成されたアドホックレポートの結果が許容されるのであれば、PowerPivot でのデータ取得時に SELECT 文に NOLOCK ヒントを付加することで同レベルの処理を実行することができるでしょう。

[結論] データが読み込めないのは「文レベル読取り一貫性」のためではない。「アプリケーションの作り方」が原因である。データ更新後にはコミットもしくはロールバックを発行する。もちろん、SQL Server では、デフォルトでトランザクション終了時には暗黙のコミットが行われるため、そもそもトランザクションを CLOSE しない、という稀有なアプリケーションでない限りこのような事態に陥ることはない。なお「非常に高い更新頻度」が原因である場合には、レコード数や頻度に依存して時間がかかるが「読み込めない」という事象には至らない。時間短縮のためには「NOLOCK ヒント」を利用することができる。

[本項目における突っ込みどころ]
1. 「前提」に書かれているテーブル群からすると、当該システムは「受注管理システム」のようです。これから「売上分析レポート」を作成するというのは理にかなっています。しかし、「月末のため、事業部のほぼ全員がデータベースにアクセスして顧客毎の営業ステータスを更新するために更新処理を行っている」というワークロードは「受注管理システム」に対してのワークロードとしては不適切なのではないでしょうか。どちらかといえば営業管理システムや顧客管理システムの範疇ではないかと。そもそも営業ステータスを格納するようなテーブルは対象のテーブルの中には見当たりません。仮に「月末に受注処理が集中する」としても、発生するワークロードは新しい受注レコード及び明細レコードの挿入であり、この場合、コミット済みのデータに関しては正しく読み取ることが可能です。
2. 都市伝説本文の図には「データに一貫性がない = ダーティリード」という記載がありますが、「読取り一貫性」で提供される一貫性とは通常「文レベル読取り一貫性」であり、コミット済みデータを読み取る際に、SELECT 文が発行された時点の一貫性が保たれていることを意味しています。一方「ダーティリード」とは、ロールバックすると存在しないレコードを読み込むことを意味しています。読取り一貫性とはそもそも異なる概念です。もちろん、読取り一貫性は同時実行性を高めることは可能ですが、アドホックレポートを複数作成した場合、その結果は共通のものとはならない可能性が高くなります。
3. 売上分析レポートが標準の定型レポートに含まれていない、ということがそもそもあるのかどうか…。
4. アドホックな売上分析レポートが必要なのであれば、SQL Server 2008 R2 PowerPivot for Excel より Report Builder 3.0 のほうが適切ですね。こちらも SQL Server だけではなく、Oracle Database 他のデータベースに接続することが可能です。
アプリケーション基盤の標準化とコスト削減のための EAP: Enrollment for Application Platform を発表しました。

Posted over 5 years ago

by ysaito9613
マイクロソフトの斎藤です。

新聞等のメディアで報道があったのですでにご存じだと思いますが、マイクロソフトでは 10月2日に、企業内アプリケーション基盤の標準化を検討されているお客様を対象とした新しいライセンスプログラム、EAP (Enrollment for Application Platform) を発表しました。

EAP は下記 3 つの特長があります。
- アップグレード権 (SA) を持っていない製品でも、最新のバージョンにバージョンアップする権利を得られる。この場合のライセンス (L) 費用を終了しない限り支払う必要はない。
- 新規の購入の場合ライセンス (L) 費用を最大 40% のディスカウント。
- Premier サポートの問題解決レイバーが無制限。
この EAP はどなたでも加入契約ができるわけではなく、最低のベースラインが設定されております。また EA (Enterprise Agreement) 契約の一環になり、全社契約が前提となりますので、ご注意ください。詳細は、下記 Web サイトをご覧ください。

http://www.microsoft.com/japan/licensing/enterprise/eap.mspx
SQL Server 2008 新機能 - 空間（Spatial）データ型への対応

Posted over 5 years ago

by T.Kitagawa
マイクロソフトの北川です。

本日いったんポストした「Spatial データへの対応」を読みやすくページ形式でポストしなおしました。
今後はこのような形で掲載を行いたいと思います。

SQL Server 2008 では、新機能として空間データ型が追加されましたが、その利用方法および詳細な情報に関して残念ながら十分に周知できていません。

今後の SQL Server の進化において Beyond Relational という観点で重要な項目ですので、どのような新機能なのか興味のある方はぜひご確認ください。

Read More...
Spatial データへの対応

Posted over 5 years ago

by TechNet Archive
- 1 Comment
マイクロソフトの太田です。

社内や知人から聞かれた質問の代表的なものをとりあげて、解説していこうと思います。今日は社内の人からSQL Server 2008の空間データ型について、質問を受けました。

Spatial データ

どのような機能かということと、次のバージョンでの展望のようなものを聞かれました。一言で言うと、Spatial データ型のサポートとは、次の3点セットを意味します。

１．空間情報（xy 座標または緯度経度等）を、位置を表す情報として格納するためのデータ型

２．上記のデータ型に入れられたデータ（点、図形、領域等）を操作する関数群

３．上記関数のいくつかが高速に実行できるようにするためのインデックス

データを表現する部分（多くは地図とともに表示されます）は、SQL Server 2008 としては特に対象としていません。ただし、SSMS（SQL Server Management Studio）では一部表示機能（空間結果）があります。

情報が少ないことは事実なのですが、次のような説明はあります。

http://msdn.microsoft.com/ja-jp/library/cc280766.aspx

http://msdn.microsoft.com/ja-jp/library/cc280487.aspx

上記の3点セットの中で、１は Geometry 型と Geography 型というものがあります。これらはそれぞれ平面状のｘ座標、ｙ座標で表される図形を入れるためのデータ型、および緯度経度（＋空間参照識別系）で表される図形を入れるためのデータ型となります。そして２はそれらの関係（図形間の包含関係、距離等）や特性（長さ、面積、頂点等）を取得するための関数群です。これらの関数群は Geometry 型と Geography 型とで用意されているものが異なります。たとえば Geometry 型にある STContains のような包含関係を表す関数は Geography 型にはなく、逆の場合もあります。

空間データに対するクエリの例や関数の例は、Geoquery2008 というソフトウェアで見るとかなり視覚的に理解しやすいと思います。

次のスクリーンショットはSQL Server 2008用のAdventureWorks2008というデータベースの中のPerson.Addressテーブルに対してクエリを行った結果を図示しています。

（使い方は、Connectでデータベースに接続し、データベースを選び、クエリを記述します。）

このサンプルデータベースについては中身のデータまで真剣に見たことがなかったのですが、住所情報が散らばっていることが分かりました。

またメニューの Examples を選ぶと前述の関数群の一覧が表示され、いずれかを選択するとその使用例としてのクエリの例が表示され実行（Execute）すると結果が地図上にプロットされます。一通りの機能の概要を見るには便利なツールです。

このように１と２については表層的に理解することができます。質問者はきっとインデックスについてお客様から聞かれたのかも知れません。また今後の予定については、当然どのような拡張が行われますかという意図だと考え、可能性をお伝えしたのですが、質問者の意図は、「機能がなくなることはないですか？」というものだったようです。ちょっとがっかりしましたが、空間情報や FILESTREAM をはじめとするいわゆる通常の文字数値以外のデータの扱いは Beyond Relational というカテゴリになりますが、これは今後もSQL Serverにとっては大きな柱の一つですという回答をいたしました。この辺はまたいつか書いてみたいと思います。
USTREAM 収録を公開 Microsoft BI/DWH Day (12/7@秋葉原 UDX ギャラリー)

Posted over 4 years ago

by ysaito9613
マイクロソフトの斎藤です。

12月7日秋葉原の UDX ギャラリーで開催された Microsoft BI / DWH Day ですが、非常に多くの方にご参加いただき成功裏に終了することができました。ご参加いただいた皆様ありがとうございました。

残念ながらご参加いただけなかった皆様は、基調講演と Parallel Data Warehouse エディションのセッションに関しては USTREAM の収録を是非ご覧ください。

収録を見る-> http://www.microsoft.com/japan/sqlserver/2008/r2/event/pdw.mspx
SQL Server 2008 Service Pack 1 提供開始

Posted over 5 years ago

by ysaito9613
- 2 Comments
マイクロソフトの斎藤です。

SQL Server 2008 Service Pack 1 (SP1) のダウンロード提供を本日より開始しましたのでお知らせします。
- SQL Server 2008 Service Pack 1 ダウンロード
  http://www.microsoft.com/downloads/details.aspx?familyid=66AB3DBB-BF3E-4F46-9559-CCC6A4F9DC19&displaylang=ja
SQL Server 2008 SP1 には、2008年 8月の製品開発完了後に確認されたすべての不具合を修正するモジュールが同梱されており、２ヶ月に一回定期的に提供されている累積的な更新プログラムパッケージ 1 (CU1) から同 3 (CU3) の内容を包含しています。

また、今回の SP1 では、管理者の負荷を軽減するために、下記 2 つの機能があらたに提供されます。

■ Service Pack 適用業務の工数削減のためのスリップストリームイメージの作成が可能
従来の Service Pack では、一旦製品版をインストール後、Service Pack を追加で適用する必要がありました。この作業は SQL Server インスタンスの追加毎にも必要で Service Pack を適用する業務を行う管理者の負担になっていました。
今回の SQL Server 2008 SP1 では、単一のセットアップで SQL Server 2008 の製品版と SP1 のインストールを同時に行うことを可能とするスリップストリームイメージを作成することができ、新規インストール時およびインスタンス追加時の作業工数を削減すること可能になっています。

■ Report Builder 2.0 を ClickOnce アプリケーションとして配布が可能
Report Builder 2.0 は、2008年 10月より提供を開始した SQL Server 2008 Reporting Services に対応したレポート作成ツールです。Report Builder 2.0 は、2007 Office system と同様のリボンインターフェースや、データベースへの選択クエリを自動生成するツールを搭載し、専門的な開発ツールや SQL 言語に不慣れなインフォメーションワーカーでも、セルフサービスによる本格的かつグラフィカルなレポートの作成を可能にします。
従来 Report Builder 2.0 は、管理者によって各クライアント PC に個別にインストールする必要がありましたが、今回の SP1 で提供される Report Builder 2.0 では、.NET Framework の ClickOnce の機能に統合され、初回起動時に自動的にクライアント PC にインストールすることが可能になっています。

新しい開発プロセスを採用することによって、製品出荷時点から高い品質を提供している SQL Server 2008 ですが、今回の SP1 の提供によって更に高い品質を提供できるようになります。是非 SP1 をダウンロード頂き、適用をお願いいたします。
- SQL Server 2008 Service Pack 1 ダウンロード
  http://www.microsoft.com/downloads/details.aspx?familyid=66AB3DBB-BF3E-4F46-9559-CCC6A4F9DC19&displaylang=ja
都市伝説 (Urban Legends) を読み解く - 必要なデータをフィルタリングする方法は!?

Posted over 4 years ago

by T.Kitagawa
マイクロソフトの北川です。

都市伝説には「ニュース性」「真実味」「オチ」という特徴があり、起源や根拠が全く不明なものが多いとされています。また、何かしらの根拠があるものに関しても、なんでもない事実に尾ひれがついて伝説化したとされています。この都市伝説の問題はそれが「真実」であるかのように語られる点にあります。特定の都市伝説が広く普及した原因は、広く信頼されているソースにより紹介されたことにあるとされています。

閑話休題

日本オラクル社のウェブサイトにおける「オラクル都市伝説」で揶揄されている「あのデータベース」ですが、今回は「PowerPivot と相性がいい」とされているようです。この PowerPivot は、提示されている UI を見るとマイクロソフトが5月1日より提供開始した SQL Server 2008 R2 PowerPivot for Excel (以降 PowerPivot) のようです。

「データの活用」という観点でエンジンでは競合する両社がともに「セルフサービス BI」の重要性を訴求するといういいお話では残念ながらないようです。では、今回はこの「都市伝説」を読み解いてみましょう。

以下オラクル都市伝説サイトより。
1. テーブルに格納されているデータすべてを取得しようとしている
2. 3時間かけてもデータの取得が終わらない
実際にディスクの転送量からそのデータ量を検討してみましょう。今回のシステムは一般的なタワー型サーバーを使用していると仮定します。こういったサーバーにはデータ領域用途で通常4本程度のディスクを内蔵することができるようになっています。近年主流となっている SATA 7,200rpm のディスクのシーケンシャル Read の性能がおおむね 30MB/sec (Disk to CPU) とします。一般的なタワー型サーバーでは、4本のディスクを内蔵することができますので、このディスクで RAID0+1 (Stripe & Mirror) 構成をとった場合、60MB/sec となります。

都市伝説サイト本文では「バッチが終了した6時から9時までかけてもデータ取得が完了できなかった」と書かれていますので、3時間かけてもデータ取得を完了できなかったことになります。では、いったいどれくらいのデータサイズだったのでしょうか。計算してみましょう。60MB/sec * 3,600sec * 3 = 648,000MB となりますので、データは最低でも約650GB あるようです。

Oracle Database で稼働する X 事業部のシステムおよび「あのデータベース (SQL Server)」で稼働する Y 事業部のシステムは同じサイズのデータを持っており、同スペックのタワー型サーバーで稼働していると仮定します (比較対象ですので、同じデータ量および同じハードウェア構成を持つと仮定することが出来ますよね)。

3時間かけてもすべてのデータの取得が終わらなかった「あのデータベース (SQL Server)」で稼働する Y 事業部のシステムに対して、Oracle Database で稼働する X 事業部のシステムは、VPD (Virtual Private Database) により「ユーザーごとに必要なデータにのみアクセスを許可」する一種のフィルタリングが行われているため「データ取得もサクサクと短時間で終わっている」とされています。

では、X 事業部のシステムはどのような属性でフィルタリングされているのでしょうか。データの取得のため、J くんは自身のアカウントで X 事業部のシステムにログインしたと推測されます (セキュリティに配慮した、とされている X 事業部が共有アカウントを利用していることは想定外)。アクセス制御で利用されている VPD は、ユーザー名を含む「セッションコンテキスト」という属性を利用してアクセス制御をおこないます。どのようなポリシーが施行されていたかは都市伝説本文中には記載されていませんが、同スペックの機材で純粋な読取りに3時間以上かかるデータを「サクサクと短時間で終わっている」といえる時間で読み取っていることから、かなりの量のデータがフィルタリングされていると推測されます。とすると、ユーザーもしくはユーザーが所属するグループの発注情報のみ参照できるようにアクセス制御ポリシーが設定されているのかもしれません。

ここで当初の目的を振り返ってみましょう。M 部長から K さんが依頼されたのは「会議で使うための X 事業部と Y 事業部の売り上げ分析レポートの作成」です。そして依頼された K さんは「X 事業部は新人の J くん、Y 事業部は K さん」と担当を決め、のちに「J くんと担当を変えようかと思ったが、先輩として新人に重荷を負わせることはできない」と逡巡していますので、二人が固定的に特定の事業部に所属している、もしくは特定の事業部のシステムをメンテナンスしている、ということはないと想定することが出来ます。

とすれば、J くんのアカウントで X 事業部のシステムにログインしたとしても、J くんの受注データや J くんが所属するグループのデータが抽出できるわけではなさそうです。そのため、アクセス制御ポリシーは、ログインしたユーザーの職責に基づいていると新たに想定することが出来ます。

では、当初の目的に「J くんの職責で抽出したデータ」は合致しているでしょうか。残念ながら M 部長が求めている売り上げ分析レポート、すなわち X 事業部としての売り上げ分析レポートとしては不十分な情報から作成されたレポートになってしまっているのではないでしょうか。

PowerPivot で必要なデータをフィルタリングする方法は!?

PowerPivot では、圧縮された多次元データベースとしてデータを保持することにより、Excel の限界を超えるデータを高速に処理することが可能です。しかし、今回のケースのように、650GB を超えるデータを取り込もうとした場合、データの読み取りに相応の時間が必要となります。

そこで、PowerPivot では、データベースから直接データを読み取るのではなく、SQL Server Reporting Service (SSRS) からデータを読み取ることが出来るようになっています。Y 事業部のシステムは「あのデータベース (SQL Server)」で稼働していますので、おそらく定型レポートは SSRS により実装されていると思われます。この SSRS からのデータ読み取りを利用することで、あらかじめ PowerPivot に取り込むデータを柔軟にフィルタリングすることが可能となります。

[結論] 仮に J くんが「特権ユーザー」でログインしている場合には約650GBのデータにアクセスすることが出来るかもしれません。両システムが稼働しているサーバーのハードウェア構成が共通の場合、やはり全データの取り込みには3時間以上かかることになります。

もし「サクサクと短時間で終わっている」という時間でデータ取得を終了させたい場合には、同レベルのハードウェアではなく、15,000rpm SAS ��ィスクを10本搭載した MSA2300 ストレージアレイを複数台利用した大規模システムである必要があります (MSA2300 ストレージアレイを3筐体 8G FC で接続したとしても、約650GB のデータをすべて取得するには14分ほどかかる計算になります)。

つまり、VPD によるアクセス制御が施行されたおかげでデータ取得が高速化されることは今回の目的には全く合致しておらず、高速なデータ取得のためには、いずれのシステムにおいてもストレージの増強が必要であると言えます。

もしくは、PowerPivot でデータを取り込む前にデータを簡単にフィルタリングする仕組みが必要です。SQL Server では SSRS からのデータ取得を利用することで、SQL 文を入力したりせず、簡単にフィルタリングを行うことが出来ますので、PowerPivot にはやっぱり SQL Server ということが出来ます。

[本項目における突っ込みどころ]
1. SQL Server 2008 Enterprise, SQL Server 2008 R2 Enterprise / Datacenter では、データ圧縮の機能を標準で利用することが出来ます。マイクロソフトがパートナー様と実施した共同検証では、TPC-C の LineItem テーブルを 1:10 で圧縮することが出来ました。今回のシステムで使用されている発注テーブルおよび発注明細テーブルなども同じ圧縮率で圧縮することが出来たと仮定すると、ハードウェアを増強せずとも、約650GB の生データを約18分 (650,000MB / 10 / 60MB/sec) で読み込むことが出来ることになります。
2. そもそも「売り上げ分析レポート」という基本的なレポートであれば、定型レポートとして準備されていてもよさそうですが。SQL Server のコンポーネントである SSRS を利用すれば、こうした定型レポートも簡単に作成することが出来ます。
3. アドホックレポートの作成であり、ユーザー側でのデータのマージなどの処理が不要なのであれば、そもそも PowerPivot ではなく、Report Builder 3.0 の方が適しているかもしれません。Report Builder 3.0 を利用すれば、PowerPoint のようなユーザーインターフェースで、エンドユーザーが簡単にアドホックレポートを作成することが可能です。もちろん地図連携も可能です。また、SQL Server だけではなく、その他のデータベースにも直接接続してデータを取得することが可能です。こうした「追加の費用なく、データベースに格納されたデータをより簡単にエンドユーザーが活用することが出来る」という点が SQL Server の特徴であるということが出来ます。
4. PowerPivot を活用したセルフサービス BI については「こんな悩みにさようなら! 明日から使えるシーン別データ活用法」でも紹介されています。
伝説の Dr.K's SQL Server チューニング研修連載復活

Posted over 4 years ago

by ysaito9613
マイクロソフトの斎藤です。

マイクロソフトの技術顧問であり CSK WinTechnology の技術フェロー特別役員である Dr.K こと熊澤幸生氏による伝説の連載記事「@IT Dr. K's SQL Serverチューニング研修」がこの度復活いたしました。

http://www.atmarkit.co.jp/fdb/rensai/10_drk/01/drk01.html

その Dr.K が登壇する SQL Server 2008 R2 のセミナーイベント開催決定！
- SQL Server 2008 R2 Technology Summit (6月15日開催)
お申込みはこちらから。
動画で分かる SQL Server 2008 R2 ついにシリーズ完結！

Posted over 4 years ago

by Jun Matsuzawa
こんにちは。マイクロソフト松澤です。

SQL Server 2008 R2 が発売となり、1か月ちょっと経ちました。ちょっと時間がかかってしまいましたが、ようやく完成したものがありますのでご紹介します。

■SQL Server 2008 R2 製品ガイド

SQL Server 2008 R2 の機能概要は、Web サイトやカタログでもご紹介していますが、さらに詳しく書いているのがこちらの資料です。142ページもあり、かなり読み応えたっぷりになっています。

PDF ファイル / XPS ファイル

■マイクロソフトのビジネスインテリジェンスソリューションカタログ

SQL Server 2008 R2 ではビジネスインテリジェンス (BI) 機能が強化されています。BI はもちろん、SQL Server だけでもできることはたくさんありますが、Microsoft Office 2010 や Microsoft SharePoint Server 2010 と組み合わせることで、もっともっとできることが増えます。このカタログではそれぞれの製品のもつ便利な機能をご紹介しています。

PDF ファイル / XPS ファイル

■動画で分かる SQL Server 2008 R2

全18本、全て公開されました！これにてシリーズ完結となります。

さて、ここで簡単なクイズです。実は1本だけ、他とちょっと違う松澤が出ております。微妙な差ですが、お分かりになるでしょうか？分かった！という方は Twitter の個人アカウント（先日の blog エントリにて公表しております）でダイレクトメールをいただければ、と思います。正解者には・・・何か考えておきます。（何かできたとしても、先着2名ぐらいでしょうか。）
SQL Server 2008 による PCI DSS (Payment Card Industry Data Security Standard) への対応

Posted over 5 years ago

by T.Kitagawa
- 1 Comment
マイクロソフトの北川です。

セキュリティの基準として PCI DSS (Payment Card Industry Data Security Standard) という規格が話題に上ることが出てきました。この規格はクレジットカード業界におけるセキュリティ基準なのですが、情報セキュリティに関する具体的な実装に言及しているため、クレジットカード業界以外でも参考とされるケースが出てきているようです。

SQL Server Security ブログでも「PCI DSS Compliance with SQL Server 2008」として紹介されていますので、英文資料ではありますが、PCI DSS に準拠する形で SQL Server 2008 を導入する手法に関して興味のある方は、下記資料をご一読いただければと思います。

Parente Randolph - PCI QSA (Qualified Security Assessor)
Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standard (PCI DSS) Version 1.2 (英語)
情報基盤強化税制のための ISO/IEC 15408 取得状況

Posted over 5 years ago

by ysaito9613
マイクロソフトの斎藤です。

SQL Server の情報基盤強化税制のための ISO/IEC 15408 取得状況についてよくご質問をいただきますので、ここでも紹介させていただきます。

SQL Server は、SQL Server 2005 も SQL Server 2008 も ISO/IEC 15408 を取得済みで、情報基盤強化税制に対応しております。

詳細は、こちらの Web サイトをご覧ください。