[B31,32]SQL Server Internal とパフォーマンスチューニングｂｙ Yukio Kumazawa

SQL Server Internal と
パフォーマンスチューニング
Part I & II : Level 400 +
2013.11.15 10:00 – 11:45
日本マイクロソフト株式会社
SQL Server 技術顧問
熊澤幸生

2014

Agenda
•
•
•
•
•

SQL Server のこれまでとシステム基盤の変化
仮想環境上の SQL Server 構築
SQL Server の内部構造と SQLOS の役割
SQL Server のメモリー管理
第四世代 SQL Server RDB エンジン
•
•
•
•

インメモリー処理
データベース格納構造とラッチの見直し
ロック処理の見直し
フラッシュメモリー SSD への対応

• チューニングの要点
• まとめ

© 2013 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.
Microsoft makes no warranties, express or implied in this presentation.

2014

SQL Server の歴史
• 第一世代 1994 - 1998

• SQL Server 4.2 / 6.0 / 6.5

o Sybase 社から技術提供を受け、Windows NT Server 上に移植
–

2KB/ページ 16KB/エクステントページロック

• 第二世代 1998 - 2005

• SQL Server 7.0 / 2000

o Dr. Jim Gray / Dave Campbell 氏らを迎えアーキテクチャを刷新
–
–
–

8KB/ページ 64KB/エクステント行ロックの導入
SQLOSの採用
Analysis Service / ETL の提供開始 / XML のサポート

• 第三世代 2005 - 2012

• SQL Server 2005 / 2008 / 2008R2
o
o
o
o
o
o
o

IA32 から x64 への移行
NUMA アーキテクチャの拡張
クエリー並列処理機能の強化
動的管理ビューによる内部動作と問題点の可視化
ラージオブジェクト格納への対応
BI 機能の強化
パラレル・データ・ウェアハウス

• 第四世代 2012 -

• SQL Server 2012

o Non Clustered ColumnStore Index
–

Read Only

o Always On : HA DR 機能の強化
o Power View : Self Service BI 機能の強化
o FileTable : NTFSファイルとディレクトリの統合

• SQL Server 2014

o Clustered Columnstore Index
–

Insert / Update / Delete が透過的に処理可能

o インメモリー OLTP (Hekaton)
o SSD バッファープール拡張機能


2014

システム基盤の環境変化
• マルチコア化とインメモリー処理へのサーバー側の対応

• 次世代 Xeon Processer 15 物理コア / ソケット 45MB L3 キャッシュ

o 4 ソケット 60 物理コア・120 論理コア / 8 ソケット 120 物理コア・240 論理コア
– ハイパースレッドによる論理コア利用の可否

• Windows Server としての対応
o 仮想化と NUMA

– ハイパースレッド設定の可否 (BIOS レベル)
– ホスト側設定パラメータとゲスト側設定パラメータ

o Cloud OS

• SQL Server : OLTP / ETL / DWH / OLAP / Reporting

• クライアントアプリケーションの並列処理とインメモリー化への対応

• Excel Add on ツール群 : Power View / Power Pivot / Power BI for Office 365

• 磁気ディスクからSSD フラッシュストレージへのシフト
• 5 年後にはサーバー上の磁気ディスクは消滅 ?

• 次世代DBMSの動向
•
•
•
•

データ格納構造の変化
OLTP 内部のラッチ処理とロック処理の見直し
オプティマイザーによる並列実行プランの生成
Insert 処理の並列処理化

• ネットワーク帯域の高速化

• InfiniBand による高速化 (30GBit / sec)
• 最もクリティカルなボトルネックとなる


2014

NUMA ノード上の Windows Server と Hyper-V (1)
• メモリーアクセスが、ローカルとリモートにまたがり、効率が悪い
• SQL Server は、SMP マシンとして認識する
SQL Server
仮想 Windows Server & Hyper-V Guest

Windows Server & Hyper-V Host
物理
コア
1

物理
コア
2

物理
コア
3

物理
コア
4

物理
コア
5

物理
コア
6

物理
コア
7

物理
コア
8

物理
コア
1

物理
コア
2

物理
コア
3

物理
コア
4

物理
コア
5

物理
コア
6

CPU ソケット 1

CPU ソケット 2

NUMA ノード 0

NUMAノード1

ローカルメモリー

物理
コア
7



2014

物理
コア
8

• メモリーアクセスは、ローカルのみで効率が良い
• Aligned on NUMA Node boundary 機能を提供

• SQL Server は、SMP マシンとして認識する

SQL Server

SQL Server

仮想 Windows
Server & Hyper-V
Guest

仮想 Windows
Server & Hyper-V
Guest

物理
コア
1

物理
コア
2

物理
コア
3

物理
コア
4

物理
コア
5

物理
コア
6

物理
コア
7

物理
コア
8

物理
コア
1

物理
コア
2

物理
コア
3

物理
コア
4

物理
コア
5

物理
コア
6

CPU ソケット 1

CPU ソケット 2

NUMA ノード 0

NUMAノード1


物理
コア
7



2014

物理
コア
8

• SQL Server は、仮想環境上で NUMA を利用可能
• Windows Server 2012 Hyper-V V-NUMA で実現した
• SQL Server は、NUMA を認識し、最適化を行う

SQL Server

SQL Server

仮想 Windows Server & Hyper-V Guest

仮想 Windows Server & Hyper-V
Guest

物理
コア
1

物理
コア
2

物理
コア
3

物理
コア
4

物理
コア
5

物理
コア
6

物理
コア
7

物理
コア
8

物理
コア
1

物理
コア
2

物理
コア
3

物理
コア
4

物理
コア
5

物理
コア
6

物理
コア
7

物理
コア
8

CPU ソケット 1

CPU ソケット 2

CPU ソケット 3

CPU ソケット 4

NUMA ノード 0

NUMA ノード 1

NUMA ノード 0

NUMA ノード 1






2014

仮想環境上の SQL Server OLTP 構築の留意点
• NUMA アライン境界内にゲスト環境を構築する
• SQL Server の NUMA によるスケールアウト機能が犠牲になる場合
がある
• ストレージ・サブシステムが最大のボトルネックになる場合が多い
• フラッシュ・メモリーを搭載するストレージ・サブシステムを考慮する

• ホスト上の物理的な CPU コア数、メモリー容量を超える、オーバー
コミット環境の仮想化は禁物
• SQL Server の機能である、リソース・ガバナー機能活用を検討
• パーティショニング可能な共有資源
o NUMA ノード ( CPU ソケット単位の割り当て)
o NUMA ノード ( ローカルメモリーの割り当て)
o ストレージ・サブシステムの I/O 帯域

• BIOS / Windows Server の省電力オプションはすべて Disable に
設定


2014

SMP 上でのマルチユーザ処理


2014

NUMA 環境 4 ソケット 40 物理コアハイパースレッド


2014

SQLOS とは ?
• SQL Server 7.0 / SQL Server 2000 で
UMS (ユーザモド・スケジューラ) として誕生
• UMS を SQL Server 2005 で機能拡張し、 SQLOS が誕生
• 二つの DLL (SQLDK.DLL & SQLOS.DLL) から構成されるエンジン
• Windows OS 上のサービスとは異なる
• 多くのデータ構造から構成される
• SQLOS は抽象化層
• 開発者向けに SQLOS API を提供
• オペレーティングシステムと SQL Server を関連付けするインターフェース

•
•
•
•

RDBMS から独立している
スケーラブル、かつ、NUMA 機能をフルに活用する
サイズは小さく、かつ、最適化されている
Windows API を利用して機能拡張を行っている
• マイクロソフトで最も優秀な開発技術者の集団でチーム構成


2014

SQL Server 2012 の内部構造
SQLSERVER.EXE

.NET
Query
Processor
実行

clr.dll

CHECKPOINT
LazyWriter
LockMonitor
実行

sqlserver.exe
sqllang.dll
30 MB

SQL Server 2012 以前
61 MB
SQL Server 2012
190 KB

XEvent

Monitors

I/O
Completion
Port

CLR Hosts

SQLDK.DLL
2 MB

sqlmin.dll
30 MB

SQLOS

NUMA
Scheduling
Services

Memory
Services

SQLOS.DLL
25 KB

Windows OS

2014

SQL Server 主要機能
Network Protocol
MS DTC (Distributed Transaction Coordinators )

SQL OS API

Query Processor (Relational Engine)
Parser

Transaction Services

File Manager
Buffer Manager

SQL Manager

Storage Engine
Utility:

BCP
DBCC
Backup/Restore

DB Manager

Query Executer

Access Methods Manager:
Row Operations
Indexes
Pages
Allocation
Versions

SQL OS API
SQL OS

Resource Monitor
Lazy Writer

Lock
Manager

Buffer Memory
Synchronization
Scheduling
Manager
Pool
Services
Schedule Monitor

I/O

SQLOS Hosting API

Deadlock Monitor

External Components (CLR/MDAC)

Lock Manager

Optimizer

2014

SQL Server 構成パラメータ
name

minimum

access check cache bucket count
access check cache quota
Ad Hoc Distributed Queries
affinity I/O mask
affinity mask
affinity64 I/O mask

0
0
0
-2,147,483,648
-2,147,483,648
-2,147,483,648

affinity64 mask
Agent XPs
allow updates
backup checksum default

-2,147,483,648
0
0
0

backup compression default
blocked process threshold (s)

0
0

c2 audit mode
clr enabled
common criteria compliance
enabled
contained database authentication
cost threshold for parallelism
cross db ownership chaining
cursor threshold
Database Mail XPs

0
0

maximum config_value run_value name
minimum
maximum config_value
run_value
max degree of
65,536
0
0 parallelism
0
32,767
1
1
2,147,483,647
0
0 max full-text crawl range
0
256
4
4
1
0
0 max server memory (MB)
128 2,147,483,647 2,147,483,647 2,147,483,647
2,147,483,647
0
0 max text repl size (B)
-1 2,147,483,647
65,536
65,536
2,147,483,647
0
0 max worker threads
128
65,535
0
0
2,147,483,647
0
0 media retention
0
365
0
0
min memory per query
2,147,483,647
0
0 (KB)
512 2,147,483,647
1,024
1,024
1
0
0 min server memory (MB)
0 2,147,483,647
0
16
1
0
0 nested triggers
0
1
1
1
1
0
0 network packet size (B)
512
32,767
4,096
4,096
Ole Automation
1
0
0 Procedures
0
1
0
0
86,400
0
0 open objects
0 2,147,483,647
0
0
optimize for ad hoc
1
0
0 workloads
0
1
1
1
1
0
0 PH timeout (s)
1
3,600
60
60

0
1
0
1
0
32,767
0
1
-1 2,147,483,647
0
1

0
0
5
0
-1
0

0 precompute rank
0 priority boost
5 query governor cost limit
0 query wait (s)
-1 recovery interval (min)
0 remote access
remote admin
default full-text language
0 2,147,483,647
1,041
1,041 connections
default language
0
9,999
3
3 remote login timeout (s)
default trace enabled
0
1
1
1 remote proc trans
disallow results from triggers
0
1
0
0 remote query timeout (s)
EKM provider enabled
0
1
0
0 Replication XPs
filestream access level
0
2
0
0 scan for startup procs
fill factor (%)
0
100
0
0 server trigger recursion
ft crawl bandwidth (max)
0
32,767
100
100 set working set size
ft crawl bandwidth (min)
0
32,767
0
0 show advanced options
ft notify bandwidth (max)
0
32,767
100
100 SMO and DMO XPs
ft notify bandwidth (min)
0
32,767
0
0 transform noise words
index create memory (KB)
704 2,147,483,647
0
0 two digit year cutoff
in-doubt xact resolution
0
2
0
0 user connections
lightweight pooling
0
1
0
0 user options
locks
5,000 2,147,483,647
0
0 xp_cmdshell

0
1
0
1
0 2,147,483,647
-1 2,147,483,647
0
32,767
0
1

0
0
0
-1
0
1

0
0
0
-1
0
1

0
1
0 2,147,483,647
0
1
0 2,147,483,647
0
1
0
1
0
1
0
1
0
1
0
1
0
1
1,753
9,999
0
32,767
0
32,767
0
1

0
10
0
600
0
0
1
0
1
1
0
2,049
0
0
0

0
10
0
600
0
0
1
0
1
1
0
2,049
0
0
0

2014

SQLOS / SQL Server と非同期 I/O
• SQL Server は、データページをストレージから読み取り実施時に
非同期 I/O 機能を利用する
• テーブルスキャン処理では、 Read Ahead 処理を用いて高速化する

• SQLOS は非同期 I/O 処理のメカニズムを提供する
• SQL Server はSQLOS に非同期 I/O を要求し完了割り込み通知を待つ
• 非同期 I/O のスケジューリング中は、すべての非同期 I/O の状況を SQLOS
が管理する
• SQL Server のワーカースレッドは、非同期 I/O 処理待ち以外のユーザの処理
を行う

• SQLOS は、処理中の非同期 I/O の一覧表により管理する
• DMV sys.dm_io_pending_io_requests により非同期 I/O 処理中一覧を参照
できる
• 表示されるのは、一瞬のスナップショットの情報である
• レイテンシーの発生している物理ファイルを発見できる可能性がある


2014

sys.dm_io_pending_io_requests 実行結果

io_completion_request io_
_address
type

io_pending_m
s_ticks
io_pending

io_completio
n_routine_ad io_user_data_
dress
address
io_offset

0x00000000085CA790 disk

2

0x000007FEE 0x00000004E
1 C6E9E00
F4C0CC0

0x00000000085CA268 disk

2

0x000007FEE 0x00000004E
1 C6E9E00
F4C3CC0

0x00000000085CA688 disk

2

0x000007FEE 0x00000004E
1 C6E9E00
F4C6CC0

0x00000000085C9A28 disk

2

0x000007FEE 0x00000004E
1 C6E9E00
F4C9CC0

0x00000000085CA580 disk

2

0x000007FEE 0x00000004E
1 C6E9E00
F4CCCC0

0x00000000085CA478 disk

2

0x000007FEE 0x00000004E
1 C6E9E00
F4CFCC0

0x00000000085CA160 disk
netwo
0x00000004E45C1AE8 rk

2

8,621,414

0x000007FEE 0x00000004E
1 C6E9E00
F4D2700
0x000007FEE 0x00000004E
1 AAED5B0
45C1AE8

io_handle_path
¥¥?¥C:¥ProgramFiles¥Microsoft SQL
Server¥MSSQL12.SQL2014CTP2¥MSSQL¥D
2,118,123,520 ATA¥AdventureWorks_Data.mdf


0 NULL

2014

SQL Server のシステムプロセス
spid SQL User
Status
Last Command
1 sa
background
RESOURCE MONITOR
2 sa
background
RESOURCE MONITOR
3 sa
background
RESOURCE MONITOR
4 sa
background
RESOURCE MONITOR
5 sa
background
RESOURCE MONITOR
6 sa
background
RESOURCE MONITOR
7 sa
background
RESOURCE MONITOR
8 sa
background
RESOURCE MONITOR
9 sa
background
LAZY WRITER
10 sa
background
LAZY WRITER
11 sa
background
LAZY WRITER
12 sa
background
LAZY WRITER
13 sa
background
LAZY WRITER
14 sa
background
LAZY WRITER
15 sa
background
LAZY WRITER
16 sa
background
LAZY WRITER
17 sa
runnable
LOG WRITER
18 sa
background
LOCK MONITOR
19 sa
background
SIGNAL HANDLER
20 sa
sleeping
TASK MANAGER
21 sa
background
TRACE QUEUE TASK
22 sa
sleeping
UNKNOWN TOKEN
23 sa
sleeping
TASK MANAGER
24 sa
suspended
CHECKPOINT
25 sa
background
TASK MANAGER
26 sa
background
BRKR EVENT HNDLR
27 sa
sleeping
TASK MANAGER
28 sa
sleeping
TASK MANAGER
29 sa
sleeping
TASK MANAGER
30 sa
background
BRKR TASK
31 sa
background
BRKR TASK
32 sa
sleeping
TASK MANAGER
33 sa
sleeping
TASK MANAGER
36 sa
sleeping
TASK MANAGER
37 sa
sleeping
TASK MANAGER

2014

SQLOS の監視方法とサービス (1)
• リソースモニター
• メモリー利用状況のチェックを行う
o QueryMemoryResourceNotification Windows API を利用して物理メモリーの利用状況を
取得
o 仮想メモリー空間と仮想メモリー利用状況をチェックする
o SQL Server のメモリー利用状況をチェックする
o ワーキング・セットの大きさを削減する必要があるかを判断する
o SQL Server が確保しているメモリーサイズを (削減、増加、安定化) の判断を行う

• I/O 処理の失速を監視する (エラーメッセージ 833)
• メモリーブローカー機能を提供する
o SQL Server = Procedure Cache + Compile + Query Working Memory

• 下記の状態を監視する機能を提供
o Sys.dm_or_ring_buffers
o Sys.dm_os_sys_memory, sys.dm_os_process_memory, DBCC MEMORYSTATUS
o XEvent


2014

SQLOS の監視方法とサービス (2)
• スケジュールモニター
• 特徴
o NUMA ノード単位に存在する
o 常時起動のノン・プリエンプティブ型タスク (5 秒毎にトリガー)

• 自分のノード内で稼働中のスケジューラの状態を監視する
o スケジューラがスイッチング不可能状態かの監視を行う
– Non-yielding Scheduler

o すべてのスケジューラが停止状態かつメモリープレッシャーは発生していない
– Deadlock Scheduler

o I/O 完了ポートが無応答状態
o リソースモニターが無応答状態
o いづれかのモニターが問題発生を検知
– SQLOS は SQL Server を呼び出す

• 状態の監視手段
o
o
o
o

sys.dm_os_ring_buffers
XEvent ring buffer
トレースフラグ T8022 により ERRORLOG に記録可能
SQL Server 2012 で提供する新しい XEvent により、障害発生を知ることができる
– 例) deadlock_schediuler_callback_executed


2014

その他のシステムプロセス
• Checkpoint
• トランザクション処理とは非同期に、バックグラウンドでバッファープール上
のダーティ・ページ (更新済みページ) を、データベースデータファイルに
書き込み処理 (バッファーフラッシュ) を行う

• Lazy Writer
• NUMA ノード毎に起動され、リソースモニターからの要求 (Windows OS の
メモリー枯渇時) により、バッファープール上のページを、一括処理で
メモリーマネージャに返却処理を行う

• Log Writer
• メモリー上の論理ログファイルの内容を、物理トランザクションログファイル
に、先行書き込みを行う

• Lock Monitor
• デッドロック発生を検知する


2014

SQLOS の提供するメモリーサービス
• SQLOS ベースのメモリーサービス
• NUMA のサポート
• ワークスペース、フラグメント管理、ブロックアロケータ、
仮想メモリーアロケータ
• メモリークラーク
• メモリーオブジェクト
• キャッシュストア、ユーザストア、オブジェクトストア
• メモリープール
• リソース管理 (リソース・ガバナー)
• メモリーブローカー (プロシージャ・キャッシュ、
コンパイル済み実行プラン、クエリー実行時のメモリー領域)

• SQL Server 2012 からメモリー管理アーキテクチャを変更した


2014

SQL Server 2008 R2 までのメモリー管理
NUMA
Memory Node
Plan Cache

Memory
Object

Memory Allocators

Optimizer

Backup Buffers

Database
Page
Cache

Memory
Clerk

Single
Page
Allocator

Buffer
Pool


Multi
Page
Allocator

Virtual
Allocator

VirtualAlloc and
AWE API
2014

SQL Server 2012 以降のメモリー管理
NUMA
Memory Node
Plan Cache

Memory
Object

Memory Allocators

Optimizer

Database
Page
Cache

Memory
Clerk

Fragment
Manager

Virtual
Allocator

Backup Buffers

Workspaces

Block
Allocator

Buffer Pool
Memory
Clerk


VirtualAlloc and
AWE API
2014

メモリーマネージャの変更理由
• すべてのメモリー管理を統一性のあるモデルに変更した
• マルチページコンセプトの廃止
• max server memory パラメータを、真の max server memory に
変更
• MemoryToReserve 領域 (–G 起動パラメータ領域サイズ指定)
o SQL Server 2008 R2 まで
– 拡張ストアドプロシージャ
– CLR 用領域
– 複数の 8KB ページを利用するメモリーオブジェクト

o SQL Server 2012 以降
– 拡張ストアドプロシージャ
– CLR 用領域

• この他に、 max server memory に含まれない領域
o ワーカースレッドスタック領域

• すべてのリソースガバナーが、リソースプール内の仮想的な
バッファープール領域を制御可能とするため


2014

メモリー領域の確保オプション
• VirtualAlloc API を利用する
•
•
•
•

Conventional memory in the memory manager
メモリーチューニングオプションは無指定
複数ページに渡る大きなサイズのメモリーを確保できる
NUMA を認識したメモリー確保を行う

• AWE API を利用する
• メモリーチューニングオプション
o AWE 機能を有効にする
(SQL Server 2012 から sp_configure AWE Enabled オプションは利用できなくなった)
o SQL Server サービス起動アカウントにメモリー内ページロック権限を付与

• ページングの対象外
• NUMA を認識したメモリー確保を行う

• Large Pages を利用する
• Locked pages in the memory manager
• メモリーチューニングオプション
o SQL Server サービス起動アカウントにメモリー内ページロック権限を付与

• VirtualAlloc with MEM_LARGE_PAGES を利用する
• 2 MB 以上のサイズのメモリーを確保する
• NUMA を認識したメモリー確保を行う

2014

メモリー内ページロック権限の設定


2014

Conventional memory in the memory manager
• Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks
per node.
• Node configuration: node 0: CPU mask: 0x000000000000000f:0 Active CPU mask:
0x000000000000000f:0. This message provides a description of the NUMA configuration for this
computer.
• This instance of SQL Server last reported using a process ID of 6792 at 2013/11/07 14:51:16
(local) 2013/11/07 5:51:16 (UTC).
• The maximum number of dedicated administrator connections for this instance is '1'
• Query Store settings initialized with enabled = 1<c />
• Default collation: Japanese_CI_AS (日本語 1041)
• Using conventional memory in the memory manager.
• Detected 16079 MB of RAM.
• SQL Server is starting at normal priority base (=7).
• SQL Server detected 1 sockets with 2 cores per socket and 4 logical processors per socket<c /> 4
total logical processors; using 4 logical processors based on SQL Server licensing.
• Command Line Startup Parameters:<nl/> -s "SQL2014CTP2"
• The service account is 'NT Service¥MSSQL$SQL2014CTP2'.
• Logging SQL Server messages in file 'C:¥Program Files¥Microsoft SQL
Server¥MSSQL12.SQL2014CTP2¥MSSQL¥Log¥ERRORLOG'.
• Authentication mode is WINDOWS-ONLY.
• System Manufacturer: 'LENOVO'<c /> System Model: '2306AJ5'.
• Server process ID is 2932.
• All rights reserved.
• (c) Microsoft Corporation.
• UTC adjustment: 9:00
• Microsoft SQL Server 2014 (CTP2) - 12.0.1524.0 (X64)Enterprise Evaluation Edition (64-bit) on
Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

2014

Locked pages in the memory manager
• Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks
per node.
• Node configuration: node 0: CPU mask: 0x000000000000000f:0 Active CPU mask:
0x000000000000000f:0. This message provides a description of the NUMA configuration for this
computer.
• This instance of SQL Server last reported using a process ID of 2932 at 2013/11/07 15:10:57
(local) 2013/11/07 6:10:57 (UTC).
• The maximum number of dedicated administrator connections for this instance is '1'
• Query Store settings initialized with enabled = 1<c />
• Default collation: Japanese_CI_AS (日本語 1041)
• Large Page Allocated: 32MB
• Using locked pages in the memory manager.
• Detected 16079 MB of RAM.
• SQL Server is starting at normal priority base (=7).
• SQL Server detected 1 sockets with 2 cores per socket and 4 logical processors per socket<c /> 4
total logical processors; using 4 logical processors based on SQL Server licensing.
• Command Line Startup Parameters:<nl/> -s "SQL2014CTP2"
• Registry startup parameters: <nl/>
-d C:¥Program Files¥Microsoft SQL
Server¥MSSQL12.SQL2014CTP2¥MSSQL¥DATA¥master.mdf<nl/>
-e C:¥Program
Files¥Microsoft SQL Server¥MSSQL12.SQL2014CTP2¥MSSQL¥Log¥ERRORLOG<nl/>
-l
C:¥Program Files¥Microsoft SQL Server¥MSSQL12.SQL2014CTP2¥MSSQL¥DATA¥mastlog.ldf
• The service account is 'YKUMA06¥ykuma'. This is an informational message; no user action is
required.
• Logging SQL Server messages in file 'C:¥Program Files¥Microsoft SQL
Server¥MSSQL12.SQL2014CTP2¥MSSQL¥Log¥ERRORLOG'.
• Authentication mode is WINDOWS-ONLY.
• System Manufacturer: 'LENOVO'<c /> System Model: '2306AJ5'.
• Server process ID is 4644.
• All rights reserved.(c) Microsoft Corporation.

2014

メモリー・クラークのパーティショニング例
• バッファープール、プロシージャキャッシュ、クエリー実行領域、
ユーザコネクション領域、インメモリー OLTP テーブル領域等に
分割管理されている
type
MEMORYCLERK_SQLGENERAL
MEMORYCLERK_SQLBUFFERPOOL
MEMORYCLERK_SQLQUERYCOMPILE
MEMORYCLERK_SQLQUERYPLAN
MEMORYCLERK_SQLQUERYEXEC
MEMORYCLERK_SQLOPTIMIZER
MEMORYCLERK_QUERYDISKSTORE
MEMORYCLERK_SQLUTILITIES
MEMORYCLERK_SQLSTORENG
MEMORYCLERK_SQLCONNECTIONPOOL
MEMORYCLERK_SQLCLR
MEMORYCLERK_SQLCLRASSEMBLY
MEMORYCLERK_SQLSERVICEBROKER
MEMORYCLERK_SQLXML
MEMORYCLERK_SQLHTTP
MEMORYCLERK_SQLSOAP
MEMORYCLERK_SQLSOAPSESSIONSTORE
MEMORYCLERK_SNI
MEMORYCLERK_SERIALIZATION
MEMORYCLERK_FULLTEXT
MEMORYCLERK_SQLXP
MEMORYCLERK_QSRANGEPREFETCH
MEMORYCLERK_BHF
MEMORYCLERK_SQLQERESERVATIONS
MEMORYCLERK_XE_BUFFER
MEMORYCLERK_TRACE_EVTNOTIF
MEMORYCLERK_XTP

name
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default
Default


memory_node_id pages_kb
0
6,536
0
30,352
0
0
0
0
0
56
0
984
0
256
0
80
0
6,584
0
1,200
0
10,928
0
0
0
448
0
0
0
8
0
0
0
0
0
24
0
0
0
312
0
16
0
0
0
0
0
0
0
0
0
0
0
3,104

2014

メモリー・ブローカ・クラークのパーティショニング例
• 通常ページとインデックス用バッファープールと、
BLOB ページ用カラムストアバッファープールを別領域として保
持可能

clerk_name

total_kb simulated_kb simulation_benefit

internal_benefit

external_benefit

value_of_memory

periodic_freed_kb

internal_freed_kb

Column store object pool

71,200

0

0

0

0

0

0

0

Buffer Pool

55,864

0

0

0

0

0

0

0


2014

メモリー・ブローカーのパーティショニング例
• インメモリー OLTP 専用の領域がブローカーにより確保されている
• MEMORYBROKER_FOR_XTP
pool_id memory_broker_type

Allocations
_kb

predicted_allocations
_kb

target_allocations
_kb

future_allocations
_kb

1 MEMORYBROKER_FOR_CACHE

12,352

12,352

9,091,208

0

1 MEMORYBROKER_FOR_STEAL

56,072

56,072

9,134,928

0

0

0

9,078,856

0

195,608

195,608

9,274,464

0

0

0

9,078,856

0

3,424

3,424

9,082,280

0

21,448

21,448

9,100,304

0

424

424

9,079,280

0

2 MEMORYBROKER_FOR_RESERVE

0

2,293,560

10,300,928

2,293,560

2 MEMORYBROKER_FOR_HASHED_DATA_PAGES

0

0

9,078,856

0

546,768

546,768

9,625,624

0

1 MEMORYBROKER_FOR_RESERVE
1 MEMORYBROKER_FOR_COMMITTED
1 MEMORYBROKER_FOR_HASHED_DATA_PAGES
1 MEMORYBROKER_FOR_XTP
2 MEMORYBROKER_FOR_CACHE
2 MEMORYBROKER_FOR_STEAL

2 MEMORYBROKER_FOR_XTP


2014

dbcc memorystatus 出力
MEMORYCLERK_SQLQUERYEXEC (node 0)
KB
---------------------------------------- ----------VM Reserved
0
VM Committed
0
Locked Pages Allocated
0
SM Reserved
0
SM Committed
0
Pages Allocated
56

Memory Manager
KB
---------------------------------------- ----------VM Reserved
35,670,564
VM Committed
823,752
0
Large Pages Allocated
0
Emergency Memory
1,024
Emergency Memory In Use
16
Target Committed
12,962,160
Current Committed
823,752
Pages Allocated
685,552
Pages Reserved
0
Pages Free
11,688
Pages In Use
766,072
Page Alloc Potential
14876352
NUMA Growth Phase
0
Last OOM Factor
0
Last OS Error
0

MEMORYCLERK_SQLOPTIMIZER (node 0)
KB
---------------------------------------- ----------VM Reserved
0
VM Committed
0
0
SM Reserved
0
SM Committed
0
Pages Allocated
984

Memory node Id = 0
KB
---------------------------------------- ----------VM Reserved
35,670,500
VM Committed
823,732
0
Pages Allocated
685,552
Pages Free
11,688
Target Committed
12,962,136
Current Committed
823,736
Foreign Committed
0
Away Committed
0
Taken Away Committed
0
MEMORYCLERK_SQLBUFFERPOOL (node 0)
---------------------------------------- ----------VM Reserved
12,261,500
VM Committed
17,680
0
SM Reserved
0
SM Committed
0
Pages Allocated
46,032

KB

MEMORYCLERK_SQLSTORENG (node 0)
KB
---------------------------------------- ----------VM Reserved
576
VM Committed
576
0
SM Reserved
0
SM Committed
0
Pages Allocated
6,856


2014

dbcc memorystatus 出力 (メモリー内ページロック)
MEMORYCLERK_SQLQUERYEXEC (node 0)
KB
---------------------------------------- ----------VM Reserved
0
VM Committed
0
0
SM Reserved
0
SM Committed
0
Pages Allocated
56

Memory Manager
KB
---------------------------------------- ----------VM Reserved
35,737,936
VM Committed
191,676
840,592
Large Pages Allocated
116,736
Emergency Memory
1,024
Emergency Memory In Use
16
Target Committed
12,851,072
Current Committed
1,032,272
Pages Allocated
770,520
Pages Reserved
0
Pages Free
66,144
Pages In Use
839,064
Page Alloc Potential
14,803,360
NUMA Growth Phase
0
Last OOM Factor
0
Last OS Error
0

MEMORYCLERK_SQLOPTIMIZER (node 0)
KB
---------------------------------------- ----------VM Reserved
0
VM Committed
0
0
SM Reserved
0
SM Committed
0
Pages Allocated
984

Memory node Id = 0
KB
---------------------------------------- ----------VM Reserved
35,737,872
VM Committed
191,656
840,592
Pages Allocated
770,520
Pages Free
66,144
Target Committed
12,851,048
Current Committed
1,032,248
Foreign Committed
0
Away Committed
0
Taken Away Committed
0
MEMORYCLERK_SQLBUFFERPOOL (node 0)
---------------------------------------- ----------VM Reserved
12,261,500
VM Committed
16,384
3,104
SM Reserved
0
SM Committed
0
Pages Allocated
57,920

KB

MEMORYCLERK_SQLSTORENG (node 0)
KB
---------------------------------------- ----------VM Reserved
640
VM Committed
0
640
SM Reserved
0
SM Committed
0
Pages Allocated
6,584


2014

第四世代 SQL Server RDB (1)
• インメモリー機能の活用
• インメモリー OLTP エンジン
o インデックス情報とデータをメモリー上に保持する
o 従来のバッファーキャッシュとは異なる

• カラムストアーインデックス
o
o
o
o

DWH の不定型検索処理や集計処理に最適
ビットマップインデックスの採用
データ圧縮機能によりインメモリー化に貢献
カラム(列)単位の検索処理と集計処理を、インメモリーテクノロジーを活用し、高速化する
– バッチ処理モード
– 従来の統計情報を利用しない実行プランの生成

• 導入されたテクノロジー
o SQL Server 2012
– 従来型の行ストア型テーブルに、非クラスタカラムストアインデックスを付与する

o SQL Server 2014
– ヒープ構造のテーブルを、直接クラスタカラムストアインデックスに変換する


2014

OLTP エンジン待機時間 (レイテンシー) の詳細


2014

パフォーマンス向上のポイント
Client App
TDS Handler and Session Management

通信、パラメータ処理、
結果セット作成の部分
では変化なし

10-30倍高速

ログ書き込みに
必要なIOバンド幅、
競合の低減

チェックポイントは
バックグラウンドの
シーケンシャルIO

Hekaton
Compiler
Natively
Compiled
SPs and
Schema

Hekaton Engine for
Memory_optimized
Tables & Indexes

Key

Proc /Plan cache for
ad-hoc T-SQL and SPs

既存の
SQL
Server

Interpreter for TSQL,
query plans,
expressions

コンポーネント

Access Methods

Parser,
Catalog,
Algebrizer,
Optimizer

生成された
.dll

Hekaton

Query
Interop
Buffer Pool for Tables
& Indexes
SQL Server.exe

Memory36
Transaction Log
optimized Table
Filegroup
All rights reserved. This presentation is for informational purposes only.

© 2013 Microsoft Corporation.

Data Filegroup

2014

インメモリ OLTP
アプリケーション
SQL Server に統合され、最新ハードウェア
のトレンドに合わせて設計された新しい高パ
フォーマンスのメモリ最適化 OLTP エンジン
SQL Server リレーショナルデータベース
に統合
完全な ACID サポート
メモリ最適化インデックス
(B ツリーおよびバッファープールなし)
ブロック不可マルチバージョン
オプティミスティック同時実行制御
(ロック/ラッチなし)
ネイティブコードにコンパイルされた
T-SQL
お客様の利点:
•
短い待機時間
•
最大 10 倍のパフォーマンス向上
•
2 ～ 5 倍のスケーラビリティ向上
•
SQL Server の投資を活用

SIP (株式情報処理) –高ボリュームのリ
アルタイム取引データを取り、売買が終
わった後に市場株式価格を公開。待機時
間は 0.5 ミリ秒以下であることが要求さ
れる。

インメモリ OLTP ソリューション
テーブル上の競合がなく、ネイティブに
コンパイルされたコードからのパス長が
短いので、アプリケーションは 0.4 ミリ
秒の予測可能なエンドツーエンドの待
機時間を達成
待機時間 (ミリ秒)

SQL Server

待機時間 (ミリ秒)

2008 SP1
SQL Server
2014

0
0.5

1

1.5

2014

PASS Summit 2013 at Charlotte


2014

PASS Summit 2013 Hekaton 早期導入ユーザ紹介


2014

SBI リクイディティマーケット様事例
• http://www.microsoft.com/casestudies/Case_Study_Detail.aspx
?CaseStudyID=710000003429


2014

カラムストアインデックスの進化
• SQL Server 2012 で非クラスタ化カラムストアインデックスを提供
• 従来型のクラスタ化インデックスを持つテーブルに設定可能
• DWH 業務の非定型型の集計や検索処理が飛躍的にスピードアップ
• 非クラスタ化カラムストアインデックスを付与したテーブルは、検索処理専用で、
直接更新処理はできない
o バッチ処理等でデータ追加後に、非クラスタ化カラムストアインデックスの再作成が必要

• テーブル使用領域が大きくなる
o 従来のクラスタ化インデックス領域 + 非クラスタ化カラムストアインデックス領域

• SQL Server 2014 でクラスタ化カラムストアインデックスを提供
• ヒープ構造のテーブルをクラスタ化カラムストアインデックスに変換
• データ圧縮機能によりテーブル使用領域が小さい
• リアルタイムに透過的な更新処理が可能
o Insert 処理 : 新たなパーティション内に追加
o Update 処理 : Delete + Insert 処理
o Delete 処理 : 行に削除フラグを設定する

• 定期的にインデックスの再構築を実施する

• カラムストアインデックスは、ビットマップインデックスを利用
• インデックスの格納は BLOB 領域を利用
• カラムストアインデックスは統計情報を持たない

2014

カラム・ストアーの考え方
CPU
Core1

CPU
Core2

CPU
Core3

CPU
Core4

CPU
Core5

CPU
Core6

CPU
Core7

CPU
Core8

CPU
Core9

Core10

L1
L2

L1
L2

L1
L2

L1
L2

L1
L2

L1
L2

L1
L2

L1
L2

L1
L2

L1
L2

CPU

コア・キャッシュ・インターコネクト
30MB
L3 Cache
Intel Xeon E7 シリーズの例

行・オリエンテッド
データストアー

カラム・オリエンテッド
データストアー

キー1 a1

b1

c1

d1

a1

a2

a3

……. an

キー2 a2

b2

c2

d2

b1

b2

null

…….


bn

2014

非クラスタ化とクラスタ化カラムストアインデックス


2014

ColumnStore インデックスの作成

Base table
B

C

D

BLOB
Row
group

データ型
変換と圧縮

データ型
変換と圧縮

Segment
directory

Row group 3 Row group 2Row group 1

A

Column store index

Compressed
column segments

Row
group

Row
group

データ型
変換と圧縮

1,000,000 行 / セグメント

新しいシステムテーブル:
sys.column_store_segments
セグメントメタデータ: サイズ、最小データ id、
最大データ id 等


2014

バッチモード処理

• ソケット内の複数のコアで
並列処理が可能

• フィルター、ハッシュ結合、
ハッシュ集計などを新たにサポート
• CPU 時間の大幅な削減 (7 ～ 40 倍)

バッチオブジェクト
列ベクター

条件を満たす行のビットマップ

• クエリープロセッサー
ベクター演算子を利用
• 一度に約 1,000 行を処理
• ベクター形式で格納されるバッチ
• CPU ソケット内
L3 キャッシュサイズに最適化


2014

bigTransactionHistory14 の DDL
• CREATE TABLE [dbo].[bigTransactionHistory14](
[TransactionID] [int] NOT NULL,
[ProductID] [int] NOT NULL,
[TransactionDate] [datetime] NULL,
[Quantity] [int] NULL,
[ActualCost] [money] NULL
) ON [PRIMARY]
• CREATE CLUSTERED COLUMNSTORE INDEX [ClusteredColumnStoreIndex_BigTranHistory] ON
[dbo].[bigTransactionHistory14] WITH
(DROP_EXISTING = OFF) ON [PRIMARY]
• ヒープ構造のベーステーブルは、 TransactionID 列の値で昇順にソート済み
• テーブル内データ件数 31,263,601 / インデックス作成時間 1 分 23 秒


2014

sys.column_store_segments (セグメント情報)
• min_data_id と max_data_id を参照し、検索セグメントを決定する
column_id segment_id version encoding_type row_count has_nulls
base_id
min_data_id
1
0
1
1
1,048,576
0
-2
1
1
1
1
1
1,048,576
0
29,478,774
29,478,777
1
2
1
1
1,048,576
0
28,112,318
28,112,321
1
3
1
1
1,048,576
0
27,060,751
27,060,754
1
4
1
1
1,048,576
0
26,154,758
26,154,761
1
5
1
1
1,048,576
0
24,975,944
24,975,947
1
6
1
1
1,048,576
0
23,916,675
23,916,678
2
0
1
2
1,048,576
0
-1
1,001
2
1
1
2
1,048,576
0
-1
1,001
2
2
1
2
1,048,576
0
-1
1,001
2
3
1
2
1,048,576
0
-1
1,001
2
4
1
2
1,048,576
0
-1
1,001
2
5
1
2
1,048,576
0
-1
1,001
2
6
1
2
1,048,576
0
-1
1,001
3
0
1
2
1,048,576
0
-1
164,716,290,768,896
3
1
1
2
1,048,576
0
-1
172,996,987,715,584
3
2
1
2
1,048,576
0
-1
172,571,785,953,280
3
3
1
2
1,048,576
0
-1
172,258,253,340,672
3
4
1
2
1,048,576
0
-1
171,966,195,564,544
3
5
1
2
1,048,576
0
-1
171,601,123,344,384
3
6
1
2
1,048,576
0
-1
171,274,705,829,888
4
0
1
2
1,048,576
0
-1
1
4
1
1
2
1,048,576
0
-1
1
4
2
1
2
1,048,576
0
-1
1
4
3
1
2
1,048,576
0
-1
1
4
4
1
2
1,048,576
0
-1
1
4
5
1
2
1,048,576
0
-1
1
4
6
1
2
1,048,576
0
-1
1
5
0
1
4
1,048,576
0
0
0
5
1
1
4
1,048,576
0
0
0
5
2
1
4
1,048,576
0
0
0
5
3
1
4
1,048,576
0
0
0
5
4
1
4
1,048,576
0
0
0
5
5
1
4
1,048,576
0
0
0
5
6
1
4
0
0
0
© 2013 Microsoft Corporation. All rights reserved. 1,048,576
This presentation is for informational purposes only.


max_data_id
31,263,601
31,245,824
30,197,248
29,148,672
28,100,096
27,051,520
26,002,944
50,999
50,999
50,999
50,999
50,997
50,999
50,999
173,508,088,823,808
173,503,793,856,512
173,198,851,178,496
172,893,908,500,480
172,567,490,985,984
172,253,958,373,376
171,914,655,956,992
100
100
100
100
100
100
100
7,014,151,213
7,156,143,655
7,027,283,306
7,144,141,920
7,126,428,747
7,137,000,989
7,096,266,811

on_disk_size
4,194,888
2,796,792
2,796,792
2,796,792
2,796,792
2,796,792
2,796,792
2,097,736
2,097,736
2,097,736
2,097,736
2,097,736
2,097,736
2,097,736
1,408
1,728
1,760
1,800
1,784
1,840
1,800
191,600
320,600
361,488
370,952
388,768
379,240
402,056
4,125,176
5,035,760
5,068,400
5,050,616
5,030,512
5,054,416
5,056,520

2014

ベンチマーク用クエリー
use AdventureWorks
go

SELECT

Production.ProductSubcategory.Name AS Subcategory,
bigProduct.Name AS Product, COUNT(*) AS Transactions,
SUM(bigTransactionHistory14.Quantity) AS Units,
SUM(bigProduct.ListPrice) AS ListPriceRevenue

FROM
bigTransactionHistory14
INNER JOIN
bigProduct ON bigTransactionHistory14.ProductID =
bigProduct.ProductID
INNER JOIN
Production.ProductSubcategory ON
bigProduct.ProductSubcategoryID =
Production.ProductSubcategory.ProductSubcategoryID
GROUP BY
Production.ProductSubcategory.Name, bigProduct.Name
ORDER BY
Subcategory, Product
-- OPTION (MAXDOP 1);
OPTION (MAXDOP 0);


2014

Row Mode 処理と Batch Mode 処理
• 処理時間 Row Mode 22 秒 / Batch Mode 2 秒


2014

クラスタ化カラムストアインデックス Batch Mode
実行プラン


2014

テーブル領域サイズの比較
• クラスタ化カラムストアインデックスの領域サイズは、データ圧縮機能
により、ヒープ構造領域サイズの 24.2 % (約 ¼ )
• クラスタ化インデックスの付与されたテーブルに、非クラスタ化カラム
ストアインデックスを定義すると、26.7 % の領域が増加する
クラスタ化カラムストアインデックスの領域サイズと比較すると、
領域サイズは 21.1 % ( 約 1/5 )

ヒープ構造
クラスタ化インデックス設定
クラスタ化インデックス設定 +
非クラスタ化カラムストアインデックス
クラスタ化カラムストアインデックス

データ領域
サイズ (KB)
1,269,592
1,147,296

インデックス領域
サイズ (KB)
8
1,864

1,269,600
1,149,160

1,147,296

308,648

1,455,944

307,288

0

307,288


合計 (KB)

2014

第四世代 SQL Server RDB (2)
• ラッチ処理の見直し
• ラッチ処理
o 三種類のラッチから構成される
– PageIOLatch
– PageLatch
– Latch

o ストレージエンジン内の処理のシリアライズ処理
– ディスクからバッファープールへのデータ転送非同期処理の完了待ち
– 更新のロストの防止
– データ領域の動的拡張処理の完了待ち

• 次世代データ格納構造の採用
• 従来型データ格納構造
o B-Tree or Heap 構造
o 64KB エクステントと 8KB ページ
o データの追加・削除によりページ分割が発生する
– データページとインデックスページの両方

• 次世代データ格納構造 (SQL Server 2012 - 2014)
o ファイルストリーム型
– インメモリー OLTP (Hekaton)
» インデックス構造の排除
» メモリー展開時に、動的なインデックス情報を付加する

o BLOB型
– ColumnStore Index セグメント構造


2014

データファイルの構造（その他）
• 空き領域を追跡するためのデータ構造体
• PFS(Page Free Space)

• 各ペ－ジ上で利用可能な空き領域に関する情報

• GAM(Global Allocation Map)
• エクステントが割り当て済かどうかの情報
• tempdb 上に、一時テーブル領域を作成するときに
参照・更新される
o トランザクションの同時実行性を損なう場合がある

• SGAM(Shared Global Allocation Map)
• 混合エクステントとして使用されており、
1 ページ以上の未使用ページを含んでいるかどうかの情報

ﾌｧｲﾙ
ﾍｯﾀﾞｰ

PFS

GAM SGAM DCM BCM

デ－タ
ページ

･･･

エクステント

2014

データファイルの構造（ページ/エクステント）
• text、ntext、imageデータ型を除き、
データ行内のすべてのデータはページに格納される

- text、ntext、imageのデータは別のページ
に格納
エクステント(64KB)＝８KB×８page
• 新規のテーブル/インデックスには
混合エクステントからページが割り当てられる

･･･

･･･

- 混合エクステント
最大８つのオブジェクトによってページを
共有
- 単一エクステント
単一のオブジェクトによって所有

･･･

･･･

･･･

･･･

･･･

ペ－ジ（８
KB）
ページヘッダー
デ－タ行

１

デ－タ行２
デ－タ行

３

空き領域
3

2

1

RIDと行オフセット

2014

データページの内容
•
•

BUFFER:
BUF @0x04297F60

•
•
•
•

bpage = 0x07252000
bdbid = 6
bsampleCount = 0
blog = 0x32159

•
•

PAGE HEADER:
Page @0x07252000

•
•
•
•
•
•
•
•
•

m_pageId = (1:50)
m_headerVersion = 1
m_type = 1
m_typeFlagBits = 0x4
m_level = 0
m_flagBits = 0x0
m_objId (AllocUnitId.idObj) = 60
m_indexId (AllocUnitId.idInd) = 1 Metadata: AllocUnitId = 281474980642816
Metadata: PartitionId = 281474980642816
Metadata: IndexId = 1
Metadata: ObjectId = 60
m_prevPage = (1:5035)
m_nextPage = (1:49)
pminlen = 17
m_slotCnt = 19
m_freeCnt = 81
m_freeData = 8073
m_reservedCnt = 0
m_lsn = (508:5479:3)
m_xactReserved = 0
m_xdesId = (0:0)
m_ghostRecCnt = 0
m_tornBits = 1073742850

•
•
•

Allocation Status
GAM (1:2) = ALLOCATED
DIFF (1:6) = CHANGED

•

DATA:

bhash = 0x00000000
breferences = 0
bUse1 = 5274
bnext = 0x00000000

bpageno = (1:50)
bcputicks = 0
bstat = 0xc00009

SGAM (1:3) = NOT ALLOCATED
ML (1:7) = NOT MIN_LOGGED

PFS (1:1) = 0x40 ALLOCATED

• Slot 0, Offset 0x192c, Length 591, DumpStyle BYTE
• Record Type = PRIMARY_RECORD
Record Attributes = NULL_BITMAP VARIABLE_COLUMNS
• Record Size = 591
• Memory Dump @0x5FC2D92C
• 00000000: 30001100 3c2c0000 00020000 00000000 †0...<,..........
• 00000010: 00060000 02002400 4f027f01 01000000 †......$.O.......
• 00000020: 00000000 07000000 2fc0e500 919d0000 †......../A......
• 00000030: 01000000 00000000 01000000 00000000 †................
• 00000040: 00000000 0000803f 0000803f 0000803f †.......?...?...?
• 00000050: 0000803f 00000000 00000000 00000000 †...?............

0_PCT_FULL

2014

SQL Server のインデックス
• インデックスペ－ジに格納
• インデックスペ－ジには、前後ページへのポインタ
情報が含まれる
• Bツリー構造
• 非リ－フレベル

Bツリ－構造

o ル－トおよび中間レベル
o リ－フレベルへポイントする
デ－タを階層的に格納

ル－トレベル

ﾍﾟ-ｼﾞ

• リ－フレベル
o インデックスキ－値がソ－トされ格納

• インデックスの種類
• クラスタ化インデックス
• 非クラスタ化インデックス
• ColumnStore インデックス

中間レベル

リ－フレベル


2014

ページ分割













デ－タを挿入するための空き領域が
不足している場合に発生
デ－タ挿入のため新しいペ－ジが
追加される
新しいペ－ジには、元のペ－ジより
50％のデ－タの移動が伴う
非クラスタ化インデックスが存在する
場合、非クラスタ化インデックスの
保守は自動的に行われる
対策
 Fillfactor オプション
 インデックスの再構築
PageLatch が発生する。
トランザクションがキャンセルされても
ページ分割処理はロールバックしない

INSERT member (last name)
VALUES lastname = ‘Jackson’
Akhtar

…
Martin

リ－フレベル
（キ－値）

Akhtar
Ganio

Lang
Smith

Jackson

…

Akhtar …
Barr …

Ganio
Hall

…
…

Lang …
Martin …

Smith
Smith

…
…

Barr
Borm
Buhl

Hart
Jones
Jones

…
…
…

Martin …
Martin …
Moris …

Smith
Smith
Smith

…
…
…

…
…
…
Ganio

…

Hall
Hart

…
…
…
…


Jackson …
Jones
Jones

…
…
…
…

2014

ページラッチのメカニズム
ページヘッダ内の
情報の変更が必要
(例 Checksum,
torn page bits)

• なぜ Lock では不十分か?
INSERT VALUES
(3,300)

Page 100

Page 100
m_freedata=126

1

100

2

IX Page
100

m_freedata=126
156
141
PageLatch_
EX
1

200

2

400
300

96

4

141

INSERT VALUES
(4,400)
111

100

126

200

4
3

400

111

96

PageLatch_
EX


2014

ラッチ不要なアーキテクチャ
• データベース格納構造は、1970 年代から同じアーキテクチャを採用
• 従来の階層型格納構造とページ構造
o
o
o
o
o

データベースデータファイル
格納制御用ビットマップ領域 (PFS / GAM)
インデックスアロケーションマップ (IAM)
エクステント ( 8 KB Page * 8)
ページ (8 KB)
– インデックスページ
– データページ

• 階層型格納構造の整合性を維持するためにラッチ処理を採用
• トランザクション処理とは無関係な、ストレージエンジン内部の短時間
排他制御
• 該当するトランザクションが異常終了しても、ロールバック処理は実施しない

• これらの処理を排除するには、データベース格納構造の見直しが
必要
• インメモリー OLTP は、ファイルストリーム機能を利用
• カラムストアインデックスは、BLOB ページに格納

2014

第四世代L Server RDB (3)
• ロック処理の見直し
• トランザクションの ACID プロパティの担保
• ANSI トランザクション分離レベルの提供
• 行バージョニングと Read Committed Isolation Level の採用

• ペシミスティック (悲観的)同時実行制御と
オプティミスティック (楽観的)同時実行制御
• 従来の SQL Server は、ペシミスティック同時実行制御をコンセプトに
デザイン
o データ検索時に共有ロックを取得する

• SQL Server 2005 からは、オプティミスティック同時実行制御と読み取り行
のバージョニング機能を提供し、ユーザが選択可能となった

• SQL Server 2014 インメモリー OLTP は、オプティミスティック
同時実行制御と読み取り行のバージョニング機能を、標準アーキテ
クチャとして採用


2014

3 種類のアーキテクチャにより実現
• オプティミスティック (楽観的)同時実行制御
• コンフリクト(更新の競合)の発生確率は多くない
• トランザクションは排他制御(ロック)を発行しない
• コンフリクト(更新の競合)発生検出メカニズムを実装する

• 同一データに対して複数のバージョンを保持する
• データの更新と追加時には、新たなバージョンの行を作成する
• コミット処理後、コンフリクト(更新の競合)が発生していないことを確認する
までは、他のトランザクションからはイン・ビジブル

• データはタイム・スタンプにより管理する
• それぞれのバージョンの行は、開始と終了のタイムスタンプを持つ
• トランザクション開始時には、開始時間により該当するバージョンの行を取得
する
• タイムスタンプは、行の作成された順序 (FIFO) でポインターにより検索可能で
ある
• 最後にコミットされた行の終了時間は無限大となる


2014

ロック不要なアーキテクチャ
Begin

Pre-Commit

Commit

Terminate
Time

通常の
コンフリクト
トランザクション処理
の検出

トランザクション
後処理

• 通常トランザクション処理
• RCSI によりコミットされた最新の行を検索
• 更新したデータは仮の行バージョンとなり、他のトランザクションからは
イン・ビジブル

• コンフリクトの検出
• 他のトランザクションでコンフリクトの有無を検出
• コンフリクトを検出した場合はロールバックを行いアプリケーションに通知

• トランザクション後処理
• トランザクションが更新した最後の行バージョンを他のトランザクションから
参照可能な状態に変更する(非同期処理)
• CMPXCHG : Compare and Exchange 命令を利用

2014

インメモリーインデックスとバージョニング

Timestamps

Chain ptrs

Name

City

Row format

Hash index
on Name

J
S

Hash index
on City

200, ∞

John

B
P

Beijing

100, 200
90,150

Susan

•
•
•
•
•

Paris

Bogota
50, ∞

70, 90

John

Jane

Prague

Susan Brussels

テーブルは行の集まり。行は複数バージョン。
それぞれの行は2つのタイムスタンプにより有効な範囲を持っている。
トランザクションのリードの時刻がそのタイムスタンプ内の場合に読める。
バージョンのガベージコレクションはインクリメンタル、パラレル、ブロックしない。
テーブルは複数のインデックスを持てる。


2014

SQL Server とフラッシュメモリー SSD
• Database on the Memory
• HDD vs. Flash Memory (SSD)

*1

1TB Random Read (8K) – 約 20 倍高速に

1TB Random Write (8K) – 約 10 倍高速に

<

HDD

SSD

*1 比較対象のストレージ詳細
SSD Violin Memory Array 3205
HDD CX4-240 (SAS 15K 450GB HDD x10 RAID10)
SQLIO を利用した自社社内検証結果より


2014

SSD バッファープールの拡張
• 利点

•
•
•

不揮発性ドライブ (SSD) の使用による
バッファープールの拡張
NUMA 対応のラージページバッファープール
割り当て
SSD のバッファープール拡張
o
o
o

•

アプリケーションの変更を必要としない OLTP クエリ
パフォーマンスの向上
データ損失のリスクなし (クリーンページのみを使用)
コモディティサーバー (32 GB の RAM) 上の OLTP ワー
クロード用の構成の容易な最適化

8 ソケット以上のシステムでのスケーラビリティの
向上


2014

SQL Server の共有資源
• トランザクション間で共有する資源
• CPU

o 論理 CPU は、SQLOS 上のスケジューラとして一括管理する
o クエリーのコンパイル
o クエリーの実行

• メモリー
o
o
o
o
o

データキャッシュとプロシージャキャッシュ
論理ログファイル領域
排他制御管理領域
ユーザー接続管理領域
その他 SQL Server システム領域

• ストレージ

o ユーザ DB / tempdb の物理ファイル (データファイルとトランザクションログファイル)を、
Windows OS 上のファイルシを関連付け、一括管理をする
o フラッシュメモリー型 SSD の採用

• ネットワーク

o 今後最もクリティカルな共有資源となる

• 個々のクエリー実行時に必要な共有資源

• クエリーのタイプと実装方法により大きく異なる

o アドホッククエリー、プリペアードクエリー、ストアドプロシージャ
o コンパイル時の CPU 負荷と、メモリー上の実行プラン格納領域

• クエリー実行時 ( 実行コンテキスト )

o 中間結果セットと最終結果セットのメモリー領域
o 結合、ソート、集計処理時の CPU と tempdb (一時テーブル領域)
o カーソル処理、結果セットの転送処理

• ネットワーク上のラウンドトリップ


2014

メモリ共有リソースの監視
• データキャッシュ領域

• sys. dm_os_wait_stats
o PAGEIOLATCH_xx
• sys. dm_os_performance_counters
o Buffer Manager Page Life expectancy (単位: 秒 600 以上を推奨)
o Buffer Manager Buffer cache hit ratio (単位: % 限りなく 100% を推奨)

• プロシージャキャッシュ領域

o Memory Manager Optimizer Memory (KB)

• その他共有領域

o Memory Manager Connection Memory (KB)
o Memory Manager Lock Memory (KB)
• sys. dm_os_wait_stats
o LOGBUFFER

• クエリ実行時の一時領域

o Memory Manager Memory Grants Outstanding
• Sys. dm_os_wait_stats
o RESOURCE_SEMAPHORE
o CMEMTHREAD


2014

共有資源とクエリーの調査
• 内部の待ち事象からの考察
• sys.dm_os_wait_stats
• SQLOS の待ち事象からシステムの状況を把握する
o OLTP 処理の通常日、高負荷日の日別の待ち事象を測定する
o 何が把握できるか
– アプリケーションアーキテクチャの問題点
– メモリー不足 / CPU ボトルネック / ディスクサブシステム帯域不足
– 適切なインデックスの欠落

• データベース I/O 負荷の把握

• sys.dm_io_virtual_file_stats
• データベース物理ファイルとログファイルの I/O 発生状況を把握する
o OLTP 処理の通常日、高負荷日の日別の I/O 発生状況を測定する

• パフォーマンスカウンターの値

• CPU コア(スケジューラ)のボトルネック
• sys.dm_os_schedulers

• プロシージャ・キャッシュの調査
• sys.dm_exec_cached_plans
• sys.dm_exec_sql_text


2014

クエリー実行時の監視
• テーブル / インデックススキャンの監視
• 適切なインデックスチューニングの実施
o クエリーの実行プラン分析

• 実行頻度の高いクエリーを特定する
• プロシージャ・キャッシュ領域の分析

• 実行時の共有リソース消費状況監視
• アドホッククエリーの CPU 負荷
• メモリー負荷
o クエリープラン領域
o クエリーの中間結果セット領域

• ブロッキングの監視

• システムの致命的な遅延が発生する
o
o
o
o

どのアプリケーションが
どのリソースを
古い統計情報が原因ではないか
Index 定義列と順序は適切か

• 排他待ちの監視

• アプリケーションアーキテクチャに依存する
o 共有ロックと排他ロックの発生状況
o 適切な分離レベル (Isolation level ) の利用
o トランザクション境界と実行時間


2014

重点的な監視が必要な SQLOS 待ち事象

•

sys.dm_os_wait_stats から発見可能な問題点
• ストレージ・サブシステムの I/O 帯域不足
• データベース容量と比較したメモリー不足
• アプリケーションアーキテクチャの問題点
o
o
o
o

トランザクションの境界
ロックの種類と利用状況
分離レベル (Isolation level)
クエリー実行時のメモリー不足 (不適切なクエリー)

• データベース物理設計の問題点
o クラスタ化インデックスと
非クラスタ化インデックスの選択
o 物理ファイルのストレージへの格納 (RAID 選択)


2014

クエリーをカバーするインデックス
• 非クラスタ化インデックスのリ－フレベルに
検索に必要なデータが全て入っている
• データページのアクセスが不要となり I/O を減少でき、
パフォ－マンスが向上する

• 作成のガイドライン
• インデックスに列を追加
o 最も一般的なクエリをカバ－するインデックスを作成する
o 複数のクエリをカバ－できる、頻繁に参照される列を選択する
o キー列と付加列

• インデックスキ－のサイズを最小化
• 行サイズに対するキ－サイズの比率を小さくする


2014

クエリーをカバーするインデックスの例
• クエリーをカバーするインデックス定義例
• CREATE NONCLUSTERED INDEX [DEPARTMENT_NAME] ON
[dbo].[DPARTMENT]
([DEPARTMENT_CODE)
INCLUDE ([DEPARTMENT_NAME])
WITH (DROP_EXISTING = OFF) ON [PRIMARY]

• クエリをカバーするインデックスの利用例
• SELECT DEPARTMENT_CODE, DEPARTMENT_NAME
FROM DEPARTMENT
WHERE DEPARTMENT_CODE < 10
AND
DEPARTMENT_CODE > 101


2014

インデックスの使用の確認
•
•

クエリー実行プランを確認
インデックスが使用されない原因
•
•

•

プランのコストが小さすぎる
ページ数や行数の少ないテーブル

オプティマイザヒントの使用
•

クエリ処理に使用するオプションを指定
o テーブルヒント
o 結合ヒント
o インデックスヒント

•

通常はクエリオプティマイザで最適化されるため、
あまり使用しないことが推奨


2014

アプリケーションロックの使用例
USE AdventureWorks2012;
GO
BEGIN TRANSACTION;
DECLARE @result int;
EXEC @result = sp_getapplock
@Resource = ‘アプリケーション排他リソース名’,
@LockMode = ‘Exclusive’;
IF @result = -3
-- ロック取得に失敗
BEGIN
ROLLBACK TRANSACTION;
END
ELSE
-- ここに排他制御中に実行する処理を記述 -BEGIN EXEC @result = sp_releaseapplock
@Resource = 'アプリケーション排他リソース名';
COMMIT TRANSACTION;
END;
GO

2014

SQL Server のデータベース物理設計
• クラスター化インデックスと非クラスター化インデックスの違いを
理解する
• クラスター化インデックスの重要な役割
o B-Tree 構造によりデータを高速に検索可能
– インデックス情報は、ページ内最少キーを保持

o 新しい行の Insert 時に、格納するターゲットページを決定する
o 基本はテーブルには必ずクラスター化インデックスを定義する

• クラスター化インデックスを持つテーブル上の非クラスター化インデックス
検索
o 非クラスター化インデックスを検索し、クラスター化インデックスのキーを取得する
o クラスター化インデックスを検索し、検索対象の行を取得する
– 非クラスター化インデックス情報は、データと 1: 1 の関係で保持される

o ANSI Isolation Level を実装するには、キーの範囲指定排他制御機能が必要

• 非クラスター化インデックスのみから構成されるテーブル
o インデックス情報は、データと 1: 1 の関係で保持される
– 非クラスター化インデックスキー + RID
» データはヒープ構造として保持される


2014

SQL Server のデータベース物理設計
- インデックスを作成する列の決定 • 発生するデータを理解する
• データの特性、利用方法
• クラスター化インデックスを付与する列の場合、Insert する行のキー値の分布を
把握する
o ランダム値、昇順値 (伝票番号等)
o 複合列 (複数列で構成するキー)

• キー項目の更新の有無と頻度 (非クラスター化インデックス)
• 実行されるクエリの種類と実行頻度

• インデックスを作成する列のガイドライン
•
•
•
•

主キーと外部キー、結合処理で参照される列
煩雑に範囲検索される列
並び替え、集計処理で利用される列
キーの内容が変更されない列 (クラスター化インデックス)

• インデックス作成に適していない列
•
•
•
•

クエリで参照されない列
一意の値を含まない列
text、ntext、image データ型属性を持つ列
null、可変長属性を持つ列


2014

インデックスと統計情報による実行プラン生成
• テーブル毎の検索方法の決定
• テーブルの行数とデータページ数、保持するインデックスの把握
• テーブルスキャン or インデックス検索の決定
o クラスタ化インデックスと非クラスタ化インデックス
– それぞれのインデックスの持つ統計情報を参照する

• テーブル毎の検索条件句による選択行数の推測と検索方法の決定
• テーブルスキャン or インデックススキャン or ブックマーク
ルックアップ or インデックスシーク or カバリングインデックス
o 統計情報を参照し、キーの分布情報から、対象行数と検索ページ数を算出する
o 検索ページ数 / 総ページ数から、セレクティビティを算出する

• どの検索方法を取るかが決まる

• Join アルゴリズムの決定
• インデックス・ネステッドループ or ネステッド・ループ or
ソートマージ or ハッシュ結合
• 推測行数により、Join アルゴリズムを決定する

• テーブル単位の中間結果セットを用いた結合処理
• 集計、ソート処理
• 最終結果セットの作成

2014

データベースの運用設計
- 統計情報とは • クエリオプティマイザーが最適なクエリ実行プランを作成するため
の情報
• インデックスを構成する列の値をサンプリングし、分布情報を格納
「どうのような値をもつデー-タが何件入っているか? 」
• クエリオプティマイザーは統計情報を使用して、クエリに対してどの
インデックスを使用するかの実行コストを予測し、利用の有無、利用方法を判
断する
• パフォ-マンスに影響を及ぼす
• デー-タの変更に伴い統計情報の定期的な更新が必要
o インデックス再構築・再構成後に、データ更新処理により、実際の分布状態と、統計情報間
にデータの乖離が発生する

• 統計情報の作成

• 自動作成 (既定)

o インデックス作成時に、インデックス列内の値の分布情報を自動的に作成
o 結合述語または WHERE 句で使用されるインデックスが作成されていない列の利用状
況を保持する (インデックスチューニングの推奨データ)

• 統計情報の保守

• 自動更新 (既定) : インデックス単位に保持している更新状況から、一定の閾
値を超えた時に実行される
• 手動更新: update statistics on <テーブル名>


2014

まとめ
• 起こっている現象、ボトルネックの把握、仮設の設定と検証には、
ハードウエアとオペレーティングシステム、RDBMS エンジン等の
原理と動作に関する知識が重要です。
• ハードウエアの進化に、Windows Server OS と協調して今後も
進化していきます。
• 今年の PASS Summit 2013 もたくさんの知識が習得できました。


2014

© 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
2013
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

[B31,32]SQL Server Internal とパフォーマンスチューニングｂｙ Yukio Kumazawa

Recommended

More Related Content

What's hot (20)

Similar to [B31,32]SQL Server Internal とパフォーマンスチューニングｂｙ Yukio Kumazawa (20)

More from Insight Technology, Inc. (20)