SlideShare uma empresa Scribd logo
1 de 61
Baixar para ler offline
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
オペレーティング システム領域
Systemdatastructures
Lock
ProcedureCache
Logcache
UsersConnectioncontext
Buffercache
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,648Compiled 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
46,767 32,768Compiled Plan Prepared
(@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
21,724 40,960Compiled Plan Prepared
(@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
17,575 49,152Compiled Plan Prepared
(@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
17,497 622,592Compiled Plan Prepared
(@C_ID nvarchar(9))SELECT C_LNAME,C_FNAME FROM CUSTOMER WHERE C_ID=@C_ID 17,234 16,384Compiled 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
8,687 24,576Compiled Plan Prepared
(@C_ID nvarchar(8))SELECT C_LNAME,C_FNAME FROM CUSTOMER WHERE C_ID=@C_ID 6,401 16,384Compiled 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,384Compiled 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
5,587 32,768Compiled Plan Prepared
(@SYSDATETIME nvarchar(4000),@EXPIRATIONDATETIME nvarchar(4000),@C_ID nvarchar(9))UPDATE
CUSTOMER SET C_LOGIN = @SYSDATETIME, C_EXPIRATION = @EXPIRATIONDATETIME WHERE C_ID =
@C_ID
4,207 24,576Compiled Plan Prepared
(@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.
4,207 65,536Compiled Plan Prepared
(@SCL_I_ID nvarchar(4),@I_STOCK nvarchar(2))UPDATE ITEM SET I_STOCK = @I_STOCK WHERE I_ID =
@SCL_I_ID
4,000 24,576Compiled Plan Prepared
(@SCL_I_ID nvarchar(4))SELECT I_STOCK FROM ITEM WHERE I_ID = @SCL_I_ID 4,000 16,384Compiled Plan Prepared
SELECT MAX(O_ID) AS MAX_O_ID FROM ORDERS with(NOLOCK) 3,563 16,384Compiled Plan Adhoc
(@1 varchar(8000))SELECT [I_ID],[I_COST] FROM [ITEM] WHERE [I_ID]=@1 3,409 40,960Compiled 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,915 32,768Compiled Plan Prepared
キャッシュプランの分析 (2)
text
plan_generati
on_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('AIALAMANAOARBABBBEBLBMBPBQBSCACBCCCECHCOCPDADCDRDUE
AEBEDERFAFCFEFOFQFRFSFTFUGAGCGOGPGRGSHAHCHIHUHWIRISITJAJFJKJLKAK
DKOLALBLCLDLELFLGLHLILJLOMAMBMCMDMEMONANCNOOAOBOCOLOTPAPBP
CPEPIPRQRQSQVQWRARBRCRDRERIRJSASBSCSDSESISPSQTDTETHTITOTPTSUVUW
VAVCVDVIVJWAWBWCWDWEWHWIWOXAXDYAYDZIZK',@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
…
MartinMartin
id indid = 1 ルート
Martin 7778 ...
非クラスタ化インデックスの行の検索
• 非クラスタ化インデックス
はindid = 2~255のエント
リを持つ
• root列は非クラスタ化
インデックスのル-ト
レベルを指す
• SQL Server はル-トレベ
ルよりインデックスをた
どって移動し、非クラスタ
化
インデックス キーと共に
行ロケ-タを取得
• 行ロケ-タによってポイン
トされた対応する行をヒ-
プより見つける
sysindexes
ページ 140 – ルート
Akhtar
…
MartinMartin
id indid = 2 ルート
ページ 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
…
id indid = 2 ルート
sysindexes
Barr
Kim
Nagata
O’MeliaNash
非クラスタ化
インデックス
クラスタ化
インデックス
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
パーティション 3
パーティション 4
2010 年
2009 年
2008 年
2007 年
複数パーティションに対する
高速なクエリの実行
パーティション単位で
管理や保守を実施
OK
クエリ パフォーマンスの向上
並列処理の強化で複数のパーティション
にまたがるクエリを高速に実行可能
複数ユーザーの同時実行性を向上
テーブルおよびパーティション レベル
のロック エスカレーション制御に対応
ダウンタイムの削減
障害やメンテナンスの範囲を最小化し、
対象外のパーティションは継続的に利用
可能
大規模データの管理効率を向上
パーティション単位でインデックスの構
築やバックアップ/復元、データの入れ
替えが可能
障害
データパーティション機能
大規模なデータを論理的なパーティ
ションで分割
データ パーティション の適用シナリオ
• データベース保守時間の短縮化
• バックアップデータ取得の局所化
• インデックス再構築の局所化
• 統計情報更新処理の局所化
• ストレージ・デバイス選択の階層化
• SSD (アクティブデータ)
• SAS (検索頻度の高いデータ)
• SATA (大量のアーカイブデータ)
• スライディング・ウィンドウズの有効利用
• 月次単位の集計処理
• 前年同月比較処理
SQL Server 主要機能
Network Protocol
SQLOSAPI
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
SQLOSHostingAPI
ExternalComponents(CLR/MDAC)
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.

Mais conteúdo relacionado

Mais procurados

Sql server エンジニアに知ってもらいたい!! sql server チューニングアプローチ
Sql server エンジニアに知ってもらいたい!! sql server チューニングアプローチSql server エンジニアに知ってもらいたい!! sql server チューニングアプローチ
Sql server エンジニアに知ってもらいたい!! sql server チューニングアプローチMasayuki Ozawa
 
[D11] SQL Server エンジニアに知ってもらいたい!! SQL Server チューニングアプローチ by masayuki ozawa
[D11] SQL Server エンジニアに知ってもらいたい!! SQL Server チューニングアプローチ by masayuki ozawa[D11] SQL Server エンジニアに知ってもらいたい!! SQL Server チューニングアプローチ by masayuki ozawa
[D11] SQL Server エンジニアに知ってもらいたい!! SQL Server チューニングアプローチ by masayuki ozawaInsight Technology, Inc.
 
Azure Synapse Analytics 専用SQL Poolベストプラクティス
Azure Synapse Analytics 専用SQL PoolベストプラクティスAzure Synapse Analytics 専用SQL Poolベストプラクティス
Azure Synapse Analytics 専用SQL PoolベストプラクティスMicrosoft
 
Sql server よく聞く設定とその効果
Sql server よく聞く設定とその効果Sql server よく聞く設定とその効果
Sql server よく聞く設定とその効果Masayuki Ozawa
 
Sql server のバックアップとリストアの基礎
Sql server のバックアップとリストアの基礎Sql server のバックアップとリストアの基礎
Sql server のバックアップとリストアの基礎Masayuki Ozawa
 
カラムストアインデックス 最初の一歩
カラムストアインデックス 最初の一歩カラムストアインデックス 最初の一歩
カラムストアインデックス 最初の一歩Masayuki Ozawa
 
SQL Server運用実践 - 3年間80台の運用経験から20の教訓
SQL Server運用実践 - 3年間80台の運用経験から20の教訓SQL Server運用実践 - 3年間80台の運用経験から20の教訓
SQL Server運用実践 - 3年間80台の運用経験から20の教訓貴仁 大和屋
 
C34 Always On 可用性グループ 構築時のポイント by 小澤真之
C34 Always On 可用性グループ 構築時のポイント by 小澤真之C34 Always On 可用性グループ 構築時のポイント by 小澤真之
C34 Always On 可用性グループ 構築時のポイント by 小澤真之Insight Technology, Inc.
 
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違いバックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違いRyota Watabe
 
シンプルでシステマチックな Oracle Database, Exadata 性能分析
シンプルでシステマチックな Oracle Database, Exadata 性能分析シンプルでシステマチックな Oracle Database, Exadata 性能分析
シンプルでシステマチックな Oracle Database, Exadata 性能分析Yohei Azekatsu
 
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]Hideo Takagi
 
Sql server浅く広く
Sql server浅く広くSql server浅く広く
Sql server浅く広くokumar savurou
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションMasahiko Sawada
 
[DI03] DWH スペシャリストが語る! Azure SQL Data Warehouse チューニングの勘所
[DI03] DWH スペシャリストが語る! Azure SQL Data Warehouse チューニングの勘所[DI03] DWH スペシャリストが語る! Azure SQL Data Warehouse チューニングの勘所
[DI03] DWH スペシャリストが語る! Azure SQL Data Warehouse チューニングの勘所de:code 2017
 
SparkとCassandraの美味しい関係
SparkとCassandraの美味しい関係SparkとCassandraの美味しい関係
SparkとCassandraの美味しい関係datastaxjp
 
Sql server これだけはやっておこう 最終版
Sql server これだけはやっておこう 最終版Sql server これだけはやっておこう 最終版
Sql server これだけはやっておこう 最終版elanlilac
 

Mais procurados (20)

Sql server エンジニアに知ってもらいたい!! sql server チューニングアプローチ
Sql server エンジニアに知ってもらいたい!! sql server チューニングアプローチSql server エンジニアに知ってもらいたい!! sql server チューニングアプローチ
Sql server エンジニアに知ってもらいたい!! sql server チューニングアプローチ
 
SQL Server 入門
SQL Server 入門SQL Server 入門
SQL Server 入門
 
[D11] SQL Server エンジニアに知ってもらいたい!! SQL Server チューニングアプローチ by masayuki ozawa
[D11] SQL Server エンジニアに知ってもらいたい!! SQL Server チューニングアプローチ by masayuki ozawa[D11] SQL Server エンジニアに知ってもらいたい!! SQL Server チューニングアプローチ by masayuki ozawa
[D11] SQL Server エンジニアに知ってもらいたい!! SQL Server チューニングアプローチ by masayuki ozawa
 
Azure Synapse Analytics 専用SQL Poolベストプラクティス
Azure Synapse Analytics 専用SQL PoolベストプラクティスAzure Synapse Analytics 専用SQL Poolベストプラクティス
Azure Synapse Analytics 専用SQL Poolベストプラクティス
 
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
 
Sql server よく聞く設定とその効果
Sql server よく聞く設定とその効果Sql server よく聞く設定とその効果
Sql server よく聞く設定とその効果
 
Sql server のバックアップとリストアの基礎
Sql server のバックアップとリストアの基礎Sql server のバックアップとリストアの基礎
Sql server のバックアップとリストアの基礎
 
カラムストアインデックス 最初の一歩
カラムストアインデックス 最初の一歩カラムストアインデックス 最初の一歩
カラムストアインデックス 最初の一歩
 
SQL Server運用実践 - 3年間80台の運用経験から20の教訓
SQL Server運用実践 - 3年間80台の運用経験から20の教訓SQL Server運用実践 - 3年間80台の運用経験から20の教訓
SQL Server運用実践 - 3年間80台の運用経験から20の教訓
 
C34 Always On 可用性グループ 構築時のポイント by 小澤真之
C34 Always On 可用性グループ 構築時のポイント by 小澤真之C34 Always On 可用性グループ 構築時のポイント by 小澤真之
C34 Always On 可用性グループ 構築時のポイント by 小澤真之
 
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
 
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違いバックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
 
シンプルでシステマチックな Oracle Database, Exadata 性能分析
シンプルでシステマチックな Oracle Database, Exadata 性能分析シンプルでシステマチックな Oracle Database, Exadata 性能分析
シンプルでシステマチックな Oracle Database, Exadata 性能分析
 
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
 
Sql server浅く広く
Sql server浅く広くSql server浅く広く
Sql server浅く広く
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
 
[DI03] DWH スペシャリストが語る! Azure SQL Data Warehouse チューニングの勘所
[DI03] DWH スペシャリストが語る! Azure SQL Data Warehouse チューニングの勘所[DI03] DWH スペシャリストが語る! Azure SQL Data Warehouse チューニングの勘所
[DI03] DWH スペシャリストが語る! Azure SQL Data Warehouse チューニングの勘所
 
SparkとCassandraの美味しい関係
SparkとCassandraの美味しい関係SparkとCassandraの美味しい関係
SparkとCassandraの美味しい関係
 
Sql server これだけはやっておこう 最終版
Sql server これだけはやっておこう 最終版Sql server これだけはやっておこう 最終版
Sql server これだけはやっておこう 最終版
 

Semelhante a C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa

Share pointを支えるsql server2014最新情報
Share pointを支えるsql server2014最新情報Share pointを支えるsql server2014最新情報
Share pointを支えるsql server2014最新情報Atsuo Yamasaki
 
[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...
[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...
[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...Insight Technology, Inc.
 
Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Yukio Kumazawa
 
OSC ver : MariaDB ColumnStore ベンチマークしちゃいませんか?
OSC ver : MariaDB ColumnStore ベンチマークしちゃいませんか?OSC ver : MariaDB ColumnStore ベンチマークしちゃいませんか?
OSC ver : MariaDB ColumnStore ベンチマークしちゃいませんか?KAWANO KAZUYUKI
 
[db tech showcase Tokyo 2015] B12:カラムストアデータベースの技術と活用法 by 日本電気株式会社 田村稔
[db tech showcase Tokyo 2015] B12:カラムストアデータベースの技術と活用法 by 日本電気株式会社 田村稔[db tech showcase Tokyo 2015] B12:カラムストアデータベースの技術と活用法 by 日本電気株式会社 田村稔
[db tech showcase Tokyo 2015] B12:カラムストアデータベースの技術と活用法 by 日本電気株式会社 田村稔Insight Technology, Inc.
 
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~Naoki (Neo) SATO
 
db tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解する
db tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解するdb tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解する
db tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解するMasayuki Ozawa
 
データマイニング+WEB勉強会資料第6回
データマイニング+WEB勉強会資料第6回データマイニング+WEB勉強会資料第6回
データマイニング+WEB勉強会資料第6回Naoyuki Yamada
 
SQL Server 2019 とともに知る Microsoft Data Platform
SQL Server 2019 とともに知る Microsoft Data PlatformSQL Server 2019 とともに知る Microsoft Data Platform
SQL Server 2019 とともに知る Microsoft Data PlatformDaiyu Hatakeyama
 
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)オラクルエンジニア通信
 
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#2
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#2しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#2
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#2オラクルエンジニア通信
 
[D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama
[D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama [D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama
[D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama Insight Technology, Inc.
 
Oracle Gen 2 Exadata Cloud@Customer:サービス概要のご紹介 [2021年7月版]
Oracle Gen 2 Exadata Cloud@Customer:サービス概要のご紹介 [2021年7月版]Oracle Gen 2 Exadata Cloud@Customer:サービス概要のご紹介 [2021年7月版]
Oracle Gen 2 Exadata Cloud@Customer:サービス概要のご紹介 [2021年7月版]オラクルエンジニア通信
 
MySQLの公式GUIツール MySQL Workbench
MySQLの公式GUIツール MySQL WorkbenchMySQLの公式GUIツール MySQL Workbench
MySQLの公式GUIツール MySQL Workbenchyoyamasaki
 
Microsoft Azure SQLマネージド インスタンスのソースとしての利用
Microsoft Azure SQLマネージド インスタンスのソースとしての利用Microsoft Azure SQLマネージド インスタンスのソースとしての利用
Microsoft Azure SQLマネージド インスタンスのソースとしての利用QlikPresalesJapan
 
A13 MySQL & NoSQL~Best of both world~ by Philip Antoniades & Ryusuke Kajiyama
A13 MySQL & NoSQL~Best of both world~ by Philip Antoniades & Ryusuke Kajiyama A13 MySQL & NoSQL~Best of both world~ by Philip Antoniades & Ryusuke Kajiyama
A13 MySQL & NoSQL~Best of both world~ by Philip Antoniades & Ryusuke Kajiyama Insight Technology, Inc.
 
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)Insight Technology, Inc.
 
Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)
Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)
Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)NTT DATA Technology & Innovation
 

Semelhante a C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa (20)

Share pointを支えるsql server2014最新情報
Share pointを支えるsql server2014最新情報Share pointを支えるsql server2014最新情報
Share pointを支えるsql server2014最新情報
 
[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...
[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...
[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...
 
Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用
 
OSC ver : MariaDB ColumnStore ベンチマークしちゃいませんか?
OSC ver : MariaDB ColumnStore ベンチマークしちゃいませんか?OSC ver : MariaDB ColumnStore ベンチマークしちゃいませんか?
OSC ver : MariaDB ColumnStore ベンチマークしちゃいませんか?
 
[db tech showcase Tokyo 2015] B12:カラムストアデータベースの技術と活用法 by 日本電気株式会社 田村稔
[db tech showcase Tokyo 2015] B12:カラムストアデータベースの技術と活用法 by 日本電気株式会社 田村稔[db tech showcase Tokyo 2015] B12:カラムストアデータベースの技術と活用法 by 日本電気株式会社 田村稔
[db tech showcase Tokyo 2015] B12:カラムストアデータベースの技術と活用法 by 日本電気株式会社 田村稔
 
BPStudy20121221
BPStudy20121221BPStudy20121221
BPStudy20121221
 
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
[ウェビナー] Build 2018 アップデート ~ データ プラットフォーム/IoT編 ~
 
20180216 sapporo techbar_db_migration
20180216 sapporo techbar_db_migration20180216 sapporo techbar_db_migration
20180216 sapporo techbar_db_migration
 
db tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解する
db tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解するdb tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解する
db tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解する
 
データマイニング+WEB勉強会資料第6回
データマイニング+WEB勉強会資料第6回データマイニング+WEB勉強会資料第6回
データマイニング+WEB勉強会資料第6回
 
SQL Server 2019 とともに知る Microsoft Data Platform
SQL Server 2019 とともに知る Microsoft Data PlatformSQL Server 2019 とともに知る Microsoft Data Platform
SQL Server 2019 とともに知る Microsoft Data Platform
 
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
オラクル・データベース・クラウド~さらなる進化のご紹介(Oracle Cloud Days Tokyo 2015)
 
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#2
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#2しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#2
しばちょう先生が語る!オラクルデータベースの進化の歴史と最新技術動向#2
 
[D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama
[D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama [D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama
[D37]MySQLの真のイノベーションはこれだ!MySQL 5.7と「実験室」 by Ryusuke Kajiyama
 
Oracle Gen 2 Exadata Cloud@Customer:サービス概要のご紹介 [2021年7月版]
Oracle Gen 2 Exadata Cloud@Customer:サービス概要のご紹介 [2021年7月版]Oracle Gen 2 Exadata Cloud@Customer:サービス概要のご紹介 [2021年7月版]
Oracle Gen 2 Exadata Cloud@Customer:サービス概要のご紹介 [2021年7月版]
 
MySQLの公式GUIツール MySQL Workbench
MySQLの公式GUIツール MySQL WorkbenchMySQLの公式GUIツール MySQL Workbench
MySQLの公式GUIツール MySQL Workbench
 
Microsoft Azure SQLマネージド インスタンスのソースとしての利用
Microsoft Azure SQLマネージド インスタンスのソースとしての利用Microsoft Azure SQLマネージド インスタンスのソースとしての利用
Microsoft Azure SQLマネージド インスタンスのソースとしての利用
 
A13 MySQL & NoSQL~Best of both world~ by Philip Antoniades & Ryusuke Kajiyama
A13 MySQL & NoSQL~Best of both world~ by Philip Antoniades & Ryusuke Kajiyama A13 MySQL & NoSQL~Best of both world~ by Philip Antoniades & Ryusuke Kajiyama
A13 MySQL & NoSQL~Best of both world~ by Philip Antoniades & Ryusuke Kajiyama
 
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
[INSIGHT OUT 2011] B27 SQL Anywhereの先進のセルフヒーリング技術について(glenn paulley)
 
Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)
Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)
Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)
 

Mais de Insight Technology, Inc.

グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?Insight Technology, Inc.
 
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~Insight Technology, Inc.
 
事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明する事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明するInsight Technology, Inc.
 
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーンInsight Technology, Inc.
 
MBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごとMBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごとInsight Technology, Inc.
 
グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?Insight Technology, Inc.
 
DBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォームDBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォームInsight Technology, Inc.
 
SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門Insight Technology, Inc.
 
db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉 db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉 Insight Technology, Inc.
 
db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也Insight Technology, Inc.
 
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー Insight Technology, Inc.
 
難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?Insight Technology, Inc.
 
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介Insight Technology, Inc.
 
そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?Insight Technology, Inc.
 
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...Insight Technology, Inc.
 
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。 複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。 Insight Technology, Inc.
 
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...Insight Technology, Inc.
 
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]Insight Technology, Inc.
 

Mais de Insight Technology, Inc. (20)

グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?
 
Docker and the Oracle Database
Docker and the Oracle DatabaseDocker and the Oracle Database
Docker and the Oracle Database
 
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
 
事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明する事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明する
 
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
 
MBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごとMBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごと
 
グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?
 
DBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォームDBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォーム
 
SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門
 
Lunch & Learn, AWS NoSQL Services
Lunch & Learn, AWS NoSQL ServicesLunch & Learn, AWS NoSQL Services
Lunch & Learn, AWS NoSQL Services
 
db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉 db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉
 
db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也
 
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
 
難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?
 
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
 
そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?
 
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
 
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。 複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
 
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
 
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
 

Último

2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 

Último (11)

2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 

C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa

  • 1. SQL Server 2012 Performance Tuning Part I & II 日本マイクロソフト株式会社 SQL Server 技術顧問 熊澤 幸生
  • 2. Agenda • パフォーマンスチューニングの定義 • SQL Server 共有資源の利用方法 • バランスド・システムとは • ボトルネックの把握とツール • クエリーチューニングと物理・運用設計 • SQLOS とプラットフォームチューニング • シナリオベースのデータ収集と解析 • まとめ
  • 3. 自己紹介 • 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 - )
  • 4. データベースアプリケーション設計と監視 • システム開発段階 • データベース設計 o データボリューム調査 o E-R 図 • 負荷の高い処理の洗い出し • アプリケーションアーキテクチャ設計 • 移行設計 • 運用設計と物理設計 • キャパシティ設計とサイジング • クエリーチューニング • 負荷テスト • システム運用後 • トランザクションミックスの把握 • バッチ処理とバックアップ処理を含めた運用時間の監視 • 継続的な性能監視 • 負荷の高いクエリーへの対処 • システム変更とインパクトの監視
  • 5. パフォーマンスチューニングの定義 • 大きく分けて二つのフェーズ • 第一フェーズ : クエリーチューニング o システム開発段階でのデータベース構造の最適化と主要クエリー処理の最適化 – テーブル構造とキーの選択 – インデックスの選択 – 結合処理の最適化 – SQL Server 固有の物理設計の理解が重要となる • 第二フェーズ : プラットフォームチューニング o システム移行段階 – H/W の選択と本稼働環境のパラメータ設定 – データベース保守の決定と導入 » インデックス再構築と統計情報の更新 o システム本稼働運用 – トランザクションミックスの把握 – 継続的な性能測定とプラットフォームチューニング – 負荷の高いクエリーへの対処 – データ (インデックスとデータ) のメモリー利用状況 – アプリケーションサービス追加と変更への対処
  • 6. 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 カーソル処理、結果セットの転送処理 • ネットワーク上のラウンドトリップ
  • 7. 共有資源とクエリーの調査 • 内部の待ち事象からの考察 • 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
  • 8. バランスド システムとは • SQL Server RDB エンジンに最適化されたハードウエア構成 • リファレンス アーキテクチャ : 松竹梅モデル • 考慮すべき構成要素 (共有資源) • プロセッサ • メモリ • ストレージ サブシステム • ネットワーク • SQL Server 専用サーバー上に配置する • トランザクション処理用と、DWH系は、分離したサーバー上に配置する • 将来のトランザクション ベースラインを明確化する • SQLOS の内部動作を理解する
  • 9. 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) を 監視する
  • 10. 必要なメモリサイズの考え方 • 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 表面上はストレージサブシステムのボトルネックとして表面化する
  • 11. メモリー見積もりの詳細 • 必要とメモリーの見積もり方法 • 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 の論理プロセッサー数により自動決定される
  • 12. 64 ビット SQL Server メモリー空間 12 オペレーティング システム領域 Systemdatastructures Lock ProcedureCache Logcache UsersConnectioncontext Buffercache SQL Server カーネル領域 ワーカースレッドスタック CLR / 拡張ストアド / その他 仮想メモリー空間 : 4TB max server memory
  • 13. ストレージ サブシステムの選定 • 接続方法 • 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 領域) • 搭載する物理ディスク数は、データ ボリュームとトランザクション負荷により決定 する
  • 14. 代表的な監視ツール • パフォーマンスモニター • サーバー全体のスループットと共有資源の負荷状況の把握 • Profiler • ユーザが実行中のクエリーの収集と再現テストの実施 • デッドロックとブロッキングの原因究明 • SQL Server パフォーマンスデータコレクション • SQL Server サーバーダッシュボード • 動的管理ビュー (DMV) と動的管理関数 (DMF) • SQL Server 2000 は非公開のコマンドと関数が、SQL Server 2005 以降 動的管理ビュー (DMV) 、動的管理関数 (DMF) として公開 • 3RD ベンダーパフォーマンス監視ツール • DELL Software Spotlight on SQL Server
  • 16. 取得可能な数値 • 動的管理ビュー、動的管理関数、パフォーマンスカウンターでは、 二種類の数値を取得できる • 累積値 o データベースファイル別 I/O 統計情報 o ロック、ラッチタイプ別発行回数と待ち時間 – ロック : ACID プロパティ実現のためにトランザクション終了まで保持される排他制御 – ラッチ : 主に SQLOS ストレージエンジンが内部処理の為に、一時的に内部で実施する排他制御 o SQLOS 待ち事象別発生回数と待ち時間累積値 • 現在の値 o CPU占有率 o トランザクション数 / 秒 o ディスク I/O 待ちキュー発生数 o バッチとコンパイル発生 / 秒 o ディスク I/O 負荷
  • 17. クエリー実行時の監視 • テーブル / インデックス スキャンの監視 • 適切なインデックスチューニングの実施 o クエリーの実行プラン分析 • 実行時の共有リソース消費状況監視 • アドホッククエリーの CPU 負荷 • メモリー負荷 o クエリープラン領域 o クエリーの中間結果セット領域 • ブロッキングの監視 • システムの致命的な遅延が発生する o どのアプリケーションが o どのリソースを o 古い統計情報が原因ではないか o Index 定義列と順序は適切か • 排他待ちの監視 • アプリケーションアーキテクチャに依存する o 共有ロックと排他ロックの発生状況 o 適切な分離レベル (Isolation level ) の利用 o トランザクション境界と実行時間
  • 19. プロシージャキャッシュ内容の取得 -- プロシージャキャッシュの内容を取得 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;
  • 20. キャッシュプランの分析 (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,648Compiled 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 46,767 32,768Compiled Plan Prepared (@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 21,724 40,960Compiled Plan Prepared (@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 17,575 49,152Compiled Plan Prepared (@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 17,497 622,592Compiled Plan Prepared (@C_ID nvarchar(9))SELECT C_LNAME,C_FNAME FROM CUSTOMER WHERE C_ID=@C_ID 17,234 16,384Compiled 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 8,687 24,576Compiled Plan Prepared (@C_ID nvarchar(8))SELECT C_LNAME,C_FNAME FROM CUSTOMER WHERE C_ID=@C_ID 6,401 16,384Compiled 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,384Compiled 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 5,587 32,768Compiled Plan Prepared (@SYSDATETIME nvarchar(4000),@EXPIRATIONDATETIME nvarchar(4000),@C_ID nvarchar(9))UPDATE CUSTOMER SET C_LOGIN = @SYSDATETIME, C_EXPIRATION = @EXPIRATIONDATETIME WHERE C_ID = @C_ID 4,207 24,576Compiled Plan Prepared (@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. 4,207 65,536Compiled Plan Prepared (@SCL_I_ID nvarchar(4),@I_STOCK nvarchar(2))UPDATE ITEM SET I_STOCK = @I_STOCK WHERE I_ID = @SCL_I_ID 4,000 24,576Compiled Plan Prepared (@SCL_I_ID nvarchar(4))SELECT I_STOCK FROM ITEM WHERE I_ID = @SCL_I_ID 4,000 16,384Compiled Plan Prepared SELECT MAX(O_ID) AS MAX_O_ID FROM ORDERS with(NOLOCK) 3,563 16,384Compiled Plan Adhoc (@1 varchar(8000))SELECT [I_ID],[I_COST] FROM [ITEM] WHERE [I_ID]=@1 3,409 40,960Compiled 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,915 32,768Compiled Plan Prepared
  • 21. キャッシュプランの分析 (2) text plan_generati on_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('AIALAMANAOARBABBBEBLBMBPBQBSCACBCCCECHCOCPDADCDRDUE AEBEDERFAFCFEFOFQFRFSFTFUGAGCGOGPGRGSHAHCHIHUHWIRISITJAJFJKJLKAK DKOLALBLCLDLELFLGLHLILJLOMAMBMCMDMEMONANCNOOAOBOCOLOTPAPBP CPEPIPRQRQSQVQWRARBRCRDRERIRJSASBSCSDSESISPSQTDTETHTITOTPTSUVUW VAVCVDVIVJWAWBWCWDWEWHWIWOXAXDYAYDZIZK',@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
  • 25. クエリをカバーするインデックス • 非クラスタ化インデックスのリ-フレベルに 検索に必要なデータが全て入っている • データ ページのアクセスが不要となり I/O を減少でき、 パフォ-マンスが向上する • 作成のガイドライン • インデックスに列を追加 o最も一般的なクエリをカバ-するインデックスを作成する o複数のクエリをカバ-できる、頻繁に参照される列を選択する oキー列と付加列 • インデックスキ-のサイズを最小化 • 行サイズに対するキ-サイズの比率を小さくする
  • 26. クエリをカバ-するインデックス設計 • クエリーをカバーするインデックス定義例 • 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
  • 27. インデックスの使用の確認 • クエリー実行プランを確認 • インデックスが使用されない原因 • プランのコストが小さすぎる • ページ数や行数の少ないテーブル • オプティマイザヒントの使用 • クエリ処理に使用するオプションを指定 o テーブルヒント o 結合ヒント o インデックスヒント • 通常はクエリオプティマイザで最適化されるため、 あまり使用しないことが推奨
  • 28. アプリケーションロックの使用例 • 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
  • 29. SQL Server のデータベース物理設計 • クラスター化インデックスと非クラスター化インデックスの違いを 理解する • クラスター化インデックスの重要な役割 o B-Tree 構造によりデータを高速に検索可能 – インデックス情報は、ページ内最少キーを保持 o 新しい行の Insert 時に、格納するターゲットページを決定する o 基本はテーブルには必ずクラスター化インデックスを定義する • クラスター化インデックスを持つテーブル上の非クラスター化インデックス 検索 o 非クラスター化インデックスを検索し、クラスター化インデックスのキーを取得する o クラスター化インデックスを検索し、検索対象の行を取得する – 非クラスター化インデックス情報は、データと 1: 1 の関係で保持される o ANSI Isolation Level を実装するには、キーの範囲指定排他制御機能が必要 • 非クラスター化インデックスのみから構成されるテーブル o インデックス情報は、データと 1: 1 の関係で保持される – 非クラスター化インデックス キー + RID » データはヒープ構造として保持される
  • 30. クラスタ化インデックスでの行の検索 • クラスタ化インデックスは 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 … MartinMartin id indid = 1 ルート Martin 7778 ...
  • 31. 非クラスタ化インデックスの行の検索 • 非クラスタ化インデックス はindid = 2~255のエント リを持つ • root列は非クラスタ化 インデックスのル-ト レベルを指す • SQL Server はル-トレベ ルよりインデックスをた どって移動し、非クラスタ 化 インデックス キーと共に 行ロケ-タを取得 • 行ロケ-タによってポイン トされた対応する行をヒ- プより見つける sysindexes ページ 140 – ルート Akhtar … MartinMartin id indid = 2 ルート ページ 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 ... ...
  • 32. クラスタ化インデックス+非クラスタ化インデックス • SQL Server はル-トレベ ルより非クラスタ化イン デックスをたどって移動し、 非クラスタ化インデックス キーと共にクラスタ化キ- を取得 • 取得したクラスタ化キーを 用いて、再度クラスタ化イ ンデックスをルートレベル より探索 • クラスタ化インデックス キーに対応する行を見つけ る Aaron Deanna … Aaron ... Jose Jose Nina … id indid = 2 ルート sysindexes Barr Kim Nagata O’MeliaNash 非クラスタ化 インデックス クラスタ化 インデックス 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 … リ-フレベル (クラスタ化キ-値) リ-フレベル
  • 33. インデックスと統計情報による実行プラン生成 • テーブル毎の検索方法の決定 • テーブルの行数とデータページ数、保持するインデックスの把握 • テーブルスキャン or インデックス検索の決定 o クラスタ化インデックスと非クラスタ化インデックス – それぞれのインデックスの持つ統計情報を参照する • テーブル毎の検索条件句による選択行数の推測と検索方法の決定 • テーブルスキャン or インデックススキャン or ブックマークルックアップ or インデックスシーク o 統計情報を参照し、キーの分布情報から、対象行数と検索ページ数を算出する o 検索ページ数 / 総ページ数から、セレクティビティを算出する • どの検索方法を取るかが決まる • Join アルゴリズムの決定 • インデックス・ネステッドループ or ネステッド・ループ or ソートマージ or ハッシュ結合 • 推測行数により、Join アルゴリズムを決定する • テーブル単位の中間結果セットを用いた結合処理 • 集計、ソート処理 • 最終結果セットの作成
  • 34. SQL Server のデータベース物理設計 - インデックスを作成する列の決定 - • 発生するデータを理解する • データの特性、利用方法 • クラスター化インデックスを付与する列の場合、Insert する行のキー値の分布を把 握する o ランダム値、昇順値 (伝票番号等) o 複合列 (複数列で構成するキー) • キー項目の更新の有無と頻度 (非クラスター化インデックス) • 実行されるクエリの種類と実行頻度 • インデックスを作成する列のガイド ライン • 主キーと外部キー、結合処理で参照される列 • 煩雑に範囲検索される列 • 並び替え、集計処理で利用される列 • キーの内容が変更されない列 (クラスター化インデックス) • インデックス作成に適していない列 • クエリで参照されない列 • 一意の値を含まない列 • text、ntext、image データ型属性を持つ列 • null、可変長属性を持つ列
  • 35. 格納領域断片化の発生原因と防止方法 • 格納領域断片化の原因 • ページ分割の発生原因 o データの追加と更新処理 – insert 処理は、クラスター化インデックスのキー値により、格納ページを決定 する – 空き領域がなかった場合、ページ分割処理が発生する – ページ分割により、分割された後半のデータ ページに対応するインデックス 情報を追加する – update 処理は、可変長属性、null 属性をもつ列に更新が発生した場合、 物理的な行の長さが変わり、同一領域に格納できない時に発生する • 発生場所 o データ ページとインデックス ページ • 断片化の防止方法 • インデックス再構築・再構成時に fillfactor を指定して、将来の追加領域を 確保する o クラスター化インデックス領域に指定可能 (0-100%) o インデックス キー値の分布状況と、再構築・再構成の実施頻度により fillfactor の値を決定する • 定期的にインデックスの再構築・再構成を実施する
  • 36. ページ分割の抑制 FillFactor が設定されていない状態 データ : “①②③④” 使用済み領域 データページの領域不足 により、ページ分割が発生 空き領域 FillFactor による予約域の確保 FillFactor : 70 ページ ページ 使用済み領域 データ追加用の予約域 予約域が予め確保されること により、ページ分割の発生が抑制 データ : “①②③④” ①② ③④ ①② ③ ④ PageLatchが発生する
  • 37. データベースの運用設計 - インデックス再構築と再構成のタイミング - • 再構築とは • 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 オプションを利用する • 統計情報も同時に更新される
  • 38. 断片化の解消 “エクステント” = 8 ページ (ページの管理単位) ① ③② ④ 空き領域使用済み領域 インデックス キー値の順番 : ① ② ③ ④ ・・・・ INDEX REBULD の実行 ① ② ③ ④ ・ ・ ・ OS の IO 単位 OS の IO 単位 現在 : “ページ分割によりデータの断片化が発生している状態”
  • 39. データベースの運用設計 - 統計情報とは - • クエリ オプティマイザーが最適なクエリ実行プランを作成するため の情報 • インデックスを構成する列の値をサンプリングし、分布情報を格納 「どうのような値をもつデー-タが何件入っているか? 」 • クエリ オプティマイザーは統計情報を使用して、クエリに対してどの インデックスを使用するかの実行コストを予測し、利用の有無、利用方法を判 断する • パフォ-マンスに影響を及ぼす • デー-タの変更に伴い統計情報の定期的な更新が必要 o インデックス再構築・再構成後に、データ更新処理により、実際の分布状態と、統計情報間 にデータの乖離が発生する • 統計情報の作成 • 自動作成 (既定) o インデックス作成時に、インデックス列内の値の分布情報を自動的に作成 o 結合述語または WHERE 句で使用されるインデックスが作成されていない列の利用状 況を保持する (インデックス チューニングの推奨データ) • 統計情報の保守 • 自動更新 (既定) : インデックス単位に保持している更新状況から、一定の閾値 を超えた時に実行される • 手動更新: update statistics on <テーブル名>
  • 41. 大規模データのパフォーマンスと管理性を向上 • データ パーティション機能 • 大規模なテーブルを論理的なパーティションに分割、複数の小さなテーブルとして利用 • クエリやインデックス、バックアップの範囲を縮小し、パフォーマンスと管理性を向上 2003 ~ 2008 年売上明細テーブル パーティション 1 パーティション 2 パーティション 3 パーティション 4 2010 年 2009 年 2008 年 2007 年 複数パーティションに対する 高速なクエリの実行 パーティション単位で 管理や保守を実施 OK クエリ パフォーマンスの向上 並列処理の強化で複数のパーティション にまたがるクエリを高速に実行可能 複数ユーザーの同時実行性を向上 テーブルおよびパーティション レベル のロック エスカレーション制御に対応 ダウンタイムの削減 障害やメンテナンスの範囲を最小化し、 対象外のパーティションは継続的に利用 可能 大規模データの管理効率を向上 パーティション単位でインデックスの構 築やバックアップ/復元、データの入れ 替えが可能 障害 データパーティション機能 大規模なデータを論理的なパーティ ションで分割
  • 42. データ パーティション の適用シナリオ • データベース保守時間の短縮化 • バックアップデータ取得の局所化 • インデックス再構築の局所化 • 統計情報更新処理の局所化 • ストレージ・デバイス選択の階層化 • SSD (アクティブデータ) • SAS (検索頻度の高いデータ) • SATA (大量のアーカイブデータ) • スライディング・ウィンドウズの有効利用 • 月次単位の集計処理 • 前年同月比較処理
  • 43. SQL Server 主要機能 Network Protocol SQLOSAPI 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 SQLOSHostingAPI ExternalComponents(CLR/MDAC) MS DTC (Distributed Transaction Coordinators )
  • 44. リレーショナルエンジンのコンポーネント • ネットワークプロトコル経由で、T-SQL バッチとして処理単位 を分割する • パーサー • オプティマイザ • コストベースのオプティマイザ • 統計情報(キーの分布状況)により最適プランを選択 • クエリーの実行プランをプロシージャキャッシュ内に格納する • プロシージャキャッシュに格納された、ストアドプロシージャ、 プリペアードクエリーは、再利用が可能 • SQL マネージャ • DB マネージャ • クエリエグゼキュータ • プロシージャキャッシュ上の実行プランを、実行ステップごとに ストレージエンジンに実行を依頼し、結果セットを取得 • 実行コンテキストは、プロセス単位 (spid) に作成する • インタープリター形式で実行する
  • 45. ストレージエンジンのコンポーネント • クライアントからの T-SQL をトランザクション属性を保証し てサーバー全体の実行管理を行う。 • トランザクションサービス • ACID プロパティとIsolation • ロックマネージャ • ロックとラッチ o ロック : トランザクション終了まで排他処理を行う o ラッチ : ストレージエンジンの内部処理用で、トランザクション 処理とは非同期に 動作する • ファイルマネージャ • ユーティリティ • BCP / Backup Restore / DBCC ユーティリティ • アクセスメソッド • 行操作 / インデックス検索 / ページ領域管理 / 領域の割当 / バージョン管理 • 外部コンポーネントインターフェース
  • 46. NUMA の特徴 • CPUは他ノードを含む全ての物理メモリをマップ可能 • 同一ノード内にあるメモリをローカルメモリ、他ノードにある メモリをリモートメモリと呼ぶ • ローカルメモリに対するアクセスの方が効率が良い • 効率の良いメモリアクセスを行うには、Server OS と RDBが NUMAに対応している必要がある メモリー コント ローラ CPU CPU CPU CPU メ モ リ インターコネクト メモリー コント ローラ CPU CPU CPU CPU メ モ リ
  • 47. 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
  • 48. 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
  • 49. 重点的な監視が必要な SQLOS 待ち事象 • sys.dm_os_wait_stats から発見可能な問題点 • ストレージ・サブシステムの I/O 帯域不足 • データベース容量と比較したメモリー不足 • アプリケーションアーキテクチャの問題点 o トランザクションの境界 o ロックの種類と利用状況 o 分離レベル (Isolation level) o クエリー実行時のメモリー不足 (不適切なクエリー) • データベース物理設計の問題点 o クラスタ化インデックスと 非クラスタ化インデックスの選択 o 物理ファイルのストレージへの格納 (RAID 選択)
  • 50. メモリ共有リソースの監視 • データ キャッシュ領域 • 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
  • 51. MAX DOP とは • max degree of parallelism パラメータ • サーバーのプロパティ詳細設定 o 並列処理の最大限度 • sp_configure max degree of parallelism パラメータ • 既定値は 0 o 各ユーザセッションは、SQL Server が認識している スケジューラ(論理CPUコア)全てを用いて、並列処理を実行可能 – バッチ処理には適切な設定 » 処理時間短縮化を重視 – OLTP 処理では、トランザクション処理の同時実行性を重視 o SQL Server オプティマイザは、実行プラン作成時に、 並列処理可能なプランを自動認識する
  • 52. 並列処理の最大限度 (MAX DOP) の考慮 • 並列処理の最大限度とは • ユーザ・コネクションから受け取った T-SQL は、オプティマイザにより、 木構造の複数の実行ステップに、分解される • 各実行ステップは、一つ以上の CPU (スケジューラ) 上で実行される • この時の、1 タスクが実行可能な並列処理の多重度を、並列処理の最大限度と 呼ぶ • 考慮点 • 並列処理は、NUMA の同一ノード上で実行されることが、メモリーアクセス 効率化の観点からも重要である。 o NUMA ローカルメモリーアクセスと、リモートメモリーアクセスを比較すると、数倍の時間 を必要とする • チューニングポイント • NUMA の場合 o 並列処理の最大限度 (MAX DOP) を、ソケット内の物理 CPU コア数に制限する
  • 54. 初期化処理と固定情報の取得 • 累積値を表示する 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 データベース物理配置と格納情報を取得
  • 55. リアルタイム取得 • 取得する情報 • スケジューラの動作状況 • SQL Server パフォーマンスカウンター オブジェクト • Windows Serverパフォーマンスカウンター オブジェクト • ロックの発行状況 • ブロッキングの発生状況 • 負荷の高いクエリーの実行プラン • 3rd ベンダーの監視ツールの活用 • デル・ソフトウエア o Spotlight on SQL Server
  • 56. OLTP とバッチ終了時 • 取得する情報 • データベースごとの、データキャッシュ上のオブジェクト利用状況 o 検索頻度の高いテーブルとインデックスを知ることが可能 • プロシージャキャッシュ上の実行プラン情報 • データベースごとの、データ領域断片化情報 • データベースごとの、統計情報の最終更新日時 • 不足しているインデックス情報 • 累積値差分計算用情報 o sys.dm_os_wait_stats o sys.dm_os_latch_stats o sys.dm_io_virtual_file_stats
  • 57. 構成情報 • ユーザデータベース定義 • テーブルとインデックス定義 • SQL Server インスタンス構成情報 • ユーザ定義ストアードプロシージャ、関数等
  • 58. データの可視化と事実の把握 • 採取したデータを可視化して整理 • 数字や文字列だけではわからない傾向が見えてくる • 事実の積み上げ方は自然と決まってくる o サーバーの環境設定 (HW / SW / パラメータ) o リソースのアクティビティ (CPU / Memory / Disk) o データ領域とインデックス定義 o ロックとトランザクション • 積み上げた事実を客観的に把握 • 全体を正しく把握することは意外と難しい • この時点では事実はただの『点』に過ぎない ※分析を進めると意外なところに原因があったりする
  • 59. 問題を特定 • 仮説と検証を繰り返し問題を特定 • 発生している事象からいくつかの問題を推測 • その推測が積み上げた事実の上に成り立つか 検証 ※説明のつかない事象がある場合は要注意 • 『点』と『点』を線で結ぶようなイメージ ※SQL Server に関する知識と経験に加え洞察力が求められる
  • 60. まとめ • セミナーの目的 • トラブルの分析手段と、チューニング方法が SQL Server に存在することを 理解してもらう • 実際の利用シナリオに沿って、何が判明して、どうすれば解決するかの観点で 作成した • バランスド・システムのコンセプト • 共有リソースを理解し、あらかじめ将来のデータ量増加、 トランザクション負荷を考慮した、H/W サイジングを実施する • 10 年間にわたり、実際のお客様で得たものをベストプラクティスとして記載 した
  • 61. © 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.