Same answer as always: It depends.
a) Is caching generally enabled on the server?
b) Is caching enabled for the tables your requests hit?
c) Does the analysis used in the agent explicitly turn off cache using the DISABLE_CACHE_HIT variable?
Thanks Chris for your quick response.
So is there any way , that we could know, whether my scheduled Agents(Ibots) for Alerts are hitting the database or Cache currently?
I have 20 scheduled Alerts in place currently.
Look at the logs, everything running on your system leaves some logs, everything doing an query has logs there (with the info if the LSQL has been sent down to a database or matched a cache entry).
As Gianni said: Look at the logs. And at the Usage Tracking tables.
Logs : How do we differentiate whether the query hits cache or database.
Usage Tables: Does (NUM_CACHE_HITS - Indicates the number of times that the cache result returned for the query. ) tells us that it had hit cache instead of database?
It's written in full letters if the cache is used in the logs, and you also see that no physical query is generated and executed.
Why not cache the report or source table for the time between agents. say if you are running the agent daily keep the cache for the objects for a day or 20 hours.
Not sure if that's a valid idea in all cases since what the OP calls "wasting the database resources" may simply be the agent running off doing precisely what it is supposed to do: getting 200 *personalized* data sets for 200 distinct users.
And if the 200 recipients should get the same data then the query anyway only ever runs once. Most likely the confusion comes from a misunderstanding of how agents work in general and what that agent does in particular.
Added to that is an equally likely misunderstanding of cache as "cache solves all your performance issues" rather than attacking the root causes of performance issues.