Can DPA have multiple monitoring profiles for the same database technology platform ?

Hi guruN  

You can accomplish the above by using two features in DPA (Alert Rules and Custom Properties):

1. Creating Custom Properties (e.g., RelatedApplication) and assign values for the custom property to your DB instances (e.g., set DB 1, 2, 5 RelatedApplication custom property value to "ecommerceApp" and for DBs 3 and 4 set the value to "HRApplications"
2. Create an alert rule for each RelatedApplication custom property value or use standard Database Properties (e.g., Database Type)
3. Create an alert and instead of manually assigning instances, select one of the alert rules (e.g. for HRApplications" RelatedApplication custom property) which will automatically assign all of the DB instances whose "RelatedApplication" custom property value is "HRApplications"
4. Configure the specifics of the alert details
5. Now all DB instances currently matching that rule (i.e., the set auto adjusts as DBs are registered, removed, or whose custom property value is updated) will automatically be assigned to any alert template using that automatic rule assignment.

For more details you can reference the DPA Administrator guide and look for alert rules and custom property sections

Thank you - appreciate the detailed response. I also found that alert groups seem to also offer a similar functionality. Is one preferred over the other, as a recommendation from Solarwinds ?

Alert Groups are setup so that you can assign a subset of alert definitions to a specific set of DB instances. You cannot take advantage of rules to automate inclusion/exclusion either of the list of selected alerts or the list of DB instances to assign the alerts.  All alert and instances in the alert group must be maintained manually. Which means:

1. It is a nice way to bundle a set of alerts - e.g., common PostgreSQL alerts vs. Oracle vs. .. that you want every DB instance to be assigned to one or more.  Create a new DB instance and simply assign it to one of the groups.  
2. Every time you add a new DB instance to monitor, you have to remember to assign that instance to the appropriate subset of alert groups.  
3. If some status of the DB instance changes (e.g., upgrade from version 2 to 4, moved from being a staging to a production DB, etc.) you may have to add/remove the instance from some of your groups.
4. If you include alerts that are only intended for specific DB types, versions, or business reasons production vs. staging vs. development contacts etc. in the same alert group, all the alerts in the group will run (or attempt to run) on every instance in the group definition.  
   1. Note: even including alerts in a group that have an alert rule won't matter - the alert rule is only used to identify which DB instances the alert should run on.  The Alert Group's definition list of DB instances ignores/overrides the rule and assigns the list of DBs in its configuration.   (e.g., an Oracle only rule in alert Ora123 can be included in a Sybase alert group of alerts and assigned to Sybase instances)

Alert Rules are meant to automate/eliminate the manual administration of which DB instances an alert should be assigned to.  As mentioned earlier, the rules can be built on:

1. DB attributes such as DB type (Oracle, Db2...), DB version, ...
2. Business or logical concepts where you define custom property to exist on all DB instances and optionally assign one or more values of that custom property. 
   1. Example 1 (single), define a custom property "ProdStatus" and optionally assign a ProdStatus value of either 'Production', 'Staging', 'QA', 'Development', 'Support' to one or more instances
   2. Example 2 (multi-value), define a custom property "DBA Team Approved" and assign values to instances identifying which DBA team's required alert set should be assigned -- e.g. values of  "ORADBAs_BU_ECommerce" OR "ORADBAs_Mission Critical" to DB instance #1, "ORADBAs_INTERNAL" to instance #2, ...  
3. You can then use a combination of the above to create a rule:
   1. Assign all DB instances whose "DB Type" is either "SQL Server, Azure SQL DB, ASMI"    AND whose ProdStatus = "Production"  AND to alerts approved by "DBA Team Approved" values of "ORADBAs_BU_ECommerce"
      1. Any time a new DB instance is added or changes either DB attributes (e.g., DB version) or assigned custom property values, the alert assignments made by rules are automatically re-evaluated and change which alerts are assigned to that instance (unless overridden by an Alert Group)
4. With alert rules, potentially all you have to worry about when registering a new instance is what values to assign it for each custom property type.  Then the decision of which alerts apply is completely automatic. Likewise when any of the properties (DB or Custom) change (e.g., from "Staging" to "Production"), the alert assignments potentially automatically change as well. 
5. Also, if you have a lot of alerts using a particular alert rule "R" and you need to adjust the criteria, you can simply update "R"s definition without having to open or touch any of the alert definitions. 

There's no recommendations for one or the other.  Whether you use Alert Rules, Alert Groups, or both really depends on how you want organize and manage which alerts apply to which monitored DB instances.  

If you have a large number of monitored DB instances that diverse types, versions, or owned by multiple orgs with different alert criteria,  I'd suggest alert rules.  Then when you add a DB instance, you just pick out its property assignments.  When you add a new alert, you just pick out (or add) which alert rule to apply.

Thank you very much. Is there a specific training session - on demand or instructor led, that addresses this topic ? The "monitoring profile" we'd like is a combination of technology platform + App. For example, the Oracle instances for App "A" will have a specific set of metrics we'd like monitored. This would be separate from the template used for monitoring Oracle instances for App "B", which will have it's own defined metrics and thresholds, etc. I have full access to the customer portal and looked up available training. However, I cannot (from the title) ascertain which one deals with this topic. And unfortunately,  we do not have the time to go thru all of them. 

Not sure about which training session may include. But the DPA Administration Guide can give you the basics of how but here's a sequence of screen captures to show how I set up a custom property "Application Name(s)" and assign values for that custom property to different DB instances, then create a rule to match Oracle Databases for either Application A or Application C, and finally added that rule to all alerts it should apply to.

At this point any Oracle DB instance that is part of either App A or App C will automatically be assigned for that alert to monitor (in essence this is a dynamic self-defining application group)

Attached is a ZIP file of screen shots for the complete sequence to create all the above from scratch - note download rename the file suffix type to  .zip  and the uncompress it.26 DPA Sequence to create cust props and alert rules change to zip.sql

Not sure about which training session may include. But the DPA Administration Guide can give you the basics of how but here's a sequence of screen captures to show how I set up a custom property "Application Name(s)" and assign values for that custom property to different DB instances, then create a rule to match Oracle Databases for either Application A or Application C, and finally added that rule to all alerts it should apply to.

At this point any Oracle DB instance that is part of either App A or App C will automatically be assigned for that alert to monitor (in essence this is a dynamic self-defining application group)

Attached is a ZIP file of screen shots for the complete sequence to create all the above from scratch - note download rename the file suffix type to  .zip  and the uncompress it.26 DPA Sequence to create cust props and alert rules change to zip.sql