Alan:

Thanks for your reply!

Your SQL query is exactly what I was needing. Glad to hear that my post is of use to you as well.

As for your suggestions, I've already been running the stored procs individually attempting to assess which ones are slower than others. I'll keep analyzing query performance within the report, especially with your handy-dandy query in my toolkit now.

But, it seems there may actually be a "ghost in the machine". My colleagues and I are beginning to suspect that the team that setup the server may not have it configured optimally (hardware-wise, memory allocation, virtual-machine config...). We're seeing other issues with the server, not just inexplicable reporting performance lag, but also with data loading being impacted and network connectivity to other data sources failing.

Interestingly, this morning the "problem" report is now back to performing at blazing sub-1 second data-retrieval rates -- average time to retrieve the report data is .53 second! The only thing that changed on our end was that 65 million records were added to the data warehouse over the weekend. Doesn't make sense that more data would improve performance, does it?

So, for the time being, I'll keep monitoring the reports.

Thanks for your assistance,

Pete