New year, new updates. After a brief stint as a DBA at another organization I have returned to my previous employer to take on a new and exciting role as a Database Administrator in a large SaaS environment. This environment has customers and data centers all over the wold and will certainly present some new challenges. It’s no secret that IT as a whole is trending toward cloud architecture and I’m excited to be right in the thick of it.
I’m also excited to announce that I will be presenting my session “Troubleshooting SQL Server Performance Using Wait Stats” at the Ohio North SQL Server User Group on January 6 and then again at SQLSaturday #357 – Cleveland on February 7. These events will be my first speaking engagements and I am definitely looking forward to them.
I have again become quiet on this blog as the last few months have seen two career moves that have kept me busy. Now that I have started to settle in I hope to increase my posting frequency. My new role should provide me with plenty to share!
My first post on this blog detailed a scenario where a read uncommitted select statement could ultimately block an insert/update/delete. In this scenario, a long running read uncommitted select is executed requiring a schema stability lock. That lock prevented the online rebuild from grabbing the schema modification lock necessary and caused the update statement to get queued up behind it.
SQL Server 2014 introduced an option that will allow more control over how online rebuilds behave in a scenario such as the one I described. The WAIT_AT_LOW_PRIORITY option gives you a few different choices in dealing with blocking scenarios. The syntax, from Books Online, is below.
If you’ve worked with SQL Server for any length of time, you know that sort order is never guaranteed without an ORDER BY. I was recently asked why a query (without an ORDER BY) brings back results in alphabetical order in production while in test it returns them in the order they were inserted to the table. To explain this, I showed a quick example that I thought I would share.
Collation is one of the easiest settings to overlook when configuring SQL Server but it’s one that can come back to bite you if it isn’t properly set. In this post I intend to cover the basics of collations, common issues resulting from collation misconfiguration, and basic resolution of those common issues.