Presentation given to the Springfield .NET Users Group on SQL Server 2008 Development.

1. SQL Server 2008 Development for Programmers(Level 200) Springfield .NET Users Group June 28th, 2011 Presentation by Adam Hutson

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

3. Presentation Overview Review of CRUD & JOIN basics Dynamic vs. Compiled Statements Indexes & Execution Plans Performance Issues Scaling up your Database Personal toolbox, templates, & links

4. CRUD basics Create  INSERT statementsINSERTMyTable(Col1, Col2)VALUES ('a','b') Read  SELECT statementsSELECT Col1, Col2 FROMMyTable Update  UPDATE statementsUPDATE MyTable SET Col1 = Col1 + Col1 Delete  DELETE statementsDELETEFROMMyTableWHERE Col2 ='b'

5. JOIN basics [INNER] JOIN LEFT [OUTER] JOIN RIGHT [OUTER] JOIN FULL [OUTER] JOIN CROSS JOIN

6. [INNER] JOIN INNER Joins combine the matching records from 2 tables. INNER keyword is optional.

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

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

9. FULL [OUTER] JOIN FULL [OUTER] JOINs combine all rows from both tables regardless of match. OUTER keyword is optional.

10. CROSS JOIN CROSS JOINs provide a Cartesian product between two tables. A Cartesian product contains all the rows from all the tables combined.

11. Dynamic vs. Compiled Statements Dynamic SQL Statements Constructed at runtime with variable data Execution plan is determined on 1stexecution 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

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

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

14. Index storage An index is a set of pages (index nodes) that are organized in a B-tree structure. Root Level IntermediateLevels Leaf Level

15. 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 nonclustered functionality; adds non-key columns to the leaf level; not included when calculating number of index key columns or index key size.

16. 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_*)

17. Performance Issues Possible causes Blocking CPU Bottlenecks Memory Bottlenecks I/O Bottlenecks Tools to Identify Performance Monitor (PerfMon) SQL Server Profiler DBCC commands DMVs

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

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

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

21. 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_stats where wait_type like 'PAGEIOLATCH%'

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

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