Comments on: SQL Quiz, Part 2: Toughest Challenges

By: SQL Quiz: Toughest challenges | Ian Kirk - SQL DBA

SQL Quiz: Toughest challenges | Ian Kirk - SQL DBA — Mon, 22 Dec 2008 16:25:03 +0000

[...] Shaw posted a SQL Quiz, setting it up as a game of tag, and I got my tag from SQL Fool (@SQLFool on Twitter) when she answered the question -“What are the largest challenges that you [...]

By: David Stein

David Stein — Mon, 15 Dec 2008 16:14:05 +0000

Jeff Atwood has a good article on your first point. Everything is fast for small n.

http://www.codinghorror.com/blog/archives/000957.html

Just an FYI.

By: Phil Factor

Phil Factor — Sat, 13 Dec 2008 11:02:08 +0000

My great education was when I moved to a fast-growing Telecommunications company to take on the retail billing system. It was a culture shock, and a lot of relearning. A million rows sounds like nothing, but that was the daily feed of calls that went into the system. (SQL Server 7) I can’t remember the size of the table with the calls in (well over the billion) but ever since then, I’ve had a deep respect for SQL Server, and indexing strategies ever since.
It is sooo important to develop on a database the same size as the production server, if you can. The characteristics of a billion row table are quite different from the outgrown excel spreadsheets that people generally develop on. If I could only choose one utility to have, as a developer, it would be SQL Data Generator. Ten million rows, sir? right away!

By: SQLDenis

SQLDenis — Thu, 11 Dec 2008 21:09:58 +0000

This is a common scenario where people develop on a test/qa/dev system without any capacity planning and a subset of the data. Once they go live…oops…blocking galore, snail paced queries, timeouts etc etc

Also most people don’t update stats or defragment tables/indexes and over time it slows down too!!

By: Jeremiah Peschka

Jeremiah Peschka — Wed, 10 Dec 2008 14:43:50 +0000

I’m with you and Brent about the database size issue. Until a month ago, I was developing against 10% of the total data and my queries were running in tiny fractions of a second, I didn’t pay any attention to performance tuning. Now that I have all of the data in place, I’m revisiting all of my queries, optimizing the SQL, adding indexes, and generally doing all of the things that I’ve ignored since August. The change in scope is phenomenal and there are different techniques that I’ve had to pick up on very quickly in order to stay on top of my game.

By: Brent Ozar

Brent Ozar — Wed, 10 Dec 2008 14:24:19 +0000

You’re right about the move up in size: going from 10mm to even just 200-300mm row tables requires a big readjustment. Developers get so frustrated when their code flies on a 10mm row system and slows down in production, and it’s always “our” fault as the DBAs. Doh! Education is so important as a part of DBA life: we have to keep helping and training everybody if we’re going to be successful.