Voice of the DBA

Author: way0utwest

  • Machine Learning in the Database

    When SQL Server added the ability to execute R code, the decision seemed to split the customer base into two groups. One group was impressed and thought the idea of executing R code to analyze data in the database was a good idea. They were excited and impressed by the loan classification demo. If you haven’t read about this or seen the demo, it’s very interesting, and it’s something you might take a few minutes to read or watch it.

    The other group of customers felt this was a poor use of CPU cycles for a very expensive SQL Server CPU license. Running a complex analysis, training models, and other functions commonly associated with R scripts aren’t a good use of scarce resources. They would rather have R code execute on a separate server, much like any large messaging workload might be better served by a service such as AWS’ Simple Queue Service rather than Service Broker.

    I tend to be in the first group, as is Dr. Low. He writes that there is a place where Machine Learning Services (MLS), with both R and Python, are a good use of resources. Not in all cases, and certainly not for all work. The difficult parts of training models and doing the hard work of coming up with new ways to perform an analysis is definitely better left to workstations and data scientists. Those actions might not be worth the resources they take.

    Once the models are trained, however, the executable load of submitting parameters to a model and getting a prediction is small. SQL Server allows us to load pre-trained models into the database and just call them as needed. Plus, the R models run in a multi-threaded fashion, unlike the single threaded execution in clients such as R Studio.

    As with any feature of SQL Server, it’s important to test and evaluate the real world impact of new code on production sized workloads. Not only will you want to measure the load of your model execution, but you should also measure any changes in your existing workload with the additional R or Python code load. While I wouldn’t prevent the use of MLS in SQL Server, just like SQL CLR code, I would be careful about introducing without extensive testing, including dark deployments and simulated loads.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.2MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Be Prepared with Baselines

    I visited a doctor recently, and he told me a measurement he’d made. I asked if it was good or bad, and he said he had no idea. The value varied too much from person to person, and without values from the past, he couldn’t really evaluate the significance of it. He will be able to in the future, now that he has a value, but there’s nothing that can be done now. At this point, he has a baseline (of sorts) and can now start to judge how things change over time.

    After that visit, I started thinking about Page Life Expectancy (PLE). PLE is one of those counters that so many DBAs look at early in their career. Often they’ve read guidance that they should worry once this is below 300, which isn’t true. There are calculations for this, but they are based on your system, and really, they’re a rough rule of thumb. Really you need to measure this for your system, so that you know what a the value often is and then worry when it dips.

    To do that you need a baseline. You need to measure various metrics about your system over time so that you understand what’s a normal value. Plenty of experts, like Erin Stellato and Tim Radney have written about baselines, why they’re important, and what you might want to capture. In fact, we have quite a few articles on baselines at SQLServerCentral.

    If that sounds like a lot of work to you, I agree. I’ve built systems in the past that captured metrics on my instances and stored the data. I wrote reports to view data, alerts to let me know when something is breaking (or broken), and maintenance that kept data storage under control. I essentially had to be both the software developer and operations staff for my systems. That works, but I’d try to avoid repeating that effort from now on. As Tim mentions in his piece, there are better ways to do this. There are products, such as SQL Monitor and SQL Sentry, that capture this data for you, that won’t have typos, mistakes, or holes in their operation.  Some will even show you the baseline visually to see if things are withing expected ranges.

    The monitoring software does lots for you, though at a price. It’s tested, and it does all the gathering, storage, basic analysis and alerting in a way that allows you to spend time on actually fixing issues, tuning queries, and providing value for your organization. I think it’s worth the cost, since I know that my time is better spent on solving problems, not writing monitoring software. You may feel the same way or youj may not. You may prefer to write your own system, or you may not have a budget and be forced to build your own. Whichever route you go, make sure you set up a baseline. You’ll appreciate having one the next time your phone rings with a call that the server is slow.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Two Types of Performance Counters

    I had an issue where an instance of SQL Server was only showing the XTP (In Memory) performance counters. None of the other SQL Server counters were available, so I followed the procedure I’d written about previously. Once that was completed, I restarted SQL Server and looked.

    No counters, still.

    Hmmm. It was then I scrolled further and realized that I had the SQL Server Agent counters, but not the database engine ones. I looked closer in the Performance folder for my instance and noticed this:

    2018-05-29 21_30_31-Binn

    There are two .ini files. There are

    • perf-<named instance>sqlcrt.ini
    • perf-SQLAgent<instance>sqlagtctr.ini

    These refer to the counters for the database engine and the Agent subsystem. I had unknowingly copied the Agent file for the lodctr.exe call rather than the other one.

    Lesson learned. I had to re-run the procedure with the engine ini file and restart the instance again.

    If you need to add counters, make sure you load both and run a restart, otherwise you might incur more downtime than you expect.

  • Microsoft and GitHub

    I started using git with GitHub. I thought their hosted service was fantastic, and have seen quite a few companies using private repos for their internal code, including my employer, Redgate. I see companies from Five Thirty Eight to releasing their data to the MuseScore sheet music software to TensorFlow to Programmer’s Proverbs. There are no shortage of useful, inspiring, and helpful repos you can browse. There are also plenty of silly ones, like the

    I have a GitHub folder on all my machines, and that’s become the place where I just stick repos. Some of them go to VSTS, some to Bitbucket, but I still always think of GitHub first when writing code. The others work great, and I’m glad we have choice, but I’ve always been fond of GitHub as a company that opened up a place to share code and data in a way that was somehow more attractive and easier than SoundForce or Codeplex or any other location. Maybe it’s the ease of git, but I really liked the site. The GitHub for Windows, not so much, but I don’t expect everything a company does to be perfect.

    Microsoft is buying the company, and GitHub seems fine with this. As one of the heaviest users of GitHub, Microsoft has been releasing their code on the platform for some time. This seems like there are some synergies here, and this is a great way for Microsoft to continue to open up some of their code and support the development community on all platforms, languages, and environments. Microsoft has said that they’ll keep the open source model, though there is no shortage of concerns and complaints. There are also a fair number of jokes. The Linux Foundation isn’t upset, which should make some people rethink their concerns.

    This is an interesting topic for me, and I brought up concerns over IP with some people inside my company. After all, we compete directly with Microsoft in some places, and we wouldn’t them to copy (and rewrite) our code to add to their products. That could dramatically affect our business, but no one worries about that. Decompilers and our own Reflector could be used to understand how algorithms are implemented, and certainly Microsoft has the resources to do this if they want to. They don’t, and there are other business and legal protections to prevent this.

    In some sense, the actual code really isn’t as important as many of us think. Certainly it’s not in SQL Server where our object is readable by whoever controls the instance. That includes your encrypted code, which can be easily rendered readable. I’ve often thought that the value I provide with my code is that I wrote it, I support it, and I ensure you don’t burn way more time doing those things than necessary.

    I think for the most part GitHub isn’t going to change for me. I’ll still post code out there for demos and presentations and even sharing some code with my kid as he learns to program. It will take time for Microsoft to assimilate parts of the company, but overall, I expect that most of the platform will remain the same for a long time, especially if Microsoft can get more enterprise customers to use it for their systems, especially their database code.

    Steve Jones