Login

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

I use a large number of SQL sensors, can I continue using the deprecated SQL sensors somehow?

Votes:

1

I monitor my databases with a lot of SQL sensors. With PRTG version 16.2.23 you announced that you would remove the “original” SQL v1 sensors. Your recommendation is to create new SQL v2 sensors.

Re-creating all SQL sensors would create a significant workload for us, so is there is a workaround for this approach? Do you provide a migration path for the discontinued SQL sensors?

adosql cleanup database-monitoring deprecated mssql mysql oraclesql prtg sensors sql

Created on Apr 14, 2016 9:57:01 AM by David Fabian [Paessler Support] (50) ●3 ●1

Last change on Nov 22, 2016 5:09:44 PM by Martina Wittmann [Paessler Support]

15 Replies

Accepted Answer

Votes:

0

This article applies to PRTG Network Monitor 16.x.25 or later

Migration Path for Deprecated SQL Sensors

With PRTG version 16.2.23 we informed you about The PRTG Sensor Cleanup, meaning that we are deprecating several sensor types. If you extensively monitor SQL databases with many sensors, we understand that you are worried about creating dozens or hundreds of new SQL v2 sensors to keep your detailed SQL monitoring. Therefore we decided not to force you to recreate all your SQL sensors.

We have prepared a migration path that transfers the existing sensors to an internal sensor type called “[…] SQL v2 DEPRECATED” (depending on the type of a specific SQL sensor, for example, “MySQL v2 DEPRECATED”). You will not be able to add any of these deprecated sensor types but you will be able to continue using your original SQL sensors beyond version 16.x.25.

Important note: We strongly recommend that you use the new SQL v2 sensors nevertheless! The migration path we describe in this article is intended to give you more time to replace the discontinued SQL sensors.

We will not provide support for deprecated SQL sensors! If you encounter any issues with these sensors, please first try to create according SQL v2 sensors before you contact us.

Migration Approach

We provide a migration path for the following deprecated sensor types:

ADO SQL
Microsoft SQL
MySQL
Oracle SQL

With the update to PRTG version 16.x.25 these sensor types are replaced by a new (internal) sensor type. They will keep the configuration of the existing but deprecated SQL sensors. You can still define the SQL statements in the web interface and the credentials on the sensor level.

In the background the new SQL sensor engine will be running and the new output will map to the existing sensor channels. New channels of the SQL v2 sensors are left out. Generally the displayed data and sensor functions will be very similar to the SQL v1 sensors, with following exceptions:

The "Execution time” value of the sensor will be higher.
The sensors will be .NET-based and will require additional system resources. You might want to increase the scanning intervals. See also the article Which .NET version does PRTG require?
Some SQL queries may return other values than before or may not work at all, so please check your running instances of deprecated SQL sensors.

Please understand that we cannot provide such migration paths for other deprecated sensor types.

If you need a guidance to set-up the SQL v2 sensors, please refer to:

How to setup the SQL v2 sensors in PRTG? Is there a guide?

Created on Apr 14, 2016 9:57:52 AM by David Fabian [Paessler Support] (50) ●3 ●1

Last change on Mar 10, 2017 11:52:53 AM by Luciano Lingnau [Paessler]

Votes:

0

Hi there With Version 16.2.23.3270 the SQL-Sensors have already been switched to SQL Deprecated. These sensors work as they did before. My question is, will these sensors also be removed after upgrading to version 16.2.25.xxxx or will they stay as they are (only not supported anymore)? This point is not very clear in your answer to the above question.

If they stay as they are we would have enough time to migrate sensor by sensor to the new version SQL v2. If not, we will not install the next updates because we've got hunderds of Oracle SQL Sensors implemented.

Thanks for a short answer.

Created on Jun 2, 2016 7:14:26 AM

Votes:

0

Hi Marcel,

for the foreseeable future, the deprecated SQL sensors will continue to work similarly as before. You merely won't be able to add new SQL v1 sensors. As long as you have .NET 4.0 (or later) installed on your probe system, all should be fine.

You'll have enough of time to gradually replace the deprecated sensors with SQL v2 sensors.

Regards

Created on Jun 2, 2016 9:50:46 AM by David Fabian [Paessler Support] (50) ●3 ●1

Last change on Jun 2, 2016 9:55:37 AM by David Fabian [Paessler Support] (50) ●3 ●1

Votes:

0

Hi there

The question is, will this sensors be there after upgrading to 16.2.25.xxxx or even later?

It's not very clear in your answer if they will stay forever as "deprecated sensors" or if they will be deleted as well in one of the next upcoming releases?

Thanks and regards

Created on Jun 2, 2016 12:08:13 PM

Votes:

0

Marcel, we do not have a fixed date when the old SQL v1 Sensors will definitely be removed. So they will not stay forever, but definitely will still work in version 16.2.25. That definitely is within the range of "foreseeable future".

Created on Jun 2, 2016 1:32:37 PM by Torsten Lindner [Paessler Support]

Votes:

0

Good afternoon. Will deprecated sensors keep the history of the alerts after migration, or is it only configuration that is getting migrated? Thank you!

Created on Jul 18, 2016 8:56:43 PM

Votes:

0

History of alerts will be kept, as long as the purging date for "Log Entries" is set in PRTG's system settings. Regardless if a sensor is deprecated or not.

Created on Jul 19, 2016 8:10:51 AM by Torsten Lindner [Paessler Support]

Votes:

0

Torsten, thank you so much for a quick reply. I have one last question. After I create new sensors for SQL Server, can I tie historical data from the deprecated sensors to the new ones?

Created on Jul 19, 2016 4:32:58 PM

Votes:

0

I'm afraid that is not really possible. We suggest to simply keep the old sensors paused for their historic data.

Created on Jul 20, 2016 7:21:54 AM by Torsten Lindner [Paessler Support]

Votes:

0

I noticed the SQL V2 sensors require a .sql file to be run and can't accept parameters. The V1 sensors allowed us to run a different query for each sensor.

Is there anyway we can have several sensors that all run very similar script with a different variable? or should we be building our own SQL sensor using powershell.

Created on Jul 21, 2016 4:58:28 AM

Votes:

0

You can actually use parameters in the SQL v2 sensors:

Created on Jul 21, 2016 8:35:06 AM by Torsten Lindner [Paessler Support]

Votes:

0

Those two Input Parameter fields are not available in our MySQL v2 sensors.

Does this only apply to Microsoft SQL sensors? We need this in MySQL too.
Does it only apply to a particular PRTG version? (We're running 16.3.24.5303+, and while not the latest anymore, it was released five days after your answer...)

Created on Aug 19, 2016 8:37:35 AM

Votes:

0

The parameters should be available in all SQLv - Sensors. Please do update to version 16.3.25 then.

Created on Aug 19, 2016 10:55:45 AM by Torsten Lindner [Paessler Support]

Votes:

0

Hi there.

Are you aware that with this new sensor types, it is a major regression in administration and usability ?

The need for a file containing the SQL query, which will have to be uploaded to the probes, is really a pain and will require much more work than the previous sensors which were working perfectly well... This is exact opposite to the migration from the old WMI custom (which required a WMI query file) to the so easy to use PerfCounter custom which only requires the counter definition directly in the settings...

This is really a shame... :-(

Created on Oct 14, 2016 2:27:19 PM

Votes:

0

Olivier, we are aware of the plus of work this sensor now needs, and did still chose this, because the security aspect was more important to us.

Created on Oct 14, 2016 2:31:42 PM by Torsten Lindner [Paessler Support]

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.