Top 10 Developer Mistakes That Won't Scale with SQL Server
•Download as PPTX, PDF•
0 likes•324 views
You're a C# or Java developer building an application that stores data in Microsoft SQL Server, and you want to avoid common pitfalls that will cause you scalability problems down the road. In this session from my live stream, you'll learn why you probably want to avoid triggers, SELECT *, user-defined functions, dynamic SQL, big datatypes, heaps, storing binaries in the database, old indexes, TempDB, and SQL Server's v1 features.
Recommended
More Related Content
Similar to Top 10 Developer Mistakes That Won't Scale with SQL Server
Similar to Top 10 Developer Mistakes That Won't Scale with SQL Server (20)
More from Brent Ozar
More from Brent Ozar (17)
Recently uploaded
Recently uploaded (20)
Top 10 Developer Mistakes That Won't Scale with SQL Server
- 1. TOP 10 DEVELOPER MISTAKES THAT WON’T SCALEBRENT OZAR, MCM BRENT OZAR PLF
- 6. TODAY’S AGENDA Triggers SELECT * UDFs Dynamic SQL Big Fields Heaps Binaries Old Indexes TempDB V1 Features
- 7. 10. TRIGGERS Automated business logic Always enforced Instantaneous Transparent to application Reduces network traffic
- 8. WHY TRIGGERS DON’T SCALE Can’t uncouple timing Can’t uncouple processing Minimal error handling Messy multi-record handling
- 9. TYPICAL TRIGGER DESIGN CREATE TRIGGER trig_addUser ON Users FOR INSERT AS DECLARE @newStatus VARCHAR(10) SELECT @newStatus = (SELECT StatusName FROM Inserted) IF @newStatus = 'INACTIVE' PRINT 'Inactive employees not allowed.’ ROLLBACK
- 10. TRIGGER ALTERNATIVES SQL Agent Job Application Server Service Broker
- 11. 9. SELECT * SELECT TOP 100 * FROM dbo.Posts WHERE OwnerUserId = 1538 SELECT TOP 100 Tags, Id FROM dbo.Posts WHERE OwnerUserID = 1538
- 13. Temp tables: old and busted Table variables: the new hotness 8. TABLE VARIABLES
- 14. Table variables are in memory Don’t hit TempDB Not logged Must be faster MID-CAREER-CRISIS DBA SAYS Picture Source http://www.flickr.com/photos/bounder/1233004463/
- 15. DECLARE @Cruisers TABLE (ID INT IDENTITY(1,1), CruiserName VARCHAR(100)); INSERT INTO @Cruisers VALUES ('Tim Ford'); SELECT * FROM @Cruisers; THE TABLE VARIABLE STATS PROBLEM
- 17. DECLARE @Cruisers TABLE (ID INT IDENTITY(1,1), CruiserName VARCHAR(100)); INSERT INTO @Cruisers VALUES ('Tim Ford'); INSERT INTO @Cruisers VALUES ('Brent Ozar'); SELECT * FROM @Cruisers; NOW WITH TWO ROWS…
- 19. DECLARE @Cruisers TABLE (ID INT IDENTITY(1,1), CruiserName VARCHAR(100)); INSERT INTO @Cruisers VALUES ('Tim Ford'); INSERT INTO @Cruisers VALUES ('Brent Ozar'); SELECT * FROM @Cruisers OPTION RECOMPILE; USING OPTION RECOMPILE
- 21. “Let’s use OPTION RECOMPILE everywhere.” MID-CAREER-CRISIS DBA SAYS Picture Source http://www.flickr.com/photos/bounder/1233004463/
- 23. 7. DYNAMIC SQL DECLARE @string NVARCHAR(100) SELECT @string = 'select * from authors' + 'ORDER BY ' + @OrderBy EXEC sp_executesql @string
- 24. DYNAMIC SQL ALTERNATIVES Move it into the app Build permanent stored procedures Educate your developers with:
- 26. PROBLEMS WITH BIG FIELDS More memory means less is cached More storage means slower IO More sort space required Study of effects: http://BrentOzar.com/go/bigfields
- 27. 5. BINARIES IN THE DATABASE SharePoint Document management Fax software Web site images File uploads
- 28. ALTERNATIVE STORAGE SQL Server 2008’s FileStream SQL Server 2008 R2’s Remote Blob Storage SQL Server Denali’s FileTable Store pointers, not files Content Distribution Networks (CDNs)
- 29. 4. HEAPS
- 31. WHEN HEAPS AREN’T BAD Staging tables Temporary or one-time backups When you’ve really, really tested them
- 32. HOW TO FIND HEAPS: BRENTOZAR.COM/GO/HE APS
- 33. HOW TO FIX ‘EM Implement a primary key Ask the developers & business for unique fields Sometimes PK != CL In a rush? Use identity fields Measure for improvement
- 35. HOW TO SCALE Pick a business statistic Set a baseline Monitor growth Revisit indexes Reset baseline
- 37. REMOVING INDEXES
- 39. THE RESULTS
- 40. 2. RELYING ON TEMPDB
- 41. CONSIDER AN APP-BASED TEMPDB One per app, like AccountingTempDB Can tweak storage Avoids differential backup problems Avoids log shipping, mirroring problems
- 42. 1. USING VERSION 1.0 FEATURES Photo Source http://www.flickr.com/photos/nobihaya/96169325/
- 44. PAST ONE-AND-DONE FEATURES SQL Server Notification Services English Query SQLMail DTS Packages (well, 2 versions) Surface Area Configuration Tool Vardecimal
- 45. SQL 2008 V1.0 Master Data Services StreamInsight PowerPivot FileStream Remote Blob Storage Performance Data Warehouse Change Data Capture Change Tracking Resource Governor DAC Pack Photo Source http://www.flickr.com/photos/seantyler/2632084397/
- 46. EARLY ADOPTERS Expect bugs, not scalability Meet peers, share work Expect fast rework Photo Source http://www.flickr.com/photos/denn/18743985/
- 47. RECAP You’re no Einstein Set yourself up for success Gotta scale? Avoid v1.0. Learn more: BrentOzar.com/go/scale Photo Source http://www.flickr.com/photos/jonkeegan/28036718/
Editor's Notes
- Uncouple timing – if we’re under heavy load and we just need to get the records in, we can’t. Processing – the crunching always has to happen on the SQL Server Minimal error handling – if something goes wrong, it can be difficult to gracefully alert humans Messy multi-record handling – people don’t build triggers right. Say we build a system that used to allow inactive employees, and now we want to add a trigger to not allow any new ones to be inserted.
- This doesn’t mean triggers are wrong. This just means BAD implementations of triggers are wrong. And there’s a lot of ways to go wrong with triggers. Let’s talk alternatives.
- In SSMS, you can do two queries, and it’ll show you the relative cost of the query. 98% of the crunch time went to the top query. Why? The bottom one can use an index. SQL Server doesn’t know that you don’t really need every single field on the table. Copies that data across the network, uses more memory in cache, uses more memory in your application too. All the hard work you put into indexing – gone. Fix: just don’t do it. Specify the fields you need. When you see it in someone’s slow query, try replacing it with just the fields you need. Then you can do effective index tuning. SQL Server’s DMVs will recommend bad indexes if you’re using SELECT *.
- The sad truth is that all of these are wrong, and in fact, table variables are usually SLOWER.
- This problem gets worse and worse with bigger volumes of data. Even with just 100 rows, SQL Server will make a spectacularly bad decisions about when it should do lookups versus table scans on OTHER tables.
- Gives us statement-level recompilations. SQL Server stops and does a gut check with everything it’s learned so far. This is great inside stored procs, because everything else in the stored proc keeps its execution plan.
- The sad truth is that all of these are wrong, and in fact, table variables are usually SLOWER.
- Better solution: stick with temp tables.
- Bobby Tables SQL Injection Problems with execution plan caching
- Customer table with Customer status field, Active bit. “We’re only going to need active/inactive, so let’s use a bit.” “Well, we might need more statuses in the future. Let’s use a tinyint.” “Well, what if we want to use a child table later to store statuses? We use Int for our primary keys.” Same approach happens with varchar – “Active” or “Inactive”. What if we get acquired by an international company and we need unicode in there? Gets worse with bigger fields - Social Security Numbers, addresses, customer numbers
- If you use a varchar field to store status, your application has to be able to handle invalid values. If you store Customer Number in five places in the DB, and they’re all smallint except one is a bigint, guess what’s gonna break? App, views, sps, temp tables, table variables What if somebody goofs up an update and misspells “Active”? What if there’s data corruption? More IO – Micelle Ufford has an excellent study at SQLPass I’ll link to in the show notes where storage is cut by 1/3 when fields are sized appropriately. Smaller indexes, smaller backups, faster defrags. Alternative – right-size your fields and document them.
- Heap is a table with no clustered index. No logical order to how the data is stored on disk. SQL Server just throws it wherever.
- Gives you exact index creation scripts Examine top two rows – same table, same equality column, different includes If we just build the top one, we’ll satisfy both requirements Need to combine the results of these together, analyze them, AND factor in your current indexes
- Temporary, and shared. Can run into TempDB contention problems when you’re constantly creating and destroying objects Usually not indexed well – people just create objects and think I just need ‘em once and they’ll be small But it’s a shared environment and you’re fighting for others with resources Not just other USERS, but database processes too. Sorts, indexing, snapshot isolation modes Totally unpredictable performance Solution – persist objects in their own databases. Either in the original DB, or make a user DB for it.
- Sometimes things take off right away, and they become massively popular. Sometimes…
- Sometimes they don’t You think it won’t be a problem for you?