Presentation is loading. Please wait.

Presentation is loading. Please wait.

Execution Plans for Mere Mortals A beginners look at execution plans. Mike Lawell, Teammate, Linchpin People.

Similar presentations


Presentation on theme: "Execution Plans for Mere Mortals A beginners look at execution plans. Mike Lawell, Teammate, Linchpin People."— Presentation transcript:

1

2 Execution Plans for Mere Mortals A beginners look at execution plans. Mike Lawell, Teammate, Linchpin People

3 2 Please silence cell phones 2

4 3 Explore Everything PASS Has to Offer FREE SQL SERVER AND BI WEB EVENTS FREE 1-DAY TRAINING EVENTS REGIONAL EVENT LOCAL USER GROUPS AROUND THE WORLD FREE ONLINE TECHNICAL TRAINING THIS IS COMMUNITYBUSINESS ANALYTICS TRAINING SESSION RECORDINGSPASS NEWSLETTER 3

5 Agenda We will be taking a look at Graphical Execution Plans from a beginners perspective. The ride will include the following: Execution Steps Execution Plan Basics Basic Operators Join Operators Other Operators 4

6 Execution Step by Step

7 6 On The Inside Relational Engine Optimizer Command Parser Query Executor SNI* User Storage Engine Buffer Manager Access Methods Transaction Manager SQL OS Buffer Pool Borrowed from Bradley Ball’s “SQL Internals, Recovery Models, & Backups” presentation Plan Cache Data Cache Data *SQL Server Network Interface (SNI)

8 Relation Engine 1.Is the query syntactically correct? SELECT [Name], [Number] FORM [Production].[Product] Incorrect syntax near 'Production'. SELCT [Name], [Number] FROM [Production].[Product] Msg 156, Level 15, State 1, Line 3 Incorrect syntax near the keyword 'FROM'. 2.No Errors Output as Parse Tree to Algebrizer Query Parsing 7

9 8 SELECT [Name], [Number] FORM [Production].[Product] Incorrect syntax near 'Production'.

10 9 Query Parsing SELECT [Name], [Number] FROM [Production].[Product]

11 10 Execute Parallel/ Not Parallel Store in Plan Cache (*) Find Plan Hash Checked in Plan Cache Aggregate Binding Resolve Data Types Name Resolution Plan Creation 3 45 6 12 10 Algebrizer Query Optimizer Recompile? Storage Engine No Results Returned 7 Cost > Cost for Parallelism 8 YES Does Plan Exist? Create Plan NO Yes

12 11 Execute Parallel/ Not Parallel Store in Plan Cache (*) Find/Create Plan Hash Checked in Plan Cache Aggregate Binding Resolve Data Types Name Resolution Plan Creation 3 45 6 12 11 Does Plan Exist? Algebrizer Query Optimizer Yes Recompile? No Storage Engine No Results Returned 7 Cost > Cost for Parallelism 8 When a plan is found, good enough or optimal, then it is stored in cache (*). *If optimize for adhoc workloads is enabled, a stub is saved the first execution. If a recompile has been triggered, the process starts over. Is cost > cost for threshold? If it is, parallelize query. The algebrizer finds aggregate operations and performs aggregate binding. The algebrizer resolves the data types for the objects being accessed. The algebrizer resolves the names for objects (tables, columns, etc). Check the query hash against the plan cache to see if it exists If it doesn’t exist, use the query processor tree and statistics to determine execution plan generating multiple plans assigning cost (CPU, I/O) to each step and picks the best one.

13 12 Cardinality Estimation The optimization process depends on a cost estimation of each physical operator and the estimated number of records (cardinality estimation) to be processed. DBCC SHOW_STATISTICS ("[Sales].[SalesOrderDetailEnlarged]", [_WA_Sys_00000003_3D7E1B63]); The accuracy of the cardinality estimation depends upon the distribution of values in one or more columns of a table (statistics). NameUpdatedRowsRows SampledStepsAverage key lengthString IndexFilter ExpressionUnfiltered Rows _WA_Sys_00000003_3D7E1B63Nov 26 2014 11:26AM1000100019624YESNULL1000 RANGE_HI_KEYRANGE_ROWSEQ_ROWSDISTINCT_RANGE_ROWSAVG_RANGE_ROWS 002EE045-E300101 0169388E-8EC6161 031622B3-B683131 0424F840-4C23131 04C4FEAC-7C13131 Create Plan 5

14 13 Cardinality Estimation There are multiple factors that can negatively impact the cardinality estimation process: 1. 1.Out of date Statistics SELECT object_name(object_id) as TableName, name AS stats_name, STATS_DATE(object_id, stats_id) AS statistics_update_date FROM sys.stats WHERE object_id = OBJECT_ID('[Sales].[SalesOrderDetailEnlarged]'); 2. 2.Cardinality Estimation Errors https://www.sqlskills.com/blogs/joe/cardinality-estimation-model-version/

15 14 Which cardinality version am I using?

16 Execution Plan Basics Getting Started

17 16 Required Permissions Server or database roles with permissions: sysadmin, dbcreator or db_owner or showplan To give showplan rights to the database: GRANT SHOWPLAN TO [username];

18 How to Read 17 1 3 2 4 5 6 7 8

19 Basic Operators Start Here

20 Basic Operators DML StatementsAccess Methods 19 Other Operators

21 Join Operators Making it Happen

22 21 Nested Loop Non-blocking Description For each row in the top (outer) input, scan the bottom (inner) input, and output matching rows. Where does it happen: Joins with indexes on join columns.

23 Nested Loop SELECT [sod].[CarrierTrackingNumber], [sod].[OrderQty], [soh].[RevisionNumber], [soh].[OrderDate] FROM [Sales].[SalesOrderHeader] soh JOIN [Sales].[SalesOrderDetail] sod ON sod.[SalesOrderID] = soh.[SalesOrderID] WHERE soh.[OrderDate] = '2013-08-30 00:00:00.000' Outer Loop Inner Loop Non-blocking 22

24 23 Nested Loop

25 24 Non-blocking Nested Loop SalesOrderIDRevisionNumberOrderDate 5523382013-08-30 00:00:00.000 5523482013-08-30 00:00:00.000 5523582013-08-30 00:00:00.000 5523682013-08-30 00:00:00.000 5523782013-08-30 00:00:00.000 5523882013-08-30 00:00:00.000 5523982013-08-30 00:00:00.000 5524082013-08-30 00:00:00.000 5524182013-08-30 00:00:00.000 5524282013-08-30 00:00:00.000 5524382013-08-30 00:00:00.000 5524482013-08-30 00:00:00.000 5524582013-08-30 00:00:00.000 5524682013-08-30 00:00:00.000 5524782013-08-30 00:00:00.000 5524882013-08-30 00:00:00.000 5524982013-08-30 00:00:00.000 5525082013-08-30 00:00:00.000 5525182013-08-30 00:00:00.000 5525282013-08-30 00:00:00.000 5525382013-08-30 00:00:00.000 SalesOrderIDProductIDCarrierTrackingNumberOrderQty 552337381590-499E-955 552337921590-499E-955 552337931590-499E-954 552337941590-499E-954 552337951590-499E-954 552337961590-499E-955 552337971590-499E-956 552337981590-499E-952 552337991590-499E-951 552338001590-499E-951 552338011590-499E-956 552338351590-499E-956 552338741590-499E-958 552338751590-499E-958 552339381590-499E-955 552339391590-499E-955 552339401590-499E-954 552339731590-499E-955 552339741590-499E-951 552339751590-499E-951

26 25 Description Match rows from two suitably sorted input tables exploiting their sort order. Where does it happen: Joins with indexes on join columns sorted in an appropriate sort order. Merge Non-blocking

27 Merge SELECT [sod].[CarrierTrackingNumber], [sod].[OrderQty], [soh].[RevisionNumber], [soh].[OrderDate] FROM [Sales].[SalesOrderHeader] soh JOIN [Sales].[SalesOrderDetail] sod ON sod.[SalesOrderID] = soh.[SalesOrderID] Non-blocking 26

28 27 Merge SalesOrderIDRevisionNumberOrderDate 5523382013-08-30 00:00:00.000 5523482013-08-30 00:00:00.000 5523582013-08-30 00:00:00.000 5523682013-08-30 00:00:00.000 5523782013-08-30 00:00:00.000 5523882013-08-30 00:00:00.000 5523982013-08-30 00:00:00.000 5524082013-08-30 00:00:00.000 5524182013-08-30 00:00:00.000 5524282013-08-30 00:00:00.000 5524382013-08-30 00:00:00.000 5524482013-08-30 00:00:00.000 5524582013-08-30 00:00:00.000 5524682013-08-30 00:00:00.000 5524782013-08-30 00:00:00.000 5524882013-08-30 00:00:00.000 5524982013-08-30 00:00:00.000 5525082013-08-30 00:00:00.000 5525182013-08-30 00:00:00.000 5525282013-08-30 00:00:00.000 5525382013-08-30 00:00:00.000 SalesOrderIDProductIDCarrierTrackingNumberOrderQty 552337381590-499E-955 552337921590-499E-955 552337931590-499E-954 552337941590-499E-954 552337951590-499E-954 552337961590-499E-955 552337971590-499E-956 552337981590-499E-952 552337991590-499E-951 552338001590-499E-951 552338011590-499E-956 552338351590-499E-956 552338741590-499E-958 552338751590-499E-958 552339381590-499E-955 552339391590-499E-955 552339401590-499E-954 552339731590-499E-955 552339741590-499E-951 552339751590-499E-951 Non-blocking

29 28 Hash Match Description Use each row from the top input to build a hash table, and each row from the bottom input to probe into the hash table, outputting all matching rows. Where does it happen: Missing Index, Missing Where Clause, Where Clause that is non-sargable.

30 Hash Match Blocking SELECT [sod1].[ProductID], [sod1].[CarrierTrackingNumber], [sod1].[UnitPrice], [sod1].[OrderQty] FROM [Sales].[SalesOrderDetail] sod1 JOIN [Sales].[SalesOrderDetail] sod2 ON [sod1].[ProductID] = [sod2].[ProductID] AND [sod1].[CarrierTrackingNumber] = [sod2].[CarrierTrackingNumber] AND [sod1].[OrderQty] > 5 29

31 Hash Match Hash Table Blocking 30 Column A Column B 98234750198709872 8749872 Hashed Value 8Ax94Dd343S 8Ax94Dd343S 98234750198709872 8749872

32 Hash Match Hash Table 1 Blocking 31 8Ax94Dd343S 1) From the first input (table) the column data is hashed and put in buckets in a “hash” table (in tempdb). 2) Then it reads rows from input 2, hashes the join columns and compares the hash and values to output matches. 8Ax94Dd343S 8Bx40XdF43D 8CxXDVa91f If a Match… “Send” row data to next operator and go to the next row.

33 32 Fixed Hash Match

34 Other Operators Fun Stuff

35 34 Parallelism SELECT [sod1].[ProductID], [sod1].[CarrierTrackingNumber], [sod1].[UnitPrice], [sod1].[OrderQty] FROM [Sales].[SalesOrderDetail] sod1 JOIN [Sales].[SalesOrderDetail] sod2 ON [sod1].[ProductID] = [sod2].[ProductID] AND [sod1].[CarrierTrackingNumber] = [sod2].[CarrierTrackingNumber]

36 35 Parallelism SET STATISTICS IO ON SET STATISTICS TIME ON SELECT [sod1].[ProductID], [sod1].[CarrierTrackingNumber], [sod1].[UnitPrice], [sod1].[OrderQty] FROM [Sales].[SalesOrderDetail] sod1 JOIN [Sales].[SalesOrderDetail] sod2 ON [sod1].[ProductID] = [sod2].[ProductID] AND [sod1].[CarrierTrackingNumber] = [sod2].[CarrierTrackingNumber] SELECT [sod1].[ProductID], [sod1].[CarrierTrackingNumber], [sod1].[UnitPrice], [sod1].[OrderQty] FROM [Sales].[SalesOrderDetail] sod1 JOIN [Sales].[SalesOrderDetail] sod2 ON [sod1].[ProductID] = [sod2].[ProductID] AND [sod1].[CarrierTrackingNumber] = [sod2].[CarrierTrackingNumber] OPTION(MAXDOP 1)

37 36 Parallelism

38 37 Parallelism

39 38 Hash Aggregate SELECT [sod1].[CarrierTrackingNumber], sum([sod1].[UnitPrice]) UnitPriceTotal, sum([sod1].[OrderQty]) as OrderQtyTotal FROM [Sales].[SalesOrderDetail] sod1 JOIN [Sales].[SalesOrderDetail] sod2 ON [sod1].[ProductID] = [sod2].[ProductID] AND [sod1].[CarrierTrackingNumber] = [sod2].[CarrierTrackingNumber] AND [sod1].[OrderQty] > 5 GROUP BY [sod1].[CarrierTrackingNumber]

40 39 Stream Aggregate SELECT [sod1].[CarrierTrackingNumber], sum([sod1].[UnitPrice]) UnitPriceTotal, sum([sod1].[OrderQty]) as OrderQtyTotal FROM [Sales].[SalesOrderDetail] sod1 JOIN [Sales].[SalesOrderDetail] sod2 ON [sod1].[ProductID] = [sod2].[ProductID] AND [sod1].[CarrierTrackingNumber] = [sod2].[CarrierTrackingNumber] AND [sod1].[OrderQty] > 5 GROUP BY [sod1].[CarrierTrackingNumber]

41 40 Sort Spill Operator used tempdb to spill data during execution with spill level 2 SELECT [sod].[CarrierTrackingNumber], [sod].[OrderQty], [soh].[RevisionNumber], [soh].[OrderDate] FROM [Sales].[SalesOrderHeader] soh JOIN [Sales].[SalesOrderDetailEnlarged] sod ON sod.[SalesOrderID] = soh.[SalesOrderID] WHERE [sod].[CarrierTrackingNumber] > '41D0-42A8-A5' ORDER BY [soh].[RevisionNumber], [soh].[OrderDate]

42 41 Sort Spill SELECT TOP 1 [sod].[CarrierTrackingNumber], [sod].[OrderQty], [soh].[RevisionNumber], [soh].[OrderDate] FROM [Sales].[SalesOrderHeader] soh JOIN [Sales].[SalesOrderDetailEnlarged] sod ON sod.[SalesOrderID] = soh.[SalesOrderID] WHERE [sod].[CarrierTrackingNumber] > '41D0-42A8-A5' ORDER BY [soh].[RevisionNumber], [soh].[OrderDate]

43 42 Implicit Conversion SELECT [sod].[CarrierTrackingNumber], [sod].[OrderQty], [soh].[RevisionNumber], [soh].[OrderDate] FROM [Sales].[SalesOrderHeaderEnlarged] soh JOIN [Sales].[SalesOrderDetailEnlarged] sod ON sod.[SalesOrderID] = soh.[SalesOrderID] WHERE CONVERT(varchar(10),[soh].[OrderDate],110) = '04-14-2014'

44 43 Cool Tools/Products SQL Server Query Plan Analysis by Joe Sack

45 44 Resources http://www.red-gate.com/community/books/

46 45 Session Evaluations ways to access Go to passsummit.com/evals Download the GuideBook App and search: PASS Summit 2015 Follow the QR code link displayed on session signage throughout the conference venue and in the program guide Submit by 5pm Friday November 6 th to WIN prizes Your feedback is important and valuable. 45

47 46 Mike Lawell Principal Consultant Twitter:@SQLDiver Blog:SQLServerAssociates.com LinkedIn:LinkedIn.com/in/MikeLawell

48 47 Properties

49

50

51 50 Palette PRIMARY PALETTESECONDARY PALETTE 50

52 Titles are set 36 Segoe UI, maximum 2 lines, ideally 1 line Heading One Style, 28pt Body content, 18pt Segoe UI (gray) Heading Two Style, 24pt Body content, 18pt Segoe UI (gray) HEADING THREE STYLE, 16pt, BOLD, ALL CAPS Body content, 18pt Segoe UI (gray) 51

53 1.Resolve the Names of the objects (tables, columns, etc.) 2.Resolve the data types for the objects being accessed. 3.Finds aggregate operations (min, max, group by) and performs an operation called aggregate binding. If the names of the objects, columns aren’t found an error is output and the process halts. If it is successful the algebrizer outputs the query processor tree to the query optimizer. The query hash is generated and passed with the query processor tree. Algebrizer

54 The query optimizer checks the hash against the plan cache. If it exists use it and the optimization step is skipped and plan is passed to query execution. The query optimizer uses the query processor tree and the statistics to determine an estimated execution plan. The optimizer goes through a process of using different types of joins and indexes and assigns a cost to each step by CPU and I/O and determines a cost for each possible estimated plan it generates. Once an acceptable estimated plan is found it is stored in the plan cache then sent to the query execution. Query Optimizer

55 Storage Engine The storage engine determines if a recompile was triggered causing a change in the estimated execution plan. SQL Server determines based upon cost whether it exceeds the threshold for parallelism changing the estimated plan for parallelism. Statistics that have changed causing a change in the estimated plan. SQL Server returns the results. Query Execution


Download ppt "Execution Plans for Mere Mortals A beginners look at execution plans. Mike Lawell, Teammate, Linchpin People."

Similar presentations


Ads by Google