Rule fires only when a scoped object changed the second time. This happens only if the rule scope has an additional where clause to limit the amount of alarms. With a simple rule scope the fires even if the object changed first time.
To understand why this happens, you need to understand the time line of object creation and the related rulette creation.
When an agent collects data, new data objects will be created. The object definition can be found in the CDT file. The data object contains properties and observations. As a next step the needed rulettes will be created for the related rules. A rulette can be considered as an instance of a rule and each rulette is assigned to a specific object.
When looking at the time line, first the object is created and then the rulette is created. The time difference between object creation and rulette creation can be 30 seconds up to 1 minute. So for the first data collection the rulette cannot be triggered, because it does not exist when the data is coming in.
Only if there is a simple rule scope the rulette can be created nearly the same time, the object will be created and so it can be triggered directly within the first collection. A simple rule scope is a scope which does not contain any additional clause. If the scope contains an additional clause - for example: where name != ‘abc’ – the rulette can not be created the same time the object is created and so it cannot be triggered within the first collection.
If there are ongoing collections for an object, for example for CPU utilization, the short delay is not critical, because with every collection new data is coming in and the object will be changed, so the roulette will be triggered.
But for specific rules it can be problematic, for example the rule DBO_Initialization_Parameter_Modified. If an init parameter changed you need an alarm directly, but if the scope of the rule contains a where clause, the rulette will not be created the same time the object is being created. So the first change is missed but the second change will be picked up and trigger the rulette. In this example the second change can happen days or weeks after the first change as init parameter of the database are not being changed very often.
To avoid missed alarms and unwanted delays, you should not change the rule scope of this rule. But what can be done if the rule scope should be limited because not for every init parameter change an alarm is needed?
The workaround is:
Instead of changing the rule scope you need to change the rule condition. When changing the condition, the rulette will be created directly when the object is created and can be triggered. Following the example of rule DBO_Initialization_Parameter_Modified:
Original rule condition:
#parameter_changes#
return Dbwc_Common_Oracle_AlarmEnablingCheck("DBO - Initialization Parameter Modified",scope);
Modified rule condition:
#parameter_changes#
return scope.name != "<unwanted parameter name>" && Dbwc_Common_Oracle_AlarmEnablingCheck("DBO - Initialization Parameter Modified",scope);
