Precedence 20 events flood OneClick every time the secondary SpectroSserver is restarted
Article ID: 254767
Updated On:
Products
Issue/Introduction
More than 50,000 events are generated from the secondary SpectroServer during every online backup. 50 K is the max number that can be displayed so in reality we do not know how many are displayed.
Why do those events show up in OneClick?
Environment
Release : 21.2.8 and 22.2.5
Cloud environment.
Cause
The secondary role determination was taking an extended time which caused the precedence 20 events. So far has only been seen by one customer and only happens in cloud environment which is comprised of 2 landscapes. All others are working as normal. In the cloud environment landscapes the secondary startup events are not being deleted. This is normally controlled by the following SS flag which defaults to true but was not being read in this environment at startup.
delete_secondary_startup_events=TRUE
Resolution
Add the following to the .vnmrc.
is_secondary=TRUE
secondary_polling=FALSE
delete_secondary_startup_events=TRUE
The patch Spectrum_21.02.08.D149 was created for this issue:
REQUIREMENTS
SPECTRUM 21.02.00 and 21.02.08 are the prerequisites for installation of this patch.
This patch needs to be installed on SpectroSERVER.
OVERVIEW
This is a Debug patch for the following issue:
33206436- offshot from DE545794 - Precedence 20 event flood every time the secondary SS is restarted
(DE554392, 33206436)
BILL OF MATERIALS
ReleaseNote.D149.txt
runme (Linux)
uninstall_D149.pl (Linux)
libsskrnl.so.1 (Linux)
After upgrade the customer should keep the same .vnmrc settings as above.
Note: the same fix has been ported to Spectrum release 22.2.5 with patch Spectrum_22.02.05.D168:
REQUIREMENTS
SPECTRUM 22.02.00 and 22.02.05 are the prerequisites for installation of this patch.
This patch needs to be installed on SpectroSERVER.
OVERVIEW
This is a Debug patch for the following issue:
DE560820 Details:
33382374 SAP - Porting of patch 21.02.08.D149 to 22.2.5 for Precedence 20 Event Flood
(DE560820, 33382374)
BILL OF MATERIALS
ReleaseNote.D168.txt
runme (Linux)
uninstall_D168.pl (Linux)
libsskrnl.so.1 (Linux)
runme.exe (Windows)
uninstall_D168.exe (Windows)
libsskrnl.dll (Windows)
Additional Information
It is expected to see some precedence 20 events at every OLB. Putting the "is_secondary=true" entry in the .vnmrc of the secondary should reduce these sufficiently.
The logging of the device events during an online backup was disabled in 10.2, so that they will not show in the Event history on the primary SpectroSERVER after the online backup has completed. There is an exception to this and is FAD as described below but that is not the case here in this issue as we are seeing other precedence 20 events.
During an OLB, the primary SpectroSERVER copies the SSdb file to the Secondary SpectroSERVER and then the secondary loads the file and comes back to a "running" state.
Later, the secondary SpectroSERVER generates the events( Eg: "The VNM has been started") and those will be synced with Primary Archive Manager and marks them as event precedence 20.
OneClick displays events in the yellow color if the events are found with precedence as 20 which means those events generated by secondary SS.
So, the yellow events do not mean that the Secondary Archive Manager took over during the OLB but are specific to the OLB process.
e.g. "Contact Lost to Secondary SpectroSERVER" which means secondary SpectroSERVER went down and started loading the SSdB file of primary SS.
Primary SpectroSERVER found that secondary SpectroSERVER came up and running and starts clearing original event(i.e Contact Lost to Secondary SpectroSERVER).
You will see this event creation time as "Clear On" time for secondary SpectroSERVER lost event.
i.e. Secondary SpectroSERVER established the connection with primary SpectroSERVER and same event is raised. You will see that event as yellow color with precedence 20.
But we see should not see a large amount of events with precedence 20 around each OLB.
to debug we used the following .vnmrc settings.
debug_precedence_change=TRUE
ftasv_debug=TRUE
mdlact_debug=TRUE
ctrace=TRUE
RTM_debug_logs=TRUE
Feedback
