Growing Artificial Intelligence

This editorial was originally published on Jul 4, 2016. With Steve on holiday, this is an interesting look back almost a decade into the past at AI technology.

There’s a fascinating piece over at O’Reilly that looks at what we might consider Artificial Intelligence (AI) to be. The discussion looks at Deep Blue, Watson, and AlphaGo, all of which have defeated humans in game competitions where we might expect some intelligence is needed. We could argue that, but certainly, these computing machines have done more to display knowledge than the best humans at certain endeavors.

What is interesting is that each of these machines, while very competent in its area, is specialized. AlphaGo can’t play chess, nor can DeepBlue play Go. Each has been tuned to a specialized area, and also trained to excel in that area. This isn’t fundamentally different than humans that train and specialize themselves, though certainly we find humans have more capabilities in a general sense (for now) than machines.

As we look to grow intelligence, however, there is one thing that’s commonly needed in both artificial or machine intelligence and human intelligence: data. Whether a human is training themselves to solve a particular problem, compete in a game, or even excel in a sport, they need lots of data. We gather this with our senses as well as by examining what others have one, contemplating actions, trying out different actions, ideas, or concepts, and then adjusting to improve.

This is what researchers are also trying to do with gaming machines, with self-driving cars, and even with bots. That last item is interesting to me, as I haven’t paid much attention to bots. A long conversation with another SQL professional got me interested in, and intrigued by, the idea of software robots that might handle various complex tasks better than the FAQ method that so many applications and websites use. I wasn’t sure these would be useful, but I have found the Slackbot to be more helpful than the help or searches for some tasks.

There’s work to be done, and I know the Slackbot (and other machine intelligence software) needs to be trained better. This requires data. Lots of data, and possibly lots of hand holding from a human. For many areas, such as relatively low-level customer support or problem solving, I wonder if a bot could be trained to work better than the simple decision tree algorithms like those found in the Windows Troubleshooter.

There are various ways we might grow this software to help us, and make no mistake, we will need to grow it. Plenty of businesses are becoming excited about machine learning, the R language or Python, software bots, and more. In all the cases of implementing these systems, the one demand that will impact many of us is the need for lots of data. Data that’s organized, that is relevant, that we can use to separate out successes from failures, and evaluate our particular problem better. We will need to group data into knowledge and then feed it into software.

I think this is a bit different than how most of us have used data over the years. We’ve often collected, manipulated, aggregated, summarized, and spit data back out to (ultimately) some human that can make a decision. Most of us haven’t worked with sending data to a machine intelligence and somehow then helping it to understand how to respond on make a decision.

My suspicion is there will be lots of work for us in the next decade in helping machines to use data and understand it, maybe even to use them to help us gather, organize, clean, and manipulate data better ourselves. It’s an exciting time to be a data professional, and I’m sure some of you will work on a few very exciting projects in the future.

Steve Jones

Posted in Editorial | Tagged | 1 Comment

Monday Monitor Tips: Native Replication Monitoring

Redgate Monitor has been able to monitor replication for a long term, but it required some work from customers. Now we’ve added native monitoring.

This is part of a series of posts on Redgate Monitor. Click to see the other posts.

New Native Monitoring

The monitoring capabilities in Redgate Monitor were originally fairly limited to a few counters from PerfMon. A few people had written custom metrics on sqlmonitormetrics.com that clients could use, but we’ve had customers asking for more native integrations.

We’ve done it. With version 14.2, we have added an estate view of your replication environment. In the Estate menu, there is a new entry for Replication Monitoring.

2025-11_line0125

If I click this, I get a list of the jobs running replication across various servers. You can see this below, with each instance and the job denoted by a REPL- at the start. These are the defaults that Microsoft sets up and should be left alone.

You can see below that the agent server name is listed, and I can click it to get to that server overview in Redgate Monitor. I also have the category and job name to the side. Beyond that we have the last completed run if it’s successful. If it’s running, the Job Ended is blank. To the right we have the publisher, subscriber, and distributor names.

2025-12_0164

I can resort the columns, such as below when I am looking by category.

2025-12_0165

I can also sort by publisher:

2025-12_0166

Or subscriber (or any other column).

2025-12_0167

Clicking the column a second time reverses the sort order.

Alerting

There are two new replication specific alerts available for the job failures and maintenance job failures. These work the same as any other alert in Redgate Monitor and can be configured for specific servers, groups, levels, etc., with notifications going out to all the notification targets.

Here are the alerts in the alert configuration.

2025-12_0168

These jobs run across the various replication categories: distribution, merge, snapshot, log reader, and queue reader.

If I look at the details, I can see the job failure works across multiple categories and is set to a high level alert. I can adjust this as I can with any other Redgate Monitor alerts, and exclude jobs if I wish with a regular expression.

2025-12_0169

The replication capabilities are documented here: https://documentation.red-gate.com/monitor14/sql-server-replication-314869637.html

Summary

Replication isn’t something most people use, but for those that do implement it, monitoring is critical. Redgate Monitor has added some native capabilities to let you get a glimpse of your entire replication estate at once and get notified if there are issues.

Replication can be amazing, but I find it brittle. When it works, it’s amazing, but when it breaks, it’s broken. Getting a jump on issues is important for many organizations and Redgate Monitor can help you do that.

Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

Posted in Blog | Tagged , , | 1 Comment

Refactoring SQL Code

One of the things I see software developers often talking about is how they refactor code. As they touch a class, method, etc., they may take the time to refactor the code to make it cleaner, perform better, or just add some documentation. It seems that a regular part of a software developer’s job is refactoring code in the codebase.

That is unless they see a “don’t touch this, no idea how it works” comment. There are plenty of those, and often everyone leaves that code alone.

I was thinking about this when I saw this article on strategies to refactor sql code. The article seems written more for PostgreSQL, but there are items that relate to T-SQL as well. The main thrust of the article is about trying to rewrite code to DRY (don’t repeat yourself). The more changes you can make to shrink code, either to make it easier to read or avoid repeating those copy/paste items, the better off your team will be. It’s easy to think those copies aren’t a big deal, but it’s easy to update code in one place because that solves the problem you were given, and forget to fix all the copies.

I don’t know that anyone should implement all the techniques listed, but they are things to think about. Using CTEs, Views, APPLY, the WINDOW clause, and more can help improve the health of your codebase and make it easier for all the members of your team to understand how the system works.

I wonder how many of you have a refactor mentality when you touch code, or do you tend to leave things alone and add new queries/objects/etc. to your database. I wonder if the fear of breaking something that might be used by other code is on your mind. Or maybe you suffer from “not invented here” (NIH) and just add your own code.

If you refactor code, then what things do you look to change or improve? Any tips/tricks/guidelines you’d share with others? If you don’t refactor code, why not?

I think testing is a big part of refactoring. If you have tests, then you can be less worried about your changes breaking something. There is a great video on practical refactoring. It’s from the software engineering view, and it’s long, but it’s worth a watch if you have a few moments.

I wish more people tested their SQL code and refactored poorly written (or poorly performing) code on a regular basis.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | 1 Comment

Advice I Like: Art

Superheroes and saints never make art. Only imperfect beings can make art because art begins in what is broken – from Excellent Advice for Living

Interesting advice for living here. What is art? For many of us this is a painting, a piece of music, a theatrical performance, maybe a garden. In those cases, often inspiration comes from something broken. A broken heart, a tragedy, maybe something else.

Even in software, where I work, we might seek to create something amazing, an artistic piece of code, because we’ve seen other things that were broken and caused problems.

However.

What about love songs, the inspiration of which might be something great. I looked for some, but in most of the lyrics, there seems to be something broken. I Will Always Love You is popular, but seems to be a relationship that isn’t amazing.  Something, one of my favorites has the idea that the the author doesn’t know. There’s some lack of confidence.

Maybe the best one I found is Just the Way You Are (Billy Joel, not Bruno Mars). Here the author doesn’t care about any sort of imperfections of problems, and doesn’t seem to imply there are. He just says I accept you for what you are. That isn’t broken.

In most other songs, the singer, or the object of their affection is broken in some way, so maybe there’s more to this advice than I thought at first.

I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

Posted in Blog | Tagged , | 2 Comments