With Foglight for Oracle, invalid objects are monitored and alerted upon for each schema. While it's possible to exclude schema's from monitoring, this can be tedious if you only have a handful of schema's that need to be monitored.

There are 2 ways to build an "include list" filter for the invalid objects alarms. Both involve editing the rule using the Foglight Administration -> Rules dashboard. There are 6 invalid object rules, 1 for each object type.

The quick way is to put a scoping query on the rule definition, to only fire the rule if it matches the specified schemas:

Note that data will still be collected on all schema's, so that they can be reviewed in the Invalid Objects dashboard. But only alarms will fire on the objects that are within the scope of the rule. The downside here is if you get a new schema that you need to alert upon, you will have to remember to edit all 6 of the rules.

The more elegant way to address this is via UI Queries and Service Builder. If you've forgotten about my love of those, this post is a good reference

Start by building a UI query that returns a list of Oracle Invalid Objects.

Next, use Service Builder to create a service (ie. container) to hold the schema's that you only want included in alerting for invalid objects.

Use the UI query you built for invalid objects to create a dynamically managed service component. In this case, any schema with invalid objects which contains 'QUEST' will be part of the service. If a schema gets added or removed, it will be reflected in the service definition. Create additional dynamic components as necessary to contain the required schema's.

To validate, we can see "invalid view" alarms for 2 QUEST schema's, and 1 for a SQLEXP schema.

Next, the 6 rules will need to be modified once with a scoping query referencing the service name created above. Any future changes to the schema will be done via the service builder, and not require editing the rules.

Once the rules are saved, we can clear the existing alarms and wait for them to fire again. From the Invalid Objects dashboard, we can still see that "SQLEXP" has 5 invalid views.

Yet when we look at the 3 alarms on the SQLEXP schema, the "invalid view" is absent, as expected.

Checking the QUEST_PROD schema, we can also validate that an invalid view alarm fired, as that schema is contained in the service definition.

If you found this helpful, please like the post!

Related Content