Your SlideShare is downloading. ×
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

C11,12 SQL Server 2012 Performance Tuning by Yukio Kumazawa

2,772

Published on

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,772
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
58
Comments
0
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 15. 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 トランザクション境界と実行時間
  • 18. クエリープランの分析
  • 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
  • 22. キャッシュプランの分析 (3)
  • 23. sqlplan として保存した実行プラン
  • 24. クエリー実行プラン • 不足しているインデックスを表示
  • 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 <テーブル名>
  • 40. 統計情報の確認 dbcc show_statistics (‘テーブル名’, ‘インデックス名')
  • 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 コア数に制限する
  • 53. アクティビティの取得タイミング • 初期化処理と固定情報の取得 • リアルタイム取得 • OLTP 終了時 • バッチ終了時
  • 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.

×