T-SQL Tuesday #80 Happy Birthday Chris, Have Some Changes
My good friend and brother Chris Yates is hosting this month’s T-SQL Tuesday. I’ve not participated in one of these for a little bit now. Been busy doing the consulting thing, I guess! I cannot believe this is the 80th month already! That’s about six years of T-SQL Tuesday Blog Carnivals. I still remember way back when when Adam Machanic started this blog carnival up on his site. I contributed a post to it on SQL Server dates and times. And just a few months later I hosted the 4th on “IO”. What a great resource this has been.
This month Chris is celebrating his birthday on T-SQL Tuesday and wanted to make this a post where folks could give a present. Maybe a tip or trick. Maybe a reminder. Maybe talk about some features they’d like in the Engine. I’ll make my contribution a feature request kind of post. These are presents that would help a lot of the folks who are accidental DBAs or the people who sort of install SQL Server and set it and forget it.
SQL Server Health Assessment Finding Inducing Changes
So in my day job I run a SQL Server consultancy and am a consultant to a lot of different industries and clients. I sometimes do SQL Server health assessments. I sometimes get called to parachute in and fix problems caused by misses on best practices. So I say this knowing I could lose some of the clients with simpler challenges. I understand I’d miss some of what I see at so many environments. I’m really okay with that potential, though. I want folks to have a great experience in SQL Server. I’ve been working with it for 17 years now (!!) and it is a great product. Some of these things can be resolved. Like they changed the TempDB configuration in SQL Server 2016. I would be fine seeing more environments off to a healthier start.
CHECKDBs – I would love to find a way to improve on this process. Or even a dashboard that is visible to any (and all) who go into SSMS to see that CheckDBs have been missed. These are vital and they help show when a database is possibly corrupt. Knowing about that as soon as you can means you have a chance to do something about it.
Alerts – We all recommend the same alerts. To every client. Why not just build them in. There are a lot of products that give an optional “e-mail address” request during setup. What if SQL Server configured an “administrative” DB mail profile and enabled it during the installation? It prompted you for mail server info, account info, etc. and this was only used internally for alerts and health. Then this process could scour the error logs, receive alerts and send them out. Sure I tell my clients to use agent alerts and install a tool like SQL Sentry, but not all do, not all can. Heck why not even allow an outlook.com mail server to act as a proxy in the event someone doesn’t have one. Something simple that doesn’t send too much info but let’s someone know “hey something isn’t right”
Backups – Simple vs Full. Default is FULL, but how many clients have I been to with really really large transaction logs? Heck my most popular blog post still 7 years later is my one where I tell folks to be careful with shrinking data files and to watch log growth by using best practices.
Other Defaults – Imagine if setup asked some more questions or used some better guesses for things like max memory. Sure a default has to be dumb in a sense, but what if the install just automatically decided that MAXDOP of 35 was a better “one size fits all” number than 5. What if they decided that Optimize for Ad Hoc workloads made more sense more often than it didn’t and just had it enabled by default. Or did a max mem calculation which still wouldn’t be perfect in all environments (multi instance, SSAS and SQL, installing SQL on a server with other items, etc) but would generally beat out the default of effectively unlimited.
I’m sure there are many others, but I’m trying to stay well shy of 1,000 words 🙂 How about you? What do you want to see? It’s not too late to start blogging and contribute to T-SQL Tuesday today 🙂