Reporting inconsistencies in Spectrum Report Manager due to model handle reuse

Products

• Network Observability
• Spectrum

Issue/Introduction

Incorrect device information, duplicated names, or "replaced" models appear in Spectrum Report Manager (SRM) availability or Global Collection reports. This happens when the SpectroSERVER reuses model handles (model_h) after a database restoration, creating collisions with historical data stored in the MySQL reporting database.

• Global Collection reports show incorrect model types (e.g., Gen_IF_Port instead of a Switch).
• Reports contain "pingable" models that were previously deleted but have reappeared.
• MySQL queries on the reporting.model table show a single model_h tied to multiple model_key records with different names.

Environment

• DX NetOps Spectrum
• Spectrum Report Manager (SRM)

Cause

Restoring an older SpectroSERVER database (SSdb) rolls back the internal model handle counter. When Spectrum discovers new devices after the restore, it assigns them handles it believes are free. However, the SRM database still contains recent history for those handles, causing SRM to merge different devices under the same handle.

Resolution

 Initialize the SRM database to clear corrupted history and resync with the SpectroSERVER.

1. Log into the SRM system as the Spectrum installation owner.
2. Stop the Spectrum Tomcat process.
3. Open a bash shell and navigate to $SPECROOT/bin/.
4. Run the initialization script (ensure 1.5x disk space of the largest table is available for optimization): ./RpmgrInitializeLandscape.sh root -initHist 45 -all (Replace 'root' with the MySQL user; provide the password when prompted).
5. Start the Spectrum Tomcat process.

Note: If disk space is insufficient for optimization, truncate the event table in MySQL before running the script.

Additional Information

• To prevent this, always restore SRM, DDMdb and SSdb to the same point in time.