Known issue where during full synchronization of the Spectrum Data Source (DS) in Performance Management (PM) times out, or throws an exception, causing Global Collections (GC) to be removed from Performance Management. When the DS next completes a sync cycle without interruption, the Global Collections are synced again.
The issue may occur without being noticed, and the Global Collection Inventory will look normal. Behind the scenes, in the database, those GCs now have a new ID.
The impact is often seen in Group Rules and Views where the GC is the fixed Context of the View. Those configurations use the ID of the GC in the DB. When it needs to show the name of the GC it references a different table to provide the name. In that table, due to this issue, that ID is no longer present. The GC is in the table but with a new ID due to this known issue.
At this point the Group Rule and Views affected are referencing a GC ID that is no longer present.
The cause of this issue is a full sync from PM to Spectrum data source interrupted by an error during the pull of groups from Spectrum.
Any error on either the PM or Spectrum OC side can trigger the problem.
Full synchronizations are only launched upon user request via the UI, or data source restarts, being an OC tomcat restart in this case.
The timing of what happened here was OC restarted which triggered the full sync from PM. Then some error interrupted the full sync in that critical groups pull phase.
All supported Performance Management releases
Unfortunately there is no way to determine, after the issue is observed, what the name of the GC was to reset it without a MySql netqosportal DB backup from before the problem start.
If a database backup is available, it can be loaded into a support lab to provide a list of GC names and IDs to use in resolving this.
First determine the Data Source ID for the Spectrum Data Source.