Custom Indexes on Db.Timeseries tables breaks Database Maintenance in the SolarWinds Platform

When you create a custom index in the timeseries tables hosted in the SolarWinds Platform database, it results in errors in some timeseries tables like APM_PortEvidence_*, APM_ComponentStatus_*, Interface_*, etc., which host historical tables.

The Custom Indexes can impact the views and functions reading from them, instead of getting “current” values from related entity tables. 

During the database maintenance, it will fail as in this example below showing "There is no identical index in source table":

===
ERROR SolarWinds.Data.DatabaseMaintenance.Reporter - [Failure] 91.47s Finalize Maintenance - InterfaceErrors
Message:
--------------------------------------------
dbm_ExecuteMaintenance: dbm_Move2Partitioned: ALTER TABLE SWITCH statement failed. 
There is no identical index in source table 'SolarWindsOrion.dbo.InterfaceErrors_CS_stg' for 
the index 'IX_InterfaceErrors_CS_Detail_hist_InterfaceID' in target table 'SolarWindsOrion.dbo.InterfaceErrors_CS_Detail_hist' . 
ALTER TABLE InterfaceErrors_CS_stg


ERROR SolarWinds.Data.DatabaseMaintenance.Reporter - [Failure] 1.19s Finalize Maintenance - LoadAverage
Message:
--------------------------------------------
dbm_ExecuteMaintenance: dbm_AggregateData_part: dbm_AggregateTimeSerie_part: XACT_STATE=-1ALTER TABLE SWITCH statement failed. 
There is no identical index in source table 'SolarWindsOrion.dbo.LoadAverage_CS_Hourly_stg' for the index 'IX_LoadAverage_CS_Hourly_hist_NodeID' 
in target table 'SolarWindsOrion.dbo.LoadAverage_CS_Hourly_hist' ., ALTER TABLE LoadAverage_CS_Hourly_stg
									SWITCH
									TO LoadAverage_CS_Hourly_hist PARTITION 25
WITH (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 1 MINUTES, ABORT_AFTER_WAIT = BLOCKERS))
Warning: Null value is eliminated by an aggregate or other SET operation.

Custom indexes are not supported in SWOSH until 2025.2 (including). This bug is now fixed in the 2025.2 release.

To resolve this issue, please upgrade to SolarWinds Platform 2025.2 and above. 

If you are unable to upgrade at this time, the workaround is:

Option 1:

You need to get the list of all indexes from a clean installation of a given product version, then get the exact list from the customer and compare it based on the index name, table name and type or other properties.

Or

Another option is checking the error message, which tells you what index is breaking the processing. Most of the time, it would be a custom index.

Once the custom index is identified, it should be removed. After that, the database maintenance will run without errors.

Option 2

Run the 3 stored procedures to fix the custom indexes for versions before Oxygen (2025.2).