There's a book I read many years ago called "Controlling Software Projects" by Tom DeMarco. The first chapter starts with: "You can't control what you can't measure". This statement has popped up in my head regularly, especially since the IOD conference last October. While I was there, I had a long conversation with a customer that seems to be measuring everything and the results show.
IDS provides the ability to collect a lot of measurements. With the latest IDS version, we have even more capabilities than ever before. If we add the Open Admin Tool for IDS to the mix, monitoring has never been easier. Of course, monitoring and measuring are two different things. You need to collect the data provided in the monitoring and compare it over time.
Here's an example of measurement: Each time new features are added to the IDS code line, performance testing is done. The results are compared to previous performance runs. If the performance declines, it triggers an investigation to fix the performance issue. The IDS development team always aims at improving IDS performance.
So, we know IDS is always improving. We know that we can collect a lot of data on the IDS execution and tune the engine to get the most out of it. Is that enough?
My answer is NO. As data access experts, we need to get involved in the application side and monitor and measure what is being done there. How much data are they pulling out? what are they doing with it? There can be cases where implementing a stored procedure could greatly reduce data movement and yield both additional performance and scalability. This is just one example of what can be done.
You can't control what you can't measure. Don't limit yourself to the database server. By lending your expertise to a larger team, you can make a significant difference in your work environment.