Post on 24-Jun-2015
description
2
Assumptions @ You
• You aren’t a DBA• You don’t want to be a 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
3
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
4
Tip #2: Prettify!
http://extras.sqlservercentral.com/prettifier/prettifier.aspx
5
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.)
6
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.
7
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
8
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.
9
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)
10
Tip #8 - Quick Indexing Tricks.• check for clustered indexesSELECT t.[Name] FROM sys.Indexes i
JOIN sys.Tables t ON t.Object_ID = i.Object_idWHERE 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
11
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
12
Tip #10 – I don’t really know the symptoms, but SQL Doctor will find the cure.
• Idera• Red Gate• DB Artison• Quest
13
Tip #11– Baseline the right way• Idera Diagnostics Manager & RedGate
14
Tip #12 – Enforce Business Rules in the DB
• Foreign Keys• Unique Constraints• Check Constraints
15
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
16
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
Tip #15: CTE’s
• 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 NULLORDER BY NumSales DESC
A named temporary result set based on a SELECT queryA named temporary result set based on a SELECT queryCommon Table Expression
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: temp tables vs. table variables
• 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
• 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
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 salesPersonIDfrom sales.salesPerson swhere exists(select managerIDfrom humanresources.employee ewhere e.managerID = s.salesPersonID)
select salesPersonIDfrom sales.salesPersonwhere salesPersonID in(select managerIDfrom humanresources.employee)
where not exists vs. where not in• the possible presence of a null generates
different plans for not exists and not inselect salesPersonID from sales.salesPerson swhere not exists(select managerID fromhumanresources.employee ewhere e.managerID =s.salesPersonID)
select salesPersonID from sales.salesPersonwhere salesPersonID not in(select managerID fromhumanresources.employee)
22
Tip #19: Statistics UpdateFrom 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.
23
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.
24
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.
25
Conclusion
• Have a great code camp!• Ike Ellis
ike@ellisteam.net619.922.9801@ellisteam1www.ellisteam.netEllisteam.blogspot.com
• DevelopMentor SQL Course is coming!