Hosting and managing more than 10k Progress DB in our own Datacenters, we had to design a full-featured process to check their structures, their startup parameters and the performance issues that could happen with accesses made by the 50 000 Progress objects deployed on our application servers.

By taking metrics every five minutes on all of our databases up to every 0.05 seconds for the most active users, our health-monitoring console allows you to:

- Make the link between a huge activity to the source code / block, and even the precise query and if relevant, the concerned index.
- Highlight a user waiting (user wait)
- Prevent a potentially too long transaction (Transaction duration)
- Suggest the improvements of a DB startup parameters ( -n, -L, -B2, ...) before they become critical that will apply online or at the next start

These direct connections between metrics and code/parameters/recommendations lead to very fast and accurate corrective actions.

This session would be an opportunity for us to present:
- The way we take metrics
- How we establish the links between user’s activity and source code
- The management console GUI
- Several other "home-made" tools (Index analysis, locks visualization, …)
- Some Progress functionality use case (Statement caching, diagnostic, …)
- Quick overview of Progress best practices
- How the OE features help us