Editorials, Ethics

Blind Trust of AI for SQL Server… Even Now

With so much happening with AI and so many instant wins, it’s easy to remember to step carefully into the darkness.  I’ve been seeing and hearing so many more questions, stories, suggestions and other feedback about “it said to do “X”, so I did… what do you mean that might not have been the best solution?”

There are so many things we’ve all come to trust in automation.  From index tuning to performance ideas, compliance and into the operation of the systems in general.  I’m a big fan of SQL Agent too, it provides automation in ways that standardize and save time and money.

The thing is, back to that whole “keeping up with the changes” theme in the code of ethics that has been being discussed, things change.  Data, inputs, users, requirements, access needs, systems, environments, etc.  All of it changes – it’s this constant ebb and flow of functionality.  The things that have been biting people are unchecked  automation, and AI-type tools that are taken as gospel, not suggestions.

We’ll see more and more of this – the automation of the systems, tools and and infrastructure.  The tendency is to set it and forget it until you need to change it.  However, I’d suggest that this type of acceptance can hurt your installations.  Sure, the tools work well, but it’s “machine learning” not “machines were born knowing all absolute truths about your systems and data and will never need to be updated.”  Machine learning is such a simpler term.  🙂

We have to learn how to automate all of  this.  How to manage and maintain it too once the pieces are in play.  It’s not that you have to be constantly looking over your shoulder, checking and re-checking every single thing and making sure some small thing didn’t work right.  But it is about having review cycles, exception logging and recovery built in.  More and more I’ve been seeing deployments with the upside of automation, but no recovery path in terms of what should happen if the process fails, or if some bit of the AI doesn’t quite put the right pieces in play.

As you use these tools, make sure you have a process for watching over things – operations that are supposed to run.  Optimizations that need to be double-checked for sanity before being applied.  Even down to how information is presented to your user base – making sure ALL of the data elements are there for consideration all the time, and that there is some sort of double-check.  There have been several cases where information came from multiple sources and one source was an empty set for whatever reason.  The information was just not considered and no error was thrown or indication that portions of the processing were based on partial data sets.

We’re not yet there – the blind reliance on automation and AI and all of that.  The tools are working, they’re learning, but we need to make sure it’s happening in the manner we expected and appreciate, rather than taking whatever happens as gospel.

It’s critical that there be a reasonable set of checks and balances – job that run, automation selections, AI, performance, information integration operations, etc.  All of it that you rely on – it only works if ALL of it is happening as you expect.  In addition, if you’re expecting your systems to make suggestions (be it reporting or performance tuning ideas) a sanity check is always in order before significant action is taken.

Be careful, and smart, out there.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
  • John Shadows

    One uncomfortable reality is that you may have to pan back further than is normal and change your design patterns and even learn new math.

    A common theme I see with SQL and R for example is that you have to have some background in statistics to be effective. Guess who bought himself a “Statistics for Dummies” book……

    Also the design patterns for the cloud impact even hybrid solutions to so now you have things like DTUs, eDTUs and IOPS to look at. Your trusty onprem function/
    stored procedure may turn out to be a DTU/eDTU/IOPS hog that’s better served as….wait for it….. a “serverless function”.

    Relinquishing timehonored onprem tactics maybe forced upon us by the volume and cost of moving that volume in the cloud.