The most popular tech Q&A site in the world serves 12-14 million web pages per day with Microsoft SQL Server 2008 R2. They’re passionate about performance, and they’ll share the scalability lessons they learned along the way. This session is aimed at production DBAs who manage SQL Servers that need to go faster and SQL programmers who don’t understand why their database won’t deliver queries quicker.

More of My Free Training Videos

Brent Ozar
I make Microsoft SQL Server faster and more reliable. I love teaching, travel, and laughing.

I’m mostly a figurehead here at Brent Ozar Unlimited. My true skills are menu advice, interpretive dance, and reading Wikipedia.
Brent Ozar on sabtwitterBrent Ozar on sablinkedinBrent Ozar on sabinstagramBrent Ozar on sabgoogleBrent Ozar on sabfacebook
↑ Back to top
  1. Another interesting trend I *think* I have noticed is a move from LINQ to more hand written queries (would need a dev to confirm for sure). Possibly because it is easier for `select *` statements (or just extraneous columns) to slip in. Also, since SQL is already a declarative language, tuning T-SQL with yet another abstraction layer I imagine is kind of a pain.

    As I said though, you would need to check with the developers to make sure I am not making this up.

  2. I love the conventional-wisdom-man voice you do.

    By the way, who was that quote from “Do stuff by the book …”?

  3. Following up on Kyle’s comment.

    While we’ve always had some plain SQL in our app, there has been a definitely trend away from LINQ in the last year or so. Places where we’ve always used SQL are generally those where we needed some construct you can’t (easily) express in LINQ, or where the “fetch and update” pattern of LINQ imposed too much overhead.

    A tiny part of the migration was caused by the “SELECT *” problem, although that’s easy to solve with LINQ it’s also rather easy to forget to. The rest was actually the CPU cost of LINQ generating the query SQL and deserializing the resulting rows.

  4. Absolutely the best presentation about scaling and not only SQL Server.

  5. Great webcast. I do not agree with Comparing and calculating != Querying completely, Sometime it is ok to do some calculation on SQL server, for example, If i have 1000 records and i just want to know the sum of amount column, I would prefer to use SUM function on SQL instead of bringing 1000 rows with amount to APP server and calculate the sum. In some cases we have to look at the amount of data we will be fetching from SQL.

    Thanks for the webcast, I am going to share it with my DBA co-workers. We are in middle of rewriting an APP for a big bank and they are just not able to understand that why we are moving all business logic from SPs to Domain.

  6. Minor correction: actually, we *do* run mvc-mini-profiler 24×7 in production (for devs) – it is very very low impact, so spotting problems immediately is more important.

  7. Pingback: Stuff The Internet Says On Scalability For November 18, 2011 | Krantenkoppen Tech

  8. Pingback: | Blog | Stuff The Internet Says On Scalability For November 18, 2011

  9. Pingback: Links for November 15th through November 18th — Vinny Carpenter's blog

  10. Sorry to be a pedant, but the Chrome ad is not ‘live’ over the web, so doesn’t illustrate anything regarding the performance of the recipie site.

    The ads use locally cached pages (and do say that in the ad), to illustrate how fast Chrome renders (and that alone).

  11. Hi Brent,
    Trying to find the “Glenn” script ( but link goes to a page of Glenn Berry’s blog posts.
    Can you provide/correct the link?

  12. Pingback: SE Podcast #28 – Brent Ozar - Blog – Stack Exchange

  13. I thought the cost of SQL server was per socket not per core, or has this change in 2012?

  14. @Ian, just noticed that on their pricing page too… Interesting turn of events.

  15. Pingback: Scaling SQL Server « Shawn P Hoffman

  16. Brent, Thank you for the excellent presentation. It’s very helpful.

    One question: What is a two-socket server? Does that refer to CPU cores, CPUs, etc?

    Thanks again.

    • Hey Mike,

      “Socket” means physical processor socket. The main reason this term is used is just to distinguish the physical processor itself from the number of cores it has (with or without hyper threading).

      Hope this helps!

  17. Pingback: Scaling SQL Server « Fast .NET

  18. Pingback: Scalability: Links, News And Resources (2) | Angel "Java" Lopez on Blog

  19. Hi Brent, what did you use to make the video above? The talking head popout is great.

Leave a Reply

Your email address will not be published. Required fields are marked *