Share pointを支えるsql server2014最新情報 tokyo_公開用

SharePointを支える
SQL Server2014最新情報
Copyright© CSK WinTechnology Corporation
2014.5.31
株式会社 CSK Winテクノロジ
技術フェロー特別役員
熊澤幸生

Agenda
 SQL Server のこれまでと今後
 SharePoint の基盤設計と設定
 本稼働後の性能監視
 まとめ
1Copyright© CSK WinTechnology Corporation

2

自己紹介
 1977年に富士通メインフレームで初めてデータベースと出会う
 自動車会社割賦販売システム用DB移行プロジェクト
 1979年-1983年米国駐在日系企業全米オンラインシステム構築に従事
 データ主導型アーキテクチャを学ぶ(リポジトリによるメタデータ管理:IDMS/R)
 メインフレーム上で大規模DB設計とチューニングを数多く経験
 運送会社貨物追跡システム等を構築
 1994年アスキーNT(現㈱CSK Winテクノロジ)設立に参加
 株主 : アスキー、マイクロソフト、NTT データ、CSK 、みずほ銀行
 Windows Server と SQL Server に特化し、教育、構築に従事
 現在
 SQL Server 上のDBコンサルティングとチューニングに従事
 ㈱CSK Winテクノロジ技術フェロー特別役員
 Microsoft MVP – SQL Server (2007.4 – 2015.3)
 Microsoft Press インサイド SQL Server 2005 シリ－ズ監修
 日本マイクロソフト株式会社 SQL Server 技術顧問 (2008.7 - )

SQL Server の歴史
 第一世代 1994 - 1998
 SQL Server 4.2 / 6.0 / 6.5
 Sybase 社から技術提供を受け、Windows NT Server 上に移植
 2KB/ページ 16KB/エクステントページロック
 第二世代 1998 - 2005
 SQL Server 7.0 / 2000
 Dr. Jim Gray / Dave Campbell 氏らを迎えアーキテクチャを刷新
 8KB/ページ 64KB/エクステント行ロックの導入
 SQLOSの採用
 Analysis Service / ETL の提供開始 / XML のサポート
 第三世代 2005 - 2012
 SQL Server 2005 / 2008 / 2008R2
 IA32 から x64 への移行
 NUMA アーキテクチャの拡張
 クエリー並列処理機能の強化
 動的管理ビューによる内部動作と問題点の可視化
 ラージオブジェクト格納への対応
 BI 機能の強化
 パラレル・データ・ウェアハウス
 第四世代 2012 -
 SQL Server 2012
 Non Clustered ColumnStore Index
 Read Only
 Always On : HA DR 機能の強化
 Power View : Self Service BI 機能の強化
 FileTable : NTFSファイルとディレクトリの統合
 SQL Server 2014
 Clustered Columnstore Index
 Insert / Update / Delete を透過的に処理可能
 インメモリー OLTP (Hekaton)
 SSD バッファープール拡張機能
Copyright© CSK WinTechnology Corporation 4

Dr. Jim Gray 行方不明に
1966年カルフォルニア大学バークレー校卒業
1995年 IBM / タンデムを経てマイクロソフトに入社
1998年 DB とトランザクション処理に関して、チューリング賞を受賞
1998 年、2005 年に来日
5

Dr. Jim Gray
 2007年1月28日サンフランシスコ沖で、ヨット
“TENACIOUS” に乗り行方不明になる。
衛星写真を用いた懸命な捜査が行われる。
 2012年5月16日死亡認定
 He said
 Disk is Tape
 Disk is Flash
 Memory is King

Database Server Bricks
 2006 年 2 月
 Microsoft TechReady
Database Server Bricks Using SQL Server 2005 x64 NUMA
Dr. Jim Gray – Researcher
 2007 年 8 月
 日本経済新聞社 DL585 4P8C AMD Opteron を株価検索 Web サイトに採用

Dr. Jim Gray の後継者出現
 Dr. David J. DeWitt
Technical Fellow,
Data and Storage Platform Division
Microsoft Corp.
2008.3 入社
 University of Wisconsin – Madison 校
Computer Sciences Department 教授
 Teradata を開発し、NCRに売却
 Microsoft Jim Gray Systems Lab 創設者
 大規模リレーショナル型DHWのアーキテクチャを設計
(パラレル DWH)
 SQL Server 2008 R2 PDWH 開発に貢献
 カラム・ストアーインデックスを実装
8

バランスドシステムとは
 SQL Server リレーショナルエンジンに最適化された
ハードウエア構成
 リファレンスアーキテクチャ
 考慮すべき構成要素 (共有リソース)
 プロセッサ
 メモリ
 ストレージサブシステム
 ネットワーク
 SQL Server 専用サーバー上に配置する
 トランザクション処理用と、DWH系は、分離したサーバー上に
配置する
 将来のトランザクションベースラインを明確化する
 SQLOS の内部動作を理解する

プロセッサの選定
 主流は、x 64 アーキテクチャ
 NUMA アーキテクチャサポートの有無
 NUMA 対応 CPU
 Intel Xeon E3 / E5 / E7 シリーズ
 AMD Opteron
 CPU ソケット内にローカルメモリコントローラーと複数の
高速インターコネクトを内蔵
 マルチコア化が今後も加速
 Intel Xeon E3 4 Core/ソケット
 Intel Xeon E5 v2 10 Core/ソケット
 Intel Xeon E7 v2 15 Core/ソケット
 AMD Opteron 16 Core/ソケット
 クロック数と、キャッシュサイズも重要
 CPU 占有率の監視より、コア数不足
(SQLOS スケジューラと 1: 1) を監視する

必要なメモリサイズの考え方
 SQL Server 2000 では、最もクリティカルな共有リソースだった
 現在 x64 64 ビットアドレス方式が主流
 SQL Server 2012 Enterprise Edition は、最大 4TB のメモリ空間を
利用可能
 SQL Server 2012 からメモリーの利用方法が変更
 8 KB Page vs Large page
 リソースガバナーを利用してインメモリー OLTP と
ColumnStore Index に対応
 必要な物理メモリサイズは?
 NUMA アーキテクチャの場合
 NUMA ノードあたり 32–64 GB を推奨
 SMP アーキテクチャの場合
 CPU 物理コアあたり、4 GB をスタートラインに
 OLTP の場合、ユーザー DB 容量の 10% を目安に
メモリ見積もりを実施する

Flash Memory SSD の適用分野
 仮想環境基盤のストレージサブシステム
 データベースアプリケーション基盤
DWH スタースキーマ
多次元データベース
商品点数と顧客数の多いコマースサイト用
データベース
生産管理用 BOM と MRP バッチ処理の短縮化
データベースの論理設計と物理設計ノウハウが
重要となる

SQL Server 2008 R2 と NUMA
13Copyright© CSK WinTechnology Corporation 13
インターコネクト
Windows
Node No Node 0 Node 1 Node 2 Node 3
SQLOS
Node No
Node 1 Node 0 Node 2 Node 3
OS
グローバル・
リソース
SQLOS
ユーザノード
SQLOS
グローバル・
リソース
システムノード
SQLOS
ユーザノード
SQLOS
ユーザノード
メモリー
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリー
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリー
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリー
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU

SQL Server 2012 と NUMA
インターコネクト
Windows
Node No Node 0 Node 1 Node 2 Node 3
SQLOS
Node No
Node 0 Node 1 Node 2 Node 3
Windows OS
グローバル・
リソース
SQLOS
グローバル・
リソース
システムノード
SQLOS
ユーザノード
SQLOS
ユーザノード
SQLOS
ユーザノード
メモリ
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリ
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリ
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリ
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU

2/19 Xeon E7 V2 発表

検証環境
DB Storage
Violin Memory
V-6000 Series
Model : V-6606-
HA24-8xFC
24x 256GB SLC
VIMM
DB Server
NEC NX7700x
4x Intel® Xeon®
Processor E-4890V2
(2.80GHz,
37.5MB L3 cache,
15 processor cores)
1024GB Memory
2x 2port 8Gbps FC HBA
4x 8Gbps
FC 4x 8Gbps
FC
Windows Server 2012
Data Center
8Gbps FCHBA
Slot03
8Gbps FCHBA
Slot03
MG-BMG-A
仮想OS#1
Server 2012
0.5
TB
0.5
TB
0.5
TB
0.5
TB
HYPER-V
仮想OS#2
Server 2012
4x 8Gbps
FC

Xeon E7 v1 NUMA とノード間結合
メモリ
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリ
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリ
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
メモリ
コント
ローラ
CPU
CPU
CPU
CPU
メ
モ
リ
CPU
CPU
CPU
CPU
I / O バスI / O バス

Xeon E7 v2 NEC NX7700x A2010M

2,300 Thread Hyper Thread off

SQL Server サービス起動ログ
Configuration option 'max degree of parallelism' changed from 0 to 15. Run the RECONFIGURE statement to install.
Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.
Starting up database 'Northwind'.
Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.
Service Broker manager has started.
The Database Mirroring endpoint is in disabled or stopped state.
The Service Broker endpoint is in disabled or stopped state.
Starting up database 'tempdb'.
Clearing tempdb database.'.
The resource database build version is 11.00.2100.
Starting up database 'mssqlsystemresource'.
Starting up database 'msdb'.
Resource governor reconfiguration succeeded.
CLR version v4.0.30319 loaded.
Lock partitioning is enabled.
Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node.
Node configuration: node 3: CPU mask: 0x0fffe00000000000:0 Active CPU mask: 0x0fffe00000000000:0. This message
provides a description of the NUMA configuration for this computer.
Node configuration: node 2: CPU mask: 0x00001fffc0000000:0 Active CPU mask: 0x00001fffc0000000:0. This message
Node configuration: node 1: CPU mask: 0x000000003fff8000:0 Active CPU mask: 0x000000003fff8000:0. This message
Node configuration: node 0: CPU mask: 0x0000000000007fff:0 Active CPU mask: 0x0000000000007fff:0. This message
Machine supports memory error recovery. SQL memory protection is enabled to recover from memory corruption.
Large Page Allocated: 32MB
Using locked pages in the memory manager.
Detected 1,048,419 MB of RAM.
SQL Server detected 4 sockets with 15 cores per socket and 15 logical processors per socket<c/> 60 total
logical processors; using 60 logical processors based on SQL Server licensing.
The service account is 'NX7700X¥Administrator'.
Authentication mode is WINDOWS-ONLY.
System Manufacturer: 'NEC'<c/> System Model: 'Express5800/A2040b [NE3400-001S]'.
Server process ID is 5304.
Microsoft SQL Server 2012 - 11.0.2100.60 (X64) <nl/> Feb 10 2012 19:39:15 <nl/> Copyright (c) Microsoft
Corporation<nl/> Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.2 <X64> (Build 9200: )

NUMA ノード上の Windows Server と Hyper-V (1)
 メモリーアクセスが、ローカルとリモートにまたがり、効率が悪い
 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 Host
仮想 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
物理
コア
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

 Windows Server 2012 からHyper-V V-NUMA で実現
 SQL Server は Win32 API でHyper-V 上でNUMAを認識する
 VMware は ?
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
仮想 Windows Server & Hyper-V Guest
SQL Server
仮想 Windows Server & Hyper-V
Guest
SQL Server

V-NUMA SQL Server 起動ログ
Lock partitioning is enabled.
Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node.
Node configuration: node 1: CPU mask: 0x000000003fff8000:0 Active CPU mask: 0x000000003fff8000:0. This message provides a
description of the NUMA configuration for this computer.
Node configuration: node 0: CPU mask: 0x0000000000007fff:0 Active CPU mask: 0x0000000000007fff: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 2696 at 2014/02/24 16:19:46 (local) 2014/02/24 7:19:46 (UTC).
Machine supports memory error recovery. SQL memory protection is enabled to recover from memory corruption.
Using locked pages in the memory manager.
Detected 449,999 MB of RAM.
SQL Server is starting at normal priority base (=7).
SQL Server detected 2 sockets with 15 cores per socket and 15 logical processors per socket<c/> 30 total logical processors; using 30
logical processors based on SQL Server licensing.
Command Line Startup Parameters:<nl/> -s "SQLSERVER2012"
Registry startup parameters: <nl/> -d E:¥MSSQL11.SQLSERVER2012¥MSSQL¥DATA¥master.mdf<nl/> -e
E:¥MSSQL11.SQLSERVER2012¥MSSQL¥Log¥ERRORLOG<nl/> E:¥MSSQL11.SQLSERVER2012¥MSSQL¥DATA¥mastlog.ldf
The service account is 'WIN-DVUOFCD25CV¥Administrator'.
Logging SQL Server messages in file 'E:¥MSSQL11.SQLSERVER2012¥MSSQL¥Log¥ERRORLOG'.
Authentication mode is WINDOWS-ONLY.
System Manufacturer: 'Microsoft Corporation'<c/> System Model: 'Virtual Machine'.
Server process ID is 4860.
Microsoft SQL Server 2012 - 11.0.2100.60 (X64) <nl/> Feb 10 2012 19:39:15 <nl/> Copyright (c) Microsoft Corporation<nl/>
Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)

Hyper-V の V-NUMA 設定

V-NUMA 830 Thread 並列稼働 600 秒
0
500
1,000
1,500
2,000
2,500
3,000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59
830 Threads
VNUMA_1 Hyper
Thread_off
830 Thread
VNUMA_2 Hyper
Thread_off
830 Threads
Hyper Thread_off

PASS Summit 2013 at Charlotte

ハードウエアトレンド (CPU と Memory)
 キーワード
 メニーコアを念頭においた並列処理化
 NUMA を最大限に活用する RDB エンジン
 インメモリーテクノロジの活用
 ColumnStore Index とインメモリー OLTP エンジン
1
100
10000
1000000
1990
1991
1992
1993
1994
1994
1995
1996
1997
1998
1999
2000
2000
2001
2002
2004
2005
2007
2008
2009
2011
US$/GB
$ per GB of PC Class Memory
RAM コストの低下
クロック当たりの処理能力
(ILP) は伸びず
発熱対策は限界
ムーアの法則
トランジスタ数/コア頭打ち
クロック数増加の失速
Chart reference
http://www.gotw.ca/publications/concurrency-ddj.htm

第四世代 SQL Server RDB (1)
 インメモリー機能の活用
 インメモリー OLTP エンジン
 インデックス情報とデータをメモリー上に保持する
 従来のバッファーキャッシュとは異なる
 カラムストアーインデックス
 DWH の不定型検索処理や集計処理に最適
 ビットマップインデックスの採用
 データ圧縮機能によりインメモリー化に貢献
 カラム(列)単位の検索処理と集計処理を、インメモリーテクノロジーを活用し
、高速化する
 バッチ処理モード
 従来の統計情報を利用しない実行プランの生成
 導入されたテクノロジー
 SQL Server 2012
 従来型の行ストア型テーブルに、非クラスタカラムストアインデックスを付与する
 SQL Server 2014
 ヒープ構造のテーブルを、直接クラスタカラムストアインデックスに変換する

カラムストアインデックスの進化
 SQL Server 2012 で非クラスタ化カラムストアインデックスを提供
 従来型のクラスタ化インデックスを持つテーブルに設定可能
 DWH 業務の非定型型の集計や検索処理が飛躍的にスピードアップ
 非クラスタ化カラムストアインデックスを付与したテーブルは、検索処理専用で、
直接更新処理はできない
 バッチ処理等でデータ追加後に、非クラスタ化カラムストアインデックスの再作成が必要
 テーブル使用領域が大きくなる
 従来のクラスタ化インデックス領域 + 非クラスタ化カラムストアインデックス領域
 SQL Server 2014 でクラスタ化カラムストアインデックスを提供
 ヒープ構造のテーブルをクラスタ化カラムストアインデックスに変換
 データ圧縮機能によりテーブル使用領域が小さい
 リアルタイムに透過的な更新処理が可能
 Insert 処理 : 新たなパーティション内に追加
 Update 処理 : Delete + Insert 処理
 Delete 処理 : 行に削除フラグを設定する
 定期的にインデックスの再構築を実施する
 カラムストアインデックスは、ビットマップインデックスを利用
 インデックスの格納は BLOB 領域を利用
 カラムストアインデックスは統計情報を持たない

カラム・ストアーの考え方
カラム・オリエンテッド
データストアー
行・オリエンテッド
データストアー
コア・キャッシュ・インターコネクト
30MB
L3 Cache
キー1 a1 b1 c1 d1
キー2 a2 b2 c2 d2
a1 a2 a3 ……. an
b1 b2 null ……. bn
CPU
Core2
CPU
Core1
CPU
Core3
CPU
Core4
CPU
Core5
CPU
Core6
CPU
Core7
CPU
Core8
L1
L2
L1
L2
L1
L2
L1
L2
L1
L2
L1
L2
L1
L2
L1
L2
Intel Xeon E7 シリーズの例
CPU
Core9
CPU
Core10
L1
L2
L1
L2

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
 min_data_id と max_data_id を参照し、検索セグメントを決定する
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

Row Mode と Batch Mode 処理
 処理時間 : Row Mode 22 秒 vs Batch Mode 2 秒

テーブル領域サイズの比較
データ領域
サイズ (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 % (圧縮率約 4 倍 )
• クラスタ化インデックスの付与されたテーブルに、非クラスタ化カラム
ストアインデックスを定義すると、26.7 % の領域が増加する
クラスタ化カラムストアインデックスの領域サイズと比較すると、
領域サイズは 21.1 % (圧縮率約 5 倍 )

第四世代 SQL Server RDB (2)
 ラッチ処理の見直し
 ラッチ処理
 三種類のラッチから構成される
 PageIOLatch
 PageLatch
 Latch
 ストレージエンジン内の処理のシリアライズ処理
 ディスクからバッファープールへのデータ転送非同期処理の完了待ち
 更新のロストの防止
 データ領域の動的拡張処理の完了待ち
 次世代データ格納構造の採用
 従来型データ格納構造
 B-Tree or Heap 構造
 64KB エクステントと 8KB ページ
 データの追加・削除によりページ分割が発生する
 データページとインデックスページの両方
 次世代データ格納構造 (SQL Server 2012 - 2014)
 ファイルストリーム型
 インメモリー OLTP (Hekaton)
 インデックス構造の排除
 メモリー展開時に、動的なインデックス情報を付加する
 BLOB型
 ColumnStore Index セグメント構造

PageLatch のメカニズム
 なぜ Lock では不十分か?
4 400
96
1
Page 100
m_freedata=126
100 2 200
111
m_freedata=126
IX 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 年代から同じアーキテクチャを採用
 従来の階層型格納構造とページ構造
 データベースデータファイル
 格納制御用ビットマップ領域 (PFS / GAM)
 インデックスアロケーションマップ (IAM)
 エクステント ( 8 KB Page * 8)
 ページ (8 KB)
 インデックスページ
 データページ
 階層型格納構造の整合性を維持するためにラッチ処理を採用
 トランザクション処理とは無関係な、ストレージエンジン内部の短時間
排他制御
 該当するトランザクションが異常終了しても、ロールバック処理は実施しない
 これらの処理を排除するには、データベース格納構造の見直しが必要
 インメモリー OLTP は、ファイルストリーム機能を利用
 カラムストアインデックスは、BLOB ページに格納

第四世代L Server RDB (3)
 ロック処理の見直し
 トランザクションの ACID プロパティの担保
 ANSI トランザクション分離レベルの提供
 行バージョニングと Read Committed Isolation Level の採用
 ペシミスティック (悲観的)同時実行制御とオプティミスティック
(楽観的)同時実行制御
 従来の SQL Server は、ペシミスティック同時実行制御をコンセプト
にデザイン
 データ検索時に共有ロックを取得する
 SQL Server 2005 から、オプティミスティック同時実行制御と
読み取り行のバージョニング機能を提供し、ユーザが選択可能
 SQL Server 2014 インメモリー OLTP は、オプティミスティック
同時実行制御と読み取り行のバージョニング機能を、標準アーキ
テクチャとして採用

3 種類のアーキテクチャにより実現
 オプティミスティック (楽観的)同時実行制御
 コンフリクト(更新の競合)の発生確率は多くない
 トランザクションは排他制御(ロック)を発行しない
 コンフリクト(更新の競合)発生検出メカニズムを実装する
 同一データに対して複数のバージョンを保持する
 データの更新と追加時には、新たなバージョンの行を作成する
 コミット処理後、コンフリクト(更新の競合)が発生していないことを確認する
までは、他のトランザクションからはイン・ビジブル
 データはマルチ・バージョニングで管理する
 それぞれのバージョンの行は、開始と終了のタイムスタンプを持つ
 トランザクション開始時には、開始時間により該当するバージョンの行を取得
する
 タイムスタンプは、行の作成された順序 (FIFO) でポインターにより検索可能
である
 最後にコミットされた行の終了時間は無限大となる

ロック不要なアーキテクチャ
 通常トランザクション処理
 RCSI によりコミットされた最新の行を検索
 更新したデータは仮の行バージョンとなり、他のトランザクションからは
イン・ビジブル
 コンフリクトの検出
 他のトランザクションでコンフリクトの有無を検出
 コンフリクトを検出した場合はロールバックを行いアプリケーションに通知
 トランザクション後処理
 トランザクションが更新した最後の行バージョンを他のトランザクションから
参照可能な状態に変更する(非同期処理)
 CMPXCHG : Compare and Exchange 命令を利用
Time
Begin
通常の
トランザクション処理
コンフリクト
の検出
トランザクション
後処理
Pre-Commit Commit Terminate

一般のデータ検索機能
 一般のデータ検索機能
 OLTP とバッチ処理
 マルチユーザによる多頻度更新処理
 トランザクション属性を保障したリアルタイムデータを保持
 正規化された構造化データを扱う
 ETL と DWH
 ペタバイト (10の15乗) のデータをスタースキーマ形式で格納する
 大量データ追加更新を短時間で
 定型検索
 データ反映の即時性の有無
 多次元検索機能
 事前集計された多次元データのドリルダウン検索
 大量データ追加更新を短時間で

SharePoint のデータベース要件
 ドキュメントの管理
所有者と変更管理
アクセス権の設定
 ファイルサーバー機能の提供
マルチバージョン形式の大量データの保存
フルテキスト検索機能
 マルチユーザへのアクセス基盤提供
 SharePoint Online によりブラックボックス化

SharePoint 用に追加された機能
 非構造型データの格納と検索機能
 BLOB
 ファイルストリーム
 ファイルテーブル
 Update 処理
 Delete / Insert で処理
 Delete は削除フラグを設定し、削除処理は非同期処理
 コンテンツのインデックス検索
 Fast Index Search
 バックアップ・リストアをどう扱うか？

SharePoint 用データベース

SQL Server の設定・管理は必要 ?
 データ格納基盤のサイジング
 仮想化基盤利用の是非
 利用ユーザ数と格納容量見積もり
 必要なサーバー数は
 コンテンツ DB / Index / DWH / MOLAP / Reporting Service
 CPU コア数、メモリーサイズ、ネットワーク帯域
 tempdb 同時実行性の向上
 CPU リソースの並列処理設定
 SQL Server が使用するメモリーの固定化
 ストレージサブシステム設計
 どのファイルをどの論理デバイス上に配置するか
 データファイルとトランザクションログファイルの初期サイズと
拡張増分指定の設定
 データ格納領域の断片化とインデックス再構築

tempdb 同時実行性の向上
 物理CPUコア数 < 8
 Tempdb データファイル数 = 物理CPUコア数
 物理CPUコア数 > 8
 Tempdb データファイル数 => 8

CPU リソースの並列処理設定
 並列処理の最大限度 (Max DOP)
 NUMA の場合
 ソケット内の物理コア数を設定
 SMP の場合
 (物理コア数 / 4) の値を設定

SQL Server が使用するメモリーの固定化
 SQL Server の利用するメモリーを固定化する
 ただし、仮想環境の場合は注意が必要

SQLOS 内部待ち事象の監視
 select * from sys.dm_os_wait_stats
wait_type waiting_tasks_count wait_time_ms
max_wait_time
_ms signal_wait_time_ms
PAGELATCH_EX 299,490 62,458,812 1,714 286,201
PAGELATCH_SH 269,656 46,166,230 1,002 367,886
SOS_SCHEDULER_YIELD 5,296,104 12,631,779 136 12,627,863
LATCH_SH 24,716 2,012,683 9,722 31,067
LATCH_EX 4,612 1,588,947 9,726 2,768
WRITELOG 216,300 610,175 105 299,788
DIRTY_PAGE_POLL 4,615 465,679 147 21
HADR_FILESTREAM_IOMGR_IOCOMPLETION 926 465,509 520 1,604
ASYNC_NETWORK_IO 51,075 109,771 84 103,399
LCK_M_S 11,962 49,165 60 9,917
IO_COMPLETION 49,491 38,471 52 898
LCK_M_U 7,167 27,350 82 5,126
PAGEIOLATCH_EX 305 754 27 162
CMEMTHREAD 614 509 4 507
LCK_M_IX 31 409 33 41
PAGELATCH_UP 244 370 8 151
ASYNC_IO_COMPLETION 1 277 277 0
SOS_PHYS_PAGE_CACHE 43 150 8 144
THREADPOOL 17 96 16 0
PAGEIOLATCH_UP 27 67 5 0
LOGMGR_FLUSH 26 43 2 0
LOGBUFFER 27 17 4 16

データベース I/O 監視
 select * from sys.dm_io_virtual_file_stats(null, null)
db file_id
size_on_disk_byt
es
num_of_read
s num_of_bytes_read
io_stall_read_
ms
num_of_write
s
num_of_bytes_writte
n
io_stall_write_
ms io_stall
tempdb 1 387,579,904 494,102 28,318,130,176 2,734,719 877,889 54,112,444,416 70,618,588 73,353,307
tempdb 2 328,794,112 278 2,048,000 1,167 937,537 54,502,727,680 15,282,463 15,283,630
SharePoint_Config 1 267,649,024 114,089 2,539,479,040 1,586,791 59,323 2,496,454,656 837,480 2,424,271
SharePoint_Config 2 1,271,267,328 349 2,142,208 7,477 4,037,399 5,839,324,672 36,102,091 36,109,568
SharePoint_AdminContent_1f19041d-da52-4f3c-95fa-b210e3f13eec 1 485,752,832 83,498 1,406,263,296 897,916 18,871 224,714,752 875,943 1,773,859
SharePoint_AdminContent_1f19041d-da52-4f3c-95fa-b210e3f13eec 2 7,929,856 72 757,760 1,341 34,343 206,451,200 448,906 450,247
WSS_Content 1 241,041,408 148 1,417,216 2,098 1 8,192 34 2,132
WSS_Content 2 3,997,696 18 434,176 358 5 15,872 75 433
WordAutomationServices_15d5d7ba4d7f4c79ae700f2e63d58f59 1 2,359,296 1,477 12,099,584 13,941 1 8,192 84 14,025
WordAutomationServices_15d5d7ba4d7f4c79ae700f2e63d58f59 2 589,824 6 385,024 184 5 10,752 180 364
Search_Service_Application_DB_abce596e166849578d153755368f7ec4 1 71,565,312 76,858 1,984,864,256 962,210 16,201 188,170,240 314,107 1,276,317
Search_Service_Application_DB_abce596e166849578d153755368f7ec4 2 8,716,288 131 1,298,432 1,467 946,496 665,256,448 10,279,494 10,280,961
Search_Service_Application_PropertyStoreDB_c36b8a83d0244e7990e86263e68aa00b 1 3,744,727,040 1,073,755 10,879,672,320 14,161,763 198,769 4,224,253,952 5,701,409 19,863,172
Search_Service_Application_PropertyStoreDB_c36b8a83d0244e7990e86263e68aa00b 2 251,330,560 197 1,273,856 3,899 71,299 830,382,080 1,282,807 1,286,706
Search_Service_Application_CrawlStoreDB_5a34fac31a4e4e5296cb8f1333112097 1 4,327,800,832 21,460,055 231,891,591,168 421,480,138 13,028,579 277,537,669,120 249,127,838 670,607,976
Search_Service_Application_CrawlStoreDB_5a34fac31a4e4e5296cb8f1333112097 2 1,538,260,992 314 3,334,144 6,731 12,575,486 302,634,040,320 159,112,357 159,119,088
WSS_Search_CWTSPF01 1 427,032,576 180,729 2,463,965,184 3,644,510 7,960 95,346,688 278,077 3,922,587
WSS_Search_CWTSPF01 2 538,968,064 234 1,445,888 4,965 87,180 337,313,792 816,927 821,892
StateService_ddbdde39f3df44d48fa68b27a54b8891 1 2,359,296 1,004 8,224,768 9,272 1 8,192 26 9,298
StateService_ddbdde39f3df44d48fa68b27a54b8891 2 851,968 7 389,120 50 5 13,824 237 287
Managed Metadata Service_464c6e4388ae43beb5c8e9e5c583a404 1 3,407,872 2,538 20,791,296 18,919 1 8,192 8 18,927
Managed Metadata Service_464c6e4388ae43beb5c8e9e5c583a404 2 589,824 6 206,336 94 6 72,704 250 344
WebAnalyticsServiceアプリケーション_StagingDB_4029d037-239c-4125-857f-ba74e39d784b 1 66,781,184 30,261 1,467,113,472 588,075 9,830 188,014,592 525,000 1,113,075
WebAnalyticsServiceアプリケーション_StagingDB_4029d037-239c-4125-857f-ba74e39d784b 2 188,809,216 180 983,552 5,167 87,333 237,562,880 1,127,142 1,132,309
WebAnalyticsServiceアプリケーション_ReportingDB_8d1f02f0-8a63-4c1a-b0a0-ce43e627ffe5 1 395,575,296 190,969 10,335,289,344 5,352,568 213,873 2,242,215,936 12,385,991 17,738,559
WebAnalyticsServiceアプリケーション_ReportingDB_8d1f02f0-8a63-4c1a-b0a0-ce43e627ffe5 2 37,158,912 120 970,752 2,280 13,367 350,702,080 235,236 237,516
WSS_Logging 1 1,951,924,224 113,462 8,239,308,800 1,486,240 36,655 1,893,670,912 846,464 2,332,704
WSS_Logging 2 188,809,216 250 1,609,216 5,210 156,707 2,778,958,336 2,056,932 2,062,142
ProfileDB 1 77,791,232 53,301 577,060,864 318,685 10,539 119,504,896 218,526 537,211
ProfileDB 2 4,390,912 812 33,588,224 7,640 48,493 233,288,192 664,243 671,883
TONODB 1 41,186,164,736 10,712,827 2,180,261,675,008 122,846,847 68,361 808,173,568 1,960,397 124,807,244
TONODB 2 789,250,048 321 3,061,760 6,281 109,693 566,663,168 1,533,852 1,540,133
UPSApp_SyncDB_db675b72-ec7e-46a0-a85d-931f9a53753c 1 900,988,928 73,552 1,167,491,072 798,153 9,638 128,589,824 407,694 1,205,847
UPSApp_SyncDB_db675b72-ec7e-46a0-a85d-931f9a53753c 2 45,023,232 166 1,314,816 3,279 1,316,174 758,588,416 13,896,723 13,900,002
UPSApp_SocialDB_bd2d1ac3a7114262ab9efa0ef2a452c1 1 3,407,872 5,948 48,726,016 49,388 1 8,192 22 49,410
UPSApp_SocialDB_bd2d1ac3a7114262ab9efa0ef2a452c1 2 851,968 7 389,120 221 5 17,408 221 442
Bdc_Service_DB_ff0ed6c74ee94daea5f9902448edb1c2 1 3,407,872 604 4,947,968 5,275 1 8,192 24 5,299
Bdc_Service_DB_ff0ed6c74ee94daea5f9902448edb1c2 2 589,824 6 295,424 87 5 12,288 146 233
WSS_Content_cwtspf01 1 21,233,664 141 1,335,296 2,460 1 8,192 36 2,496
WSS_Content_cwtspf01 2 5,963,776 24 108,032 321 5 15,360 420 741
DocAveCache 1 2,359,296 136 1,114,112 2,494 3 24,576 270 2,764
DocAveCache 2 851,968 7 389,120 223 7 14,336 402 625
WSS_Content_RBS 1 21,233,664 146 1,409,024 2,630 1 8,192 36 2,666
WSS_Content_RBS 2 5,963,776 24 197,120 296 5 45,056 321 617
Secure_Store_Service_DB_405b13cb-0cdb-42da-bdae-4c32a6cae31f 1 2,359,296 695 5,693,440 6,131 1 8,192 22 6,153
Secure_Store_Service_DB_405b13cb-0cdb-42da-bdae-4c32a6cae31f 2 851,968 7 98,304 24 5 35,328 294 318
DocAve_ControlDB 1 6,553,600 1,229 10,084,352 15,463 40 327,680 1,617 17,080
DocAve_ControlDB 2 1,900,544 11 405,504 131 218 141,312 3,681 3,812
DocAve_AuditDB 1 2,359,296 114 933,888 1,693 1 8,192 36 1,729
DocAve_AuditDB 2 589,824 6 361,472 57 4 9,728 186 243
DocAve_ReportDB1 1 2,359,296 943 7,725,056 6,920 4,292 35,160,064 41,689 48,609
DocAve_ReportDB1 2 589,824 95 1,114,112 557 294,709 158,908,928 2,673,298 2,673,855
DocAve_ReportDB2 1 521,404,416 1,258 10,305,536 10,537 39,350 480,329,728 372,246 382,783
DocAve_ReportDB2 2 589,824 13 385,024 610 2,801,085 1,511,337,472 28,740,888 28,741,498
WSS_Content_RBS2 1 23,330,816 140 1,318,912 1,916 1 8,192 41 1,957
WSS_Content_RBS2 2 6,553,600 26 314,368 449 5 15,872 268 717
WSS_Content_mailtest 1 46,399,488 15,803 143,269,888 116,884 381 4,849,664 11,425 128,309
WSS_Content_mailtest 2 117,178,368 140 937,984 2,976 16,050 12,248,064 163,507 166,483

バッファーキャッシュの内容
 sys.dm_os_buffer_descriptors
objname index_id buffer_count
AllDocs 1 2,641
2 1,733
23 237
4,611
AllUserData 1 3,140
2 340
3,480
Solutions 1 2,266
AllLists 1 1,940
AllWebParts 2 468
1 336
804
sysobjvalues 1 784
EventReceivers 1 702
AllDocStreams 1 622
syscolpars 1 507
Webs 1 297
AllListsPlus 1 260
UserInfo 1 64
2 58
3 8
4 4
134
Perms 1 120
WebMembers 1 107
ContentTypes 1 104
AllListsAux 1 103
NavNodes 1 84
Perms 2 80

SQL Server の監視
 select * from sys.dm_os_performance_counters
カウンター名問題点・閾値・推奨値
Physical disk Avg. Disk Queue Length ディスクサブシステム / 限りなく 0 (瞬間的は可)
Physical disk Current Disk Queue Length このドライブレター上の DB 物理ファイル
Processer % Processer Time 平均値 80% 以上多くの潜在的問題点がある
System Processer Queue Length CPU プレッシャーの発生
SS Access Method Full Scans/sec 適切なインデックス不足
SS Access Method Page Split/sec デフラグの発生 / 適切な Index 設定と fill factor 値
SS Buffer Manager Page Life expectancy この値が低い場合メモリー不足
SS Database Log Flush Wait time この値が高い場合ログファイル I/O 帯域不足
SS Memory Manager Memory Grants pending クエリー実行時のメモリー不足
SS Latches Latch Waits/sec クラスタ化 Index が不適切 / tempdb 帯域不足
SS Lock requests/sec 適切なロックヒント不足 / Index が不適切
SS Lock Wait Time (ms) トランザクション間のリソース競合
SS SQL Statistics Batch requests/sec アプリケーションから受け取った T-SQL バッチ数
SS SQL Statistics SQL Compilations/sec バッチ数と比較しアドホッククエリの比率を確認
SS SQL Statistics SQL Re-Compilations/sec バッチ数と比較しリコンパイルの比率を確認

共有資源とクエリーの調査
 内部の待ち事象からの考察
 sys.dm_os_wait_stats
 SQLOS の待ち事象からシステムの状況を把握する
 処理の通常日、高負荷日の日別の待ち事象を測定する
 何が把握できるか
 アプリケーションアーキテクチャの問題点
 メモリー不足 / CPU ボトルネック / ディスクサブシステム帯域不足
 適切なインデックスの欠落
 データベース I/O 負荷の把握
 sys.dm_io_virtual_file_stats
 データベース物理ファイルとログファイルの I/O 発生状況を把握する
 OLTP 処理の通常日、高負荷日の日別の I/O 発生状況を測定する
 パフォーマンスカウンターの値
 sys. dm_os_performance_counters
 CPU コア(スケジューラ)のボトルネック
 sys.dm_os_schedulers
 プロシージャ・キャッシュの調査
 sys.dm_exec_cached_plans
 sys.dm_exec_sql_text

まとめ
SAP
ERP
データ発生
OLTP
B2C
B2B
基幹系
システム
データ抽出
転送・ロード
ETL
データ
クレンジング
Master Data
Service
Data Quality
Service
DWH
データマート
多次元
データベース
ColumnStore
Index
FileTable
Fast Track
SSD
Appliance
パラレル DWH
SQL Azure
Hadoop
MOLAP
ROLAP
Cube
MDX Query
Power Pivot
Power View
Power BI
Excel
データ分析
マイニング
SharePoint
Reporting
Service
ダッシュボード
スコアカード

http://www.cskwin.com/

Share pointを支えるsql server2014最新情報 tokyo_公開用

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (19)

Similar a Share pointを支えるsql server2014最新情報 tokyo_公開用

Similar a Share pointを支えるsql server2014最新情報 tokyo_公開用 (20)

Share pointを支えるsql server2014最新情報 tokyo_公開用