Amazingly Useful SQL Server Articles on SQLPerformance.com

IMG_0247

Me and Aaron Bertrand, SQL Sentry flagbearers.

One of the things we’ve been working on at SQL Sentry is building up institutional knowledge for the SQL Server community. There are three main ways that we’re doing that on-line:

  1. Hard-core tech articles on SQLPerformance.com, edited by long-time SQL Server MVP Aaron Bertrand ( b | t ).
  2. Helping tune tough SQL Server transactions on Answers.SQLPerformance.com for free.
  3. Streaming videos at SQLSentry.TV.

In addition, our monthly eNews newsletter keeps you up to date on all the latest happenings on all of these websites. Please subscribe! I’ll personally hug you if you do.

 

If you’ve never looked at any of these resources, a great starting place is our top 12 most popular blog posts of 2013 from the SQLPerformance.com website:

  • I used to ask myself “Isn’t everyone bored with string splitting problems?”. But this is such a perennial favorite, the answer is clearly “No. No, we’re not”. Read more about splitting strings the right way – or the next best way here.
  • Paul White ( b | t ) presents a definitive article on one of the most common SQL coding problems, parameter sniffing.
  • CHECKDB is essential for good database maintenance, but it can also be a resource hog. Here are some ideas for lightening its load: Minimizing the impact of DBCC CHECKDB: DOs and DON’Ts.
  • Jonathan Kehayias ( b | t ) steps out into licensing, the region labelled “Here be dragons” on the maps of most IT professionals, in this great article on performance problems appearing on SQL Server 2012 servers with CAL licensing.
  • All processors are not equal in the eyes of SQL Server. Glenn Berry ( b | t ) tells you about the most important factors in choosing CPUs in these two articles.
    • For SQL Server 2012, read here
    • And for SQL Server 2014, read here
  • Now here’s a perenial T-SQL problem that I’m glad to see summarized in one concise article, Best approaches for running totals.
  • Erin Stellato ( b | t ) gives us a great review of the best practices around indexing foreign key constraints here.
  • Generating number sets is a really valuable technique in many coding scenarios. Read about the most common scenarios here.
  • Joe Sack ( b | t ) tells us all about troubleshooting CPU problems in this article.
  • Ever wonder which is better – NOT IN, LEFT OUTER JOIN, NOT EXISTS, or EXCEPT? Find out in this excellent article by Aaron Bertrand.
  • Paul Randal ( b | t ) helps dispel another commonly held myth about transaction log behavior here.

 

Let me know if you’ve learned anything new at SQLPerformance.com or gotten help at Answers.SQLPerformance.com. It’s always a big encouragement for me when I hear personal feedback that some of my hard work actually made a difference in your day.

Many thanks,

-Kevin

-Follow me on Twitter!
-Google Author

Comments

  1. Kevin,

    I have a question for you. I’m am writing a new section for our SQL Server Policies and Procedures manual for SQL installations. I’ve come to an opinion for the following:

    The old way:
    V:\Data
    W:\Logs
    X:\Index
    Y:\TempDb

    The new way:
    V:\Data; V:\Logs; V:\Index; V:\TempDb
    W:\Data; W:\Logs; W:\Index; W:\TempDb
    X:\Data; X:\Logs; X:\Index; X:\TempDb
    Y:\Data; Y:\Logs; Y:\Index; Y:\TempDb

    I intend to spread the files out according to frequency of use across all 4 drive, hoping to better concurrency between data retrieval, index seeks, log transactions, and tempdb activity. Am I right to take this approach and if so why?

  2. Hi Brandon,

    You don’t mention anything about the underlying I/O subsystem. If this is an SSD-based system and not a HDD-based system using RAID or DASD, then you’ll see no performance decrease at all with this arrangement. If this is just four simple hard disks, you’re going to get hammered and give up a lot of performance. The reason is that on traditional RAID-based systems, you would try to isolate the transaction log files onto their own disk(s) so that they don’t have to interrupt their continuous, serial writes to service randomized reads and writes for the database files. Moving the armature heads away from the serialized nature of the log writes normally contributes to about a 30% decline in log write performance when you mix transaction log and database files.

    So tell me more about the underlying IO subsystem and I can give you a better assessment. Best regards,

    -Kevin

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.