SQL Server 2008 Development for Programmers

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

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

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.

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

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

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.
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 nonclustered functionality; 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_stats where 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

SQL Server 2008 Development for Programmers

by Adam Hutson on Jun 28, 2011

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 57

Statistics

SQL Server 2008 Development for Programmers — Presentation Transcript

http://adamhutson.com	56
http://www.slideshare.net	1