SQL Server 2008 Development for Programmers
(Level 200)
Springfield .NET Users Group
June 28th, 2011
Presentation by Adam Hutson
Speaker Bio – Adam Hutson
• Database Developer at Expedia and a freelance developer.
• 11 year career, mostly on software side, on database side for past couple years.
• Enjoy learning new development techniques, earning MSSQL certifications, and picking up various web & desktop development side projects.
• Married 8 yrs & 4 kiddos (B-6y, G-4y, G-2y, & G-5m)
• Blog: http://adamhutson.com/LinkedIn: http://www.linkedin.com/in/adamhutson
Presentation Overview
• Review of CRUD & JOIN basics
• Dynamic vs. Compiled Statements
• Indexes & Execution Plans
• Performance Issues
• Scaling up your Database
• Personal toolbox, templates, & links
CRUD basics
• Create INSERT statementsINSERT MyTable (Col1, Col2) VALUES ('a', 'b')
• Read SELECT statementsSELECT Col1, Col2 FROM MyTable
• Update UPDATE statementsUPDATE MyTable SET Col1 = Col1 + Col1
• Delete DELETE statementsDELETE FROM MyTable WHERE Col2 = 'b'
JOIN basics
• [INNER] JOIN
• LEFT [OUTER] JOIN
• RIGHT [OUTER] JOIN
• FULL [OUTER] JOIN
• CROSS JOIN
[INNER] JOIN
• INNER Joins combine the matching records from 2 tables. INNER keyword is optional.
Left Table
Right Table
LEFT [OUTER] JOIN
• LEFT [OUTER] JOINs combine all the records from the left table and only the matching records from right table. OUTER keyword is optional.
Left Table
Right Table
RIGHT [OUTER] JOIN
• RIGHT [OUTER] JOINs combine all the records from the right table and only the matching records from left table. OUTER keyword is optional.
Left Table
Right Table
FULL [OUTER] JOIN
• FULL [OUTER] JOINs combine all rows from both tables regardless of match. OUTER keyword is optional.
Left Table
Right Table
CROSS JOIN
• CROSS JOINs provide a Cartesian product between two tables. A Cartesian product contains all the rows from all the tables combined.
Dynamic vs. Compiled Statements
• Dynamic SQL Statements
– Constructed at runtime with variable data
– Execution plan is determined on 1st execution
– Any adhoc query is dynamic to the optimizer
• Compiled SQL Statements
– Constructed at design time
– Execution plan is known before execution
– Stored Procedures are compiled
Execution Plans
• What is an execution plan?
– Query optimizer’s attempt to calculate the most efficient way to implement a query.
– Calculates the cost in terms of CPU, I/O, & speed.
• Where are they stored?
– Generating an execution plan is expensive, so they are stored for reuse in memory (plan cache).
– Are purged from memory using an aging formula that considers it’s cost and use
Indexes
• What are indexes?– Catalog of locations and order of records in table
• Why use them?– Speeds up queries; tables are just heaps of data
without them
• Types:– Clustered – NonClustered– Composite– Unique– Covering
Index storage
• An index is a set of pages (index nodes) that are organized in a B-tree structure.
1-200
1-100
1-50
1-25 26-50
51-100
51-75 76-100
101-200
101-150
101-125 126-150
151-200
151-175 176-200
Root Level
IntermediateLevels
Leaf Level
• Clustered – stores the actual data rows at the leaf level of the index; physically sorted table; only 1 per table
• NonClustered – leaf nodes contain only the values from the indexed columns and row locators to the actual data rows, not the actual data rows themselves; 249 per table
• Composite – contains more than one column up to 16; can be clustered or nonclustered; max of 900 bytes
• Unique – ensures each value in the indexed column is unique. If composite, then the uniqueness is enforced across the columns as a whole. Defining a PK or unique constraint automatically creates a Unique index
• Covering – includes all the columns that are needed to process a query; an extension of nonclusteredfunctionality; adds non-key columns to the leaf level; not included when calculating number of index key columns or index key size.
• If a table’s data changes frequently, keep indexes few, simple, & narrow.
• For tables with a lot of data and infrequent changes, use as many indexes as needed for performance.
• Create nonclustered indexes on columns used frequently in predicates and join conditions.
• Index columns with exact match queries.
• Don’t index small tables, a Table scan is quicker
• Try to keep predicate order the same as index order
• Periodically check DMVs for usage and for unused or missing indexes (sys.dm_db_index_usage_stats & sys.dm_db_missing_index_*)
Performance Issues
• Possible causes– Blocking
– CPU Bottlenecks
– Memory Bottlenecks
– I/O Bottlenecks
• Tools to Identify– Performance Monitor (PerfMon)
– SQL Server Profiler
– DBCC commands
– DMVs
Blocking
• Blocking is primarily waits for logical locks, which occur when a request to acquire a non-compatible lock on an already-locked resource is made.
• Identifying:
– DMVs: sys.dm_os_wait*, sys.dm_tran_locks
– Profiler: Deadlock graph & Blocked process report
CPU Bottlenecks
• Can be caused by insufficient hardware, poor query tuning, or excessive query compilation.
• Identifying:– PerfMon – “%Processor Time” > 80%, ratio of
“SQL Recompilations / sec” to “Batch Requests / sec” be low
– Profiler – watch SP:Recompile & SQL:StmtRecompile classes
– DMVs – sys.dm_exec_query_stats & sys.dm_exec_query_optimizer_info
Memory Bottlenecks
• Low memory conditions, or memory pressure
• Use of AWE & VAS, actual physical memory, other applications
• Identifying:– Task Manager
– Performance Monitor – “Memory: Available”, “Process: Working Set”, “Paging File:*”
– DMVs – sys.dm_os_memory_*
– DBCC MEMORYSTATUS
I/O Bottlenecks
• Check memory first as it can cause I/O
• Check execution plans for high I/O
• Identifying:
– PerfMon – Avg Disk Queue, Avg Disk Sec/Read, Avg Disk Sec/Write, %Disk Time, Avg Disc Reads/Sec, Avg Disk Writes/Sec
– DMVs – sys.dm_io_* & sys.dm_os_wait_statswhere wait_type like 'PAGEIOLATCH%'
Scaling it all up
• Single database design isn’t appropriate here
• Designs have to incorporate multiple databases over multiple servers with different characteristics
• Transactional & Analytical needs are different
• Indexing strategies are different
• Execution plans should be scrutinized
• Partitioning becomes pertinent as current and archive data coexist
Personal toolbox, templates, & links
Watch my website and blog, I’ll post my toolbox of scripts, templates I use for object maintenance, and all the links I keep handy for referencing SQL topics.
http://adamhutson.com