Materialized view usage

For one of my DW customers we adopted a materialized view-based aggregation strategy. Only the base level summaries are exposed to the query tool and the Oracle database uses query rewrite to select the 'best fit' aggregation. This was the customers first use of query rewrite, their previous DW had all of the summary tables hand-mapped into the query tool. As often the case with something new there was a degree of uncertainty from the customer as to whether the technology did what it was supposed to do. And from my point of view, I had feeling that the customer had insisted on too many MV aggregates to be built.
To analyze what was going on we had to come up with a way of measuring which MVs were being used during the working day. Capturing the users queries is probably not the best approach. The SQL you see is against the base table, to get the MV accessed you need to look at the explain plan. It did not look a viable approach to capture hundreds of queries per day and then explain them to identify the MVs hit by the query.
However MVs physically exist as tables in the database, it would be perfectly feasible to determine physical and logical IO (from V_$SEGSTAT) against each table at the beginning and end of each day and look for changes. So we implemented a procedure to capture the IO stats for each summary MV at the end of the daily batch (to avoid any IO caused by rebuilding or collection of statistics on the MVs) and again capturing the IO stats at the end of the on-line day. From there we can build a daily history table based on tables that have shown an increase in IO over the day. For good measure we did the same for bitmap index usage.
Net result - - evidence that query re-write works and at least some of aggregates are used!