SQL Code Guard within SQL Monitor - feedback needed

• 
  Is there any public announcement of this that I can reference people to?

  paulo_morgado August 23, 2017 14:58

  - 0 +
• 
  Hello not yet. I wanted to get a feel for the usefulness of this first. A blog post should be coming out soon

  Mark_Champion August 23, 2017 15:02

  - 0 +
• 
  I would view this as a nice to have, and certainly a place where I could perhaps improve the code. I'd certainly like a good list that I could use to get counts of how often some of this is used, to show if this is a potential large scale problem.
  
  These aren't necessarily performance problems (though they could be). These are often indicators or potential other problems that could cause the code to behave poorly. As such, this could be somewhat distracting when looking to solve a specific issue.
  
  OTOH, I need to ensure if I modify the rules for SQL Code Guard, I can modify them here. I shouldn't have to say that sp_, or some generic rules needs to be an issue.
  
  In looking at the feature, it can be hard to see the lines, especially if I am actually working on some other aspect of monitoring. I'd prefer to see that you have a list somewhere, or a button that says "CodeGuard Analysis" that would list all the places and rules that are an issue. However, in a large list, I might need to be able to ignore some of these. It's entirely possible that something like NOLOCK is a fundamental embedded code item in the application (say for a Dynamics database) and I can't change it. Don't want to be constantly reminded that I can't fix this.
  

  way0utwest August 23, 2017 15:04

  - 0 +
• 
  I wouldn't want it to be a whole lot more intrusive, but I do find it a little subtle. Basically everything Steve said. Plus, is there a way to get a more complete report across the database or is it focused only on the query?

  Grant August 23, 2017 15:55

  - 0 +
• 
  I like the idea in principle. I agree with Steve, though - recommendations that don't further the goal of improving a query's performance would just be noise in SQL Monitor.

  eleightondick August 23, 2017 16:07

  - 0 +
• 
  I think this could be an incredibly powerful analytic feature. To make it so, at least for performance tuning, you need a GOOD set of rules that each have a high-probability of showing poorly-performing code, with minimal false positives or negatives. You also need a way to have SQL Monitor do a sweep/recommend JUST performance issues. Think Rules Categories. There are more than a few TSQL thingies that could be flagged as questionable/poorly written that have nothing at all to do with performance (no aliases, NOLOCK, etc).

  TheSQLGuru September 05, 2017 21:39

  - 0 +

Add comment

Please sign in to leave a comment.