SQL Tips for the YouTube generation. 20 unrelated and independant tips, one right after another to speed up your database application without a ton of work.

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

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

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 3

4. Tip #2: Prettify! 4 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.) 5

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

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 7

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

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

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

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 11

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

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

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

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 15

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 16

18. Advantages of common table expressions:

19. Queries with derived tables become more readable

20. Provide traversal of recursive hierarchiesWITH 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

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

23. private to batch

24. avoids transaction affects

25. designed for smaller number of rows where scans are cheaper than seeks

26. limited indexing

27. static nature reduces recompiles

28. prefer to use with small number of rows

29. temporary tables

30. persists for session

31. can be shared over sessions and scopes

32. can participate in transactions

33. can be indexed

34. can trigger frequent recompiles

35. get statistics

36. prefer to use when you have more rows

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

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

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

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

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