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

2014

SQL Server Internal とパフォーマンスチューニングPart I & II : Level 400 +

2013.11.15 10:00 – 11:45

日本マイクロソフト株式会社

SQL Server 技術顧問

熊澤幸生

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

Agenda

• SQL Server のこれまでとシステム基盤の変化

• 仮想環境上の SQL Server 構築

• SQL Server の内部構造と SQLOS の役割

• SQL Server のメモリー管理

• 第四世代 SQL Server RDB エンジン

• インメモリー処理

• データベース格納構造とラッチの見直し

• ロック処理の見直し

• フラッシュメモリー SSD への対応

• チューニングの要点

• まとめ


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

• 第四世代 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 2014o Clustered Columnstore Index

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

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


システム基盤の環境変化

• マルチコア化とインメモリー処理へのサーバー側の対応• 次世代 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)• 最もクリティカルなボトルネックとなる


NUMA ノード上の Windows Server と Hyper-V (1)

CPU ソケット 1

物理コア

1

物理コア

2

物理コア

3

物理コア

4

物理コア

5

物理コア

6

物理コア

7

物理コア

8

物理コア

1

物理コア

2

物理コア

3

物理コア

4

物理コア

5

物理コア

6

物理コア

7

物理コア

8

CPU ソケット 2

NUMA ノード 0 NUMAノード1

ローカルメモリーローカルメモリー

Windows Server & Hyper-V Host

仮想 Windows Server & Hyper-V Guest

SQL Server

• メモリーアクセスが、ローカルとリモートにまたがり、効率が悪い

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



CPU ソケット 1

物理コア

1

物理コア

2

物理コア

3

物理コア

4

物理コア

5

物理コア

6

物理コア

7

物理コア

8

物理コア

1

物理コア

2

物理コア

3

物理コア

4

物理コア

5

物理コア

6

物理コア

7

物理コア

8

CPU ソケット 2

NUMA ノード 0 NUMAノード1

ローカルメモリーローカルメモリー


仮想 Windows Server & Hyper-V

Guest

SQL Server

仮想 Windows Server & Hyper-V

Guest

SQL Server

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

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



CPU ソケット 1

物理コア

1

物理コア

2

物理コア

3

物理コア

4

物理コア

5

物理コア

6

物理コア

7

物理コア

8

NUMA ノード 0

ローカルメモリー


CPU ソケット 2

NUMA ノード 1


CPU ソケット 3

物理コア

1

物理コア

2

物理コア

3

物理コア

4

物理コア

5

物理コア

6

物理コア

7

物理コア

8

NUMA ノード 0


CPU ソケット 4

NUMA ノード 1



SQL Server


SQL Server

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


仮想環境上の SQL Server OLTP 構築の留意点

• NUMA アライン境界内にゲスト環境を構築する

• SQL Server の NUMA によるスケールアウト機能が犠牲になる場合がある

• ストレージ・サブシステムが最大のボトルネックになる場合が多い

• フラッシュ・メモリーを搭載するストレージ・サブシステムを考慮する

• ホスト上の物理的な CPU コア数、メモリー容量を超える、オーバーコミット環境の仮想化は禁物

• SQL Server の機能である、リソース・ガバナー機能活用を検討

• パーティショニング可能な共有資源o NUMA ノード ( CPU ソケット単位の割り当て)

o NUMA ノード ( ローカルメモリーの割り当て)

o ストレージ・サブシステムの I/O 帯域

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


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


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


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 を利用して機能拡張を行っている

• マイクロソフトで最も優秀な開発技術者の集団でチーム構成


SQL Server 2012 の内部構造

SQLSERVER.EXE

Windows OS

SQLDK.DLL2 MB

XEvent

MonitorsI/O

CompletionPort

CLR Hosts NUMA

SchedulingServices

MemoryServices

SQLOS.DLL25 KB

SQLOS

sqlserver.exe

SQL Server 2012 以前61 MB

SQL Server 2012190 KB

sqllang.dll30 MB

sqlmin.dll30 MB

clr.dll QueryProcessor

実行

CHECKPOINTLazyWriterLockMonitor

実行

.NET


SQL Server 主要機能Network Protocol

SQ

LO

S A

PI

Query Processor (Relational Engine)

Parser Optimizer SQL Manager DB Manager Query Executer

Buffer Manager

Transaction Services

Lock Manager

File Manager

Storage Engine

Utility:BCPDBCCBackup/Restore

Access Methods Manager:Row OperationsIndexesPagesAllocationVersions

SQL OS API

SQL OS

Schedule Monitor

Deadlock Monitor

Resource Monitor

Lazy WriterBufferPool

MemoryManager

SchedulingSynchronization

Services

LockManager

I/O

SQ

LOS H

ostin

g A

PI

Exte

rnal C

om

po

nen

ts (CLR

/MD

AC

)

MS DTC (Distributed Transaction Coordinators )


SQL Server 構成パラメータname minimum maximum config_value run_valuename minimum maximum config_value run_value

access check cache bucket count 0 65,536 0 0

max degree of

parallelism 0 32,767 1 1

access check cache quota 0 2,147,483,647 0 0 max full-text crawl range 0 256 4 4

Ad Hoc Distributed Queries 0 1 0 0 max server memory (MB) 128 2,147,483,647 2,147,483,647 2,147,483,647

affinity I/O mask -2,147,483,648 2,147,483,647 0 0 max text repl size (B) -1 2,147,483,647 65,536 65,536

affinity mask -2,147,483,648 2,147,483,647 0 0 max worker threads 128 65,535 0 0

affinity64 I/O mask -2,147,483,648 2,147,483,647 0 0 media retention 0 365 0 0

affinity64 mask -2,147,483,648 2,147,483,647 0 0

min memory per query

(KB) 512 2,147,483,647 1,024 1,024

Agent XPs 0 1 0 0 min server memory (MB) 0 2,147,483,647 0 16

allow updates 0 1 0 0 nested triggers 0 1 1 1

backup checksum default 0 1 0 0 network packet size (B) 512 32,767 4,096 4,096

backup compression default 0 1 0 0

Ole Automation

Procedures 0 1 0 0

blocked process threshold (s) 0 86,400 0 0 open objects 0 2,147,483,647 0 0

c2 audit mode 0 1 0 0

optimize for ad hoc

workloads 0 1 1 1

clr enabled 0 1 0 0 PH timeout (s) 1 3,600 60 60

common criteria compliance

enabled 0 1 0 0 precompute rank 0 1 0 0

contained database authentication 0 1 0 0 priority boost 0 1 0 0

cost threshold for parallelism 0 32,767 5 5 query governor cost limit 0 2,147,483,647 0 0

cross db ownership chaining 0 1 0 0 query wait (s) -1 2,147,483,647 -1 -1

cursor threshold -1 2,147,483,647 -1 -1 recovery interval (min) 0 32,767 0 0

Database Mail XPs 0 1 0 0 remote access 0 1 1 1

default full-text language 0 2,147,483,647 1,041 1,041

remote admin

connections 0 1 0 0

default language 0 9,999 3 3 remote login timeout (s) 0 2,147,483,647 10 10

default trace enabled 0 1 1 1 remote proc trans 0 1 0 0

disallow results from triggers 0 1 0 0 remote query timeout (s) 0 2,147,483,647 600 600

EKM provider enabled 0 1 0 0 Replication XPs 0 1 0 0

filestream access level 0 2 0 0 scan for startup procs 0 1 0 0

fill factor (%) 0 100 0 0 server trigger recursion 0 1 1 1

ft crawl bandwidth (max) 0 32,767 100 100 set working set size 0 1 0 0

ft crawl bandwidth (min) 0 32,767 0 0 show advanced options 0 1 1 1

ft notify bandwidth (max) 0 32,767 100 100 SMO and DMO XPs 0 1 1 1

ft notify bandwidth (min) 0 32,767 0 0 transform noise words 0 1 0 0

index create memory (KB) 704 2,147,483,647 0 0 two digit year cutoff 1,753 9,999 2,049 2,049

in-doubt xact resolution 0 2 0 0 user connections 0 32,767 0 0

lightweight pooling 0 1 0 0 user options 0 32,767 0 0

locks 5,000 2,147,483,647 0 0 xp_cmdshell 0 1 0 0


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 処理中一覧を参照できる

• 表示されるのは、一瞬のスナップショットの情報である

• レイテンシーの発生している物理ファイルを発見できる可能性がある


sys.dm_io_pending_io_requests 実行結果

io_completion_request_address

io_type

io_pending_ms_ticks io_pending

io_completio

n_routine_address

io_user_data_address io_offset io_handle_path

0x00000000085CA790 disk 2 1 0x000007FEEC6E9E00

0x00000004EF4C0CC0 2,118,123,520

¥¥?¥C:¥ProgramFiles¥Microsoft SQL

Server¥MSSQL12.SQL2014CTP2¥MSSQL¥DATA¥AdventureWorks_Data.mdf

0x00000000085CA268 disk 2 1 0x000007FEEC6E9E00

0x00000004EF4C3CC0 2,118,647,808



0x00000000085CA688 disk 2 1 0x000007FEEC6E9E00

0x00000004EF4C6CC0 2,119,172,096



0x00000000085C9A28 disk 2 1 0x000007FEEC6E9E00

0x00000004EF4C9CC0 2,119,696,384



0x00000000085CA580 disk 2 1 0x000007FEEC6E9E00

0x00000004EF4CCCC0 2,120,286,208



0x00000000085CA478 disk 2 1 0x000007FEEC6E9E00

0x00000004EF4CFCC0 2,120,810,496



0x00000000085CA160 disk 2 1 0x000007FEEC6E9E00

0x00000004EF4D2700 2,121,334,784



0x00000004E45C1AE8network 8,621,414 1

0x000007FEEAAED5B0

0x00000004E45C1AE8 0 NULL


SQL Server のシステムプロセスspid SQL User Status Last Command

1 sa background RESOURCE MONITOR








9 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


24 sa suspended CHECKPOINT

25 sa background TASK MANAGER

26 sa background BRKR EVENT HNDLR




30 sa background BRKR TASK

31 sa background BRKR TASK






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


SQLOS の監視方法とサービス (2)

• スケジュールモニター

• 特徴o NUMA ノード単位に存在する

o 常時起動のノン・プリエンプティブ型タスク (5 秒毎にトリガー)

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

– Non-yielding Scheduler

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

– Deadlock Scheduler

o I/O 完了ポートが無応答状態

o リソースモニターが無応答状態

o いづれかのモニターが問題発生を検知

– SQLOS は SQL Server を呼び出す

• 状態の監視手段o sys.dm_os_ring_buffers

o XEvent ring buffer

o トレースフラグ T8022 により ERRORLOG に記録可能

o SQL Server 2012 で提供する新しい XEvent により、障害発生を知ることができる

– 例) deadlock_schediuler_callback_executed


その他のシステムプロセス

• Checkpoint

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

• Lazy Writer

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

• Log Writer

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

• Lock Monitor

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


SQLOS の提供するメモリーサービス

• SQLOS ベースのメモリーサービス

• NUMA のサポート

• ワークスペース、フラグメント管理、ブロックアロケータ、仮想メモリーアロケータ

• メモリークラーク

• メモリーオブジェクト

• キャッシュストア、ユーザストア、オブジェクトストア

• メモリープール

• リソース管理 (リソース・ガバナー)

• メモリーブローカー (プロシージャ・キャッシュ、コンパイル済み実行プラン、クエリー実行時のメモリー領域)

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


SQL Server 2008 R2 までのメモリー管理

Plan Cache

Optimizer

Backup Buffers

DatabasePageCache

MemoryObject

MemoryClerk

BufferPool

NUMAMemory Node

Memory Allocators

VirtualAllocator

VirtualAlloc andAWE API

MultiPage

Allocator

SinglePage

Allocator


SQL Server 2012 以降のメモリー管理

Plan Cache

Optimizer

Backup Buffers

DatabasePageCache

MemoryObject

MemoryClerk

Buffer PoolMemory

Clerk

NUMAMemory Node

Memory Allocators

Workspaces

VirtualAllocator

FragmentManager

BlockAllocator

VirtualAlloc andAWE API


メモリーマネージャの変更理由

• すべてのメモリー管理を統一性のあるモデルに変更した

• マルチページコンセプトの廃止

• max server memory パラメータを、真の max server memory に変更

• MemoryToReserve 領域 (–G 起動パラメータ領域サイズ指定)o SQL Server 2008 R2 まで

– 拡張ストアドプロシージャ

– CLR 用領域

– 複数の 8KB ページを利用するメモリーオブジェクト

o SQL Server 2012 以降

– 拡張ストアドプロシージャ

– CLR 用領域

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

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


メモリー領域の確保オプション

• VirtualAlloc API を利用する• Conventional memory in the memory manager

• メモリーチューニングオプションは無指定

• 複数ページに渡る大きなサイズのメモリーを確保できる

• NUMA を認識したメモリー確保を行う

• AWE API を利用する• メモリーチューニングオプション

o AWE 機能を有効にする(SQL Server 2012 から sp_configure AWE Enabled オプションは利用できなくなった)

o SQL Server サービス起動アカウントにメモリー内ページロック権限を付与

• ページングの対象外


• Large Pages を利用する• Locked pages in the memory manager

• メモリーチューニングオプションo SQL Server サービス起動アカウントにメモリー内ページロック権限を付与

• VirtualAlloc with MEM_LARGE_PAGES を利用する

• 2 MB 以上のサイズのメモリーを確保する



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


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)


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.


メモリー・クラークのパーティショニング例

• バッファープール、プロシージャキャッシュ、クエリー実行領域、ユーザコネクション領域、インメモリー OLTP テーブル領域等に分割管理されている

type name memory_node_id pages_kb

MEMORYCLERK_SQLGENERAL Default 0 6,536

MEMORYCLERK_SQLBUFFERPOOL Default 0 30,352

MEMORYCLERK_SQLQUERYCOMPILE Default 0 0

MEMORYCLERK_SQLQUERYPLAN Default 0 0

MEMORYCLERK_SQLQUERYEXEC Default 0 56

MEMORYCLERK_SQLOPTIMIZER Default 0 984

MEMORYCLERK_QUERYDISKSTORE Default 0 256

MEMORYCLERK_SQLUTILITIES Default 0 80

MEMORYCLERK_SQLSTORENG Default 0 6,584

MEMORYCLERK_SQLCONNECTIONPOOL Default 0 1,200

MEMORYCLERK_SQLCLR Default 0 10,928

MEMORYCLERK_SQLCLRASSEMBLY Default 0 0

MEMORYCLERK_SQLSERVICEBROKER Default 0 448

MEMORYCLERK_SQLXML Default 0 0

MEMORYCLERK_SQLHTTP Default 0 8

MEMORYCLERK_SQLSOAP Default 0 0

MEMORYCLERK_SQLSOAPSESSIONSTORE Default 0 0

MEMORYCLERK_SNI Default 0 24

MEMORYCLERK_SERIALIZATION Default 0 0

MEMORYCLERK_FULLTEXT Default 0 312

MEMORYCLERK_SQLXP Default 0 16

MEMORYCLERK_QSRANGEPREFETCH Default 0 0

MEMORYCLERK_BHF Default 0 0

MEMORYCLERK_SQLQERESERVATIONS Default 0 0

MEMORYCLERK_XE_BUFFER Default 0 0

MEMORYCLERK_TRACE_EVTNOTIF Default 0 0

MEMORYCLERK_XTP Default 0 3,104


メモリー・ブローカ・クラークのパーティショニング例

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

• 通常ページとインデックス用バッファープールと、BLOB ページ用カラムストアバッファープールを別領域として保持可能


メモリー・ブローカーのパーティショニング例

• インメモリー OLTP 専用の領域がブローカーにより確保されている

• MEMORYBROKER_FOR_XTP

pool_id memory_broker_typeAllocations_kb

predicted_allocations_kb

target_allocations_kb

future_allocations_kb

1MEMORYBROKER_FOR_CACHE 12,352 12,352 9,091,208 0

1MEMORYBROKER_FOR_STEAL 56,072 56,072 9,134,928 0

1MEMORYBROKER_FOR_RESERVE 0 0 9,078,856 0

1MEMORYBROKER_FOR_COMMITTED 195,608 195,608 9,274,464 0

1MEMORYBROKER_FOR_HASHED_DATA_PAGES 0 0 9,078,856 0

1MEMORYBROKER_FOR_XTP 3,424 3,424 9,082,280 0

2MEMORYBROKER_FOR_CACHE 21,448 21,448 9,100,304 0

2MEMORYBROKER_FOR_STEAL 424 424 9,079,280 0

2MEMORYBROKER_FOR_RESERVE 0 2,293,560 10,300,928 2,293,560

2MEMORYBROKER_FOR_HASHED_DATA_PAGES 0 0 9,078,856 0

2MEMORYBROKER_FOR_XTP 546,768 546,768 9,625,624 0


dbcc memorystatus 出力

Memory Manager KB

---------------------------------------- -----------

VM Reserved 35,670,564

VM Committed 823,752

Locked Pages Allocated 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

Memory node Id = 0 KB

---------------------------------------- -----------


VM Committed 823,732



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) KB

---------------------------------------- -----------


VM Committed 17,680


SM Reserved 0

SM Committed 0


MEMORYCLERK_SQLQUERYEXEC (node 0) KB---------------------------------------- -----------VM Reserved 0VM Committed 0Locked Pages Allocated 0SM Reserved 0SM Committed 0Pages Allocated 56

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

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


dbcc memorystatus 出力 (メモリー内ページロック)

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

Memory node Id = 0 KB---------------------------------------- -----------VM Reserved 35,737,872VM Committed 191,656Locked Pages Allocated 840,592Pages Allocated 770,520Pages Free 66,144Target Committed 12,851,048Current Committed 1,032,248Foreign Committed 0Away Committed 0Taken Away Committed 0

MEMORYCLERK_SQLBUFFERPOOL (node 0) KB---------------------------------------- -----------VM Reserved 12,261,500VM Committed 16,384Locked Pages Allocated 3,104SM Reserved 0SM Committed 0Pages Allocated 57,920

MEMORYCLERK_SQLQUERYEXEC (node 0) KB---------------------------------------- -----------VM Reserved 0VM Committed 0Locked Pages Allocated 0SM Reserved 0SM Committed 0Pages Allocated 56

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

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


第四世代 SQL Server RDB (1)

• インメモリー機能の活用

• インメモリー OLTP エンジンo インデックス情報とデータをメモリー上に保持する

o 従来のバッファーキャッシュとは異なる

• カラムストアーインデックスo DWH の不定型検索処理や集計処理に最適

o ビットマップインデックスの採用

o データ圧縮機能によりインメモリー化に貢献

o カラム(列)単位の検索処理と集計処理を、インメモリーテクノロジーを活用し、高速化する

– バッチ処理モード

– 従来の統計情報を利用しない実行プランの生成

• 導入されたテクノロジーo SQL Server 2012

– 従来型の行ストア型テーブルに、非クラスタカラムストアインデックスを付与する

o SQL Server 2014

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


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


パフォーマンス向上のポイント

36

Memory-optimized Table

FilegroupData Filegroup

SQL Server.exe

Hekaton Engine for Memory_optimizedTables & Indexes

TDS Handler and Session Management

Natively Compiled SPs and Schema

Buffer Pool for Tables & Indexes

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

Client App

Transaction Log

Query Interop

Interpreter for TSQL, query plans, expressions

Access Methods

Parser, Catalog,

Algebrizer, Optimizer

Hekaton Compiler

10-30倍高速

ログ書き込みに必要なIOバンド幅、

競合の低減

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

通信、パラメータ処理、結果セット作成の部分

では変化なし

Hekatonコンポーネント

Key

既存のSQL

Server

生成された.dll


インメモリ OLTP

SQL Server に統合され、最新ハードウェアのトレンドに合わせて設計された新しい高パフォーマンスのメモリ最適化 OLTP エンジン

SQL Server リレーショナルデータベースに統合

完全な ACID サポート

メモリ最適化インデックス(B ツリーおよびバッファープールなし)

ブロック不可マルチバージョンオプティミスティック同時実行制御(ロック/ラッチなし)

ネイティブコードにコンパイルされたT-SQL

お客様の利点:

• 短い待機時間

• 最大 10 倍のパフォーマンス向上

• 2 ～ 5 倍のスケーラビリティ向上

• SQL Server の投資を活用

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

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

0 0.5 1 1.5

SQL Server

2014

SQL Server

2008 SP1

待機時間 (ミリ秒)

待機時間 (ミリ秒)


PASS Summit 2013 at Charlotte


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


SBI リクイディティマーケット様事例

• http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=710000003429

http://www.microsoft.com/casestudies/Case_Study_Detail.aspx


カラムストアインデックスの進化

• SQL Server 2012 で非クラスタ化カラムストアインデックスを提供• 従来型のクラスタ化インデックスを持つテーブルに設定可能

• DWH 業務の非定型型の集計や検索処理が飛躍的にスピードアップ

• 非クラスタ化カラムストアインデックスを付与したテーブルは、検索処理専用で、直接更新処理はできないo バッチ処理等でデータ追加後に、非クラスタ化カラムストアインデックスの再作成が必要

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

• SQL Server 2014 でクラスタ化カラムストアインデックスを提供• ヒープ構造のテーブルをクラスタ化カラムストアインデックスに変換

• データ圧縮機能によりテーブル使用領域が小さい

• リアルタイムに透過的な更新処理が可能o Insert 処理 : 新たなパーティション内に追加

o Update 処理 : Delete + Insert 処理

o Delete 処理 : 行に削除フラグを設定する

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

• カラムストアインデックスは、ビットマップインデックスを利用

• インデックスの格納は BLOB 領域を利用

• カラムストアインデックスは統計情報を持たない


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

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

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

コア・キャッシュ・インターコネクト

30MBL3 Cache

キー1 a1 b1 c1 d1

キー2 a2 b2 c2 d2

a1 a2 a3 ……. an

b1 b2 null ……. bn

CPUCore2

CPUCore1

CPUCore3

CPUCore4

CPUCore5

CPUCore6

CPUCore7

CPUCore8

L1

L2

L1

L2

L1

L2

L1

L2

L1

L2

L1

L2

L1

L2

L1

L2

Intel Xeon E7 シリーズの例

CPUCore9

CPUCore10

L1

L2

L1

L2


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


ColumnStore インデックスの作成

Base table

A B C D

データ型変換と圧縮



Compressed column segments

Row

gro

up 1

Row

gro

up 2

Row

gro

up 3

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

Column store index

BLOB

Row group

Row group

Row group

Segm

ent

directo

ry

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


バッチモード処理

• クエリープロセッサーベクター演算子を利用

• 一度に約 1,000 行を処理

• ベクター形式で格納されるバッチ

• CPU ソケット内L3 キャッシュサイズに最適化

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

• フィルター、ハッシュ結合、ハッシュ集計などを新たにサポート

• CPU 時間の大幅な削減 (7 ～ 40 倍)

条件

を満

たす

行の

ビッ

トマ

ップ

列ベクター

バッチオブジェクト


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 秒


sys.column_store_segments (セグメント情報)

column_id segment_id version encoding_type row_count has_nulls base_id min_data_id max_data_id on_disk_size

1 0 1 1 1,048,576 0 -2 1 31,263,601 4,194,888

1 1 1 1 1,048,576 0 29,478,774 29,478,777 31,245,824 2,796,792

1 2 1 1 1,048,576 0 28,112,318 28,112,321 30,197,248 2,796,792

1 3 1 1 1,048,576 0 27,060,751 27,060,754 29,148,672 2,796,792

1 4 1 1 1,048,576 0 26,154,758 26,154,761 28,100,096 2,796,792

1 5 1 1 1,048,576 0 24,975,944 24,975,947 27,051,520 2,796,792

1 6 1 1 1,048,576 0 23,916,675 23,916,678 26,002,944 2,796,792

2 0 1 2 1,048,576 0 -1 1,001 50,999 2,097,736

2 1 1 2 1,048,576 0 -1 1,001 50,999 2,097,736

2 2 1 2 1,048,576 0 -1 1,001 50,999 2,097,736

2 3 1 2 1,048,576 0 -1 1,001 50,999 2,097,736

2 4 1 2 1,048,576 0 -1 1,001 50,997 2,097,736

2 5 1 2 1,048,576 0 -1 1,001 50,999 2,097,736

2 6 1 2 1,048,576 0 -1 1,001 50,999 2,097,736

3 0 1 2 1,048,576 0 -1 164,716,290,768,896 173,508,088,823,808 1,408

3 1 1 2 1,048,576 0 -1 172,996,987,715,584 173,503,793,856,512 1,728

3 2 1 2 1,048,576 0 -1 172,571,785,953,280 173,198,851,178,496 1,760

3 3 1 2 1,048,576 0 -1 172,258,253,340,672 172,893,908,500,480 1,800

3 4 1 2 1,048,576 0 -1 171,966,195,564,544 172,567,490,985,984 1,784

3 5 1 2 1,048,576 0 -1 171,601,123,344,384 172,253,958,373,376 1,840

3 6 1 2 1,048,576 0 -1 171,274,705,829,888 171,914,655,956,992 1,800

4 0 1 2 1,048,576 0 -1 1 100 191,600

4 1 1 2 1,048,576 0 -1 1 100 320,600

4 2 1 2 1,048,576 0 -1 1 100 361,488

4 3 1 2 1,048,576 0 -1 1 100 370,952

4 4 1 2 1,048,576 0 -1 1 100 388,768

4 5 1 2 1,048,576 0 -1 1 100 379,240

4 6 1 2 1,048,576 0 -1 1 100 402,056

5 0 1 4 1,048,576 0 0 0 7,014,151,213 4,125,176

5 1 1 4 1,048,576 0 0 0 7,156,143,655 5,035,760

5 2 1 4 1,048,576 0 0 0 7,027,283,306 5,068,400

5 3 1 4 1,048,576 0 0 0 7,144,141,920 5,050,616

5 4 1 4 1,048,576 0 0 0 7,126,428,747 5,030,512

5 5 1 4 1,048,576 0 0 0 7,137,000,989 5,054,416

5 6 1 4 1,048,576 0 0 0 7,096,266,811 5,056,520

• min_data_id と max_data_id を参照し、検索セグメントを決定する


ベンチマーク用クエリー

use AdventureWorksgo

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

FROMbigTransactionHistory14 INNER JOIN

bigProduct ON bigTransactionHistory14.ProductID = bigProduct.ProductID

INNER JOINProduction.ProductSubcategory ON bigProduct.ProductSubcategoryID = Production.ProductSubcategory.ProductSubcategoryID

GROUP BY Production.ProductSubcategory.Name, bigProduct.Name

ORDER BYSubcategory, Product

-- OPTION (MAXDOP 1);OPTION (MAXDOP 0);


Row Mode 処理と Batch Mode 処理

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


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


テーブル領域サイズの比較

データ領域サイズ (KB)

インデックス領域サイズ (KB)

合計 (KB)

ヒープ構造 1,269,592 8 1,269,600

クラスタ化インデックス設定 1,147,296 1,864 1,149,160

クラスタ化インデックス設定 + 非クラスタ化カラムストアインデックス

1,147,296 308,648 1,455,944

クラスタ化カラムストアインデックス 307,288 0 307,288

• クラスタ化カラムストアインデックスの領域サイズは、データ圧縮機能により、ヒープ構造領域サイズの 24.2 % (約 ¼ )

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


第四世代 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 セグメント構造


データファイルの構造（その他）

• 空き領域を追跡するためのデータ構造体

• PFS(Page Free Space) • 各ペ－ジ上で利用可能な空き領域に関する情報

• GAM(Global Allocation Map)• エクステントが割り当て済かどうかの情報

• tempdb 上に、一時テーブル領域を作成するときに参照・更新されるo トランザクションの同時実行性を損なう場合がある

• SGAM(Shared Global Allocation Map)• 混合エクステントとして使用されており、

1 ページ以上の未使用ページを含んでいるかどうかの情報

ﾌｧｲﾙﾍｯﾀﾞｰ

PFS GAM SGAM DCM BCM デ－タページ

･･･

エクステント


データファイルの構造（ページ/エクステント）

･････････････････････

ペ－ジ（８KB）

RIDと行オフセット

ページヘッダー

デ－タ行１

デ－タ行２

デ－タ行３

空き領域

123

エクステント(64KB)＝８KB×８page

• text、ntext、imageデータ型を除き、

データ行内のすべてのデータはページに格納される

- text、ntext、imageのデータは別のページに格納

• 新規のテーブル/インデックスには

混合エクステントからページが割り当てられる

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

- 単一エクステント単一のオブジェクトによって所有


データページの内容

• BUFFER:• BUF @0x04297F60

• bpage = 0x07252000 bhash = 0x00000000 bpageno = (1:50)• bdbid = 6 breferences = 0 bcputicks = 0• bsampleCount = 0 bUse1 = 5274 bstat = 0xc00009• blog = 0x32159 bnext = 0x00000000

• 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 SGAM (1:3) = NOT ALLOCATED PFS (1:1) = 0x40 ALLOCATED 0_PCT_FULL• DIFF (1:6) = CHANGED ML (1:7) = NOT MIN_LOGGED

• DATA:

• 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 †...?............


SQL Server のインデックス

•インデックスペ－ジに格納

•インデックスペ－ジには、前後ページへのポインタ情報が含まれる

• Bツリー構造• 非リ－フレベル

o ル－トおよび中間レベル

o リ－フレベルへポイントする

デ－タを階層的に格納

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

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

• 非クラスタ化インデックス

• ColumnStore インデックス

ﾍﾟ-ｼﾞル－トレベル

中間レベル

リ－フレベル

Bツリ－構造


ページ分割

デ－タを挿入するための空き領域が

不足している場合に発生

デ－タ挿入のため新しいペ－ジが

追加される

新しいペ－ジには、元のペ－ジより

50％のデ－タの移動が伴う

非クラスタ化インデックスが存在する

場合、非クラスタ化インデックスの

保守は自動的に行われる

対策

Fillfactor オプション

インデックスの再構築

PageLatch が発生する。トランザクションがキャンセルされてもページ分割処理はロールバックしない

Lang

Smith

…

Akhtar

Ganio

Jackson

Akhtar

…

Martin

Akhtar

Barr

Barr

Borm

Buhl

…

…

…

…

…

Lang

Martin

Martin

Martin

Moris

…

…

…

…

…

Smith

Smith

Smith

Smith

Smith

…

…

…

…

…

Ganio

Hall

Hart

Jones

Jones

…

…

…

…

…

Ganio

Hall

Hart

…

…

…

…

…

Jackson …

Jones

Jones

…

…

…

…

リ－フレベル（キ－値）

INSERT member (last name)

VALUES lastname = ‘Jackson’


ページラッチのメカニズム

• なぜ Lock では不十分か?

4 400

96

1

Page 100

m_freedata=126

100 2 200

111

m_freedata=126IX Page

100

INSERT VALUES

(3,300)

INSERT VALUES

(4,400)

96

1

Page 100

100 2 200

111

3

126

300

4

PageLatch_

EX

PageLatch_

EX

141

400

141

156

ページヘッダ内の情報の変更が必要(例 Checksum, torn page bits)


ラッチ不要なアーキテクチャ

• データベース格納構造は、1970 年代から同じアーキテクチャを採用

• 従来の階層型格納構造とページ構造o データベースデータファイル

o 格納制御用ビットマップ領域 (PFS / GAM)

o インデックスアロケーションマップ (IAM)

o エクステント ( 8 KB Page * 8)

o ページ (8 KB)

– インデックスページ

– データページ

• 階層型格納構造の整合性を維持するためにラッチ処理を採用

• トランザクション処理とは無関係な、ストレージエンジン内部の短時間排他制御

• 該当するトランザクションが異常終了しても、ロールバック処理は実施しない

• これらの処理を排除するには、データベース格納構造の見直しが必要

• インメモリー OLTP は、ファイルストリーム機能を利用

• カラムストアインデックスは、BLOB ページに格納


第四世代L Server RDB (3)

• ロック処理の見直し

• トランザクションの ACID プロパティの担保

• ANSI トランザクション分離レベルの提供

• 行バージョニングと Read Committed Isolation Level の採用

• ペシミスティック (悲観的)同時実行制御とオプティミスティック (楽観的)同時実行制御

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

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

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


3 種類のアーキテクチャにより実現

• オプティミスティック (楽観的)同時実行制御

• コンフリクト(更新の競合)の発生確率は多くない

• トランザクションは排他制御(ロック)を発行しない

• コンフリクト(更新の競合)発生検出メカニズムを実装する

• 同一データに対して複数のバージョンを保持する

• データの更新と追加時には、新たなバージョンの行を作成する

• コミット処理後、コンフリクト(更新の競合)が発生していないことを確認するまでは、他のトランザクションからはイン・ビジブル

• データはタイム・スタンプにより管理する

• それぞれのバージョンの行は、開始と終了のタイムスタンプを持つ

• トランザクション開始時には、開始時間により該当するバージョンの行を取得する

• タイムスタンプは、行の作成された順序 (FIFO) でポインターにより検索可能である

• 最後にコミットされた行の終了時間は無限大となる


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

• 通常トランザクション処理• RCSI によりコミットされた最新の行を検索

• 更新したデータは仮の行バージョンとなり、他のトランザクションからはイン・ビジブル

• コンフリクトの検出• 他のトランザクションでコンフリクトの有無を検出

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

• トランザクション後処理• トランザクションが更新した最後の行バージョンを他のトランザクションから

参照可能な状態に変更する(非同期処理)

• CMPXCHG : Compare and Exchange 命令を利用

Time

Begin

通常のトランザクション処理

コンフリクトの検出

トランザクション後処理

Pre-Commit Commit Terminate


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

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

90,150 Susan Bogota

50, ∞ Jane Prague

100, 200 John Paris

70, 90 Susan Brussels

200, ∞ John Beijing

Timestamps NameChain ptrs City

Hash index

on City

BP

Hash index

on Name

JS

Row format


SQL Server とフラッシュメモリー SSD

• Database on the Memory

• HDD vs. Flash Memory (SSD) *1

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

HDD SSD

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

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

<


SSD バッファープールの拡張

• 利点

• 不揮発性ドライブ (SSD) の使用によるバッファープールの拡張

• NUMA 対応のラージページバッファープール割り当て

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

o アプリケーションの変更を必要としない OLTP クエリパフォーマンスの向上

o データ損失のリスクなし (クリーンページのみを使用)

o コモディティサーバー (32 GB の RAM) 上の OLTP ワークロード用の構成の容易な最適化

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


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 カーソル処理、結果セットの転送処理

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


メモリ共有リソースの監視

• データキャッシュ領域• 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% を推奨)

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

o Memory Manager Optimizer Memory (KB)

• その他共有領域• sys. dm_os_performance_counters

o Memory Manager Connection Memory (KB)o Memory Manager Lock Memory (KB)

• sys. dm_os_wait_statso LOGBUFFER

• クエリ実行時の一時領域• sys. dm_os_performance_counters

o Memory Manager Memory Grants Outstanding• Sys. dm_os_wait_stats

o RESOURCE_SEMAPHOREo CMEMTHREAD


共有資源とクエリーの調査

• 内部の待ち事象からの考察• sys.dm_os_wait_stats

• SQLOS の待ち事象からシステムの状況を把握するo OLTP 処理の通常日、高負荷日の日別の待ち事象を測定する

o 何が把握できるか– アプリケーションアーキテクチャの問題点

– メモリー不足 / CPU ボトルネック / ディスクサブシステム帯域不足

– 適切なインデックスの欠落

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

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

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

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

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

• sys.dm_exec_sql_text


クエリー実行時の監視

• テーブル / インデックススキャンの監視• 適切なインデックスチューニングの実施

o クエリーの実行プラン分析

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

• 実行時の共有リソース消費状況監視• アドホッククエリーの CPU 負荷• メモリー負荷

o クエリープラン領域o クエリーの中間結果セット領域

• ブロッキングの監視• システムの致命的な遅延が発生する

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

• 排他待ちの監視• アプリケーションアーキテクチャに依存する

o 共有ロックと排他ロックの発生状況o 適切な分離レベル (Isolation level ) の利用o トランザクション境界と実行時間


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

• sys.dm_os_wait_stats から発見可能な問題点• ストレージ・サブシステムの I/O 帯域不足

• データベース容量と比較したメモリー不足

• アプリケーションアーキテクチャの問題点o トランザクションの境界

o ロックの種類と利用状況

o 分離レベル (Isolation level)

o クエリー実行時のメモリー不足 (不適切なクエリー)

• データベース物理設計の問題点o クラスタ化インデックスと

非クラスタ化インデックスの選択

o 物理ファイルのストレージへの格納 (RAID 選択)


クエリーをカバーするインデックス

•非クラスタ化インデックスのリ－フレベルに検索に必要なデータが全て入っている

• データページのアクセスが不要となり I/O を減少でき、パフォ－マンスが向上する

•作成のガイドライン

• インデックスに列を追加

o最も一般的なクエリをカバ－するインデックスを作成する

o複数のクエリをカバ－できる、頻繁に参照される列を選択する

oキー列と付加列

• インデックスキ－のサイズを最小化

• 行サイズに対するキ－サイズの比率を小さくする


クエリーをカバーするインデックスの例

• クエリーをカバーするインデックス定義例

• CREATE NONCLUSTERED INDEX [DEPARTMENT_NAME] ON [dbo].[DPARTMENT]

([DEPARTMENT_CODE)

INCLUDE ([DEPARTMENT_NAME])

WITH (DROP_EXISTING = OFF) ON [PRIMARY]

• クエリをカバーするインデックスの利用例

• SELECT DEPARTMENT_CODE, DEPARTMENT_NAMEFROM DEPARTMENT

WHERE DEPARTMENT_CODE < 10AND

DEPARTMENT_CODE > 101


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

• クエリー実行プランを確認

• インデックスが使用されない原因

• プランのコストが小さすぎる

• ページ数や行数の少ないテーブル

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

• クエリ処理に使用するオプションを指定

o テーブルヒント

o 結合ヒント

o インデックスヒント

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


アプリケーションロックの使用例

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


SQL Server のデータベース物理設計

• クラスター化インデックスと非クラスター化インデックスの違いを理解する

• クラスター化インデックスの重要な役割o B-Tree 構造によりデータを高速に検索可能

– インデックス情報は、ページ内最少キーを保持

o 新しい行の Insert 時に、格納するターゲットページを決定する

o 基本はテーブルには必ずクラスター化インデックスを定義する

• クラスター化インデックスを持つテーブル上の非クラスター化インデックス検索o 非クラスター化インデックスを検索し、クラスター化インデックスのキーを取得する

o クラスター化インデックスを検索し、検索対象の行を取得する

– 非クラスター化インデックス情報は、データと 1: 1 の関係で保持される

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

• 非クラスター化インデックスのみから構成されるテーブルo インデックス情報は、データと 1: 1 の関係で保持される

– 非クラスター化インデックスキー + RID

» データはヒープ構造として保持される


SQL Server のデータベース物理設計- インデックスを作成する列の決定 -

• 発生するデータを理解する• データの特性、利用方法

• クラスター化インデックスを付与する列の場合、Insert する行のキー値の分布を

把握するo ランダム値、昇順値 (伝票番号等)

o 複合列 (複数列で構成するキー)

• キー項目の更新の有無と頻度 (非クラスター化インデックス)

• 実行されるクエリの種類と実行頻度

• インデックスを作成する列のガイドライン• 主キーと外部キー、結合処理で参照される列

• 煩雑に範囲検索される列

• 並び替え、集計処理で利用される列

• キーの内容が変更されない列 (クラスター化インデックス)

• インデックス作成に適していない列• クエリで参照されない列

• 一意の値を含まない列

• text、ntext、image データ型属性を持つ列

• null、可変長属性を持つ列


インデックスと統計情報による実行プラン生成

• テーブル毎の検索方法の決定

• テーブルの行数とデータページ数、保持するインデックスの把握

• テーブルスキャン or インデックス検索の決定o クラスタ化インデックスと非クラスタ化インデックス

– それぞれのインデックスの持つ統計情報を参照する

• テーブル毎の検索条件句による選択行数の推測と検索方法の決定

• テーブルスキャン or インデックススキャン or ブックマークルックアップ or インデックスシーク or カバリングインデックスo 統計情報を参照し、キーの分布情報から、対象行数と検索ページ数を算出する

o 検索ページ数 / 総ページ数から、セレクティビティを算出する

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

• Join アルゴリズムの決定

• インデックス・ネステッドループ or ネステッド・ループ or ソートマージ or ハッシュ結合

• 推測行数により、Join アルゴリズムを決定する

• テーブル単位の中間結果セットを用いた結合処理

• 集計、ソート処理

• 最終結果セットの作成


データベースの運用設計- 統計情報とは -• クエリオプティマイザーが最適なクエリ実行プランを作成するため

の情報• インデックスを構成する列の値をサンプリングし、分布情報を格納「どうのような値をもつデー-タが何件入っているか? 」• クエリオプティマイザーは統計情報を使用して、クエリに対してどの

インデックスを使用するかの実行コストを予測し、利用の有無、利用方法を判断する

• パフォ-マンスに影響を及ぼす• デー-タの変更に伴い統計情報の定期的な更新が必要

o インデックス再構築・再構成後に、データ更新処理により、実際の分布状態と、統計情報間にデータの乖離が発生する

• 統計情報の作成• 自動作成 (既定)

o インデックス作成時に、インデックス列内の値の分布情報を自動的に作成o 結合述語または WHERE 句で使用されるインデックスが作成されていない列の利用状

況を保持する (インデックスチューニングの推奨データ)

• 統計情報の保守• 自動更新 (既定) : インデックス単位に保持している更新状況から、一定の閾

値を超えた時に実行される• 手動更新: update statistics on <テーブル名>


まとめ

• 起こっている現象、ボトルネックの把握、仮設の設定と検証には、ハードウエアとオペレーティングシステム、RDBMS エンジン等の原理と動作に関する知識が重要です。

• ハードウエアの進化に、Windows Server OS と協調して今後も進化していきます。

• 今年の PASS Summit 2013 もたくさんの知識が習得できました。

© 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.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.

© 2013 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.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

Technology

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

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

Technology

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

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

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