Quick & Easy SQL Tips

Quick & Easy SQL Tips
Ike Ellis
http://www.ellisteam.net
ike@ellisteam.net
Twitter: @ike_ellis
1

Assumptions @ You
You are a new DBA
You don’t want to rewrite your entire application with a new schema, new DAL, or new queries
You want to learn just enough so that your SQL apps are fast and maintainable
2

Tip #1 – Performance Problem: Check the low-hanging fruit
Long-running jobs
Long-running transactions
DBCC OPENTRAN
Check for long-running queries/both in amount and in duration
3

Tip #2: Prettify!
4
http://extras.sqlservercentral.com/prettifier/prettifier.aspx

Tip #3 – Performance Problem : Identify hardware performance bottlenecks.
Memory
Disk*
Processor
Network I/O
*Most common bottleneck. It’s the Disk I/O, Stupid. (But it could be memory that’s causing it.)
5

Tip #4: The right way to find hardware problems
Merging PerfMon and Tracing
Get the Batch and Completed Events Only
Never trace from the computer you are monitoring
Always trace to a file and then load in a table after.
6

Tip #5: Files, Files Everywhere
All need their own physical drive for space management and performance
Master Data File (MDF)
Log Files (LDF)
TempDB Files
O/S/SQL Files
BAK Files
7

Tip #6: The Log File
Fills sequentially, so no need for striping, mirror is fine.
Don’t let it get filled up: Simple Mode or Backup.
8

Tip #7 - Good memory management
Check for other applications running on the SQL Server
Move anti-virus (or at least make sure it wasn't scanning the SQL ports or the SQL files)
Move Exchange and F&P services (cluster)
Turn off unneeded services
SQL is I/O bound, so I would turn off any network/disk intensive services (DHCP, DNS, etc)
9

Tip #8 - Quick Indexing Tricks.
check for clustered indexes
SELECT t.[Name] FROM sys.Indexes i
JOIN sys.Tables t
ON t.Object_ID = i.Object_id
WHERE i.type_desc = 'HEAP'
ORDER BY t.[Name]
check for nonclustered indexes on foreign key columns (ID Columns)
select * from sys.columns c
where c.name like '%id%'
and c.object_id not in
(
select object_id from sys.index_columns
)
check for non-clustered covering indexes
reads outnumber inserts/updates 5 to 10 to 1
10

Tip #9 - Run the Index Tuning Wizard (DB Tuning Advisor)
Run it a really long time, it is more accurate the longer it runs
Don’t drop existing objects
It’s OK to over-index
11

Tip #10 – I don’t really know the symptoms, but SQL Doctor will find the cure.
Idera
Red Gate
DB Artison
Quest
12

Tip #11– Baseline the right way
Idera Diagnostics Manager & RedGate
13

Tip #12 – Enforce Business Rules in the DB
Foreign Keys
Unique Constraints
Check Constraints
14

Tip #13 - Eliminate Cursors
Cursors focus on how, not why or what
Cursors are expensive
Cursors take up memory, which is usually a problem already
Cursors can often be written using a set-based method
15

Easy Tip #14 - Avoid Deadlocking, Blocking
Index Tune
Keep transactions short
Don’t lock when you don’t have to
Hit the tables in the same order (create a table order document)
Minimize the use of triggers
16

Tip #15: CTE’s
A named temporary result set based on a SELECT query
Common Table Expression
Result set can be used in SELECT, INSERT, UPDATE, or DELETE
Advantages of common table expressions:
Queries with derived tables become more readable
Provide traversal of recursive hierarchies
WITH TopSales (SalesPersonID, NumSales) AS
( SELECT SalesPersonID, Count(*)
FROM Sales.SalesOrderHeader GROUP BY SalesPersonId )
SELECT * FROM TopSales
WHERE SalesPersonID IS NOT NULL
ORDER BY NumSales DESC

Tip #16: apply operator
right parameter can be a table, but meant for tvf
cross apply does inner join
no output for row when udf produces no output
udf can get its parameters from left input
outer apply does left outer join
all rows from left input returned
may have nulls for columns returned by udf

Tip #17: temptables vs. table variables
table variables
private to batch
avoids transaction affects
designed for smaller number of rows where scans are cheaper than seeks
limited indexing
static nature reduces recompiles
prefer to use with small number of rows
temporary tables
persists for session
can be shared over sessions and scopes
can participate in transactions
can be indexed
can trigger frequent recompiles
get statistics
prefer to use when you have more rows
buffering data locally

Tip #18: where exists vs. where in
prior to sql server 2000, exists was preferred over in
now they generate the same query plan
select salesPersonID
from sales.salesPerson s
where exists(
select managerID
from humanresources.employee e
where e.managerID = s.salesPersonID)
from sales.salesPerson
where salesPersonID in
(select managerID
from humanresources.employee)

where not exists vs. where not in
the possible presence of a null generates different plans for not exists and not in
from sales.salesPersons
where not exists(
select managerID from
humanresources.employee e
where e.managerID =
s.salesPersonID)
from sales.salesPerson
where salesPersonID not in
(select managerID from
humanresources.employee)

Tip #19: Statistics Update
22
From the query plan, estimated number of rows and the actual number of rows need to equal each other. If they don’t, you might have a statistics issue.
Run sp_updatestats to rectify it.

Tip #20: Big Rows from Query Plan
When troubleshooting, thick rows means lots of data, thin rows mean not much data. You’re probably better off following the thick rows.
23

Tip #21: Missing Index Details
Just copy that, name the index something unique, and then run it.
Remember, it doesn’t look for overlapping indexes, so check that before you run.
24

Conclusion
Have a great code camp!
Ike Ellis
ike@ellisteam.net
619.922.9801
Twitter: @ike_ellis
www.ellisteam.net
25

http://ellisteam.blogspot.com	251
http://ellisteam.blogspot.co.uk	3
http://www.blogger.com	1
http://twitter.com	1
http://ellisteam.blogspot.co.nz	1

Quick & Easy SQL Tips

by Ike Ellis on Sep 19, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 257

Statistics

Quick & Easy SQL Tips — Presentation Transcript