Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SQL Server 2008 Development for Programmers

3,548 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

SQL Server 2008 Development for Programmers

  1. 1. SQL Server 2008 Development for Programmers(Level 200)<br />Springfield .NET Users Group<br />June 28th, 2011<br />Presentation by Adam Hutson<br />
  2. 2. Speaker Bio – Adam Hutson<br />Database Developer at Expedia and a freelance developer.  <br />11 year career, mostly on software side, on database side for past couple years.  <br />Enjoy learning new development techniques, earning MSSQL certifications, and picking up various web & desktop development side projects. <br />Married 8 yrs & 4 kiddos (B-6y, G-4y, G-2y, & G-5m)<br />Blog: http://adamhutson.com/LinkedIn: http://www.linkedin.com/in/adamhutson<br />
  3. 3. Presentation Overview<br />Review of CRUD & JOIN basics<br />Dynamic vs. Compiled Statements<br />Indexes & Execution Plans<br />Performance Issues<br />Scaling up your Database<br />Personal toolbox, templates, & links<br />
  4. 4. CRUD basics<br />Create  INSERT statementsINSERTMyTable(Col1, Col2)VALUES ('a','b')<br />Read  SELECT statementsSELECT Col1, Col2 FROMMyTable<br />Update  UPDATE statementsUPDATE MyTable SET Col1 = Col1 + Col1<br />Delete  DELETE statementsDELETEFROMMyTableWHERE Col2 ='b'<br />
  5. 5. JOIN basics<br />[INNER] JOIN<br />LEFT [OUTER] JOIN<br />RIGHT [OUTER] JOIN<br />FULL [OUTER] JOIN<br />CROSS JOIN<br />
  6. 6. [INNER] JOIN<br />INNER Joins combine the matching records from 2 tables. INNER keyword is optional.<br />
  7. 7. LEFT [OUTER] JOIN<br />LEFT [OUTER] JOINs combine all the records from the left table and only the matching records from right table. OUTER keyword is optional.<br />
  8. 8. RIGHT [OUTER] JOIN<br />RIGHT [OUTER] JOINs combine all the records from the right table and only the matching records from left table. OUTER keyword is optional.<br />
  9. 9. FULL [OUTER] JOIN<br />FULL [OUTER] JOINs combine all rows from both tables regardless of match. OUTER keyword is optional.<br />
  10. 10. CROSS JOIN<br />CROSS JOINs provide a Cartesian product between two tables. A Cartesian product contains all the rows from all the tables combined.<br />
  11. 11. Dynamic vs. Compiled Statements<br />Dynamic SQL Statements<br />Constructed at runtime with variable data<br />Execution plan is determined on 1stexecution<br />Any adhoc query is dynamic to the optimizer<br />Compiled SQL Statements<br />Constructed at design time<br />Execution plan is known before execution<br />Stored Procedures are compiled<br />
  12. 12. Execution Plans<br />What is an execution plan?<br />Query optimizer’s attempt to calculate the most efficient way to implement a query.<br />Calculates the cost in terms of CPU, I/O, & speed.<br />Where are they stored?<br />Generating an execution plan is expensive, so they are stored for reuse in memory (plan cache).<br />Are purged from memory using an aging formula that considers it’s cost and use<br />
  13. 13. Indexes<br />What are indexes?<br />Catalog of locations and order of records in table<br />Why use them?<br />Speeds up queries; tables are just heaps of data without them<br />Types:<br />Clustered <br />NonClustered<br />Composite<br />Unique<br />Covering<br />
  14. 14. Index storage<br />An index is a set of pages (index nodes) that are organized in a B-tree structure.<br />Root Level<br />IntermediateLevels<br />Leaf Level<br />
  15. 15. Clustered – stores the actual data rows at the leaf level of the index; physically sorted table; only 1 per table<br />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<br />Composite – contains more than one column up to 16; can be clustered or nonclustered; max of 900 bytes<br />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<br />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.<br />
  16. 16. If a table’s data changes frequently, keep indexes few, simple, & narrow.<br />For tables with a lot of data and infrequent changes, use as many indexes as needed for performance.<br />Create nonclustered indexes on columns used frequently in predicates and join conditions.<br />Index columns with exact match queries.<br />Don’t index small tables, a Table scan is quicker<br />Try to keep predicate order the same as index order<br />Periodically check DMVs for usage and for unused or missing indexes (sys.dm_db_index_usage_stats & sys.dm_db_missing_index_*)<br />
  17. 17. Performance Issues<br />Possible causes<br />Blocking<br />CPU Bottlenecks <br />Memory Bottlenecks <br />I/O Bottlenecks <br />Tools to Identify<br />Performance Monitor (PerfMon)<br />SQL Server Profiler <br />DBCC commands<br />DMVs<br />
  18. 18. Blocking<br />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.<br />Identifying:<br />DMVs: sys.dm_os_wait*, sys.dm_tran_locks<br />Profiler: Deadlock graph & Blocked process report<br />
  19. 19. CPU Bottlenecks<br />Can be caused by insufficient hardware, poor query tuning, or excessive query compilation.<br />Identifying:<br />PerfMon – “%Processor Time” > 80%, ratio of “SQL Recompilations / sec” to “Batch Requests / sec” be low<br />Profiler – watch SP:Recompile & SQL:StmtRecompile classes<br />DMVs – sys.dm_exec_query_stats & sys.dm_exec_query_optimizer_info<br />
  20. 20. Memory Bottlenecks<br />Low memory conditions, or memory pressure<br />Use of AWE & VAS, actual physical memory, other applications<br />Identifying:<br />Task Manager<br />Performance Monitor – “Memory: Available”, “Process: Working Set”, “Paging File:*”<br />DMVs – sys.dm_os_memory_*<br />DBCC MEMORYSTATUS<br />
  21. 21. I/O Bottlenecks<br />Check memory first as it can cause I/O<br />Check execution plans for high I/O<br />Identifying:<br />PerfMon – Avg Disk Queue, Avg Disk Sec/Read, Avg Disk Sec/Write, %Disk Time, Avg Disc Reads/Sec, Avg Disk Writes/Sec<br />DMVs – sys.dm_io_* & sys.dm_os_wait_stats where wait_type like 'PAGEIOLATCH%'<br />
  22. 22. Scaling it all up<br />Single database design isn’t appropriate here<br />Designs have to incorporate multiple databases over multiple servers with different characteristics<br />Transactional & Analytical needs are different<br />Indexing strategies are different<br />Execution plans should be scrutinized<br />Partitioning becomes pertinent as current and archive data coexist<br />
  23. 23. Personal toolbox, templates, & links<br />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.<br />http://adamhutson.com<br />

×