This is one of several posts on modernizing T-SQL code with new features and functionality available in SQL Server.
Last year, you finally retired the last of your SQL Server 2008R2 instances. Congratulations! But are you taking advantage of everything that your new instances have to offer? Unless you did a review of all of the T-SQL in your applications, I’m guessing not.
Let’s take a look at the SEQUENCE object, introduced with SQL Server 2012.
This is another in a group of several posts on modernizing T-SQL code with new features and functionality available in SQL Server.
SQL Server 2016 gave us the STRING_SPLIT() function, but what about the reverse - compiling a set of values into one delimited string? We only had to wait 15 months for the release of SQL Server 2017, and the STRING_AGG() function.
For this post, I’m using the set of North American telephone area codes sourced from the North American Numbering Plan Administrator. It’s a really simple table, but that makes it perfect for this example. The whole table is 389 records and two columns each.
This is the first of several posts on modernizing T-SQL code with new features and functionality available in SQL Server.
Last year, you finally retired the last of your SQL Server 2008R2 instances. Congratulations! But are you taking advantage of everything that your new instances have to offer? Unless you did a review of all of the T-SQL in your applications, I’m guessing not.
At one time or another, we all find ourselves having to do some string parsing, especially splitting strings on a delimiter. Nearly all of us have one (or two or a dozen) functions for doing this somewhere on every instance of SQL Server. But since SQL Server 2016, we’ve had an official way to do it - the STRING_SPLIT() function.
It’s early September, which means it’s time for T-SQL Tuesday! This month’s topic comes from Kevin Chant (blog | twitter). Our mission, should we choose to accept it (click the image to see the original invite):
Recently I’ve had to submit suggestions to Microsoft about Azure DevOps and SQL Server.
I will admit a couple of the suggestions had certainly been in my head for a while. In fact, I wish I had suggested them sooner.
This is Part 3 in a three-part series. Please see Part 1 and Part 2 for more.
What does your average day look like?
I’m going to punt to my “A Day in the Life” series here.
When you started, did you know what your position was going to look like 1 month, 6 months, 1 year, 5 years from then? How accurate has that been so far?
I’ve only been at my current job for about 2 1/2 years, but I can speak to the shorter intervals. I’m going to be intentionally vague in spots here as I don’t want to disclose too much.
This is Part 2 of a series. Please see [Part 1]/2019/09/03/qa-dealing-with-thousands-of-databases/) for the background and more.
What is the most unexpected experience you’ve had in this position?
I have two answers to this question.
I write more dynamic SQL in any given week than I had previously in my career - all years combined!
Many DBAs deal with issues around parameter sniffing and plans being stuck in cache that don’t work well for a number of their requests as a result. This hasn’t been an issue for me because my plan cache is constantly churning and the majority of queries are ad-hoc. I usually see 75-90 percent of my cached plans being created within the previous few hours, although that number has been changing lately as we’ve been shipping query optimizations the past few months.
This is part one of a three-part series.
I’ve mentioned in various places, including in blog posts on occasion, that my production SQL Server instance hosts several thousand (nearly 9000 as of this writing) databases. People are usually surprised to hear this and it often leads to interesting conversation.
Jon Shaulis (blog | twitter) asked me on Twitter recently:
And I realized that I haven’t ever sat down to address this in detail. I’ve spoken about it on the SQL Data Partners Podcast and written little bits here and there on the blog in the context of “here’s something that tripped me up” but I haven’t really sat down to write specifically about the topic.
Announced at DataGrillen 2019 today, the amazing dbatools PowerShell module has officially released version 1.0. This is a tremendous milestone for the best Open Source project built for data professionals.
What started out as a single PowerShell script for migrating SQL Server instances in Chrissy LeMaire’s (blog | twitter) datacenter has become the most important and comprehensive Open Source toolkit for SQL Server database administrators and developers. Whether you’re managing one server or one thousand, this module is an indispensable tool which will make your day more productive and less error-prone.
This month’s T-SQL Tuesday comes from Todd Kleinhans (blog | twitter) who wants to know what we’re doing with databases outside of work.
I’m curious- outside of work and learning, what do you personally use databases for? Tracking books you have, recipes, collections, etc? While it can be said using databases for personal use could be either overkill or a hammer in search of nails on the other hand, it is exactly what they are for- storing data.
By now many of us have upgraded from SQL Server 2008R2 and we’re on the “regular Cumulative Updates” train now. For the rest, it’ll (hopefully) happen soon. And since we want a long runway, we’re upgrading to SQL Server 2016 or 2017. Current software! New features! Mainstream support! But…there’s a catch.
DBAs & sysadmins don’t want to fall too far behind on patching for a variety of reasons. It used to be that monthly patch cycles were primarily for Windows Server. When we were running SQL Server 2008R2, our last significant update was years ago. SQL Server 2012 is now out of support and isn’t receiving updates very often. Point being, a SQL Server update install has been the exception, not the norm, in the patch cycle for many of us the past couple years.