SQL Server 2008 Development for Programmers
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

SQL Server 2008 Development for Programmers

  • 1,055 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,055
On Slideshare
690
From Embeds
365
Number of Embeds
5

Actions

Shares
Downloads
28
Comments
0
Likes
0

Embeds 365

http://adamhutson.com 347
https://adamhutson.wordpress.com 11
http://feeds.feedburner.com 5
http://www.slideshare.net 1
http://adamhutson.wordpress.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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