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.

目次

SSTTEEPP 11.. SSQQLL SSeerrvveerr 22001144 CCTTPP11 でで提提供供さされれるる新新機機能能のの概概要要 .................................................... 4

1.1 SQL Server 2014 CTP1 のダウンロード...................................................................... 5 1.2 SQL Server 2014 CTP1 で提供される主な新機能の概要 ................................................. 6

SSTTEEPP 22.. イインンメメモモリリ OOLLTTPP 機機能能のの概概要要 ................................................................................ 10

2.1 インメモリ OLTP（Hekaton）機能の概要 .................................................................... 11

SSTTEEPP 33.. 更更新新可可能能なな列列スストトアア イインンデデッッククスス にによよるる性性能能向向上上 ..................................................... 15

3.1 更新可能な列ストア インデックスの概要 ..................................................................... 16 3.2 クラスター化列ストア インデックスの性能比較 ............................................................ 18 3.3 クラスター化列ストア インデックスに対するデータの更新 .............................................. 30 3.4 COLUMNSTORE_ARCHIVE（列ストア アーカイブ） ..................................................... 33

SSTTEEPP 44.. SSQQLL SSeerrvveerr 22001144 のの 主主なな新新機機能能 ........................................................................... 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

SSTTEEPP 11.. SSQQLL SSeerrvveerr 22001144 CCTTPP11 でで提提供供さされれるる新新機機能能のの概概要要

この 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 で詳しく説明）

バッファ プール拡張により、SSD をバッファ プールとして利用可能に

バッファ プール拡張を利用すると、次のような性能向上を実現できます（Step 4 で詳しく説明）

39.5倍

26.5倍 テストに利用したハードウェア環境・Core i7 3770K 3.5GHz・メモリ 32GB・SSD PLEXTOR M3P 256GB

性能結果は相対値ベンチマーク結果の公開は、使用許諾契約書で禁じられているので、グラフ内の結果は、クラスター化列ストア インデックスの値を100 とした場合の相対値で表しています。

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 から利用可能）

Cloud OS への対応（Windows Azure との連携）

- Windows Azure 上へのバックアップが可能に

- AlwaysOn 可用性グループのセカンダリを Windows Azure 上へ作成することが できるウィザードの提供（CTP1 では未実装）

- Windows Azure 上の仮想マシン（VM）へのデータベースの配置（Deploy）

SQL Server AlwaysOn のパワーアップ

- クォーラム損失時にも読み取り可能セカンダリへのアクセスが可能

- FCI（フェールオーバー クラスター インスタンス）で CSV（クラスター共有 ボリューム）がサポート

Analysis Services の多次元モデル（キューブ）

Analysis Services の多次元モデル（キューブ）からPower View のレポートを作成

Windows Azure 上の BLOB ストレージのコンテナーを指定して、バックアップが可能

- セカンダリを最大 8台まで作成可能に（SQL Server 2012 では 4台が上限）

SELECT INTO でのパラレル処理が可能に

以下は、SELECT INTO を実行したときの実行プランです（パラレル Table Insert）。

SELECT INTO のパラレル処理によって、次のような性能向上を実現できます（Step 4 で詳しく説明）。

最大 8台のセカンダリを作成可能

パラレルTable Insert

最大で 36.6％ 向上する処理も有り

平均で18.3％ 向上

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 では未実装）

パーティション スイッチやインデックス再構築時のロックの優先度変更

本自習書では、これらの新機能について、ステップ バイ ステップ形式で画面ショット満載で紹介していますので、ぜひ、皆さんも実際に試しながらこの自習書を読み進めていただければと思います。

SSTTEEPP 22.. イインンメメモモリリ OOLLTTPP 機機能能のの概概要要

この 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 するスクリプトを実行したときの実行時間を比較すると、次のグラフのようになります。

従来のデータベース エンジンを利用した通常のテーブルを、Memory-optimized Table（インメモリ OLTP 機能でのテーブル）へ変更・移行することで、約 1/2 のスピード（2 倍の性能向上）、さらにネイティブ コンパイル ストアド プロシージャへ変更することで、約 1/12 のスピード（12.2 倍の性能向上）を実現することができています。このように、大きな性能向上を期待できるのがインメモリ OLTP 機能です。

SQL Server のデータベース エンジンと完全に統合されている（＝移行が容易）

インメモリ OLTP 機能のもう 1つの大きな利点は、従来型の SQL Server データベース エンジンと完全に統合されている点にあります。他社製のインメモリ エンジンの場合は、別製品として提供されていることが多く、これでは別途インストールが必要であったり、実際の操作方法が異なったり、新しい知識が必要になったりするなど、簡単に移行することができません（新しいハードウェアを購入しなければならない場合もあります）。

これに対して、SQL Server のインメモリ OLTP 機能は、SQL Server と完全に統合されている

約2倍

実行時間が約 1/12 に短縮

12.2倍の性能向上！

ので、簡単に移行することができます。通常の 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 まで、幅広くカバーしています。

SSTTEEPP 33.. 更更新新可可能能なな列列スストトアア イインンデデッッククスス にによよるる性性能能向向上上

この 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

3

各種オプションの設定

2

列ストア インデックスによる性能向上

列ストア インデックスは、「xVelocity 列ストア インデックス」とも呼ばれ、PowerPivot および Analysis Services Tabular Mode（テーブル モード）で採用されているインメモリの BI エンジンである「xVelocity エンジン」を RDB へ応用したものです。

このエンジンでは、列単位でインデックスを格納し、それらは高度に圧縮されています。

このインデックスによって、大量のデータに対する集計処理（GROUP BY 演算など）の性能を大きく向上させることができます。したがって、夜間バッチ処理時（夜間バッチでの日次集計や月次集計処理など）や、DWH（データ ウェアハウス）環境での集計処理時に大変役立ちます。

本自習書内では、1,000万件のデータに対する GROUP BY 演算を実行するスクリプトを説明していますが、このスクリプトを実行したときの実行時間を比較すると、次のグラフのようになります。

グラフの FullScan は、インデックスが使用されないフル テーブル スキャンが実行されたときの速度、IndexScan は、列ストア インデックスではない通常の非クラスター化インデックスを作成／利用したとき、ColumnStore NonClustered が非クラスター化列ストア インデックスを作成／利用したとき、ColumnStore Clustered がクラスター化列ストア インデックス（CCI）を作成／利用したときの実行速度です（相対値）。列ストア インデックスを利用することで、フル スキャンに比べて 39.5倍、インデックス スキャンに比べて 26.5倍もの性能向上を実現することができます。このように、集計処理に強いのが列ストア インデックスです。

テーブル

a b c

a b c

従来ながらの Row ストア

…

行単位で格納

カラム（Column）ストア

a b c

列単位で格納

高度に圧縮されている

xVelocity 列ストア インデックス

39.5倍

26.5倍 テストに利用したハードウェア環境・Core i7 3770K 3.5GHz・メモリ 32GB・SSD PLEXTOR M3P 256GB

性能結果は相対値ベンチマーク結果の公開は、使用許諾契約書で禁じられているので、グラフ内の結果は、クラスター化列ストア インデックスの値を100 とした場合の相対値で表しています。

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

t1 テーブルの a列には、IDENTITY による連番、b列には、10,000件ごとに、10,000、20,000、30,000 という値が入るようにしています。

a 列には1 からの連番

b 列は 10000ごとに同じ値

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 ステートメントを選択して、ツールバーの［推定実行プラン］ボタンをクリックし、実行プランを確認します。

Clustered Index Scan（全データのスキャン）が選択されていることを確認できます。t1 テーブルの a 列には、PRIMARY KEY 制約を設定しているので、クラスター化インデックスが自動作成されていて、このインデックス（実データ）が全スキャンされています。

3. 次に、テーブルのプロパティを開いて、テーブル サイズを確認しておきましょう。

オブジェクト エクスプローラーで、t1 テーブルを右クリックして、［Properties］をクリックし、［Storage］ページを開くと、［Data space］でテーブル サイズを確認することができます（約 4GB のサイズであることを確認できます）。

2

SELECT ステートメントを選択

1

Clustered Index Scan

3

1

2

3

非クラスター化インデックスの作成（通常のインデックスの場合の性能チェック）

次に、非クラスター化インデックス（列ストア インデックスではなく、通常のインデックス）を作成した場合の性能を調べてみましょう。

1. 今回作成する非クラスター化インデックスは、先ほどの GROUP BY 演算を速く実行するために、「b, a」列の順番に作成します。

CREATE NONCLUSTERED INDEX idx1

ON t1(b, a)

2. 作成が完了したら、先ほどと同じ SELECT ステートメントを実行して、実行時間を調べましょう。

SELECT b, MAX(a) FROM t1

GROUP BY b

elapsed time（経過時間）が小さくなっていることを確認できると思います（弊社環境では、約 30％ 速く実行できることを確認しています）。

3. 次に、SELECT ステートメントを選択して、ツールバーの［推定実行プラン］ボタンをクリックし、実行プランも確認しておきましょう。

Index Scan と表示されていることを確認できると思います。

実行時間を確認する

1

Index Scan1

4. 次に、テーブル サイズとインデックス サイズを確認しておきましょう。

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)

1 2

3. 作成が完了したら、同じ SELECT ステートメントを実行して、実行時間を調べましょう。

SELECT b, MAX(a) FROM t1

GROUP BY b

elapsed time（経過時間）が桁違いに小さくなっていることを確認できると思います（弊社環境では、約 27.6倍 速く実行できることを確認しています）。

4. 次に、SELECT ステートメントを選択して、ツールバーの［推定実行プラン］ボタンをクリックし、実行プランも確認しておきましょう。

Columnstore Index Scan（NonClustered）と表示されて、非クラスター化列ストア インデックスのスキャンで実行されていることを確認できると思います。

5. 次に、インデックス サイズも確認しておきましょう。

Index space（インデックスのサイズ）が約 52MBであることを確認できます（非クラスタ

実行時間を確認する

1

NonClustered（非クラスター化）のColumnstore Index Scan

1

1

ー化インデックスの場合は 約 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'

index_name に表示される「PK__t1__～」がインデックス名および PRIMARY KEY 制約の名前になるので、これをコピーします。

4. コピーした名前を以下の ALTER TABLE ステートメントに貼り付けて、PRIMARY KEY 制約を削除します。

ALTER TABLE t1

DROP CONSTRAINT PK__t1__3BD0198EA17AC327

1

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

elapsed time（経過時間）が桁違いに小さくなっていることを確認できると思います（弊社環境では、非クラスター化列ストア インデックスのときとほぼ同じ速度で実行できることを確認しています。非クラスター化インデックスのときと比べると、約 26.5倍 速く実行）。

7. 次に、SELECT ステートメントを選択して、ツールバーの［推定実行プラン］ボタンをクリックし、実行プランも確認しておきましょう。

Columnstore Index Scan（Clustered）と表示されて、クラスター化列ストア インデックスのスキャンで実行されていることを確認できると思います。

実行時間を確認する

1

Clustered（クラスター化）のColumnstore Index Scan

1

8. 次に、テーブル サイズとインデックス サイズも確認しておきましょう。

Data space（テーブル サイズ）が約 37MB、Index space（インデックス サイズ）が 0MBになっていることを確認できます（非クラスター化列ストア インデックスでは、Data space が約 4GB、Index space が約 52MBでした）。

ここまでの結果をまとめると、次のようになります。

FullScan は Clustered Index Scan が実行されたとき、IndexScan は非クラスター化インデックスを作成／利用したとき、ColumnStore NonClustered は非クラスター化列ストア インデックスを作成／利用したとき、ColumnStore Clustered はクラスター化列ストア インデックスを作成／利用したときの実行速度です（相対値）。

非クラスター化列ストア インデックスとクラスター化列ストア インデックスでは、速度差は

1 2

39.5倍

26.5倍 テストに利用したハードウェア環境・Core i7 3770K 3.5GHz・メモリ 32GB・SSD Plextor M3P 256GB

性能結果は相対値ベンチマーク結果の公開は、使用許諾契約書で禁じられているので、グラフ内の結果は、クラスター化列ストア インデックスの値を100 とした場合の相対値で表しています。

ほとんどないことを確認できると思います。また、クラスター化列ストア インデックスを利用することで、フル スキャンに比べて 39.5 倍、インデックス スキャンに比べて 26.5 倍もの性能向上を確認できます。このように、集計処理に強いのが列ストア インデックスです。

テーブルおよびインデックス サイズをまとめると、次のようになります。

通常テーブルでは、約 4GB 分のテーブル領域を利用しているのに対して、クラスター化列ストア インデックスでは、テーブル データそのものが列ストア インデックスになるので、わずか 37MB のサイズに小さくすることができています。ただし、今回は、c および d 列には、まったく同じデータ（dummy1）を格納しているので、圧縮率が極端に高くなっていることを差し引く必要があることにも注意してください。

弊社のお客様のデータ（100億件の DWH）で、クラスター化列ストア インデックスを作成した場合は、次のような圧縮効果を確認することができました。

通常テーブルが 531GB であるところを、90GB へと、約 1/6 のサイズにすることができました。このように、クラスター化列ストア インデックスは、ディスク領域を削減できるメリットもあります。また、ディスクから読み取るサイズが小さくなる分、性能向上にも貢献します（圧縮および解凍に伴う CPU パワーとのトレードオフも存在します）。

9. 次に、SET STATISTICS TIME コマンドを OFF へ設定して、実行時間の記録を停止しておきます。

SET STATISTICS TIME OFF

クラスター化列ストア インデックスは、ディスク領域を削減で

きるメリットも有る

約 1/6に圧縮

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

10万件追加しただけにも関わらず、実行時間が長くなっていること（弊社環境では 3倍以上）を確認できると思います。

これは、クラスター化列ストア インデックスでは、更新されたデータは、「Delta ストア」と呼ばれる、更新データの格納用の領域に格納されているためです。

実行時間を確認する

1

a b c

Delta ストア（Row ストア）

… 行単位で格納

カラム（Column）ストア

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,000万件のときとほとんど同じスピードで検索できたことを確認できると思います。このように、クラスター化列ストア インデックスでは、データの更新を行うことができますが、より良いパフォーマンスを保つには、定期的にインデックスを再構築することが重要になります。

実行時間を確認する

1

3.4 COLUMNSTORE_ARCHIVE（列ストア アーカイブ）

COLUMNSTORE_ARCHIVE（列ストア アーカイブ）

クラスター化列ストア インデックスでは、さらに圧縮率を高めた、「COLUMNSTORE_ARCHIVE」（列ストア アーカイブ）というモードもあります。

さらに圧縮をすることで、ディスク使用領域をより小さくできることがメリットです（圧縮率を高くする分、さらに 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

カラム（Column）ストア

さらに圧縮

Columnstore Archive

ca b c ba

今回は、データ量が 1,010 万件と少ないので、大きな実行時間の差がでないことを確認できると思います（CPU のクロック数が低い場合には、差が大きくなります）。

3. 次に、テーブル サイズも確認しておきましょう。

Data space（テーブル サイズ）が約 15.4MBであることを確認できます（クラスター化列ストア インデックスの場合は 約 37MBでした）。

弊社のお客様のデータ（前述の 100億件の DWH）で、COLUMNSTORE_ARCHIVE を設定した場合は、次のような圧縮効果を確認することができました。

実行時間を確認する

1

2

1

約 1/6に圧縮

約 1/8に圧縮

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 ストアを利用することによるオーバーヘッドなどがありますが、インデックスを定期的に再構築するなど、うまく活用することで、大きな性能向上を実現することができます。

SSTTEEPP 44.. SSQQLL SSeerrvveerr 22001144 CCTTPP11 のの主主なな新新機機能能

この 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. コピーが完了したら、テーブル サイズを確認します。

テーブルのプロパティの［Storage］ページで、［Data space］が約 2GB であることを確認できます。

4. 次に、COUNT(*) を実行して、500万件のデータであることを確認します。

SELECT COUNT(*) FROM t1

5. 続いて、COUNT(*) のステートメントを選択して、実行プランを確認します。

Table Scan が選択されていることを確認できます。テーブル サイズは、約 2GB でしたので、Table Scan が発生する場合は、約 2GB 分のデータの読み取りが発生することになりま

1

3

2

Table Scan1

す。

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

実行が完了したら、実行時間をメモしておいてください。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

先行読み取り数を確認する

3論理読み取り数を

確認する

2

ッファ プール内には載せられなかったことを確認できます。

バッファ プール拡張の設定

次に、バッファ プール拡張を設定します。

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 サービスを再起動します。

3. 再起動が完了したら、SET STATISTICS コマンドを再度実行します。

SET STATISTICS TIME ON

SET STATISTICS IO ON

1

2

4. 設定後、先ほどと同じ COUNT(*) の SELECT ステートメントを実行して、実行時間や読み取りページ数を調べます。

SELECT COUNT(*) FROM t1

1 回目の実行は、SSD（拡張領域）への書き込みが発生するため、バッファ プール拡張を設定する前よりも実行速度が落ちます。

2回、3回、4回と何度も実行していくと、read-ahead reads（先行読み取り）のページ数が少なくなっていくことを確認できると思います。次のように、先行読み取り数が 0 になるまで実行します。

先行読み取り数が 0 になって、logical reads（論理読み取り数）のみがカウントされる場合は、すべてのデータをバッファ プールから取得していることになるので、バッファ プール拡張が最大限に活かされている状態になります。この状態では、弊社環境では、次のように 46.7％（約 2 倍）の性能向上を確認できています（実行時間はバッファ プール拡張なしの場合を 100 とした場合の相対値）。

実行時間を確認する

1

先行読み取り数を確認する

3論理読み取り数を

確認する

2

実行時間を確認する

1

先行読み取り数が0 になる

2

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 多次元モデル

Analysis Services の多次元モデル（キューブ）

Analysis Services の多次元モデル（キューブ）からPower View のレポートを作成

設定手順

Analysis Services の多次元モデルから Power View レポートを作成できるようにするには、通常と同じように Power View 環境をセットアップした後、SharePoint サイトで、以下のように設定します。

1. まずは、SharePoint サイト上で、任意のドキュメント ライブラリを開いて、［ライブラリ］タブの［ライブラリの設定］をクリックします。

2. ライブラリの設定ページが表示されたら、［詳細設定］をクリックします。

3. ［詳細設定］ページが表示されたら、［コンテンツ タイプの管理を許可する］で［はい］を選択します。

1 2

1

1

［はい］を選択した後、ページを下へスクロールして、一番下にある［OK］ボタンをクリックします。これでコンテンツの種類を追加できるようになります。

4. ライブラリの設定ページへ戻ったら、［コンテンツ タイプ］セクションが表示されるようになっているので、ここで［既存のサイト コンテンツ タイプから追加］をクリックします。

5. ［コンテンツ タイプの選択］ページが表示されたら、次のように［利用可能なサイト コンテンツ タイプ］で「レポート データ ソース」を選択して、［追加］ボタンをクリックします。

「レポート データ ソース」を追加することで、Analysis Services の多次元モデル（Multidimensional Model）から Power View レポートを作成できるようになります。Analysis Services のテーブル モデル（Tabular Model）から Power View レポートを作成する場合には、「BI Semantic Model 接続」を追加していました。

以上で、ライブラリの設定が完了です。

6. 次に、ドキュメント ライブラリへ戻って、［ファイル］タブで［新しいドキュメント］メニュ

1

1

2

3

ーを開き、［レポート データ ソース］をクリックします。

7. ［データ ソースのプロパティ］ページが表示されたら、次のように［名前］へ任意のファイル名（mdtest など）、［データ ソースの種類］で「Microsoft BI Semantic Model for Power View」を選択します。

［接続文字列］へは、Analysis Services 多次元モデルへの接続情報を次のように記述します。

Data Source=サーバー名;Initial Catalog='データベース名';Cube='キューブ名'

Data Source へ Analysis Services のサーバー名、Initial Catalog へ多次元モデルのデ

1 2

3

1

2

3

4

5

ータベース名、Cube へキューブ名を記述します。記述後、［接続テスト］ボタンをクリックして、接続が成功したことを確認したら、［OK］ボタンをクリックします。

これで、多次元モデルを利用した Power View レポートを作成できるようになります。

8. ドキュメント ライブラリへ戻ったら、作成したデータ ソース ファイル（mdtest）の［...］ボタンをクリックして、「Power View レポートの作成」をクリックします。

これで、Power View レポートの編集ページが表示されて、任意の Power View レポートを作成できるようになります。

従来までは、PowerPivot ファイルや、Analysis Servicesのテーブル モデル（Tabular Model）からしか Power View レポートを作成することができませんでしたが、SQL Server 2014（または SQL Server 2012 CP1 CU4 以降）からは、Analysis Services の多次元モデルからも作成できるようになりました。

1

2

3

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）を利用して、次のように行うことができます。

［ストレージ］を選択して、画面左下に表示される［新規］をクリックすることで、新しいストレージ アカウントを作成することができます。

次のように［新規作成］画面が表示されたら、［簡易作成］をクリックして、［URL］にストレージ アカウントの名前（画面は azurestoragetest1）を入力し、利用可能なアカウント名である場合は、緑のチェックマークが付きます。

［場所／アフィニティ グループ］でストレージ アカウントを作成するデータ センターの場所を選択して、［ストレージ アカウントの作成］ボタンをクリックすれば、ストレージ アカウントの作成が完了です。

1

2

1 2

3

4

作成可能なアカウント名なら緑のチェックマーク

が付く

ストレージ アカウントを作成する場所を選択

ストレージ アカウントの作成後は、コンテナーを作成することで、バックアップ ファイルなどを配置できるようになります。コンテナーを作成するには、ストレージ アカウントの［→］ボタンをクリックして、次のように［コンテナー］ページで［コンテナーを作成する］をクリックします。

［新しいコンテナー］ダイアログが表示されたら、［名前］へ任意のコンテナー名（画面は container1）、［アクセス］で任意のアクセス レベル（画面は プライベート）を選択して、チェック ボタンをクリックすれば、コンテナーの作成が完了です。

コンテナーの作成後は、［ダッシュボード］をクリックして、ダッシュボード ページへ移り、画面下の［アクセス キーの管理］ボタンをクリックします。

これにより、ストレージ アカウントのアクセス キーが表示されるので、これをコピーします。

コピーしたアクセス キーは、次のように CREATE CREDENTIAL ステートメントの SECRET

2

1

3

4

5

1

2

3

4

ストレージアカウント名

ストレージ アカウントのアクセス キー

句へ貼り付けます。

CREATE CREDENTIAL cred

WITH IDENTITY = 'azurestoragetest1',

SECRET = 'QaPT5m4Csb8F9SXQc8sodAVabjT4piKX～'

IDENTITY 句には、ストレージ アカウントの名前、cred には任意の資格情報名を入力すれば、資格情報の作成が完了です。

次に、ダッシュボード ページで、次のようにサービス一覧の［BLOB］に表示される［エンドポイント］の URL（http://ストレージアカウント名.blob.core.windows.net）をコピーします。

コピーした 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

1

2

COMPRESSION と STATS は、必須ではありませんが、COMPRESSION によって圧縮バックアップを実行することができ、バックアップ ファイルのサイズを小さくすることができます。これによって、ファイルの転送量を小さくでき、バックアップ時間を短縮することができるので、COMPRESSION を付けることをお勧めします。また、STATS を付けることで、進行状況を［Message］タブで確認できるようになるので、こちらも付けることをお勧めします。

バックアップされたファイルは、［コンテナー］ページから、次のように確認することができます。

Windows Azure 上のバックアップ ファイルをもとに、リストアすることもでき、これは次のように記述できます。

RESTORE DATABASE sampleDB

FROM URL = 'https://azurestoragetest1.blob.core.windows.net/container1/sampleDB.bak'

WITH CREDENTIAL = 'cred', STATS = 10

1

2

3

BLOB ストレージ上にバックアップされたファイル

Windows Azure 上の仮想マシン（VM）へのデータベースの配置（Deploy）

SQL Server 2014 からは、Windows Azure 上の仮想マシン（VM：Virtual Machine）へデータベースを配置（Deploy）できる機能（丸ごと複製／配置できる機能）が提供されています。

これは、次のように配置したいデータベースを右クリックして、［Tasks］メニューから［Deploy Database to a Windows Azure VM］をクリックすることで行えます。

1

SQL Server への接続

データベースの選択

配置で利用する一時フォルダー

を指定 証明書の選択

サブスクリプションの選択

このように、SQL Server 2014 からは、Windows Azure の仮想マシン（VM）上に、データベースを配置（丸ごと複製）することも、簡単に行うことができるようになりました。

Windows Azure 上の仮想マシンとクラウド サービス、ストレージ

アカウントの選択

仮想マシン上のクラウド アダプターへの接続情報の設定

配置先となるデータベースの名前

既存の仮想マシンを選択することも、新しい仮想マシンを

作成することも可能

Azure VM 上のSQL Server

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台のセカンダリで構成した可用性グループを監視しているときの様子

クォーラム損失時にも読み取り可能セカンダリへのアクセスが可能

SQL Server 2014 からは、AlwaysOn 可用性グループで、WSFC（フェールオーバー クラスター）のクォーラムが損失したときにも、読み取り可能セカンダリへのアクセスができるようになりました。

SQL Server 2012 のときには、クォーラム損失時は、次のようにデータベースへアクセスすることができませんでした。

最大 8台のセカンダリを作成可能

SQL Server 2012 ではクォーラムが損失していると、復旧待ちと表示されて、DB にアクセスできない

SQL Server 2014 からは、クォーラムが損失していても、次のように読み取り可能セカンダリへアクセスできるようになりました。

上記は、以下のようにクォーラムが損失している状態です。

このように、SQL Server 2014 では、SQL Server AlwaysOn がパワーアップしました。

Not Synchronizing （同期されていない）と表示される。DB にアクセス可能

クォーラムが損失していても読み取り可能セカンダリへアクセス可能

クォーラムが損失しているのでクラスターにアクセスできない状態

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」を確認できると思います。

なお、SQL Server 2012 までは、実行プランは、次のように表示されます（パラレルではない）。

パラレルTable Insert

弊社事例： SELECT INTO パラレル化の性能効果

弊社のお客様が利用している、実際の日中バッチ処理（総ステップ数が約 20,000 のストアド プロシージャで、ストアド プロシージャ内で SELECT INTO を利用）で、SELECT INTO のパラレル化による性能効果を調べたところ、次のような結果を得ることができました。

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 への依存度が大きい処理ほど、大きな効果を確認できました。

最大で 36.6％ 向上する処理も有り

平均で18.3％ 向上

平均で18.3％ 向上

最大で 36.6％ 向上する処理も有り

全体（合計実行時間）としては 20.5％ 向上合計実行時間の差

リソース ガバナーで 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, -- I/O 数を 1000に制限

AFFINITY SCHEDULER = AUTO )

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］タブを開きます。

次に、Web ページからデータを取得するために、［From Web］ボタンをクリックします。

都道府県別の人口

1 2

2. ［From Web］ダイアログが表示されたら、以下の URL を入力して、［OK］ボタンをクリックします。

http://ja.wikipedia.org/wiki/都道府県の人口一覧

3. Web ページへの接続が成功すると、次のように［Query Editor］が表示されます。

左側の Navigator ペインで［Table_0］をクリックすると、該当 Web ページ内にある最初の <Table> タグの情報が右側に表示されます（県別の人口が表示されます）。

4. 先頭の行は、総数が表示されていて、今回はこれを利用しないので、次のようにグリッドの左上のセルを右クリックして、［Remove Top Rows］をクリックします。

1

2

1

2

一番左上のセルを右クリック

1

3

4

［Remove Top Rows］ダイアログが表示されたら、［Number of Rows］で「1」と入力して、［OK］ボタンをクリックします。これで、先頭から「1」行分、データを削除することができます。

5. 先頭行が削除されたことを確認したら、［Done］ボタンをクリックします。

これで、Web ページからデータを取り込むことができ、次のように Excel 上にデータが配置されます。

クエリを編集したい場合は、右側の［Query Settings］ペインで［Filter & Shape］ボタ

1

クエリを編集したい場合は、ココをクリック

ンをクリックすれば、再度［Query Editor］を起動することができます。

6. 次に、［挿入］タブを開いて、［Map］から［Launch GeoFlow］をクリックします。

7. これにより、Power Map for Excel（開発コード名：GeoFlow）が起動するので、次のように［都道府県］をチェックします。

［GEOGRAPHY］セクションに［都道府県］が追加されたら、［County］を選択して、［Map It］ボタンをクリックします。

これにより、都道府県ごとに、赤い四角のアイコンが追加されるようになります。

1

2

1

2

3

8. 次に、［2010年］をチェックすると、棒グラフに変わって、2010年の人口データをもとに、棒グラフの長さが変わることが確認できます。

また、右下の「＜」や「＞」ボタンを利用して、角度の調整をすることができます。

1

HIGHT（高さ）に2010年が追加される

角度の調整ができる

マウスをオーバーするとポップアップで情報が表示される

なお、現在の Power Map for Excel は、プレビュー版なので、東京都のデータが三宅島付近に表示されてしまうなど、一部のデータが適切な場所に表示されません。

9. 次に、［1920年］をチェックして、［Clustered］をチェックします。

これで、1920年と 2010年の人口を比較した棒グラフを作成することができます。

10. そのほか、［Themas］でテーマ（スタイル）を変更したり、［Data Shape］でグラフの図形を変更したりすることもできます。

11. ［CHART TYPE］では、［Column］（棒グラフ）、［Bubble］（円グラフ）、［HeatMap］（ヒートマップ）などを選択して、グラフの種類を変更することもできます。

1

HIGHT（高さ）に1920年が追加される

2

テーマの変更

「四角」を「丸」に変更したりできる

［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）を受賞。