Thanks for the reply. A few points in response then:
> I'm not sure which component was a turn off for your DBAs, but the most common one I have heard is about indexes for which a configurable option was introduced in v6.1.1
Yeah, certainly our DBAs wanted more control than that. But its a step in the right direction I suppose.
>A quick note on the terminology. There are Application Monitor Templates and then there are Application Monitors. Once a template is assigned to a node, it is called an Application Monitor and both can the template >and the assigned application monitor can be modified independently. So, really there is no need to create 1 template per node. You can do a multi-edit in the 'Assigned Application Monitors' tab of the 'Manage >
>Templates' settings to define the node specific inputs like connection strings, etc.
Here's the problem when you use a single template all the time. Take a situation where you have a server running multiple Oracle databases - so you assign multiple application monitors to the node and you edit them to modify the SID and credentials. Now you've got multiple App monitors deployed to one server, all with the same name and you don't know which one is which. You can't tell from the App monitor name - only thing you can do is delve into each component and check. That's not easy to do on an enterprise scale with big consolidated databases servers. Add to that you've no way to construct a meaningful view that shows a big green light beside all of the monitored databases on that node. Alerting also becomes an issue because if one of the components in the app monitors fails, you can't report on the database connect string or SID in that component. It doesn't seem to be exposed. Not saying we did it the right way, but using multiple templates seemed like the only way to us - or one template and renaming the app monitors when they're deployed.
>On further thought, if you were to use PowerShell monitors instead of SQL user experience monitors, you can use Application Custom properties and pass the application specific details dynamically to the script body. >So, you should be able to define everything you need in just the template itself.
Haven't really looked at that, but will investigate further.
> It is a matter for constructing the query so that you can leverage the Message field. Below is a good example.
We made good use of passing info back into the Message field (ie: the 2nd column in the query results) and we passed many items into that field, but then you can't do anything with the contents of that field like splitting it up or parsing it - particular in alerts. So for example, our table space % free component would return a list of all table spaces over the threshold in the second column of the query, but then we couldn't divide up the contents of that field. So we'd have to send our alert based on all of the table spaces that we're over the limit rather than one by one.