Indexed Views in OLTPs?

Question

I'm familiar with SQL Server Indexed Views (or Oracle Materialized Views), we use them in our OLAP applications. They have the really cool feature of being able to usurp an execution plan and remap it to the indexed view w/out having to change existing code.

IE. Let's say I had a SPROC that was a really expensive join.

SELECT [SOME COLUMNS]
FROM Table1 INNER JOIN Table2 [DETAILS]
INNER JOIN Table3 [BUNCH MORE JOINS] ...

If I authored an indexed view that held a similar result set then the Query Optimizer will very likely send the SPROC to my indexed view as opposed to the base tables and I get a big performance increase.

Now say I wanted to use indexed views in an OLTP!? I mean most OLTPs (like this site) are relatively read heavy, if they have expensive joins then we could speed them up a ton AND potentially reduce locking contention (http://www.codinghorror.com/blog/archives/001166.html). Even better is you wouldn't have to change any code, just author the indexed view.

But this also means the database gets bigger since we need to keep a copy of these data in the indexed view...

Has anyone ever used indexed views to solve contention or speed issues in an OLTP? How come I've never seen this in use?

Answer 1

We use materialized views to speed up things where I work. Most often for reports against the OLTP system. Many of our reports run from a data warehouse, but since we refresh the warehouse overnight, up to the moment data has to come from the OLTP tables.

Answer 2

Were these materialized views created IN the OLTP or were they stored elsewhere? If they were created in the OLTP how did it affect database size and performance. Were any of these OLTPs under heavy load before the materialized views were put down?

Answer 3

Materialized views can be useful for reporting against OLTP, especially is large numbers of rows are aggregated to get the results. The space requirements are completely dependent on how much data you are saving. Think of it as a cache.

The tricky balance is between how recent the data needs to be for the reports, and how much of a hit you can take on OLTP performance. If somewhat stale data is OK, you may be able to schedule the updates to the views during a time when system activity is low.

The one time I could not, and need very current data, I ended up using some custom development. Each update to the base table fired a trigger which wrote a record to a transaction table. The view looked at a cached aggregate, plus the delta stored in the transaction table. As system resources allowed, the transactions were applied to the aggregate table as delta transactions. This allowed me up to the second data, good performance on reporting (the only aggregation happening was recent transactions) and fairly little load on the database (only doubling the size of every write, not re-calculating a huge aggregate every time).

Unfortunately, it was complex to maintain, and did not use simple built in tools. If you can wait on your reporting data, it is often best to use the built in materialized views and defer the refresh.