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 statementsINSERT MyTable (Col1, Col2) VALUES ('a', 'b')

• Read SELECT statementsSELECT Col1, Col2 FROM MyTable

• Update UPDATE statementsUPDATE MyTable SET Col1 = Col1 + Col1

• Delete DELETE statementsDELETE FROM MyTable WHERE 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 Table

Right Table

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.

Left Table

Right Table

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.

Left Table

Right Table

FULL [OUTER] JOIN

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

Left Table

Right Table

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 1st execution

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

1-200

1-100

1-50

1-25 26-50

51-100

51-75 76-100

101-200

101-150

101-125 126-150

151-200

151-175 176-200

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 nonclusteredfunctionality; 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_statswhere 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