Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Database Maintenance not removing orphaned data from ResponseTime (View) table

I know a "View" in SQL isn't a real table, but this is where I found the data.

The reason I found this issue is because this View is since recently being used to query the average uptime of our environment over the last month and I was asked to verify if the data returned by the query made sense. I noticed that the query returned data for a bunch of nodes that no longer exist.

When looking at the log for the database maintenance, it all seems to have gone smoothly as late as tonight. If I understand correctly, the below two line should've meant that the node with NodeID 6052 should've been removed from the ResponseTime records.

2019-08-01 02:20:21,883 [1] INFO SolarWinds.Data.DatabaseMaintenance.MaintenanceEngine - Action 'Remove orphaned data from ResponseTime' started
2019-08-01 02:20:22,226 [1] INFO SolarWinds.Data.DatabaseMaintenance.MaintenanceEngine - Action 'Remove orphaned data from ResponseTime' finished, time elapsed: 0.350 sec.

Is this a bug? It seems odd to me. This is on NPM 12.5, btw.

EDIT 0.5:

With a query found somewhere else I've discovered here are currently 1146 orphans in our ResponseTime view.

EDIT:

It turn out database maintenance hasn't actually competed entirely. I did the thing with moving the logs and rerunning and at the of the new logs it shows this error:

2019-08-01 10:43:47,321 [4] INFO SolarWinds.Data.DatabaseMaintenance.MaintenanceEngine - Action 'Rotate RabbitMQ log files' started
*** Assembly SolarWinds.Common, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null, .NET version v4.0.30319 ***
2019-08-01 10:43:48,165 [4] INFO SolarWinds.Common.Utility.ProcessRunner - stdout:
2019-08-01 10:43:48,165 [4] INFO SolarWinds.Common.Utility.ProcessRunner - stderr: Error (argument validation): too many arguments.
Arguments given:
rotate_logs .0
Usage:
rabbitmqctl [-n <node>] [-l] [-q] rotate_logs
2019-08-01 10:43:48,165 [4] INFO SolarWinds.Common.Utility.ProcessRunner - exit: 1
2019-08-01 10:43:48,180 [4] ERROR DatabaseMaintenanceGui.MainForm - Database Maintenance Error.
System.Exception: An error occurred in 'rabbitmqctl.bat'. Error (argument validation): too many arguments.
Arguments given:
rotate_logs .0
Usage:
rabbitmqctl [-n <node>] [-l] [-q] rotate_logs
   at SolarWinds.MessageBus.RabbitMQ.RabbitManager.RunRabbitBat(String batFileName, Func`2 outputLogFilter, String[] args)
   at SolarWinds.MessageBus.RabbitMQ.RabbitManager.RotateLogs(UInt32 maxFileSize, UInt32 keepFiles)
   at SolarWinds.Data.DatabaseMaintenance.MaintenanceEngine.RotateRabbitMQLogs()
   at SolarWinds.Data.DatabaseMaintenance.MaintenanceEngine.<>c__DisplayClass17_0.<StartMaintenance>b__7()
   at SolarWinds.Data.DatabaseMaintenance.MaintenanceEngine.ExecuteMaintenanceAction(Action maintenanceAction, String actionDescription)
   at SolarWinds.Data.DatabaseMaintenance.MaintenanceEngine.StartMaintenance(DateTime basisDate)
   at DatabaseMaintenanceGui.MainForm._backgroundWorker_DoWork(Object sender, DoWorkEventArgs e)

I'm not sure if this would affect the previous issue as it did show the Action as completed.

Also, this seems like a rather silly error. Why are there being passed too many arguments to that function? I'm pretty sure no one on our side changed that .bat file.

Find more posts tagged with

Accepted answers

All comments

sander_franken

UPDATE:

I have installed the latest hotfix. This fixed the issue with rotating the RabbitMQ logs that caused the DBMaintenance to fail before.

The issue with orphaned entries still persists, though.

sander_franken

Update:

I contacted Technical Support about this. They weren't able to pinpoint the cause of this problem, but did tell me this should not be an issue for me anymore. The orphaned entries are all in tables that were used in previous versions of Orion, but no longer in 2019.2. All Database Maintenance errors were alleviated by upgrading to the latest hotfix version and truncating the first partition of LoadAverage_CS_Detail_hist table that was throwing an error as well. This means that Database maintenance is now slowly phasing out those orphaned entries as their retention date passes. Because of the new structure of the database in 2019.2, this problem shouldn't reoccur.

To keep the unwanted data out of the monthly Uptime Report, I'm just going to delete those orphaned entries myself.

Fun fact: cleaning those orphaned entries cleared a little under 5 million rows from our database.

simkimdm

Hi,

we have the same issue.
Can i get your SQL Query to delete the orphans data? I struggle with the UNION Parameter..

Do run this every day or is the database Maintanence doing the job right now?

Simon

mesverrum

You shouldn't be unioning anything if you are just trying to remove orphan entries.

Should have better luck with something like

*untested psuedocode ahead*

delete from responsetime

left join nodes on nodes.nodeid = responstime.nodeid

where nodes.nodeid is null