Comments
Description
Transcript
SQL Server 2014 自習書シリーズ No.1
SQL Server 2014 自習書シリーズ No.1 SQL Server 2014 CTP1 の新機能の概要 Published: 2013 年 6 月 30 日 有限会社エスキューエル・クオリティ この文章に含まれる情報は、公表の日付の時点での Microsoft Corporation の考え方を表しています。市場の変化に応える必要 があるため、Microsoft は記載されている内容を約束しているわけではありません。この文書の内容は印刷後も正しいとは保障で きません。この文章は情報の提供のみを目的としています。 Microsoft、SQL Server、Visual Studio、Windows、Windows XP、Windows Server、Windows Vista は Microsoft Corporation の米国およびその他の国における登録商標です。 その他、記載されている会社名および製品名は、各社の商標または登録商標です。 © Copyright 2013 Microsoft Corporation. All rights reserved. 目次 STEP 1. SQL Server 2014 CTP1 で提供される新機能の概要 .................................................... 4 1.1 SQL Server 2014 CTP1 のダウンロード...................................................................... 5 1.2 SQL Server 2014 CTP1 で提供される主な新機能の概要 ................................................. 6 STEP 2. 2.1 STEP 3. インメモリ OLTP 機能の概要 ................................................................................ 10 インメモリ OLTP（Hekaton）機能の概要.................................................................... 11 更新可能な列ストア インデックス による性能向上 ..................................................... 15 3.1 更新可能な列ストア インデックスの概要 ..................................................................... 16 3.2 クラスター化列ストア インデックスの性能比較 ............................................................ 18 3.3 クラスター化列ストア インデックスに対するデータの更新 ..............................................30 3.4 COLUMNSTORE_ARCHIVE（列ストア アーカイブ） ..................................................... 33 STEP 4. SQL Server 2014 の 主な新機能 ........................................................................... 36 4.1 バッファ プール拡張（SSD をバッファ プールとして利用可能に）...................................37 4.2 Power View（パワー ビュー）機能の強化 ................................................................... 48 4.3 Cloud OS への対応（Windows Azure 連携） .............................................................. 53 4.4 SQL Server AlwaysOn のパワーアップ ...................................................................... 60 4.5 Query Processing の拡張（SELECT INTO のパラレル処理など） ....................................63 4.6 Power Query for Excel ........................................................................................... 66 4.7 インデックス再構築時のロックの優先度変更 ................................................................. 75 STEP 1. SQL Server 2014 CTP1 で提供される新機能の概要 この STEP では、SQL Server の次期バージョンである「SQL Server 2014」 の CTP1 で提供される新機能の概要を説明します。 この STEP では、次のことを学習します。 SQL Server 2014 CTP1 のダウンロード SQL Server 2014 CTP1 で提供される主な新機能の概要 1.1 SQL Server 2014 CTP1 のダウンロード SQL Server 2014 CTP1 のダウンロード SQL Server の次期バージョンである「SQL Server 2014」は、製品出荷前のプレビュー版であ る「CTP1」が、2013 年 6 月から一般公開されました。この CTP1 は、次の URL からダウン ロードすることができます。 http://technet.microsoft.com/ja-jp/evalcenter/dn205290.aspx CTP は、Community Technology Preview の略で、Beta 版（プレビュー版）と同じ位置付 けのものです。 この自習書では、CTP1 で提供された SQL Server 2014 の新機能を簡単に試せるように、ステ ップ バイ ステップ形式で画面ショット満載で紹介していますので、ぜひ、皆さんも実際に試しな がらこの自習書を読み進めていただければと思います。 1.2 SQL Server 2014 CTP1 で提供される主な新機能の概要 SQL Server 2014 CTP1 で提供される主な新機能の概要 SQL Server 2014 CTP1 には、たくさんの新機能が提供され、特に、性能向上を期待できる機 能が多くあります。その主なものは、次のとおりです。 インメモリ OLTP（開発コード名：Hekaton）機能による大幅な性能向上 インメモリ OLTP 機能は、OLTP（オンライン トランザクション処理）向けの新しいデ ータベース エンジンで、インメモリで動作する（メモリにテーブルを載せられる）こと で、大幅な性能向上を実現することができます。 列ストア インデックス（Column Store Index）が更新可能に SQL Server 2012 では、読み取り専用の列ストア インデックス（非クラスター化列ス トア インデックス）がサポートされていましたが、SQL Server 2014 からは、更新可 能な列ストア インデックス（クラスター化列ストア インデックス）がサポートされるよ うになりました。更新可能な列ストア インデックスを利用すると、次のような性能向上 を実現できます（Step 3 で詳しく説明） 39.5倍 26.5倍 テストに利用したハードウェア環境 ・Core i7 3770K 3.5GHz ・メモリ 32GB ・SSD PLEXTOR M3P 256GB 性能結果は相対値 ベンチマーク結果の公開は、使用許諾契約書 で禁じられているので、グラフ内の結果は、 クラスター化列ストア インデックスの値を 100 とした場合の相対値で表しています。 バッファ プール拡張により、SSD をバッファ プールとして利用可能に バッファ プール拡張を利用すると、次のような性能向上を実現できます（Step 4 で詳 しく説明） 46.7％ 向上 約2倍の性能向上 テストに利用したハードウェア環境 ・Core i7 3770K 3.5GHz ・メモリ 32GB ・HDD：WD30EZRX 3TB ・SSD ：PLEXTOR M3P 256GB 性能結果は相対値 ベンチマーク結果の公開は、使用許諾契約 書で禁じられているので、グラフ内の結果 は、相対値で表しています。 Power View（パワー ビュー）機能の強化 Analysis Services 多次元モデルから、Power View のレポート作成が可能に（SQL Server 2012 SP1 CU4 から利用可能） Analysis Services の 多次元モデル（キューブ）から Power View のレポートを作成 Analysis Services の 多次元モデル（キューブ） Cloud OS への対応（Windows Azure との連携） - Windows Azure 上へのバックアップが可能に Windows Azure 上の BLOB ストレージのコンテナーを指定 して、バックアップが可能 - AlwaysOn 可用性グループのセカンダリを Windows Azure 上へ作成することが できるウィザードの提供（CTP1 では未実装） - Windows Azure 上の仮想マシン（VM）へのデータベースの配置（Deploy） SQL Server AlwaysOn のパワーアップ - クォーラム損失時にも読み取り可能セカンダリへのアクセスが可能 - FCI（フェールオーバー クラスター インスタンス）で CSV（クラスター共有 ボリューム）がサポート - セカンダリを最大 8 台まで作成可能に（SQL Server 2012 では 4 台が上限） 最大 8台の セカンダリを作成可能 SELECT INTO でのパラレル処理が可能に 以下は、SELECT INTO を実行したときの実行プランです（パラレル Table Insert） 。 パラレル Table Insert SELECT INTO のパラレル処理によって、次のような性能向上を実現できます（Step 4 で詳しく説明） 。 平均で 18.3％ 向上 最大で 36.6％ 向上 する処理も有り Power Query for Excel によるさまざまなデータソースの検索・抽出が可能に Web ページ内の <Table> タグや、ファイル（Excel や CSV、XML、Text ファイル など、フォルダー内の複数ファイルをまとめて取り込むことも可能）、SQL Server や Windows Azure SQL データベース、Access、Oracle、DB2、MySQL などの各種デー タベース、Hadoop HDFS や Windows Azure HDInsight（Windows Azure の Hadoop 実装） 、SharePoint List、OData Feed、Facebook などからデータを取得する ことが可能。 Power Query for Excel で取得したデータは、次のように Power Map for Excel を 利用すれば、地図データの可視化も可能 Query Processing の拡張（CTP1 では未実装） パーティション スイッチやインデックス再構築時のロックの優先度変更 本自習書では、これらの新機能について、ステップ バイ ステップ形式で画面ショット満載で紹介 していますので、ぜひ、皆さんも実際に試しながらこの自習書を読み進めていただければと思いま す。 STEP 2. インメモリ OLTP 機能の概要 この STEP では、インメモリ OLTP（開発コード名：Hekaton）機能の概要を説 明します。 この STEP では、次のことを学習します。 インメモリ OLTP 機能の概要 インメモリ OLTP 機能の一番の利点 ブロッキングの最小化 2.1 インメモリ OLTP（Hekaton）機能の概要 インメモリ OLTP（Hekaton）機能の概要 SQL Server の次期バージョンである「SQL Server 2014」で提供される「インメモリ OLTP」 機能（開発コード名：Hekaton、ヘカトン）は、OLTP（On-Line Transaction Processing：オン ライン トランザクション処理）向けの新しいデータベース エンジンです。このエンジンは、イン メモリで動作するので（メモリにテーブルを載せられるので） 、従来のディスク ベースのデータベ ース エンジンよりも非常に高速に動作させることができます。 インメモリ OLTP 機能の主な特徴は、次のとおりです。 インメモリで動作するので、従来のデータベース エンジンよりも非常に高速 OLTP（On-Line Transaction Processing：オンライン トランザクション処理）向けの 新しいデータベース エンジン SQL Server のデータベース エンジンと完全に統合されている。 SQL Server のデータベース エンジンに完全に統合されているので、従来どおりの Transact-SQL ステートメントおよびツールを利用してインメモリの操作が可能。 シームレスに利用できるので、"移行"が容易に行える。新しいハードウェアを購入する必 要もない。 今後の CTP では、AlwaysOn 可用性グループによるデータの保護／可用性向上もサポ ートされる予定 メモリ内にのみテーブル データを配置することが可能（ディスク上にはデータを配置し ない）。メモリ内に配置したテーブルは、 「Memory-optimized Table」（メモリ最適化 テーブル）と呼ばれる 「 ネ イ テ ィ ブ コ ン パ イル ス ト アド プ ロ シ ー ジャ 」（ Natively Compiled Stored Procedure）を作成することで、さらに高速な処理が可能 SQL Server の再起動後も、データ復旧が可能な Durability（永続化）モードも用意さ れている（ディスク上に更新ログを記録して、再起動後にデータの復旧が可能） ブロッキングの最小化（ロックやラッチ待ちがほとんど発生しない同時実行性を提供） インメモリ OLTP 機能の一番の利点（Bwin 社では 16 倍もの性能向上を実現） インメモリ OLTP 機能の一番の利点は、 「インメモリ」で動作することで、非常に高速に処理でき る点です。既にこのエンジンを早期導入している「Bwin」社（サッカーのレアル・マドリードの 胸スポンサーとしてもお馴染みの、オンライン ゲームなどを提供する会社）では、従来 1 秒あた り 1 万 5 千件のトランザクション処理をしていたところを、インメモリ OLTP 機能を採用・移行 することで、1 秒あたり 25 万件トランザクション処理をできるようになりました（16 倍もの性 能向上） 。 （SQL Server 2014 Datasheet の図から引用） インメモリ OLTP 機能は、単純なデータの INSERT でも性能差を確認することができます。たと えば、100 万件のデータを INSERT するスクリプトを実行したときの実行時間を比較すると、 次のグラフのようになります。 約2倍 実行時間が 約 1/12 に短縮 12.2倍の性能向上！ 従来のデータベース エンジンを利用した通常のテーブルを、Memory-optimized Table（イン メモリ OLTP 機能でのテーブル）へ変更・移行することで、約 1/2 のスピード（2 倍の性能向 上）、さらにネイティブ コンパイル ストアド プロシージャへ変更することで、約 1/12 のスピ ード（12.2 倍の性能向上）を実現することができています。このように、大きな性能向上を期待 できるのがインメモリ OLTP 機能です。 SQL Server のデータベース エンジンと完全に統合されている（＝移行が容易） インメモリ OLTP 機能のもう 1 つの大きな利点は、従来型の SQL Server データベース エンジ ンと完全に統合されている点にあります。他社製のインメモリ エンジンの場合は、別製品として 提供されていることが多く、これでは別途インストールが必要であったり、実際の操作方法が異な ったり、新しい知識が必要になったりするなど、簡単に移行することができません（新しいハード ウェアを購入しなければならない場合もあります） 。 これに対して、SQL Server のインメモリ OLTP 機能は、SQL Server と完全に統合されている の で 、 簡 単 に 移 行 す る こ と が で き ま す 。 通 常 の SQL Server を 操 作 す る の と 同 じ よ う に Transact-SQL ス テ ー ト メ ン ト お よ び 同 じ ツ ー ル を 利 用 し て 、 イ ン メ モ リ OLTP 機 能 （Memory-optimized Table）を操作することができます。新しいハードウェアを購入する必要 もなく、通常の SQL Server をインストールするだけで インメモリ OLTP 機能を利用できるよ うになります（シームレスに利用できます） 。 Memory-optimized Table は、通常の CREATE TABLE ステートメントと同じように作成す ることができ、ネイティブ コンパイル ストアド プロシージャも通常の CREATE PROCEDURE ステートメントを利用して作成することができます。以下は、それぞれを作成している例です。 -- Memory-optimized Table の作成例 CREATE TABLE t1_InMem ( col1 int NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000) ,col2 nvarchar(100) ) WITH ( MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY ) -- Memory-optimized Table へのデータの INSERT 例 INSERT INTO t1_InMem VALUES (1, N'AAAAA') -- ネイティブ コンパイル ストアド プロシージャの作成例 CREATE PROC netiveTest @i int WITH NATIVE_COMPILATION, EXECUTE AS OWNER, SCHEMABINDING AS BEGIN ATOMIC WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'japanese') INSERT INTO dbo.t1_InMem VALUES (@i, N'AAAAA') END このように、通常の SQL Server を操作するのと同じように、Transact-SQL ステートメントを 利用して、Memory-optimized Table を作成することができ、通常のテーブルと同じように SELECT や INSERT、UPDATE、DELETE ステートメントを利用してデータ操作（検索／追加 ／更新／削除）も行うことができます。もちろん、インメモリで高速に動作させるために、いくつ かのステートメントに制限事項がありますが、基本的なステートメントはほとんど同じように利用 することができます。したがって、従来型のディスク ベースのテーブルを、インメモリ OLTP 機 能へ移行することも簡単に行うことができます。 ブロッキングの最小化（ロック待ちやラッチ待ちを最小化した同時実行性を提供） 従来のデータベース エンジンでは、データの更新時（INSERT／UPDATE／DELETE 時）に、ロ ック待ち（Lock Wait）やラッチ待ち（Latch Wait）が原因で、同時実行性が低下することがあり ましたが、今回提供されるインメモリ OLTP 機能では、このようなブロッキングはほとんど発生 しません。インメモリ OLTP 機能では、新たな「スナップショット分離」機能（従来のスナップ ショット分離のように tempdb を利用したものではなく、インメモリ OLTP 機能用の新しいスナ ップショット分離機構／ロックを利用しないマルチバージョンの楽観的同時実行制御）が提供され るからです。 これによって、インメモリ OLTP 機能では、ロック待ちやラッチ待ちがほとんど発生しない、同 時実行性を実現することができます。したがって、大量のユーザーからの多数の更新要求が発生す るシステム（オンライン ゲームやオンライン トレード、チケット予約など、トランザクションと しては小さく、多数の同時実行によるブロッキングが発生しやすいシステム）で、大きな性能向上 を期待できるのが、インメモリ OLTP 機能です。前述の Bwin 社では、ASP.NET の State Server にMemory-optimized Table を利用することで、大きな性能向上を実現しています。 インメモリ OLTP 機能の詳細については、本自習書シリーズの No.2「インメモリ OLTP 機能の 概要」編で説明していますので、こちらもぜひご覧いただければと思います。 Note： SQL Server のインメモリ技術（CEP、BI、ビッグデータもカバー） SQL Server では、既に多くのインメモリ技術が提供されており、今回のインメモリ OLTP 機能が初めて提供されたイ ンメモリ技術ではありません。2 つ前のバージョンである SQL Server 2008 R2 から提供された StreamInsight およ び PowerPivot に始まり、以下のインメモリ技術が提供されています。 ・StreamInsight（SQL Server 2008 R2 から） ・PowerPivot（SQL Server 2008 R2 から） ・xVelocity エンジン（SQL Server 2012 から） ・xVelocity 列ストア インデックス（SQL Server 2012 から） ・インメモリ OLTP 機能（SQL Server 2014 から） StreamInsight は、CEP（Complex Event Processing：複合イベント処理）を実現することができる機能で、SQL Server 2008 R2 から提供されています。CEP は、各種のセンサー データや株取引情報、Web サーバーのログ（クリ ック ストリーム）などのように、絶え間なく大量に流れてくるようなストリーム データ（イベント）を処理することが できるアプリケーションのことを指し、StreamInsight は、インメモリで動作することで高速なイベント処理が可能で す。 PowerPivot は、インメモリの BI 機能で、こちらも SQL Server 2008 R2 から提供されました。SQL Server 2008 R2 では、クライアント版の PowerPivot for Excel、サーバー版の PowerPivot for SharePoint が提供され、数億件レ ベルのデータでも、非常に高速な集計処理ができるインメモリの BI エンジン（インメモリで動作するカラムベースの エンジン）です。 PowerPivot のエンジンは、SQL Server 2012 からは、xVelocity エンジンへと名称変更・改良されて、Analysis Services（分析サーバー）でも利用できるようになりました（テーブル モデル：Tabular Model と呼ばれる） 。これに より、ビッグデータ／より大量のデータにも対応可能なサーバー版のインメモリ BI 機能が利用できるようになりまし た。 xVelocity 列ストア インデックス（Columnstore Index）は、SQL Server 2012 のデータベース エンジンの機能強 化として提供されました。列ストア インデックスは、xVelocity エンジン（インメモリのカラムベース エンジン）を RDB へ応用したもので、このエンジンでは、列単位でインデックスを格納し、それらは高度に圧縮されています。この インデックスによって、大量のデータに対する集計処理（GROUP BY 演算など）の性能を大きく向上させることができ ます。したがって、夜間バッチ処理時（夜間バッチでの日次集計や月次集計処理など）や、DWH（データ ウェアハウ ス）環境での集計処理時に大変役立ちます。列ストア インデックスは、SQL Server 2012 では読み取り専用でしたが、 SQL Server 2014 からは更新することもできるようになりました（次の Step で説明） 。 このように、SQL Server のインメモリ技術は、CEP から BI、ビッグデータ、OLTP まで、幅広くカバーしています。 STEP 3. 更新可能な列ストア インデックス による性能向上 この STEP では、SQL Server 2014 CTP1 で提供される「更新可能な列ストア イ ンデックス」（クラスター化列ストア インデックス）機能の概要を説明します。 この STEP では、次のことを学習します。 更新可能な列ストア インデックスの概要 クラスター化列ストア インデックスの性能比較 データの更新とインデックスの再構築 COLUMNSTORE_ARCHIVE モード 3.1 更新可能な列ストア インデックスの概要 更新可能な列ストア インデックスの概要 列ストア インデックス（Column-store Index）は、SQL Server 2012 からサポートされた機能 ですが、SQL Server 2012 では読み取り専用でした。SQL Server 2014 からは、更新可能な列 ストア インデックスがサポートされるようになりました（SQL Server 2012 でも、2013 年 3 月 に提供された SQL Server 2012 Parallel Data Warehouse エディション＝通称 PDW version 2 を利用している場合は、更新可能な列ストア インデックスを利用することができます）。 この更新可能な列ストア インデックスは、「クラスター化列ストア インデックス」（CCI: Clustered Columnstore Index）と呼ばれ、従来ながらの読み取り専用の列ストア インデック スは、「非クラスター化列ストア インデックス」と呼ばれます。クラスター化列ストア インデッ クスは、次のように CREATE CLUSTERED COLUMNSTORE INDEX ステートメントを利用し て、作成することができます。 CREATE CLUSTERED COLUMNSTORE INDEX インデックス名 ON テーブル名 Management Studio から作成する場合は、次のようにオブジェクト エクスプローラーで ［Indexes］フォルダーを右クリックして、 ［New Index］メニューから作成できます。 1 2 各種オプション の設定 3 列ストア インデックスによる性能向上 列ストア インデックスは、「xVelocity 列ストア インデックス」とも呼ばれ、PowerPivot およ び Analysis Services Tabular Mode（テーブル モード）で採用されているインメモリの BI エ ンジンである「xVelocity エンジン」を RDB へ応用したものです。 このエンジンでは、列単位でインデックスを格納し、それらは高度に圧縮されています。 テーブル a b xVelocity 列ストア インデックス c 従来ながらの Row ストア a b カラム（Column）ストア c a b c 行単位で格納 高度に圧縮され ている … 列単位で格納 このインデックスによって、大量のデータに対する集計処理（GROUP BY 演算など）の性能を大 きく向上させることができます。したがって、夜間バッチ処理時（夜間バッチでの日次集計や月次 集計処理など）や、DWH（データ ウェアハウス）環境での集計処理時に大変役立ちます。 本自習書内では、1,000 万件のデータに対する GROUP BY 演算を実行するスクリプトを説明し ていますが、このスクリプトを実行したときの実行時間を比較すると、次のグラフのようになりま す。 39.5倍 26.5倍 テストに利用したハードウェア環境 ・Core i7 3770K 3.5GHz ・メモリ 32GB ・SSD PLEXTOR M3P 256GB 性能結果は相対値 ベンチマーク結果の公開は、使用許諾契約書 で禁じられているので、グラフ内の結果は、 クラスター化列ストア インデックスの値を 100 とした場合の相対値で表しています。 グラフの FullScan は、インデックスが使用されないフル テーブル スキャンが実行されたとき の速度、IndexScan は、列ストア インデックスではない通常の非クラスター化インデックスを 作成／利用したとき、ColumnStore NonClustered が非クラスター化列ストア インデックス を作成／利用したとき、ColumnStore Clustered がクラスター化列ストア インデックス（CCI） を作成／利用したときの実行速度です（相対値） 。列ストア インデックスを利用することで、フル スキャンに比べて 39.5 倍、インデックス スキャンに比べて 26.5 倍もの性能向上を実現するこ とができます。このように、集計処理に強いのが列ストア インデックスです。 3.2 クラスター化列ストア インデックスの性能比較 クラスター化列ストア インデックスの性能比較 それでは、クラスター化列ストア インデックスを試してみましょう。クラスター化列ストア イン デックスを作成しない場合や、非クラスター化列ストア インデックス（読み取り専用）を作成し た場合との性能比較などを行ってみます。なお、列ストア インデックスは、複数コアに最適化さ れたアーキテクチャなので、検証する際には、複数コアを搭載した物理マシン、または複数コアを 割り当てた仮想マシンで試すようにしてください（1 コアでは性能差を確認することが難しくなり ます）。 1. まずは、データベースを作成します。データベースの名前は「CSItestDB」とし、次のよう に CREATE DATABASE ステートメントを記述して作成します。 CREATE DATABASE CSItestDB ON PRIMARY ( NAME = 'CSItestDB' , FILENAME = 'C:\CSItestDB\CSItestDB_data.mdf' , SIZE = 5120MB ) LOG ON ( NAME = 'CSItestDB_log' , FILENAME = 'C:\CSItestDB\CSItestDB_log.ldf' , SIZE = 1024MB ) FILENAME で指定しているファイル パス（データ ファイルとトランザクション ログ ファ イルの作成先となるフォルダー）には、「C:\CSItestDB」フォルダーを指定していますが、 皆さんの環境に合わせて適宜変更してください。 テーブル「t1」の作成 2. 次に、CREATE TABLE ステートメントを利用して、通常どおりに「t1」という名前のテー ブルを作成します。 USE CSItestDB CREATE TABLE t1 ( a int IDENTITY(1, 1) PRIMARY KEY , b int , c char(200) DEFAULT 'dummy1' , d char(200) DEFAULT 'dummy2' ) 1,000 万件のデータの INSERT 3. 次に、WHILE ループを利用して、1,000 万件のデータを INSERT します。 SET NOCOUNT ON DECLARE @i int = 1, @b int = 1 WHILE @i <= 10000000 BEGIN IF @i % 10000 = 0 SET @b = @i INSERT INTO t1(b) VALUES(@b) SET @i += 1 END SET NOCOUNT OFF 1,000 万件のデータを追加しているので、環境にもよりますが、実行には 20 分～2 時間くら いの時間がかかります（ディスクが低速な場合には、さらに実行時間が長くなります）。 4. データの追加が完了したら、次のように SELECT ステートメントを実行して、追加されたデ ータを確認しておきましょう。 -- 上位 10万件を確認 SELECT TOP 100000 * FROM t1 b 列は 10000 ごとに同じ値 a 列には 1 からの連番 t1 テーブルの a 列には、IDENTITY による連番、b 列には、10,000 件ごとに、10,000、 20,000、30,000 という値が入るようにしています。 5. 次に、COUNT 関数を利用して、データ件数が 1,000 万件であることを確認しておきます。 SELECT COUNT(*) FROM t1 通常テーブルでの速度チェック 次に、通常テーブルでの実行速度をチェックします（この後に作成する非クラスター化列ストア イ ンデックスや、クラスター化列ストア インデックスとの比較を行うために、通常テーブルでの速 度をチェックします） 。 1. まずは、実行速度をチェックするために、SET STATISTICS TIME を ON へ設定して、 GROUP BY 演算を利用した SELECT ステートメントを実行します。 SET STATISTICS TIME ON SELECT b, MAX(a) FROM t1 GROUP BY b 実行が完了したら、［Message］タブを開きます。 1 2 実行時間を 確認する elapsed time（経過時間）のところで実行時間を確認することができるので、これをメモし ておいてください。 2. 次に、SELECT ステートメントを選択して、ツールバーの［推定実行プラン］ボタンをクリ ックし、実行プランを確認します。 2 1 SELECT ステート メントを選択 3 Clustered Index Scan Clustered Index Scan（全データのスキャン）が選択されていることを確認できます。t1 テ ーブルの a 列には、PRIMARY KEY 制約を設定しているので、クラスター化インデックス が自動作成されていて、このインデックス（実データ）が全スキャンされています。 3. 次に、テーブルのプロパティを開いて、テーブル サイズを確認しておきましょう。 2 3 1 オブジェクト エクスプローラーで、t1 テーブルを右クリックして、 ［Properties］をクリッ クし、［Storage］ページを開くと、［Data space］でテーブル サイズを確認することがで きます（約 4GB のサイズであることを確認できます） 。 非クラスター化インデックスの作成（通常のインデックスの場合の性能チェック） 次に、非クラスター化インデックス（列ストア インデックスではなく、通常のインデックス）を 作成した場合の性能を調べてみましょう。 1. 今回作成する非クラスター化インデックスは、先ほどの GROUP BY 演算を速く実行するた めに、「b, a」列の順番に作成します。 CREATE NONCLUSTERED INDEX idx1 ON t1(b, a) 2. 作成が完了したら、先ほどと同じ SELECT ステートメントを実行して、実行時間を調べまし ょう。 SELECT b, MAX(a) FROM t1 GROUP BY b 1 実行時間を 確認する elapsed time（経過時間）が小さくなっていることを確認できると思います（弊社環境では、 約 30％ 速く実行できることを確認しています） 。 3. 次に、SELECT ステートメントを選択して、ツールバーの［推定実行プラン］ボタンをクリ ックし、実行プランも確認しておきましょう。 1 Index Scan Index Scan と表示されていることを確認できると思います。 4. 次に、テーブル サイズとインデックス サイズを確認しておきましょう。 1 2 Data space（テーブル サイズ）が約 4GB、Index space（インデックスのサイズ）が約 151MB であることを確認できます。 非クラスター化列ストア インデックスの作成、性能チェック 次に、非クラスター化列ストア インデックス（クラスター化列ストア インデックスではなく、SQL Server 2012 からサポートされている列ストア インデックス）を作成した場合の性能を調べてみ ましょう。 1. まずは、通常の非クラスター化インデックスを削除します。 DROP INDEX idx1 ON t1 2. 次に、非クラスター化列ストア インデックスを作成します。 CREATE NONCLUSTERED COLUMNSTORE INDEX idx1 ON t1(a, b, c, d) 3. 作成が完了したら、同じ SELECT ステートメントを実行して、実行時間を調べましょう。 SELECT b, MAX(a) FROM t1 GROUP BY b 1 実行時間を 確認する elapsed time（経過時間）が桁違いに小さくなっていることを確認できると思います（弊社 環境では、約 27.6 倍 速く実行できることを確認しています） 。 4. 次に、SELECT ステートメントを選択して、ツールバーの［推定実行プラン］ボタンをクリ ックし、実行プランも確認しておきましょう。 1 NonClustered（非クラスター化）の Columnstore Index Scan Columnstore Index Scan（NonClustered）と表示されて、非クラスター化列ストア イ ンデックスのスキャンで実行されていることを確認できると思います。 5. 次に、インデックス サイズも確認しておきましょう。 1 Index space（インデックスのサイズ）が約 52MB であることを確認できます（非クラスタ ー化インデックスの場合は 約 151MB でした） 。 6. 次に、UPDATE ステートメントを実行して、データが更新できないことを確認しておきまし ょう（非クラスター化列ストア インデックスは読み取り専用であることを確認します） 。 UPDATE t1 SET c = 999 WHERE a = 1 このように、非クラスター化列ストア インデックスでは、データを更新することができませ ん。 クラスター化列ストア インデックスの作成（更新可能な列ストア インデックス） 次に、SQL Server 2014 からの新機能であるクラスター化列ストア インデックス（更新可能な 列ストア インデックス）を作成しましょう。 1. まずは、非クラスター化列ストア インデックスを削除します。 DROP INDEX idx1 ON t1 2. 次に、CREATE CLUSTERED COLUMNSTORE INDEX ステートメントを利用して、クラ スター化列ストア インデックスを作成します。クラスター化列ストア インデックスには、す べての列を含む必要があるので、ON 句ではテーブル名を指定するだけになります。 CREATE CLUSTERED COLUMNSTORE INDEX cidx1 ON t1 しかし、結果はエラーになります。クラスター化列ストア インデックスを作成するには、テ ーブル内に制約やインデックスがないことが条件になる ためです。t1 テーブルには、 PRIMARY KEY 制約を設定しているので、自動的にクラスター化インデックスが作成されて いて、クラスター化列ストア インデックスを作成することができません。 3. PRIMARY KEY 制 約およ びクラスター 化インデッ クスを 削除 する ために、 次のように sp_help システム ストアド プロシージャを実行して、インデックス名を確認します。 EXEC sp_help 't1' 1 index_name に表示される「PK__t1__～」がインデックス名および PRIMARY KEY 制約 の名前になるので、これをコピーします。 4. コピーした名前を以下の ALTER TABLE ステートメントに貼り付けて、PRIMARY KEY 制 約を削除します。 ALTER TABLE t1 DROP CONSTRAINT PK__t1__3BD0198EA17AC327 sp_help で調べたイン デックス名に置換する 5. PRIMARY KEY 制 約 の 削 除 が 完 了 し た ら 、 も う 一 度 、 CREATE CLUSTERED COLUMNSTORE INDEX ステートメントを実行して、クラスター化列ストア インデックス を作成します。 CREATE CLUSTERED COLUMNSTORE INDEX cidx1 ON t1 今度は、作成が完了することを確認できます。 6. 次に、同じ SELECT ステートメントを実行して、実行時間を調べてみましょう。 SELECT b, MAX(a) FROM t1 GROUP BY b 1 実行時間を 確認する elapsed time（経過時間）が桁違いに小さくなっていることを確認できると思います（弊社 環境では、非クラスター化列ストア インデックスのときとほぼ同じ速度で実行できることを 確認しています。非クラスター化インデックスのときと比べると、約 26.5 倍 速く実行） 。 7. 次に、SELECT ステートメントを選択して、ツールバーの［推定実行プラン］ボタンをクリ ックし、実行プランも確認しておきましょう。 1 Clustered（クラスター化）の Columnstore Index Scan Columnstore Index Scan（Clustered）と表示されて、クラスター化列ストア インデッ クスのスキャンで実行されていることを確認できると思います。 8. 次に、テーブル サイズとインデックス サイズも確認しておきましょう。 1 2 Data space（テーブル サイズ）が約 37MB、Index space（インデックス サイズ）が 0MB になっていることを確認できます（非クラスター化列ストア インデックスでは、Data space が約 4GB、Index space が約 52MB でした）。 ここまでの結果をまとめると、次のようになります。 39.5倍 26.5倍 テストに利用したハードウェア環境 ・Core i7 3770K 3.5GHz ・メモリ 32GB ・SSD Plextor M3P 256GB 性能結果は相対値 ベンチマーク結果の公開は、使用許諾契約書 で禁じられているので、グラフ内の結果は、 クラスター化列ストア インデックスの値を 100 とした場合の相対値で表しています。 FullScan は Clustered Index Scan が実行されたとき、IndexScan は非クラスター化イ ンデックスを作成／利用したとき、ColumnStore NonClustered は非クラスター化列スト ア インデックスを作成／利用したとき、ColumnStore Clustered はクラスター化列スト ア インデックスを作成／利用したときの実行速度です（相対値）。 非クラスター化列ストア インデックスとクラスター化列ストア インデックスでは、速度差は ほとんどないことを確認できると思います。また、クラスター化列ストア インデックスを利 用することで、フル スキャンに比べて 39.5 倍、インデックス スキャンに比べて 26.5 倍 もの性能向上を確認できます。このように、集計処理に強いのが列ストア インデックスです。 テーブルおよびインデックス サイズをまとめると、次のようになります。 クラスター化列ストア インデッ クスは、ディスク領域を削減で きるメリットも有る 通常テーブルでは、約 4GB 分のテーブル領域を利用しているのに対して、クラスター化列 ストア インデックスでは、テーブル データそのものが列ストア インデックスになるので、 わずか 37MB のサイズに小さくすることができています。ただし、今回は、c および d 列 には、まったく同じデータ（dummy1）を格納しているので、圧縮率が極端に高くなってい ることを差し引く必要があることにも注意してください。 弊社のお客様のデータ（100 億件の DWH）で、クラスター化列ストア インデックスを作成 した場合は、次のような圧縮効果を確認することができました。 約 1/6 に圧縮 通常テーブルが 531GB であるところを、90GB へと、約 1/6 のサイズにすることができ ました。このように、クラスター化列ストア インデックスは、ディスク領域を削減できるメ リットもあります。また、ディスクから読み取るサイズが小さくなる分、性能向上にも貢献し ます（圧縮および解凍に伴う CPU パワーとのトレードオフも存在します） 。 9. 次に、SET STATISTICS TIME コマンドを OFF へ設定して、実行時間の記録を停止して おきます。 SET STATISTICS TIME OFF 3.3 クラスター化列ストア インデックスに対するデータの更新 クラスター化列ストア インデックスに対するデータの更新 次に、クラスター化列ストア インデックスに対して、データの更新を行ってみましょう。 1. まずは、UPDATE ステートメントを実行して、データが更新できることを確認してみます。 UPDATE t1 SET c = 999 WHERE a = 1 このように、クラスター化列ストア インデックスでは、データを更新することができます。 2. 次に、SELECT ステートメントを実行して、正しくデータが更新されたことを確認しておき ましょう。 SELECT * FROM t1 WHERE a = 1 10 万件のデータの INSERT 1. 次に、10 万件のデータを INSERT してみましょう（このスクリプトを実行する前に、SET STATISTICS TIME を OFF に設定しておいてください。ON のままだと、10 万件分の結 果メッセージが出力されることになり、実行時間が長くなってしまうためです）。 SET NOCOUNT ON DECLARE @i int = 1 WHILE @i <= 100000 BEGIN INSERT INTO t1(b) VALUES(8888) SET @i += 1 END SET NOCOUNT OFF 何の問題もなく、データの INSERT が完了したことを確認できると思います。 2. 次に、SET STATISTICS TIME ON を実行して、前の Step と同じ SELECT ステートメ ント（GROUP BY 演算）の実行時間を計測してみます。 SET STATISTICS TIME ON SELECT b, MAX(a) FROM t1 GROUP BY b 1 実行時間を 確認する 10 万件追加しただけにも関わらず、実行時間が長くなっていること（弊社環境では 3 倍以上） を確認できると思います。 これは、クラスター化列ストア インデックスでは、更新されたデータは、「Delta ストア」 と呼ばれる、更新データの格納用の領域に格納されているためです。 カラム（Column）ストア a b c Delta ストア（Row ストア） 更新されたデータを 格納する領域 a b 列単位で格納 インデックスの再構築に よってカラム ストアへ移動 c … 行単位で格納 クラスター化列ストア インデックスでは、カラム（列）単位でデータを格納しているカラム ストア領域と、更新データのための Delta ストア（差分領域）があり、Delta ストアにデー タがある場合は、読み取り時のオーバーヘッドが発生します。これを回避するには、インデッ クスを再構築するようにします。再構築を行うことで、Delta ストア内の差分データをカラム ストアへ移動させることができるからです。 クラスター化列ストア インデックスの再構築（REBUILD） それでは、インデックスを再構築してみましょう。 1. クラスター化列ストア インデックスの再構築は、通常のインデックスを再構築するのと同様、 ALTER INDEX ステートメントを利用して、次のように実行します。 ALTER INDEX cidx1 ON t1 REBUILD 2. 再構築が完了したら、もう一度 SELECT ステートメントを実行してみましょう。 SELECT b, MAX(a) FROM t1 GROUP BY b 1 実行時間を 確認する 今度は、1,000 万件のときとほとんど同じスピードで検索できたことを確認できると思います。 このように、クラスター化列ストア インデックスでは、データの更新を行うことができます が、より良いパフォーマンスを保つには、定期的にインデックスを再構築することが重要にな ります。 3.4 COLUMNSTORE_ARCHIVE（列ストア アーカイブ） COLUMNSTORE_ARCHIVE（列ストア アーカイブ） クラスター化列ストア インデックスでは、さらに圧縮率を高めた、 「COLUMNSTORE_ARCHIVE」 （列ストア アーカイブ）というモードもあります。 カラム（Column）ストア a b Columnstore Archive c a b c さらに圧縮 さらに圧縮をすることで、ディスク使用領域をより小さくできることがメリットです（圧縮率を高 くする分、さらに CPU パワーを余分に使うことになるので、それとのトレードオフになります） 。 データ パーティションを利用して、複数のパーティションを作成している場合は、特定のパーテ ィションのみを COLUMNSTORE_ARCHIVE へ設定することもできるので、アクセスされる頻 度の低いパーティションのみを COLUMNSTORE_ARCHIVE へ設定するという使い方もできま す。 Let's Try それでは、これも試してみましょう。 1. COLUMNSTORE_ARCHIVE は 、 次 の よ う に ALTER INDEX ス テ ー ト メ ン ト で の REBUILD 時に DATA_COMPRESSION で指定することができます。 ALTER INDEX cidx1 ON t1 REBUILD WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE) 2. 作成が完了したら、同じ SELECT ステートメントを実行して、実行時間を調べてみましょう。 SELECT b, MAX(a) FROM t1 GROUP BY b 1 実行時間を 確認する 今回は、データ量が 1,010 万件と少ないので、大きな実行時間の差がでないことを確認でき ると思います（CPU のクロック数が低い場合には、差が大きくなります） 。 3. 次に、テーブル サイズも確認しておきましょう。 1 2 Data space（テーブル サイズ）が約 15.4MB であることを確認できます（クラスター化列 ストア インデックスの場合は 約 37MB でした）。 弊社のお客様のデータ（前述の 100 億件の DWH）で、COLUMNSTORE_ARCHIVE を設 定した場合は、次のような圧縮効果を確認することができました。 約 1/8 に圧縮 約 1/6 に圧縮 27.7％ 圧縮 通常テーブルが 531GB であるところを、65GB へと、約 1/8 のサイズにすることができ ました。クラスター化列ストア インデックスの 90GB と比べても、27.7％ も圧縮するこ とができています。 このように、さらに圧縮率を高めることができるのが、COLUMNSTORE_ARCHIVE のメリ ットです（圧縮率を高くする分、CPU パワーを余計に利用することになるので、それとのト レードオフになります） 。 4. 最後に、SET STATISTICS TIME コマンドを OFF へ設定して、実行時間の記録を停止し ておきます。 SET STATISTICS TIME OFF もとに戻す（COLUMNSTORE） 1. COLUMNSTORE_ARCHIVE へ設定したテーブル（やパーティション）をもとに戻す（通常 の 列 ス ト ア に 戻 す ） に は 、 次 の よ う に ALTER INDEX ス テ ー ト メ ン ト を 実 行 し ます （DATA_COMPRESSION で COLUMNSTORE を指定します） 。 ALTER INDEX cidx1 ON t1 REBUILD WITH (DATA_COMPRESSION = COLUMNSTORE) クラスター化列ストア インデックスのまとめ 以上のように、クラスター化列ストア インデックスは、大きな性能向上およびディスク領域の削 減を期待できる、大変便利な機能です。圧縮／解凍に伴う CPU パワーとのトレードオフや、更新 時のデータを格納するための Delta ストアを利用することによるオーバーヘッドなどがあります が、インデックスを定期的に再構築するなど、うまく活用することで、大きな性能向上を実現する ことができます。 STEP 4. SQL Server 2014 CTP1 の主な新機能 この STEP では、 「バッファ プール拡張」や「Power View 機能の強化」、 「Cloud OS へ の対 応」、「 AlwaysOn の 強 化」、「SELECT INTO の パラ レ ル 処理」、 「Power Query for Excel」など、SQL Server 2014 CTP1 で提供される主な 新機能の概要を説明します。 この STEP では、次のことを学習します。 バッファ プール拡張（SSD をバッファ プールとして利用可能に） Power View（パワー ビュー）機能の強化 Cloud OS への対応（Windows Azure との連携） SQL Server AlwaysOn のパワーアップ Query Processing の拡張（SELECT INTO のパラレル処理など） Power Query for Excel、Power Map for Excel インデックスの再構築時の優先度の変更 4.1 バッファ プール拡張（SSD をバッファ プールとして利用可能に） バッファ プール拡張（SSD をバッファ プールとして利用可能に） SQL Server 2014 では、「バッファ プール拡張」 （Buffer Pool Extension）機能が提供されて、 より高速なストレージである SSD（Solid State Drive）やフラッシュ メモリ型の半導体ストレー ジ（Fusion-io ioDrive2 など）をバッファ プールの一部として利用できるようになりました。こ れは、搭載している物理メモリが足りない場合（バッファ プールが足りない場合）かつ HDD（ハ ード ディスク）などの低速なストレージを利用している場合に役立ちます。 もし、物理メモリが十分に足りている場合は、次のように 2 回目以降のアクセスでは、メモリ（バ ッファ プール）からデータを取得できるので、HDD（低速なストレージ）からデータを取り出す 必要はありません。 これに対して、物理メモリ（バッファ プール）が足りていない場合には、次のように HDD から 毎回データを取り出さなければなりません。 もし、物理メモリが 32GB の場合に、テーブル サイズが 100GB だとすると、テーブルに対す る全スキャンが発生したときにメモリには載りきりません。HDD の読み取り速度（実測）が 100MB/sec だったとすると、100GB を取り出すには、単純計算だと 1,000 秒（16 分 40 秒） もの時間が（毎回）かかることになってしまいます。 このように、物理メモリが足りない場合（バッファ プールが足りない場合）かつ HDD環境（低速 なストレージ）を利用している場合に役立つのが、 「バッファ プール拡張」機能です。バッファ プ ール拡張を利用すれば、次のように、より高速なストレージをバッファ プールの一部として利用 できるようになります。 本自習書内では、500 万件のデータをテーブル スキャンする場合の性能比較を行っていますが、 弊社環境では、以下のような性能差を確認することができています。 もちろん、この機能は、利用している HDD や、HDD の RAID 構成、SSD やフラッシュ型ドラ イブの種類など、ストレージの性能に非常に大きな影響を受けるので、sqlio ツールなどを利用し て、各ストレージの I/O 性能をチェックしておくことも重要です。 バッファ プール拡張は、次のように ALTER SERVER CONFIGURATION ステートメントを利 用して、簡単に設定することができます。 ALTER SERVER CONFIGURATION SET BUFFER POOL EXTENSION ON (FILENAME = 'G:\SSD\SSD.BPE', SIZE = 30GB) FILENAME で指定するドライブは、SSD やフラッシュ型半導体ストレージなどの高速なストレ ージを指定するようにして、SIZE で拡張したいサイズを指定します。 バッファ プール拡張を試してみよう それでは、バッファ プール拡張を試してみましょう。以降の手順では、HDD（D:ドライブ）と SSD （C:ドライブ）を例に説明しますが、SSD が用意できない環境の場合は、USB HDD や、USB メ モリなどを利用して（内蔵 HDD よりも低速なストレージ）を利用して、バッファ プール拡張の 効果を試すことができます。 1. まずは、データベースを「BPEtestDB」という名前で作成しますが、作成先となるファイル パ ス（D:\BPEtestDB フォルダー）は、HDD など低速なストレージを選択するようにしてく ださい。 CREATE DATABASE BPEtestDB ON PRIMARY ( NAME = BPEtestDB_data, FILENAME = 'D:\BPEtestDB\BPEtestDB_data.mdf', SIZE = 3072MB ) LOG ON ( NAME = BPEtestDB_log, FILENAME = 'D:\BPEtestDB\BPEtestDB_log.ldf', SIZE = 3072MB ) 2. 次に、クラスター化列ストア インデックスで利用した CSItestDB データベース内の t1 テ ーブルから、500 万件分のデータをコピーします（SELECT INTO でコピーします）。 USE BPEtestDB SELECT TOP 5000000 * INTO t1 FROM CSItestDB..t1 3. コピーが完了したら、テーブル サイズを確認します。 2 3 1 テーブルのプロパティの［Storage］ページで、［Data space］が約 2GB であることを確 認できます。 4. 次に、COUNT(*) を実行して、500 万件のデータであることを確認します。 SELECT COUNT(*) FROM t1 5. 続いて、COUNT(*) のステートメントを選択して、実行プランを確認します。 1 Table Scan Table Scan が選択されていることを確認できます。テーブル サイズは、約 2GB でしたの で、Table Scan が発生する場合は、約 2GB 分のデータの読み取りが発生することになりま す。 6. 次に、dm_os_buffer_descriptors 動的管理ビューを利用して、バッファ プールの中身を 参照します（バッファ プール内のページごとに結果が出力されます） 。 SELECT * FROM sys.dm_os_buffer_descriptors 一番右側の is_in_bpool_extentions 列には NULL が設定されていますが、現在は、バ ッファ プール拡張を設定していないので、この場合はすべてのページが NULL に設定され ます（バッファ プール拡張を設定後は、拡張領域を利用しているページに 1 がセットされる ようになります） 。 7. 次に、database_id および is_in_bpool_extension ごとに GROUP BY 演算を行って、 データベースごとのバッファ プールの使用量を確認します。 SELECT DB_NAME(database_id), is_in_bpool_extension ,COUNT(*) As 使用ページ数 ,COUNT(*) * 8.0 / 1024 As 使用サイズ_MB FROM sys.dm_os_buffer_descriptors GROUP BY database_id, is_in_bpool_extension ORDER BY 使用ページ数 DESC 「BPEtestDB」データベースが約 2GB 使用していて、t1 テーブル（500 万件分）が丸ご とバッファ プール内に存在していることを確認できます（なお、搭載メモリが小さい場合に は、2GB 分のテーブルが載りきらないので、使用サイズが 2GB よりも小さくなります） 。 8. 次に、SQL Server の Max Server Memory を 1GB（1024MB）に制限して、t1 テーブ ル（2GB）が載りきらない状況をシミュレートします。 EXEC sp_configure 'show advanced options', 1 RECONFIGURE EXEC sp_configure 'max server memory', 1024 RECONFIGURE 9. 設定後、DBCC DROPCLEANBUFFERS コマンドを実行して、バッファ プールをクリアし ます。 DBCC DROPCLEANBUFFERS 10. 次に、SET STATISTICS コマンドを実行して、実行時間と I/O 数（読み取りページ数）を 記録するようにします。 SET STATISTICS TIME ON SET STATISTICS IO ON 11. 設定後、先ほどと同じ COUNT(*) の SELECT ステートメントを実行して、実行時間や読 み取りページ数を調べます。 SELECT COUNT(*) FROM t1 2 3 論理読み取り数を 確認する 1 先行読み取り数を 確認する 実行時間を 確認する 実行が完了したら、実行時間をメモしておいてください。logical reads（論理読み取り数） が 263,161 ページ（約 2GB）で、Table Scan によって 2GB 分の読み取りが発生してい ることを確認できます。また、read-ahead reads（先行読み取り数）も 約 2GB になって いて、HDD からデータを読み取っていることを確認できます。 HDD の読み取り速度が 100MB/sec だとすると、2GB のデータを読み取るには約 20 秒 の実行時間がかかることになります。 メモリが足りていない場合は、何度実行しても、HDD からの読み取りが発生するので、もう 一度同じステートメントを実行して、同じくらいの実行時間がかかることも確認しておいてく ださい。HDD からの読み取りが発生していることは、read-ahead reads がカウントされ ることでも確認することができます。 12. 次に、dm_os_buffer_descriptors 動的管理ビューを参照して、データベースごとのメモ リ使用量を確認します。 SELECT DB_NAME (b.database_id), is_in_bpool_extension ,COUNT(*) As 使用ページ数 ,COUNT(*) * 8.0 / 1024 As 使用サイズ_MB FROM sys.dm_os_buffer_descriptors b GROUP BY b.database_id, is_in_bpool_extension ORDER BY 使用ページ数 DESC 「BPEtestDB」データベースは、約 800MB しか使用しておらず、t1 テーブルを丸ごとバ ッファ プール内には載せられなかったことを確認できます。 バッファ プール拡張の設定 次に、バッファ プール拡張を設定します。 1. バッファ プール拡張を設定するには、次のように ALTER SERVER CONFIGURATION ス テートメントを実行します。バッファ プール拡張の作成先となるファイル パス（C:\SSD フ ォルダー）は、SSD などの高速なストレージを選択するようにしてください。 ALTER SERVER CONFIGURATION SET BUFFER POOL EXTENSION ON (FILENAME = 'C:\SSD\SSD.BPE', SIZE = 10GB) 2. 設定後、SQL Server サービスを再起動します。 2 1 3. 再起動が完了したら、SET STATISTICS コマンドを再度実行します。 SET STATISTICS TIME ON SET STATISTICS IO ON 4. 設定後、先ほどと同じ COUNT(*) の SELECT ステートメントを実行して、実行時間や読 み取りページ数を調べます。 SELECT COUNT(*) FROM t1 2 3 論理読み取り数を 確認する 1 先行読み取り数を 確認する 実行時間を 確認する 1 回目の実行は、SSD（拡張領域）への書き込みが発生するため、バッファ プール拡張を設 定する前よりも実行速度が落ちます。 2 回、3 回、4 回と何度も実行していくと、read-ahead reads（先行読み取り）のページ数 が少なくなっていくことを確認できると思います。次のように、先行読み取り数が 0 になる まで実行します。 2 1 先行読み取り数が 0 になる 実行時間を 確認する 先行読み取り数が 0 になって、logical reads（論理読み取り数）のみがカウントされる場 合は、すべてのデータをバッファ プールから取得していることになるので、バッファ プール 拡張が最大限に活かされている状態になります。この状態では、弊社環境では、次のように 46.7％（約 2 倍）の性能向上を確認できています（実行時間はバッファ プール拡張なしの 場合を 100 とした場合の相対値） 。 46.7％ 向上 約2倍の性能向上 テストに利用したハードウェア環境 ・Core i7 3770K 3.5GHz ・メモリ 32GB ・HDD：WD30EZRX 3TB ・SSD ：PLEXTOR M3P 256GB 性能結果は相対値 ベンチマーク結果の公開は、使用許諾契約 書で禁じられているので、グラフ内の結果 は、相対値で表しています。 5. 次に、dm_os_buffer_descriptors 動的管理ビューを利用して、バッファ プールの中身を 参照します。 SELECT * FROM sys.dm_os_buffer_descriptors is_in_bpool_extentions 列には 1 や 0 が設定されていることを確認できると思います。 バッファ プール拡張を設定していると、拡張領域を利用しているページに 1 がセットされま るようになります。 6. 次に、データベースごとのバッファ プール使用量を確認します。 SELECT DB_NAME (b.database_id), is_in_bpool_extension ,COUNT(*) As 使用ページ数 ,COUNT(*) * 8.0 / 1024 As 使用サイズ_MB FROM sys.dm_os_buffer_descriptors b GROUP BY b.database_id, is_in_bpool_extension ORDER BY 使用ページ数 DESC 「BPEtestDB」データベースが約 2GB を使用していて、t1 テーブルのデータを丸ごとバ ッファ プール内に載せることができていることを確認できます。 設定を元に戻す 1. 最後に、設定を元に戻しておきましょう。バッファ プール拡張を元に戻すには、次のように ALTER SERVER CONFIGURATION ステートメントを実行します。また、Max Server Memory の設定も元に戻しておきましょう。 ALTER SERVER CONFIGURATION SET BUFFER POOL EXTENSION OFF EXEC sp_configure 'max server memory', 2147483647 RECONFIGURE バッファ プール拡張のまとめ 以上のように、バッファ プール拡張機能は、性能向上を期待できる大変便利な機能です。この機 能は、利用している HDD や、HDD の RAID 構成、SSD やフラッシュ型ドライブの種類など、 ストレージの性能に非常に大きな影響を受けるので、sqlio ツールなどを利用して、各ストレージ の I/O 性能をチェックしておくことも重要になります。 4.2 Power View（パワー ビュー）機能の強化 Power View（パワー ビュー）機能の強化 SQL Server 2014 では、Power View（パワー ビュー）機能が強化されて、Analysis Services の多次元モデル（Multidimensional Model）から Power View のレポートが作成できるようにな りました（この機能は、SQL Server 2012 でも、SP1 の CU4 を適用することで利用することが できます） 。 Analysis Services の 多次元モデル（キューブ）から Power View のレポートを作成 Analysis Services の 多次元モデル（キューブ） 以下は、レポートの元となっている Analysis Services 多次元モデル 設定手順 Analysis Services の多次元モデルから Power View レポートを作成できるようにするには、通 常と同じように Power View 環境をセットアップした後、SharePoint サイトで、以下のように 設定します。 1. まずは、SharePoint サイト上で、任意のドキュメント ライブラリを開いて、［ライブラリ］ タブの［ライブラリの設定］をクリックします。 1 2 2. ライブラリの設定ページが表示されたら、 ［詳細設定］をクリックします。 1 3. ［詳細設定］ページが表示されたら、 ［コンテンツ タイプの管理を許可する］で［はい］を選 択します。 1 ［はい］を選択した後、ページを下へスクロールして、一番下にある［OK］ボタンをクリッ クします。これでコンテンツの種類を追加できるようになります。 4. ライブラリの設定ページへ戻ったら、 ［コンテンツ タイプ］セクションが表示されるようにな っているので、ここで［既存のサイト コンテンツ タイプから追加］をクリックします。 1 5. ［コンテンツ タイプの選択］ページが表示されたら、次のように［利用可能なサイト コンテ ンツ タイプ］で「レポート データ ソース」を選択して、［追加］ボタンをクリックします。 2 1 3 「 レ ポ ー ト デ ー タ ソ ー ス 」 を 追 加 す る こ と で 、 Analysis Services の 多 次 元 モ デ ル （Multidimensional Model）から Power View レポートを作成できるようになります。 Analysis Services のテーブル モデル（Tabular Model）から Power View レポートを作成 する場合には、 「BI Semantic Model 接続」を追加していました。 以上で、ライブラリの設定が完了です。 6. 次に、ドキュメント ライブラリへ戻って、 ［ファイル］タブで［新しいドキュメント］メニュ ーを開き、 ［レポート データ ソース］をクリックします。 1 2 3 7. ［データ ソースのプロパティ］ページが表示されたら、次のように［名前］へ任意のファイ ル名（mdtest など）、［データ ソースの種類］で「Microsoft BI Semantic Model for Power View」を選択します。 1 2 3 4 5 ［接続文字列］へは、Analysis Services 多次元モデルへの接続情報を次のように記述します。 Data Source=サーバー名;Initial Catalog='データベース名';Cube='キューブ名' Data Source へ Analysis Services のサーバー名、Initial Catalog へ多次元モデルのデ ータベース名、Cube へキューブ名を記述します。記述後、 ［接続テスト］ボタンをクリック して、接続が成功したことを確認したら、 ［OK］ボタンをクリックします。 これで、多次元モデルを利用した Power View レポートを作成できるようになります。 8. ドキュメント ライブラリへ戻ったら、作成したデータ ソース ファイル（mdtest）の［...］ ボタンをクリックして、 「Power View レポートの作成」をクリックします。 1 2 3 これで、Power View レポートの編集ページが表示されて、任意の Power View レポートを 作成できるようになります。 従来までは、PowerPivot ファイルや、Analysis Services のテーブル モデル（Tabular Model） からしか Power View レポートを作成することができませんでしたが、SQL Server 2014 （または SQL Server 2012 CP1 CU4 以降）からは、Analysis Services の多次元モデルか らも作成できるようになりました。 4.3 Cloud OS への対応（Windows Azure 連携） Cloud OS への対応（Windows Azure 連携） SQL Server 2014 からは、Cloud OS への対応（Windows Azure 連携）として、以下の機能が サポートされるようになりました。 Windows Azure 上へのバックアップが可能に（SQL Server 2012 SP1 CU2 からサ ポート） AlwaysOn 可用性グループのセカンダリを Windows Azure 上へ作成するためのウィ ザードの提供（CTP1 では未実装） Windows Azure 上の仮想マシン（VM）へのデータベースの配置（Deploy） Windows Azure（BLOB ストレージ）上へのバックアップ SQL Server 2014 からは、Windows Azure 上の BLOB ストレージへバックアップを実行でき るようになりました（この機能は、SQL Server 2012 でも、SP1 の CU2 を適用することで利用 することができます） 。 これは、次のように利用することができます。 CREATE CREDENTIAL 資格情報名 WITH IDENTITY = 'ストレージ アカウント名', SECRET = 'ストレージ アカウントのアクセス キー' BACKUP DATABASE sampleDB TO URL = 'https://ストレージ アカウント名.blob.core.windows.net/コンテナー名/～.bak' WITH CREDENTIAL = '資格情報名', COMPRESSION Windows Azure 上のストレージ アカウントの名前やアクセス キーを利用して、CREATE CREDENTIAL で資格情報を作成し、BACKUP ステートメントの CREDENTIAL 句でこの資格 情報を指定、URL 句で Windows Azure 上の BLOB ストレージのコンテナーを指定することで、 コンテナー内へバックアップを作成することができます。 Windows Azure 上 で の ス ト レ ー ジ ア カ ウ ン トの 作 成 は 、 Windows Azure 管 理 ポ ー タ ル （http://windows.azure.com）を利用して、次のように行うことができます。 1 2 ［ストレージ］を選択して、画面左下に表示される［新規］をクリックすることで、新しいストレ ージ アカウントを作成することができます。 次のように［新規作成］画面が表示されたら、 ［簡易作成］をクリックして、 ［URL］にストレージ アカウントの名前（画面は azurestoragetest1）を入力し、利用可能なアカウント名である場合 は、緑のチェックマークが付きます。 作成可能なアカウント名 なら緑のチェックマーク が付く 1 2 3 ストレージ アカウントを 作成する場所を選択 4 ［場所／アフィニティ グループ］でストレージ アカウントを作成するデータ センターの場所を 選択して、［ストレージ アカウントの作成］ボタンをクリックすれば、ストレージ アカウントの 作成が完了です。 ストレージ アカウントの作成後は、コンテナーを作成することで、バックアップ ファイルなどを 配置できるようになります。コンテナーを作成するには、ストレージ アカウントの［→］ボタン をクリックして、次のように［コンテナー］ページで［コンテナーを作成する］をクリックします。 1 2 3 4 5 ［新しいコンテナー］ダイアログが表示されたら、［名前］へ任意のコンテナー名（画面は container1） 、［アクセス］で任意のアクセス レベル（画面は プライベート）を選択して、チェ ック ボタンをクリックすれば、コンテナーの作成が完了です。 コンテナーの作成後は、 ［ダッシュボード］をクリックして、ダッシュボード ページへ移り、画面 下の［アクセス キーの管理］ボタンをクリックします。 1 3 4 ストレージ アカウント名 ストレージ アカウント のアクセス キー 2 これにより、ストレージ アカウントのアクセス キーが表示されるので、これをコピーします。 コピーしたアクセス キーは、次のように CREATE CREDENTIAL ステートメントの SECRET 句へ貼り付けます。 CREATE CREDENTIAL cred WITH IDENTITY = 'azurestoragetest1', SECRET = 'QaPT5m4Csb8F9SXQc8sodAVabjT4piKX～' IDENTITY 句には、ストレージ アカウントの名前、cred には任意の資格情報名を入力すれば、 資格情報の作成が完了です。 次に、ダッシュボード ページで、次のようにサービス一覧の［BLOB］に表示される［エンドポ イント］の URL（http://ストレージアカウント名.blob.core.windows.net）をコピーします。 1 2 コピーした URL は、次のように BACKUP ステートメントの URL 句へ貼り付けて、 「http」の 部分を「https」へ変更します（https への変更は必須ではありませんが、暗号化をするためにも 付けることをお勧めします） 。URL には、コンテナー名（container1 など事前に作成したコンテ ナー名）とバックアップ ファイル名（～.bak など）を付加すれば、Windows Azure 上へのバ ックアップが完了です。 BACKUP DATABASE sampleDB TO URL = 'https://azurestoragetest1.blob.core.windows.net/container1/sampleDB.bak' WITH CREDENTIAL = 'cred', COMPRESSION, STATS = 10 COMPRESSION と STATS は、必須ではありませんが、COMPRESSION によって圧縮バック アップを実行することができ、バックアップ ファイルのサイズを小さくすることができます。こ れによって、ファイルの転送量を小さくでき、バックアップ時間を短縮することができるので、 COMPRESSION を付けることをお勧めします。また、STATS を付けることで、進行状況を ［Message］タブで確認できるようになるので、こちらも付けることをお勧めします。 バックアップされたファイルは、 ［コンテナー］ページから、次のように確認することができます。 1 2 3 BLOB ストレージ上に バックアップされたファイル Windows Azure 上のバックアップ ファイルをもとに、リストアすることもでき、これは次のよ うに記述できます。 RESTORE DATABASE sampleDB FROM URL = 'https://azurestoragetest1.blob.core.windows.net/container1/sampleDB.bak' WITH CREDENTIAL = 'cred', STATS = 10 Windows Azure 上の仮想マシン（VM）へのデータベースの配置（Deploy） SQL Server 2014 からは、Windows Azure 上の仮想マシン（VM：Virtual Machine）へデータ ベースを配置（Deploy）できる機能（丸ごと複製／配置できる機能）が提供されています。 これは、次のように配置したいデータベースを右クリックして、 ［Tasks］メニューから［Deploy Database to a Windows Azure VM］をクリックすることで行えます。 1 SQL Server へ の接続 データベースの 選択 配置で利用する 一時フォルダー を指定 証明書の選択 サブスクリプ ションの選択 既存の仮想マシンを選択する ことも、新しい仮想マシンを 作成することも可能 Windows Azure 上の仮想マシン とクラウド サービス、ストレージ アカウントの選択 仮想マシン上の クラウド アダプターへ の接続情報の設定 配置先となる データベース の名前 Azure VM 上の SQL Server Azure VM 上 に配置された データベース このように、SQL Server 2014 からは、Windows Azure の仮想マシン（VM）上に、データベ ースを配置（丸ごと複製）することも、簡単に行うことができるようになりました。 4.4 SQL Server AlwaysOn のパワーアップ SQL Server AlwaysOn のパワーアップ SQL Server 2014 からは、SQL Server AlwaysOn がパワーアップして、以下の機能がサポート されるようになりました。 セカンダリを最大 8 台まで作成可能に（SQL Server 2012 では 4 台が上限） クォーラム損失時にも読み取り可能セカンダリへのアクセスが可能 FCI（フェールオーバー クラスター インスタンス）で CSV（クラスター共有ボリュー ム）がサポート セカンダリを最大 8 台まで作成可能に（SQL Server 2012 では 4 台が上限） SQL Server 2014 からは、AlwaysOn 可用性グループ（Availability Group）で、セカンダリを 最大 8 台まで作成できるようになりました（SQL Server 2012 では 4 台が上限でした） 。以下の 画面は、8 台のセカンダリを作成しているときの様子です。 最大 8台の セカンダリを作成可能 以下は、8 台のセカンダリで構成した可用性グループを監視しているときの様子 最大 8台の セカンダリを作成可能 クォーラム損失時にも読み取り可能セカンダリへのアクセスが可能 SQL Server 2014 からは、AlwaysOn 可用性グループで、WSFC（フェールオーバー クラスタ ー）のクォーラムが損失したときにも、読み取り可能セカンダリへのアクセスができるようになり ました。 SQL Server 2012 のときには、クォーラム損失時は、次のようにデータベースへアクセスするこ とができませんでした。 SQL Server 2012 ではクォーラムが損失していると、 復旧待ちと表示されて、DB にアクセスできない SQL Server 2014 からは、クォーラムが損失していても、次のように読み取り可能セカンダリへ アクセスできるようになりました。 クォーラムが損失していても 読み取り可能セカンダリへアクセス可能 Not Synchronizing （同期されていな い）と表示される。DB にアクセス可能 上記は、以下のようにクォーラムが損失している状態です。 クォーラムが損失しているので クラスターにアクセスできない状態 このように、SQL Server 2014 では、SQL Server AlwaysOn がパワーアップしました。 4.5 Query Processing の拡張（SELECT INTO のパラレル処理など） Query Processing の拡張（SELECT INTO のパラレル処理など） SQL Server 2014 では、Query Processing（クエリ処理）が拡張されて、次の機能を利用でき るようになりました。 SELECT INTO のパラレル処理 Cardinality Estimate（基数見積り）の改良（CTP1 では未実装） リソース ガバナーで I/O 数による制限が可能に SELECT INTO でのパラレル処理 SQL Server 2014 では、SELECT INTO でパラレル処理ができるようになりました。これは、 実行プランを参照することで確認することができます。たとえば、次のような単純な SELECT INTO ステートメントを実行したとします。 SELECT * INTO testDB..t1 FROM t1 実行プランを確認すると、次のようになります（複数コア環境の場合） 。 パラレル Table Insert パラレル処理のマーク（ ）が付いた「Table Insert」を確認できると思います。 なお、SQL Server 2012 までは、実行プランは、次のように表示されます（パラレルではない） 。 弊社事例： SELECT INTO パラレル化の性能効果 弊社のお客様が利用している、実際の日中バッチ処理（総ステップ数が約 20,000 のストアド プ ロシージャで、ストアド プロシージャ内で SELECT INTO を利用）で、SELECT INTO のパラ レル化による性能効果を調べたところ、次のような結果を得ることができました。 平均で 18.3％ 向上 最大で 36.6％ 向上 する処理も有り 最大で 36.6％ 向上 する処理も有り 平均で 18.3％ 向上 合計実行時間の差 全体（合計実行時間） としては 20.5％ 向上 SQL Server 2012 では、抽出条件１～18 の合計実行時間が 1 時間 19 分 58 秒であったのに対 して、SQL Server 2014 に変更すると 1 時間 3 分 36 秒と、16 分 22 秒（20.5％）もの性能 向上を確認することができました。バッチのソース コードには手を加えておらず、単純に SQL Server 2014 に置き換えただけで（2012 で利用していたデータベースを 2014 へアタッチした だけで）、これだけの効果を得ることができました。最大では、36.6％ も向上する処理（抽出条 件 15）もあり、SELECT INTO への依存度が大きい処理ほど、大きな効果を確認できました。 リソース ガバナーで I/O 数による制限 SQL Server 2014 からは、リソース ガバナーで、I/O 数による制限ができるようになりました。 これは、リソース プールの作成時に、次のように設定できます。 CREATE RESOURCE POOL testPool WITH( MIN_CPU_PERCENT = 0, MAX_CPU_PERCENT = 100, MIN_MEMORY_PERCENT = 0, MAX_MEMORY_PERCENT = 100, MIN_IOPS_PER_VOLUME = 0, MAX_IOPS_PER_VOLUME = 1000, AFFINITY SCHEDULER = AUTO ) -- I/O 数を 1000に制限 I/O 負 荷 が 高 い 処 理 が 原 因 で 、 シ ス テ ム 全 体 の パ フ ォ ー マ ン ス が 落 ち て い る 場 合 に は 、 MAX_IOPS_PER_VOLUME を設定して、該当処理の I/O 数を制限することで、全体のスルー プットを向上させることができるようになります。 4.6 Power Query for Excel Power Query for Excel SQL Server 2014 では、Power Query for Excel がサポートされて、データベースや Web ペ ージ、Hadoop HDFS など、さまざまなデータソースから簡単にデータを取得できるようになり ました。 Power Query は、従来の Excel の［データ］タブや、PowerPivot for Excel でのデータ取得機 能を強力にパワーアップさせたようなもので、上画面のように、より多くのデータソースからデー タを取得できるようになりました。一番左の［Online Search］ボタンでは、Wikipedia（US） などからデータを検索・取得できたり、［From Web］ボタンを利用すれば、Web ページ内の <Table> タグや、URL アクセス可能なファイル（Excel や CSV、XML、Text など）を取得す ることもできます。 また、［From File］ボタンで OS 上のファイル（Folder を指定すればフォルダー内の複数のフ ァイルを対象にできる）、 ［From Database］ボタンで SQL Server や Windows Azure SQL デ ータベース、Access、Oracle、DB2、MySQL などの各種データベース、 ［From Other Sources］ ボタンで Hadoop HDFS や Windows Azure HDInsight（Windows Azure の Hadoop 実 装） 、SharePoint List、OData Feed、Facebook などからデータを取得することも可能です。 Power Query for Excel で取得したデータは、次のように Power Map for Excel を利用すれ ば、地図データの可視化を簡単に行うこともできます。 Power Query for Excel と Power Map for Excel のダウンロード Power Query for Excel と Power Map for Excel（プレビュー版）は、以下の Power BI ペ ージからダウンロードすることができます。 http://office.microsoft.com/en-us/excel/power-bi-download-add-in-FX104087144.aspx Power Query for Excel のダウンロード Power Map for Excel のダウンロード Let's Try それでは、Power Query for Excel を試してみましょう。ここでは、Wikipedia にある「都道 府県の人口一覧」 （http://ja.wikipedia.org/wiki/都道府県の人口一覧）を取得して、これを Power Map for Excel で可視化してみましょう。 都道府県別 の人口 1. まずは、Excel 2013 を起動して、 ［Power Query］タブを開きます。 1 2 次に、Web ページからデータを取得するために、 ［From Web］ボタンをクリックします。 2. ［From Web］ダイアログが表示されたら、以下の URL を入力して、 ［OK］ボタンをクリ ックします。 http://ja.wikipedia.org/wiki/都道府県の人口一覧 1 2 3. Web ページへの接続が成功すると、次のように［Query Editor］が表示されます。 1 左側の Navigator ペインで［Table_0］をクリックすると、該当 Web ページ内にある最 初の <Table> タグの情報が右側に表示されます（県別の人口が表示されます） 。 4. 先頭の行は、総数が表示されていて、今回はこれを利用しないので、次のようにグリッドの左 上のセルを右クリックして、 ［Remove Top Rows］をクリックします。 1 2 一番左上のセル を右クリック 3 4 ［Remove Top Rows］ダイアログが表示されたら、 ［Number of Rows］で「1」と入力 して、 ［OK］ボタンをクリックします。これで、先頭から「1」行分、データを削除すること ができます。 5. 先頭行が削除されたことを確認したら、［Done］ボタンをクリックします。 1 これで、Web ページからデータを取り込むことができ、次のように Excel 上にデータが配 置されます。 クエリを編集したい場合 は、ココをクリック クエリを編集したい場合は、右側の［Query Settings］ペインで［Filter & Shape］ボタ ンをクリックすれば、再度［Query Editor］を起動することができます。 6. 次に、［挿入］タブを開いて、 ［Map］から［Launch GeoFlow］をクリックします。 1 2 7. これにより、Power Map for Excel（開発コード名：GeoFlow）が起動するので、次のよう に［都道府県］をチェックします。 1 2 3 ［GEOGRAPHY］セクションに［都道府県］が追加されたら、 ［County］を選択して、 ［Map It］ボタンをクリックします。 これにより、都道府県ごとに、赤い四角のアイコンが追加されるようになります。 8. 次に、 ［2010 年］をチェックすると、棒グラフに変わって、2010 年の人口データをもとに、 棒グラフの長さが変わることが確認できます。 1 HIGHT（高さ）に 2010年が追加される また、右下の「＜」や「＞」ボタンを利用して、角度の調整をすることができます。 角度の調整が できる マウスをオーバーするとポッ プアップで情報が表示される なお、現在の Power Map for Excel は、プレビュー版なので、東京都のデータが三宅島付近 に表示されてしまうなど、一部のデータが適切な場所に表示されません。 9. 次に、［1920 年］をチェックして、 ［Clustered］をチェックします。 1 2 HIGHT（高さ）に 1920年が追加される これで、1920 年と 2010 年の人口を比較した棒グラフを作成することができます。 10. そのほか、［Themas］でテーマ（スタイル）を変更したり、［Data Shape］でグラフの図 形を変更したりすることもできます。 「四角」を「丸」に変更 したりできる テーマの変更 11. ［CHART TYPE］では、 ［Column］ （棒グラフ）、 ［Bubble］ （円グラフ） 、 ［HeatMap］ （ヒ ートマップ）などを選択して、グラフの種類を変更することもできます。 ［Bubble］ （円グラフ）を選択した場合 ［HeatMap］（ヒートマップ）を選択した場合 このように、Power Query for Excel を利用すれば、いろいろなデータソースから簡単にデ ータを取得することができ、Power Map for Excel を利用すれば、地図データを簡単に可視 化することができるようになります。 4.7 インデックス再構築時のロックの優先度変更 インデックス再構築時のロックの優先度変更 SQL Server 2014 では、オンライン インデックスの再構築時や、パーティション スイッチ時に ロックの優先度を変更できるようになりました。 これは、次のように利用することができます（オンライン インデックス再構築時の場合） 。 ALTER INDEX pk_index ON t1 REBUILD WITH ( ONLINE = ON ( WAIT_AT_LOW_PRIORITY (MAX_DURATION = 10 minutes, ABORT_AFTER_WAIT = SELF ))) おわりに 最後まで試された皆さん、いかがでしたでしょうか？ SQL Server 2014 には、たくさんの新機 能が追加されていることを確認できたのではないでしょうか。インメモリ OLTP や、クラスター 化列ストア インデックス（更新可能な列ストア インデックス） 、バッファ プール拡張、SELECT INTO のパラレル処理など、大きな性能向上を期待できるものが多数あります。 弊社でも、過去のお客様環境で利用できそうな機能がたくさんあり、大幅な性能向上を実現できる のではないかとワクワクしています（これからいろいろと検証します！）。皆さんも、ぜひ試して みていただければと思います。 なお、CTP1 は、パフォーマンスが最適化されたビルドではないので、今後の CTP および RTM （製品版）では、より最適化されたものが提供されることになります。 参考情報 SQL Server 2014 に関するその他の情報については、オンライン ブックや Product Guide が参 考になると思います。 オンライン ブック What's New in SQL Server 2014 http://msdn.microsoft.com/en-us/library/bb500435(v=sql.120).aspx SQL Server 2014 CTP1 Product Guide http://www.microsoft.com/en-us/download/details.aspx?id=39269 執筆者プロフィール 有限会社エスキューエル・クオリティ（http://www.sqlquality.com/） SQLQuality（エスキューエル・クオリティ）は、日本で唯一の SQL Server 専門の独立系コンサルティン グ会社です。過去のバージョンから最新バージョンまでの SQL Server を知りつくし、多数の実績と豊富な 経験を持つ、OS や .NET にも詳しい SQL Server の専門家（キャリア 17 年以上）がすべての案件に対応 します。人気メニューの「パフォーマンス チューニング サービス」は、100％の成果を上げ、過去すべての お客様環境で驚異的な性能向上を実現。チューニング スキルは世界トップレベルを自負、検索エンジンでは （英語情報を含めて）ヒットしないノウハウを多数保持。ここ数年は BI／DWH システム構築支援のご依頼 が多く、支援だけでなく実際の構築も行う。 主なコンサルティング実績 大手製造業の「CAD 端末の利用状況の見える化」システム構築（Reporting Services を利用） 大手映像制作会社の BI システム構築支援（会計／業務システムにおける予実管理／原価管理など） 大手流通系の DWH／BI システム構築支援（POS データ／在庫データ分析） 大手流通系の 100 億件の DWH 環境のパフォーマンス チューニング（POS データ／顧客データ分析） 大手アミューズメント企業の BI システム構築支援（人事システムにおける人材パフォーマンス管理） 外資系医療メーカーの Analysis Services による「販売分析」システムの構築支援（売上／顧客データ分析） 9 TB データベースの物理・論理設計支援（パーティショニング対応など） ハードウェア リプレイス時のハードウェア選定（最適なサーバー、ストレージの選定）、高可用性環境の構築 SQL Server の下位バージョンからの移行／アップグレード支援（32 ビットから x64 への対応も含む） 複数台の SQL Server の Hyper-V 仮想環境への移行支援（サーバー統合支援） 2 時間かかっていた日中バッチ実行時間を、わずか 5 分へ短縮（95.8％ の性能向上） ピーク時の CPU 利用率 100% のシステムを、わずか 10% にまで軽減し、大幅性能向上 平均 185.3ms かかっていたトランザクション処理を、わずか 39.2ms へ短縮（78.8％ の性能向上） Java 環境（Tomcat、Seasar2、S2Dao）の SQL Server パフォーマンス チューニング etc コンサルティング時の作業例（パフォーマンス チューニングの場合） アプリケーション コード（VB、C#、Java、ASP、VBScript、VBA）の解析／改修支援 ストアド プロシージャ／ユーザー定義関数／トリガー（Transact-SQL）の解析／改修支援 インデックス チューニング／SQL チューニング／ロック処理の見直し 現状のハードウェアで将来のアクセス増にどこまで耐えられるかを測定する高負荷テストの実施 IIS ログの解析／アプリケーション ログ（log4net／log4j）の解析 ボトルネック ハードウェアの発見／ボトルネック SQL の発見／ボトルネック アプリケーションの発見 SQL Server の構成オプション／データベース設定の分析／使用状況（CPU, メモリ, ディスク, Wait）解析 定期メンテナンス支援（インデックスの再構築／断片化解消のタイミングや断片化の事前防止策など）etc 松本美穂（まつもと・みほ） 有限会社エスキューエル・クオリティ 代表取締役 Microsoft MVP for SQL Server（2004 年 4 月～） 経産省認定データベース スペシャリスト／MCDBA／MCSD for .NET／MCITP Database Administrator SQL Server の日本における最初のバージョンである「SQL Server 4.21a」から SQL Server に携わり、現在、SQL Server を中心とするコンサルティングを行っている。得意分野はパフォーマンス チューニングと Reporting Services。コンサル ティング業務の傍ら、講演や執筆も行い、マイクロソフト主催の最大イベント Tech・Ed などでスピーカーとしても活躍 中。著書の『SQL Server 2000 でいってみよう』と『ASP.NET でいってみよう』（いずれも翔泳社刊）は、トップ セラー （前者は 28,500 部、後者は 16,500 部発行）。近刊に『SQL Server 2012 の教科書』（ソシム刊）がある。 松本崇博（まつもと・たかひろ） 有限会社エスキューエル・クオリティ 取締役 Microsoft MVP for SQL Server（2004 年 4 月～） 経産省認定データベース スペシャリスト／MCDBA／MCSD for .NET／MCITP Database Administrator SQL Server の BI システムとパフォーマンス チューニングを得意とするコンサルタント。過去には、約 3,000 本のスト アド プロシージャのチューニングや、テラバイト級データベースの論理・物理設計、運用管理設計、高可用性設計、BI・ DWH システム設計支援などを行う。アプリケーション開発（ASP／ASP.NET、C#、VB 6.0、Java、Access VBA など） やシステム管理者（IT Pro）経験もあり、SQL Server だけでなく、アプリケーションや OS、Web サーバーを絡めた、 総合的なコンサルティングが行えるのが強み。Analysis Services と Excel による BI システムも得意とする。マイクロソ フト認定トレーナー時代の 1998 年度には、Microsoft CPLS トレーナー アワード（Trainer of the Year）を受賞。