SQL Server 2008 Development for Programmers

3,006 views

Published on

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

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

  • Be the first to like this

No Downloads
Views
Total views
3,006
On SlideShare
0
From Embeds
0
Number of Embeds
1,664
Actions
Shares
0
Downloads
30
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

×