C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa

SQL Server 2012 Performance Tuning Part I & II

日本マイクロソフト株式会社 SQL Server 技術顧問熊澤幸生

Agenda

• パフォーマンスチューニングの定義 • SQL Server 共有資源の利用方法 • バランスド・システムとは • ボトルネックの把握とツール • クエリーチューニングと物理・運用設計 • SQLOS とプラットフォームチューニング • シナリオベースのデータ収集と解析 • まとめ

自己紹介 • 1977年に富士通メインフレームで初めてデータベースと出会う

• 自動車会社割賦販売システム用DB移行プロジェクト • 1979年-1983年米国駐在日系企業全米オンラインシステム構築に従事

• データ主導型アーキテクチャを学ぶ(リポジトリによるメタデータ管理 :IDMS/R) • メインフレーム上で大規模DB設計とチューニングを数多く経験

• 運送会社貨物追跡システム等を構築 • 1994年アスキーNT(現㈱CSK Winテクノロジ)設立に参加

• 設立株主 o アスキー、マイクロソフト、NTT データ、CSK (現 SCSK) 、日本興業銀行(現みずほ銀行)

• Windows Server と SQL Server に特化し、教育、構築に従事 • 現在

• SQL Server プラットフォーム上のDBコンサルティングとチューニングに従事 • ㈱CSK Winテクノロジ技術フェロー特別役員 • Microsoft MVP – SQL Server (2007.4 – 2014.3) • Microsoft Press インサイド SQL Server 2005 シリ－ズ監修 • 日本マイクロソフト株式会社 SQL Server 技術顧問 (2008.7 - )

データベースアプリケーション設計と監視

• システム開発段階 • データベース設計

o データボリューム調査 o E-R 図

• 負荷の高い処理の洗い出し • アプリケーションアーキテクチャ設計 • 移行設計 • 運用設計と物理設計 • キャパシティ設計とサイジング • クエリーチューニング • 負荷テスト

• システム運用後 • トランザクションミックスの把握 • バッチ処理とバックアップ処理を含めた運用時間の監視 • 継続的な性能監視 • 負荷の高いクエリーへの対処 • システム変更とインパクトの監視

パフォーマンスチューニングの定義

• 大きく分けて二つのフェーズ • 第一フェーズ : クエリーチューニング

o システム開発段階でのデータベース構造の最適化と主要クエリー処理の最適化 – テーブル構造とキーの選択 – インデックスの選択 – 結合処理の最適化 – SQL Server 固有の物理設計の理解が重要となる

• 第二フェーズ : プラットフォームチューニング o システム移行段階

– H/W の選択と本稼働環境のパラメータ設定 – データベース保守の決定と導入

» インデックス再構築と統計情報の更新

o システム本稼働運用 – トランザクションミックスの把握 – 継続的な性能測定とプラットフォームチューニング – 負荷の高いクエリーへの対処 – データ (インデックスとデータ) のメモリー利用状況 – アプリケーションサービス追加と変更への対処

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

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

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

• ストレージ o ユーザ DB / tempdb の物理ファイル (データファイルとトランザクションログファイル)を、

Windows OS 上のファイルシを関連付け、一括管理をする o デバイスタイプと接続方法により発生するボトルネックは異なる

• ネットワーク o デバイスタイプと接続方法により発生するボトルネックは異なる

• 個々のクエリー実行時に必要な共有資源 • クエリーのタイプと実装方法により大きく異なる

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

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

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

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

• 内部の待ち事象からの考察 • 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

バランスドシステムとは

• SQL Server RDB エンジンに最適化されたハードウエア構成 • リファレンスアーキテクチャ : 松竹梅モデル

• 考慮すべき構成要素 (共有資源) • プロセッサ • メモリ • ストレージサブシステム • ネットワーク

• SQL Server 専用サーバー上に配置する • トランザクション処理用と、DWH系は、分離したサーバー上に配置する

• 将来のトランザクションベースラインを明確化する • SQLOS の内部動作を理解する

CPU タイプの選定 • 主流は、x 64 アーキテクチャ • NUMA アーキテクチャサポートの有無

• NUMA 対応 CPU o Intel Xeon E3 / E5 / E7 シリーズ o AMD Opteron o CPU ソケット内にローカルメモリコントローラーと複数の高速インターコネクトを内蔵

• マルチコア化が今後も加速 • Intel Xeon E3 4 Core/ソケット • Intel Xeon E5 8 Core/ソケット • Intel Xeon E7 10 Core/ソケット • AMD Opteron 16 Core/ソケット

• クロック数と、キャッシュサイズも重要 • CPU 占有率の監視より、コア数不足(SQLOS スケジューラと 1: 1) を監視する

必要なメモリサイズの考え方

• SQL Server 2000 では、最もクリティカルな共有リソースだった • 現在 x64 64 ビットアドレス方式が主流 • SQL Server 2012 Enterprise は、最大 4TB のメモリ空間を提供 • 必要な物理メモリサイズは?

• NUMA アーキテクチャの場合 o NUMA ノードあたり 32 – 64GB を推奨

• SMP アーキテクチャの場合 o CPU コアあたり、4 - 8 GB をスタートラインに

• OLTP の場合、ユーザー DB 容量の 10% を目安にメモリ見積もりを実施する • 現在でも、メモリー不足を起因とする、トランザクション後負荷時の、クエリー処理遅延を数多く見かける o 表面上はストレージサブシステムのボトルネックとして表面化する

メモリー見積もりの詳細

• 必要とメモリーの見積もり方法 • Max Server Memory パラメータに含まれるもの

o データキャッシュ領域 – ユーザデータベースサイズに依存する

o プロシージャキャッシュ領域 – 最大値は、サーバー物理メモリーに依存する – アプリケーションに依存する

o 論理ログファイル領域 – 実行されるトランザクション処理負荷に依存する

o クエリー実行時の作業領域 o ユーザ接続管理領域 o ロック管理テーブル o その他システム領域

• Windows Server と SQL Server のメモリー o 実測値で、約 1GB

• SQL Server の起動時予約メモリー領域 o Memory to Leave 領域

– 既定値 256MB o Worker Threads Stack 領域

– CPU の論理プロセッサー数により自動決定される

64 ビット SQL Server メモリー空間

12 オペレーティングシステム領域

System

data structures

Lock

Procedure C

ache

Log cache

Users C

onnection context

Buffer cache

SQL Server カーネル領域ワーカースレッドスタック

CLR / 拡張ストアド / その他

仮想メモリー空間 : 4TB max server memory

ストレージサブシステムの選定

• 接続方法 • HBA 経由ファイバーチャネル接続

(複数 HBA による MPIO 構成を推奨する) • iSCSI • DAS

o PCI 直結型 (高信頼性 SSD : Violin Memory Array / fusion I/O)

• デバイスタイプ • 処理スピード順 (目的別の階層化を考慮)

o SSD/FC ディスク/SAS/SATA • トランザクションログ

o 順アクセスの書込み処理 (1,000 IOPS/物理ドライブ) • トランザクション処理

o 複数の高回転 (15,000 rpm) デバイスを利用 • DWH

o 大容量の中速ディスクを利用

• 容量より、回転数と物理ディスクの数が重要 • RAID 1 + 0 を推奨

• (4 + 4) 2 LUN (ユーザーデータ領域、tempdb 領域) • (3 + 3) 2 LUN (トランザクションログ領域、Index 領域) • 搭載する物理ディスク数は、データボリュームとトランザクション負荷により決定する

代表的な監視ツール

• パフォーマンスモニター • サーバー全体のスループットと共有資源の負荷状況の把握

• Profiler • ユーザが実行中のクエリーの収集と再現テストの実施 • デッドロックとブロッキングの原因究明

• SQL Server パフォーマンスデータコレクション • SQL Server サーバーダッシュボード • 動的管理ビュー (DMV) と動的管理関数 (DMF)

• SQL Server 2000 は非公開のコマンドと関数が、SQL Server 2005 以降動的管理ビュー (DMV) 、動的管理関数 (DMF) として公開

• 3RD ベンダーパフォーマンス監視ツール • DELL Software Spotlight on SQL Server

SQL Server サーバーダッシュボード

取得可能な数値

• 動的管理ビュー、動的管理関数、パフォーマンスカウンターでは、二種類の数値を取得できる • 累積値

o データベースファイル別 I/O 統計情報 o ロック、ラッチタイプ別発行回数と待ち時間

– ロック : ACID プロパティ実現のためにトランザクション終了まで保持される排他制御 – ラッチ : 主に SQLOS ストレージエンジンが内部処理の為に、一時的に内部で実施する排他制御

o SQLOS 待ち事象別発生回数と待ち時間累積値

• 現在の値 o CPU占有率 o トランザクション数 / 秒 o ディスク I/O 待ちキュー発生数 o バッチとコンパイル発生 / 秒 o ディスク I/O 負荷

クエリー実行時の監視

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

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

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

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

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

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

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

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

クエリープランの分析

プロシージャキャッシュ内容の取得

-- プロシージャキャッシュの内容を取得 SELECT st.text, cp.plan_handle, cp.usecounts, cp.size_in_bytes, cp.cacheobjtype, cp.objtype FROM sys.dm_exec_cached_plans cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st ORDER BY cp.usecounts DESC;

キャッシュプランの分析 (1) text usecounts size_in_bytes cacheobj type objtype

(@I_ID nvarchar(4))SELECT I_ID,I_THUMBNAIL FROM ITEM WHERE (I_ID=(SELECT I_RELATED1 FROM ITEM WHERE I_ID=@I_ID) OR I_ID=(SELECT I_RELATED2 FROM ITEM WHERE I_ID=@I_ID)OR I_ID=(SELECT I_RELATED3 FROM ITEM WHERE I_ID=@I_ID)OR I_ID=(SELECT I_RELATED4 FROM ITEM

218,493 155,648 Compiled Plan Prepared

(@I_ID nvarchar(4))SELECT I.I_TITLE,A.A_FNAME,A.A_LNAME,I.I_SUBJECT,I.I_IMAGE,I.I_DESC,I.I_COST,I.I_SRP,I.I_SRP-I.I_COST DISCOUNT,I.I_BACKING,I.I_PAGE,I.I_PUBLISHER,I.I_PUB_DATE,I.I_AVAIL,I.I_DIMENSIONS,I.I_ISBN FROM ITEM I with(NOLOCK),AUTHOR A with(NOLOC


(@I_ID nvarchar(3))SELECT I_ID,I_THUMBNAIL FROM ITEM WHERE (I_ID=(SELECT I_RELATED1 FROM ITEM WHERE I_ID=@I_ID) OR I_ID=(SELECT I_RELATED2 FROM ITEM WHERE I_ID=@I_ID)OR I_ID=(SELECT I_RELATED3 FROM ITEM WHERE I_ID=@I_ID)OR I_ID=(SELECT I_RELATED4 FROM ITEM


(@A_LNAME nvarchar(15))SELECT TOP 50 A_FNAME, A_LNAME, I_ID, I_TITLE FROM ITEM I with(NOLOCK), AUTHOR A with(NOLOCK) WHERE (I.I_A_ID = A.A_ID) AND (A_LNAME LIKE @A_LNAME) ORDER BY I.I_TITLE ASC


(@I_TITLE nvarchar(16))SELECT TOP 50 A_FNAME, A_LNAME, I_ID, I_TITLE FROM ITEM I with(NOLOCK), AUTHOR A with(NOLOCK) WHERE (I.I_A_ID = A.A_ID) AND (I.I_TITLE LIKE @I_TITLE) ORDER BY I.I_TITLE ASC


(@C_ID nvarchar(9))SELECT C_LNAME,C_FNAME FROM CUSTOMER WHERE C_ID=@C_ID 17,234 16,384 Compiled Plan Prepared

(@I_ID1 nvarchar(4))SELECT I.I_ID, I.I_COST, I.I_SRP, I.I_TITLE, I.I_BACKING FROM ITEM I, ITEM J WHERE J.I_ID = @I_ID1 AND J.I_RELATED1 = I.I_ID


(@C_ID nvarchar(8))SELECT C_LNAME,C_FNAME FROM CUSTOMER WHERE C_ID=@C_ID 6,401 16,384 Compiled Plan Prepared

(@I_ID nvarchar(4))SELECT I_ID, I_COST, I_SRP, I_TITLE, I_BACKING FROM ITEM WHERE I_ID = @I_ID 6,278 16,384 Compiled Plan Prepared

(@I_ID nvarchar(3))SELECT I.I_TITLE,A.A_FNAME,A.A_LNAME,I.I_SUBJECT,I.I_IMAGE,I.I_DESC,I.I_COST,I.I_SRP,I.I_SRP-I.I_COST DISCOUNT,I.I_BACKING,I.I_PAGE,I.I_PUBLISHER,I.I_PUB_DATE,I.I_AVAIL,I.I_DIMENSIONS,I.I_ISBN FROM ITEM I with(NOLOCK),AUTHOR A with(NOLOC


(@SYSDATETIME nvarchar(4000),@EXPIRATIONDATETIME nvarchar(4000),@C_ID nvarchar(9))UPDATE CUSTOMER SET C_LOGIN = @SYSDATETIME, C_EXPIRATION = @EXPIRATIONDATETIME WHERE C_ID = @C_ID


(@C_UNAME nvarchar(18))SELECT C.C_ID, C.C_UNAME, C.C_PASSWD, C.C_FNAME, C.C_LNAME, C.C_ADDR_ID, C.C_PHONE, C.C_EMAIL, C.C_DISCOUNT, C.C_BALANCE, C.C_YTD_PMT, C.C_BIRTHDATE, C.C_DATA, A.ADDR_STREET1, A.ADDR_STREET2, A.ADDR_CITY, A.ADDR_STATE, A.ADDR_ZIP, A.


(@SCL_I_ID nvarchar(4),@I_STOCK nvarchar(2))UPDATE ITEM SET I_STOCK = @I_STOCK WHERE I_ID = @SCL_I_ID


(@SCL_I_ID nvarchar(4))SELECT I_STOCK FROM ITEM WHERE I_ID = @SCL_I_ID 4,000 16,384 Compiled Plan Prepared

SELECT MAX(O_ID) AS MAX_O_ID FROM ORDERS with(NOLOCK) 3,563 16,384 Compiled Plan Adhoc

(@1 varchar(8000))SELECT [I_ID],[I_COST] FROM [ITEM] WHERE [I_ID]=@1 3,409 40,960 Compiled Plan Prepared

(@I_SUBJECT nvarchar(8))SELECT TOP 50 A_FNAME, A_LNAME, I_ID, I_TITLE FROM ITEM I with(NOLOCK), AUTHOR A with(NOLOCK) WHERE (I.I_A_ID = A.A_ID) AND I.I_SUBJECT = @I_SUBJECT ORDER BY I.I_TITLE ASC


キャッシュプランの分析 (2)

text plan_generation_num creation_time

execution_count

last_elapsed_time (μs)

min_elapsed_time (μs)

max_elapsed_time (μs)

create procedure [dbo].[GetRandomCustID] (@CustomerID varchar(5)=NULL output) as -- Update by Y.Kumazawa June,08,2011 declare @CustLetter varchar(4) declare @pos int select @pos = datepart(ms,getdate())%137 select @pos = @pos * 2 select @pos = @pos + 1 select @CustLetter = substring('AIALAMANAOARBABBBEBLBMBPBQBSCACBCCCECHCOCPDADCDRDUEAEBEDERFAFCFEFOFQFRFSFTFUGAGCGOGPGRGSHAHCHIHUHWIRISITJAJFJKJLKAKDKOLALBLCLDLELFLGLHLILJLOMAMBMCMDMEMONANCNOOAOBOCOLOTPAPBPCPEPIPRQRQSQVQWRARBRCRDRERIRJSASBSCSDSESISPSQTDTETHTITOTPTSUVUWVAVCVDVIVJWAWBWCWDWEWHWIWOXAXDYAYDZIZK',@pos,2) select @CustomerID = CustomerID from Customers WITH(NOLOCK) where CustomerID like @CustLetter + '%' 1

2013/2/19 10:51 1,303 79 37 5,471

create procedure GetRandomEmpID (@EmployeeID int=0 output) as -- This is provided "AS IS" with no warranties, and confers no rights. -- Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm -- declare @EmpLetter varchar(1) select @EmpLetter = substring('ABCDFKLMNPRT',datepart(ms,getdate())%12,1) select @EmployeeID = EmployeeID from Employees where LastName like @EmpLetter + '%' or FirstName like @EmpLetter + '%' 1

2013/2/19 10:51 497 117 23 5,811

create procedure [dbo].[GetCustInfo] (@CustomerID varchar(5)=NULL) as -- This is provided "AS IS" with no warranties, and confers no rights. -- Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm -- -- Update by Y. Kumazawa June,20,2011 if @CustomerID is NULL exec GetRandomCustID @CustomerID=@CustomerID output select CompanyName, ContactName, Address, City, Region, PostalCode, Country, Phone from dbo.Customers WITH(NOLOCK) where CustomerID = @CustomerID 1

2013/2/19 10:51 236 14 7 97

create procedure GetRandomProductID (@ProductID int=0 output) as -- This is provided "AS IS" with no warranties, and confers no rights. -- Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm -- declare @maxProdID int select @maxProdID=max(ProductID) from Products select @ProductID=cast (round(@maxProdID*rand(),0) as int) 1

2013/2/19 10:51 232 31 10 106

キャッシュプランの分析 (3)

sqlplan として保存した実行プラン

クエリー実行プラン

• 不足しているインデックスを表示

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

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

•データページのアクセスが不要となり 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_NAME FROM DEPARTMENT WHERE DEPARTMENT_CODE < 10 AND 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 » データはヒープ構造として保持される

クラスタ化インデックスでの行の検索

• クラスタ化インデックスは indid = 1 のエントリを持つ

• root列はクラスタ化インデックスのル－トレベルを指す

• SQL Server はル－トレベルよりインデックスをたどって移動し、クラスタ化インデックスキーに対応する行を検索

• 連続した範囲のキーの検索は、範囲内の開始キー値を見つけ、前後のポインタを使用してデータページをスキャン

ページ 141

Akhtar Ganio

…

ページ 145

Martin Smith

…

Martin

sysindexes

ページ 120 ページ 130 ページ 110 ページ 100

Akhtar Barr Con Funk Funk ...

2334 5678 2534 1334 1534 ...

...

...

...

...

...

...

Smith Smith Smith White White ...

1434 5778 7978 2234 1634 ...

...

...

...

...

...

...

Ganio Hall Jones Jones Jones ...

7678 8078 2434 5978 2634 ...

...

...

...

...

...

...

Martin

Ota Phua Rudd ...

1234

5878 7878 6078 ...

...

...

...

...

...

リ－フレベル

ページ 140 – ルート

Akhtar …

Martin Martin

id indid = 1 ルート

Martin 7778 ...

非クラスタ化インデックスの行の検索

• 非クラスタ化インデックスはindid = 2～255のエントリを持つ

• root列は非クラスタ化インデックスのル－トレベルを指す

• SQL Server はル－トレベルよりインデックスをたどって移動し、非クラスタ化インデックスキーと共に行ロケ－タを取得

• 行ロケ－タによってポイントされた対応する行をヒ－プより見つける

sysindexes

ページ 140 – ルート

Akhtar …

Martin Martin


ページ 130 ページ 110 ページ 100

Akhtar Barr Con Funk Funk ...

2334 5678 2534 1334 1534 ...

...

...

...

...

...

...

Smith Smith Smith White White ...

1434 5778 7978 2234 1634 ...

...

...

...

...

...

...

Ganio Hall Jones Jones Jones ...

7678 8078 2434 5978 2634 ...

...

...

...

...

...

...

Martey 1234 ... ページ 141

Akhtar Ganio

…

ページ 145

Martin Smith

…

Martin

リ－フレベル（キ－値）

ヒ－プ

01 02 03 04 ...

...

...

...

...

...

Akhtar Funk Smith Matey

...

ページ 707 ページ 808 ページ 709 ページ 704 ページ 705 ページ 706 01 02 03 ... ...

...

...

...

...

...

Conn Funk White

...

...

01 02 03 ... ...

...

...

...

...

...

Rudd White Barr ... ...

01 ... Smith 01 02 03 ... ...

...

...

...

...

...

Ganio Jones Hall ... ...

04 ... Matey

Martin 7778 ...

01 ... Martin 02 03 04 ...

...

...

...

...

Phua Jones Smith ...

ページ 120

Ota Phua Rudd ...

5878 7878 6078 ...

...

...

...

...

02 ... Ota 03 ... ...

...

...

...

Jones ... ...

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

• SQL Server はル－トレベルより非クラスタ化インデックスをたどって移動し、非クラスタ化インデックスキーと共にクラスタ化キ－を取得

• 取得したクラスタ化キーを用いて、再度クラスタ化インデックスをルートレベルより探索

• クラスタ化インデックスキーに対応する行を見つける

Aaron Deanna …

Aaron ... Jose

Jose Nina …


sysindexes

Barr Kim Nagata O’Melia Nash

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

クラスタ化インデックス

Deanna Don Doug

Daum Hall Hampton

… …

Aaron Adam Amie

Con Barr Baldwin

… …

Jose Judy Mike

Lugo Kaethler Nash

… … Mike Nash

Barr Adam Cox Daum

Arlette Deanna

… …

… … … …

Kim Kobara LaBrie

Shane Linda Ryan

… …

… … … …

Nagata Nash Nixon

Susanne Mike Toby

… …

… … … …

Nash Mike …

リ－フレベル（クラスタ化キ－値）

リ－フレベル

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

• テーブル毎の検索方法の決定 • テーブルの行数とデータページ数、保持するインデックスの把握 • テーブルスキャン or インデックス検索の決定

o クラスタ化インデックスと非クラスタ化インデックス – それぞれのインデックスの持つ統計情報を参照する

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

• どの検索方法を取るかが決まる • Join アルゴリズムの決定

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

• 推測行数により、Join アルゴリズムを決定する • テーブル単位の中間結果セットを用いた結合処理 • 集計、ソート処理 • 最終結果セットの作成

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

• データの特性、利用方法 • クラスター化インデックスを付与する列の場合、Insert する行のキー値の分布を把握する o ランダム値、昇順値 (伝票番号等) o 複合列 (複数列で構成するキー)

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

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

• インデックス作成に適していない列 • クエリで参照されない列 • 一意の値を含まない列 • text、ntext、image データ型属性を持つ列 • null、可変長属性を持つ列

格納領域断片化の発生原因と防止方法

• 格納領域断片化の原因 • ページ分割の発生原因 o データの追加と更新処理

– insert 処理は、クラスター化インデックスのキー値により、格納ページを決定する

– 空き領域がなかった場合、ページ分割処理が発生する – ページ分割により、分割された後半のデータページに対応するインデックス情報を追加する

– update 処理は、可変長属性、null 属性をもつ列に更新が発生した場合、物理的な行の長さが変わり、同一領域に格納できない時に発生する

• 発生場所 o データページとインデックスページ

• 断片化の防止方法 • インデックス再構築・再構成時に fillfactor を指定して、将来の追加領域を確保する o クラスター化インデックス領域に指定可能 (0-100%) o インデックスキー値の分布状況と、再構築・再構成の実施頻度により fillfactor の値を決定する

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

ページ分割の抑制

FillFactor が設定されていない状態

データ : “①②③④” 使用済み領域

データページの領域不足により、ページ分割が発生

空き領域

FillFactor による予約域の確保

FillFactor : 70

ページ

ページ

使用済み領域

データ追加用の予約域

予約域が予め確保されることにより、ページ分割の発生が抑制

データ : “①②③④”

①② ③④

①② ③ ④

PageLatchが発生する

データベースの運用設計 - インデックス再構築と再構成のタイミング - • 再構築とは

• ALTER INDEX REBULD (DBCC DBREINDEX) • エクステント、論理ページ両方の格納領域の断片化 (Fragmentation) を解消 • オフライン操作

o SQL Server 2008 以降の Enterprise 版は、オンライン再構築をサポート – 自分自身の格納領域と、tempdb 領域を利用する

• 再構成とは • ALTER INDEX REORGANIZE (DBCC INDEX DEFRAG) • 論理ページの格納領域の断片化を解消 • オンライン操作が可能

• 実施タイミング • 動的管理ビュー sys. dm_db_index_physical_stats による定期的な監視

o エクステント、論理ページの 10% を超える断片化が発生したときに実施する o 例) 再構成を週に 1 回、再構築を月に 1 回実施

• sort in tempdb オプションを利用する • 統計情報も同時に更新される

断片化の解消

“エクステント” ＝ 8 ページ (ページの管理単位)

① ③ ② ④

空き領域使用済み領域

インデックスキー値の順番 : ① ② ③ ④ ・・・・

INDEX REBULD の実行

① ② ③ ④ ・・・ OS の IO 単位

OS の IO 単位

現在 : “ページ分割によりデータの断片化が発生している状態”

データベースの運用設計 - 統計情報とは - • クエリオプティマイザーが最適なクエリ実行プランを作成するための情報 • インデックスを構成する列の値をサンプリングし、分布情報を格納「どうのような値をもつデー-タが何件入っているか? 」 • クエリオプティマイザーは統計情報を使用して、クエリに対してどのインデックスを使用するかの実行コストを予測し、利用の有無、利用方法を判断する

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

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

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

• 統計情報の保守 • 自動更新 (既定) : インデックス単位に保持している更新状況から、一定の閾値を超えた時に実行される

• 手動更新: update statistics on <テーブル名>

統計情報の確認

dbcc show_statistics (‘テーブル名’, ‘インデックス名')

大規模データのパフォーマンスと管理性を向上 • データパーティション機能

• 大規模なテーブルを論理的なパーティションに分割、複数の小さなテーブルとして利用 • クエリやインデックス、バックアップの範囲を縮小し、パフォーマンスと管理性を向上

2003 ～ 2008 年売上明細テーブルパーティション 1

パーティション 2



2010 年

2009 年

2008 年

2007 年

複数パーティションに対する高速なクエリの実行

パーティション単位で管理や保守を実施

OK

クエリパフォーマンスの向上並列処理の強化で複数のパーティションにまたがるクエリを高速に実行可能

複数ユーザーの同時実行性を向上テーブルおよびパーティションレベルのロックエスカレーション制御に対応

ダウンタイムの削減障害やメンテナンスの範囲を最小化し、対象外のパーティションは継続的に利用可能

大規模データの管理効率を向上パーティション単位でインデックスの構築やバックアップ/復元、データの入れ替えが可能

障害

データパーティション機能大規模なデータを論理的なパーティションで分割

データパーティションの適用シナリオ

• データベース保守時間の短縮化 • バックアップデータ取得の局所化 • インデックス再構築の局所化 • 統計情報更新処理の局所化

• ストレージ・デバイス選択の階層化 • SSD (アクティブデータ) • SAS (検索頻度の高いデータ) • SATA (大量のアーカイブデータ)

• スライディング・ウィンドウズの有効利用 • 月次単位の集計処理 • 前年同月比較処理

SQL Server 主要機能 Network Protocol

SQL O

S API

Query Processor (Relational Engine)

Parser Optimizer SQL Manager DB Manager Query Executer

Buffer Manager

Transaction Services

Lock Manager

File Manager

Storage Engine

Utility: BCP DBCC Backup/Restore

Access Methods Manager: Row Operations Indexes Pages Allocation Versions

SQL OS API

SQL OS

Schedule Monitor

Deadlock Monitor

Resource Monitor

Lazy Writer Buffer Pool

Memory Manager Scheduling Synchronization

Services

Lock Manager

I/O

SQLO

S Hosting A

PI

External Com

ponents (CLR/M

DA

C)

MS DTC (Distributed Transaction Coordinators )

リレーショナルエンジンのコンポーネント

• ネットワークプロトコル経由で、T-SQL バッチとして処理単位を分割する

• パーサー • オプティマイザ

• コストベースのオプティマイザ • 統計情報(キーの分布状況)により最適プランを選択 • クエリーの実行プランをプロシージャキャッシュ内に格納する • プロシージャキャッシュに格納された、ストアドプロシージャ、プリペアードクエリーは、再利用が可能

• SQL マネージャ • DB マネージャ • クエリエグゼキュータ

• プロシージャキャッシュ上の実行プランを、実行ステップごとにストレージエンジンに実行を依頼し、結果セットを取得

• 実行コンテキストは、プロセス単位 (spid) に作成する • インタープリター形式で実行する

ストレージエンジンのコンポーネント

• クライアントからの T-SQL をトランザクション属性を保証してサーバー全体の実行管理を行う。

• トランザクションサービス • ACID プロパティとIsolation

• ロックマネージャ • ロックとラッチ o ロック : トランザクション終了まで排他処理を行う o ラッチ : ストレージエンジンの内部処理用で、トランザクション処理とは非同期に動作する

• ファイルマネージャ • ユーティリティ

• BCP / Backup Restore / DBCC ユーティリティ • アクセスメソッド

• 行操作 / インデックス検索 / ページ領域管理 / 領域の割当 / バージョン管理 • 外部コンポーネントインターフェース

NUMA の特徴

• CPUは他ノードを含む全ての物理メモリをマップ可能 • 同一ノード内にあるメモリをローカルメモリ、他ノードにあるメモリをリモートメモリと呼ぶ • ローカルメモリに対するアクセスの方が効率が良い

• 効率の良いメモリアクセスを行うには、Server OS と RDBがNUMAに対応している必要がある

メモリーコントローラ

CPU

CPU

CPU

CPU

メモリ

インターコネクト


CPU

CPU

CPU

CPU

メモリ

SQL Server と NUMA

• 起動時に NUMA Node の役割を決定する • Server name is 'WIN-AE68NA9TPVA'. • The resource database build version is 10.50.1765. • Node configuration: node 7: CPU mask: 0x00000000000ffc00:1 Active CPU mask: 0x00000000000ffc00:1. • Node configuration: node 6: CPU mask: 0x00000000000003ff:1 Active CPU mask: 0x00000000000003ff:1. • Node configuration: node 5: CPU mask: 0x0ffc000000000000:0 Active CPU mask: 0x0ffc000000000000:0. • Node configuration: node 4: CPU mask: 0x0003ff0000000000:0 Active CPU mask: 0x0003ff0000000000:0. • Node configuration: node 3: CPU mask: 0x000000ffc0000000:0 Active CPU mask: 0x000000ffc0000000:0. • Node configuration: node 2: CPU mask: 0x000000003ff00000:0 Active CPU mask: 0x000000003ff00000:0. • Node configuration: node 1: CPU mask: 0x00000000000003ff:0 Active CPU mask: 0x00000000000003ff:0. • Node configuration: node 0: CPU mask: 0x00000000000ffc00:0 Active CPU mask: 0x00000000000ffc00:0. • Lock partitioning is enabled. • Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node. • Using locked pages for buffer pool. • Large Page Allocated: 32MB • Large Page Allocated: 32MB • Large Page Allocated: 32MB • Large Page Allocated: 32MB • Large Page Allocated: 32MB • Large Page Allocated: 32MB • Large Page Allocated: 32MB • Large Page Allocated: 32MB • Large Page Granularity: 2,097,152 • Large Page Extensions enabled. • Detected 80 CPUs. • SQL Server is starting at normal priority base (=7). • Registry startup parameters: <nl/> -d C:¥Program Files¥Microsoft SQL Server¥MSSQL10_50.MSSQLSERVER¥MSSQL¥DATA¥master.mdf<nl/> -e C:¥Program

Files¥Microsoft SQL Server¥MSSQL10_50.MSSQLSERVER¥MSSQL¥Log¥ERRORLOG<nl/> -l C:¥Program Files¥Microsoft SQL Server¥MSSQL10_50.MSSQLSERVER¥MSSQL¥DATA¥mastlog.ldf

• This instance of SQL Server last reported using a process ID of 24724 at 2011/05/25 15:22:44 (local) 2011/05/25 6:22:44 (UTC). • Logging SQL Server messages in file 'C:¥Program Files¥Microsoft SQL Server¥MSSQL10_50.MSSQLSERVER¥MSSQL¥Log¥ERRORLOG'. • Authentication mode is MIXED. • System Manufacturer: 'HP'<c/> System Model: 'ProLiant DL980 G7'. • Server process ID is 1760. • All rights reserved. • (c) Microsoft Corporation. • Microsoft SQL Server 2008 R2 (RTM) - 10.50.1765.0 (X64) <nl/> Feb 2 2011 17:33:22 <nl/> Copyright (c) Microsoft Corporation<nl/>

Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1

SQL Server と NUMA ノード

インターコネクト

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

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

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

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

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

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

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

• 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_stats o LOGBUFFER

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

o Memory Manager Memory Grants Outstanding • Sys. dm_os_wait_stats

o RESOURCE_SEMAPHORE o CMEMTHREAD

MAX DOP とは

• max degree of parallelism パラメータ • サーバーのプロパティ詳細設定

o 並列処理の最大限度

• sp_configure max degree of parallelism パラメータ

• 既定値は 0 o 各ユーザセッションは、SQL Server が認識しているスケジューラ(論理CPUコア)全てを用いて、並列処理を実行可能 – バッチ処理には適切な設定

» 処理時間短縮化を重視 – OLTP 処理では、トランザクション処理の同時実行性を重視

o SQL Server オプティマイザは、実行プラン作成時に、並列処理可能なプランを自動認識する

並列処理の最大限度 (MAX DOP) の考慮

• 並列処理の最大限度とは • ユーザ・コネクションから受け取った T-SQL は、オプティマイザにより、木構造の複数の実行ステップに、分解される

• 各実行ステップは、一つ以上の CPU (スケジューラ) 上で実行される • この時の、1 タスクが実行可能な並列処理の多重度を、並列処理の最大限度と呼ぶ

• 考慮点 • 並列処理は、NUMA の同一ノード上で実行されることが、メモリーアクセス効率化の観点からも重要である。 o NUMA ローカルメモリーアクセスと、リモートメモリーアクセスを比較すると、数倍の時間を必要とする

• チューニングポイント • NUMA の場合

o 並列処理の最大限度 (MAX DOP) を、ソケット内の物理 CPU コア数に制限する

アクティビティの取得タイミング

• 初期化処理と固定情報の取得 • リアルタイム取得 • OLTP 終了時 • バッチ終了時

初期化処理と固定情報の取得

• 累積値を表示する DMVs • sys.dm_os_wait_stats

o dbcc sqlperf(‘sys.dm_os_wait_stats’, clear) 累積値をリセットする

• sys.dm_os_latch_stats o dbcc sqlperf(‘sys.dm_os_latch_stats’, clear) 累積値をリセットする

• sys.dm_io_virtual_file_stats o 差分計算を行うための開始時の値を保存する

• 固定情報の取得 • sys.dm_os_sys_info

o SQL Server サービスが、Win32API を利用して取得する固定情報

• sp_configure o SQL Server 構成情報を取得

• sp_helpdb o データベース物理配置と格納情報を取得

リアルタイム取得

• 取得する情報 • スケジューラの動作状況 • SQL Server パフォーマンスカウンターオブジェクト

• Windows Serverパフォーマンスカウンターオブジェクト

• ロックの発行状況 • ブロッキングの発生状況 • 負荷の高いクエリーの実行プラン

• 3rd ベンダーの監視ツールの活用 • デル・ソフトウエア

o Spotlight on SQL Server

OLTP とバッチ終了時

• 取得する情報 • データベースごとの、データキャッシュ上のオブジェクト利用状況

o 検索頻度の高いテーブルとインデックスを知ることが可能

• プロシージャキャッシュ上の実行プラン情報 • データベースごとの、データ領域断片化情報 • データベースごとの、統計情報の最終更新日時 • 不足しているインデックス情報 • 累積値差分計算用情報

o sys.dm_os_wait_stats o sys.dm_os_latch_stats o sys.dm_io_virtual_file_stats

構成情報

• ユーザデータベース定義 • テーブルとインデックス定義 • SQL Server インスタンス構成情報 • ユーザ定義ストアードプロシージャ、関数等

データの可視化と事実の把握

• 採取したデータを可視化して整理 • 数字や文字列だけではわからない傾向が見えてくる • 事実の積み上げ方は自然と決まってくる

o サーバーの環境設定 (HW / SW / パラメータ) o リソースのアクティビティ (CPU / Memory / Disk) o データ領域とインデックス定義 o ロックとトランザクション

• 積み上げた事実を客観的に把握 • 全体を正しく把握することは意外と難しい • この時点では事実はただの『点』に過ぎない

※分析を進めると意外なところに原因があったりする

問題を特定

• 仮説と検証を繰り返し問題を特定 • 発生している事象からいくつかの問題を推測 • その推測が積み上げた事実の上に成り立つか検証

※説明のつかない事象がある場合は要注意 • 『点』と『点』を線で結ぶようなイメージ

※SQL Server に関する知識と経験に加え洞察力が求められる

まとめ

• セミナーの目的 • トラブルの分析手段と、チューニング方法が SQL Server に存在することを理解してもらう

• 実際の利用シナリオに沿って、何が判明して、どうすれば解決するかの観点で作成した

• バランスド・システムのコンセプト • 共有リソースを理解し、あらかじめ将来のデータ量増加、トランザクション負荷を考慮した、H/W サイジングを実施する

• 10 年間にわたり、実際のお客様で得たものをベストプラクティスとして記載した

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

Technology

C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa