I'm getting an error message when the Database Maintenance runs:
[4] ERROR SolarWinds.Data.DatabaseMaintenance.TimeSeriesTableHandler - Retention interval settings not specified
Does anyone know what this means?
See it also at one customer. Have you also just upgraded to 2022.3?
Also seeing the same problems in Deployment Health after a support call last week that upgraded to 2022.3 to try and resolve all the other issues we are having.
Took almost 2 weeks, but finally got support to acknowledge the bug. Open a support case so it gets another customer report.
"Thank you for the response. Our development team has investigated your issue with the white noise errors and has identified a bug in our product. As per the development team, the maintenance stored procedure uses its own settings and is properly started. Fixing this bug is about removing unnecessary settings. However, there isn't a functional impact - data are collapsed properly. We have added this bug to our list of known defects and will prioritize it for future releases according to its severity and impact on our customer base. We value your opinion as a customer and without you, we wouldn't have such strong features in our products. Please be sure to keep an eye on our future published release notes, where a list of our bug fixes is documented."
Also recently upgraded to 2022.3 and see similar error in maintenance health. Opening a support case as well.
Same error I've been experiencing; thanks for posting this.
please follow the below steps.
Please back up the Orion DB before running the SQL Query.
insert into Setting (Name, Value) Values ('Feature.Client.DefaultCacheExpiration', '01:00:00')
Issue has been seen on 2 different sites. Both are running 2022.4
Tried this, but the error remains.
we get this eror 4 times in the swdebugMaintenance.log:
2022-12-07 08:55:24,254 [4] ERROR SolarWinds.Data.DatabaseMaintenance.TimeSeriesTableHandler - Retention interval settings not specified
same here on 4 different installations. 2022.3 and 2022.4
We are also seeing the exact same error, four times in the log.
Same here and i've just upgraded to 2022.4.1
Same error here and now on 2022.4.1
Same here on 2022.4.
Also seeing the same problem for a customer on 2022.4.1
SW case 01244094 - have been advised it was first identifed in 2022.3 and will be fixed in a future release. It is not causing any particular problem and maintenance is completing in our case.
RC 2023.1.0 - Still an issue on this version as well.
Thanks for the feedback. Hoping SW will fix it soon.
That's a bummer because support wants to close our support case saying it's been fixed in 2023.1
Which is ridiculous because that is a release candidate not a general release. It's their version of a beta. Why would anyone install a beta version of monitoring software?
Could it be that it'll be fixed in the GA release and not the RC...
I had a different issue and was told the same thing, that upgrading to the latest version would fix it. I think they just say that with no facts to back it up. Solarwinds support is the worst I've ever come across in my 25 years in IT.
Still seeing this error in 2023.1 GA.
I am seeing it as well
THank you for bringing this up. I am experiencing the same issue.I'm at 2022.4 at this time.
was told it's not scheduled to be fixed until Q3 2023.3 or later.
A few weeks ago I received an alert that a drive on our Orion database server was growing. After further investigation it looks like the SolarWindsOrionLog seemed to be growing about a gig a day. After looking at the tables I noticed data that was well over the normal 7 day retention we have for those types of events. Reached out to support and they said there was a known issue (hidden from the release notes) where customers can have real data loss by the database maintenance not properly finishing. We have submitted many diagnostics for the open case prior, but no one noticed I guess. This was their reply and a temporary fix they provided to us since we are not able to take the 2023.1 update due to the Information Service crashing when a user uses PerfStak so we are still on 2022.4.1.
Highly suggest people take a look and review with support. Pretty shocked that a data loss type bug that was known isn't in the release notes.
There were issues with deadlocks in 2022.3 and 2022.4 which caused old data not being removed and future partitions not created.
Data are organized into partitions in the database, one partition per day and data source. Database maintenance creates partitions for the future 30 days. If there is no prepared partition for the current day, issues arise. In 2022.3 there was a data loss, in 2022.4 a special dump table is used for such data so they are not lost, but getting data back where they should be (after fixing the missing partitions) is quite complicated and sometimes time-consuming.We implemented a fix in 2023.1 which explicitly prioritizes database maintenance over incoming data, but it needs a support from SQL server. This support was added in SQL 2016 SP1 CU3, however, it is turned off by default. That's why trace flag 1237 has to be turned on manually. SQL versions 2017 and newer have this feature turned on by default. More details in https://support.microsoft.com/kb/4025261
Database maintenance has been constantly failing for some time and the last created partitions are for 31st March so there is actually more than 2 weeks left. There is actually a fallback - Business Layer performs partition management (only this part, not the whole database maintenance) and it seems that it helped, but it is rather an exception than a rule, because usually things which block database maintenance block the BL task as well. I definitely wouldn't rely on BL only.
If the customer is asking for a workaround, then there is one, but it is not very nice:1. Stop all Log Management services on the main poller and on all additionals as well (this is mandatory!). Note: It is possible to stop and start services on main and additionals from the web console (All Settings > Service Manager).2. Run database maintenance and let it finish.3. Start all Log Management services on the main poller and on all additionals.This workaround should be applied once a week to be sure that nothing is missing.
Has anyone tested the code upgrade paired with enabling trace flag 1237? I did on our lab SW instance, but I think the DB maintenance error is still occurring.
Defect still exists on 2023.2. Support said it will be resolved on 2023.3.
Same for my installation, the defect still exists.
Hi Dear,
I have the same error in my Orion in the 2023.2 with the database maintenance and I have issue with the current connections in my additional Web, this issue is unknown by Solarwinds with the answer of the case.
https://thwack.solarwinds.com/product-forums/network-performance-monitor-npm/f/forum/98186/website-errors-after-upgrading-to-version-2023-1/309254#309254
I am using version 2023.2.1 and am experiencing
ERROR SolarWinds.Data.DatabaseMaintenance.TimeSeriesTableHandler - Error getting retention intervals: 0, 0, 0
is this same ????
Have an active notification that SAM maintenance is due.
Not sure it's the same issue, but we have seen the SAM Maintenance message since updating to 2023.2 and have confirmed with support that it is a known issue.
Case # - 01352559 SAM maintenance is overdue warning
I understand that you are getting a SAM maintenance overdue warning on your Orion platform. This issue is a known message in this product version. It will be fixed in the release 2023.3 The issue seen does not have any performance hit on the working of the Orion platform.
have you check swdebugMaintenance.log .
i found bellow line , can you check and confirm please.
ERROR SolarWinds.Data.DatabaseMaintenance.TimeSeriesTableHandler - Error getting retention intervals: 0, 0, 0.
earlier or in this tread people discussing below error.
ERROR SolarWinds.Data.DatabaseMaintenance.TimeSeriesTableHandler - Retention interval settings not specified
I am not seeing that specific error, but we are regularly seeing the error mentioned previously in this thread:
Those errors have being going on for a while (since upgrading to v2022.4). The SAM Maintenance message only started showing up after upgrading to v2023.2. I was just pointing out that the SAM Maintenance message seems to be unrelated, but is a known issue.
Yep they said the same for one of our customers. Resolved in the Q3 release. Hopefully July/August.
Just installed 2023.3. Ran a DB maintenance. And it looks like the error no longer excists.Does anyone else tested 2023.3 for this issue?
Yes, and so far, it appears the issue is finally resolved.
This is great to hear! We will make sure to have this issue added to the Fixed Issues list for 2023.3 release notes.
That's very concerning that such a major issue was "left out" from the release notes. What other items were left out and what other Known Issues were not put on the release notes that we should be aware of prior to the upgrade?
Just did an upgrade to 2023.3 - can confirm, you need to run DB Maintenance following the upgrade for the problem to clear.
I did the same and the DB maintenance is now running fine on 2023.3
I recently upgraded to 2023.4.2 & get this error, support have provided this as a fix. About to attempt to see if it works.
Note: - Makes sure that you have DB backup and VM snapshots prior to the performing the steps. - Disable HA globally if you have HA - PFA for the mentioned sql scripts It requires access to Orion Log database with privilege to run SQL scripts changing a database schema as well as data and SQL Server Management Studio to run those script from. The troubleshooting has two possible scenarios. The both have a common part represented with nine steps followed by a scenario specific steps represented by two steps for scenario One or four steps of scenario Two.Scenario One is faster (takes minutes) and results in loosing all misplaced log entry data. Scenario Two takes much longer (hours at least - depends on conditions) and preserves all misplaced data. The choice of a scenario depends on you, whether you accept to lose aside stored data (quick solution) or you will be able take time consuming and more difficult steps to move data back into partitions. Preserving data (scenario Two) can take from hours to days and is not recommended if you have retention periods set to days, week or maybe a few weeks. It also requires more investigation of the amount of data to be preserved, about usual workload the target system is going to have in time of data processing and about the state of SQL Server and disk space it can use for the database.
At this state, system should run again, collect and store new incoming messages in the appropriate way, but trouble-causing data is not visible in Log Viewer module. As described above, the troubleshooting continues either with Scenario One or Scenario Two specific end steps.
Notes: Microsoft SQL Server Management Studio sometimes crashes when executing Move_data_back_to_partitions.sql and there are not enough resources and there is high incoming traffic. In such case it is safe to run the script again - the script starts processing data where it crashed, because it saves its progress to the database and it knows where to continue from.
I'm on 2023.4.3 and I'm having this issue as well. Crazy how it's been an on going issue for over a year
I gave up & shortcut the issue. It only appeared after the last upgrade & was possibly linked to a coincidental shortage of drive space in our LogDB server. The LogDB showed Pending recovery state in SQL manager. I tried a few standard SQL fixes, none worked. I was unable to locate the script files referenced in the support fix above. My SW has fallen over the last few days with the log fault.
So I bit the bullet. Stopped SW, Paused & detached the DB file in SQL, it would not reattach SQL reporting the file as corrupt. So I removed the file, which also freed up 2TB of space & created a new LogDB, same name, added the rights for SW account to access it & ran the SW Setup Wizard, select repair DB connections only & when finished restarted SW, all came up & no more critical errors.
I am also getting a similar error/warning following an upgrade from 2020.2.6 to 2023.4.2.
2024-01-31 08:30:35,810 [13] WARN SolarWinds.Data.DatabaseMaintenance.TimeSeriesTableHandler - Daily retention (30) is less than Hourly. Adjusting.2024-01-31 08:30:35,810 [13] INFO SolarWinds.Data.DatabaseMaintenance.TimeSeriesTableHandler - Retention intervals: 7, 30, 31
Was this also one of the warnings you were getting @ida71
Hi Dears,
We have several clients under management including three very important for the country. We have noticed that in Orion Core versions 2023 or higher, the "InterfaceTraffic_CS_cur" table is not sending the data it receives to the other tables: InterfaceTraffic_CS_Daily, InterfaceTraffic_CS_Daily_hist, InterfaceTraffic_CS_Detail, InterfaceTraffic_CS_Detail_hist, InterfaceTraffic_CS_Hourly. This is causing the "InterfaceTraffic_CS_cur" table to fill up with many records (One million TB) and "Database Maintenance" is unable to purge them. This issue is critical for these clients as it causes slowness, database filling, or problems when querying graphs in the web console. In summary, "InterfaceTraffic_CS_cur" is not performing the necessary conversion.
The point is that maintenance in these versions, and now with this new feature, is causing the 'Database Maintenance' not to finish because the tables are very large. I'm not sure if anyone has already validated those tables like Interface traffic, Response time, since, as we discussed, there are three Orions that already have the same issue, and Solarwinds may not have seen that flaw in its architecture.
Someone else has the same issue to validate alternatives that we are already discussing with our DBAs.
Same issue on 2023.4.2 like others mentioned. Upgraded from 2023.3.1 to 2023.4.2.
MAINTENANCE:Recent DB-Maintenance job : Failed to execute 2 procedure(s) (dbm_InterfaceAvailability_DetailToHourly dbm_InterfaceAvailability_HourlyToDaily)
Hi, this I think is exactly what Im looking for. My OrionLog database is massive compared to what it was 4mnths ago. We've set the log to 2 days, but our OrionLog_LogEntryMessage_dump table has 124600000+ rows.
Where do I find the above SQL scrips referenced.Check_for_data_to_move.sql, Move_data_to_Tmp_tables.sql, Recreate_missing_partitions.sql ect
thanks in advance
