Question

I have a requirement to create a report that is killing the processor and taking a long time to run.

I think I could speed this up significantly by creating an index view that keeps all this data in one place making it a lot easy to query/report on. This view would not just be used for the report as I think it would benefit quite a few areas in the data layer.

The indexed view will potentially contain 5 million+ records, I cant seem to find any guidance as to at what point indexed views are not longer recommended. I assume that an index view of this size would take considerable time to build when SQL first starts, but I would hope after this the cost of maintaining it would be minimal.

Is there any kind of best practice guide as to when to use index views and when not to use them? Would the view rebuild itself after every server restart or does it get stored somewhere on the disk?

Answer 1

The index associated with your Indexed View will be updated whenever updates are made to the any of the columns in the index.

High numbers of updates will most likely kill the benefit. If it is mainly reads then it will work fine.

The real benefits of Indexed Views are when you have aggregates that are too expensive to compute in real time.

Please see: Improving Performance with SQL Server 2008 Indexed Views:

Indexed views can increase query
performance in the following ways:

• Aggregations can be precomputed and stored in the index to minimize
  expensive computations during query
  execution.
• Tables can be prejoined and the resulting data set stored.
• Combinations of joins or aggregations can be stored.

The query optimizer considers indexed
views only for queries with nontrivial
cost. This avoids situations where
trying to match various indexed views
during the query optimization costs
more than the savings achieved by the
indexed view usage. Indexed views are
rarely used in queries with a cost of
less than 1.

Applications that benefit from the
implementation of indexed views
include:

• Decision support workloads.
• Data marts.
• Data warehouses.
• Online analytical processing (OLAP) stores and sources.
• Data mining workloads.

From the query type and pattern point
of view, the benefiting applications
can be characterized as those
containing:

• Joins and aggregations of large tables.
• Repeated patterns of queries.
• Repeated aggregations on the same or overlapping sets of columns.
• Repeated joins of the same tables on the same keys.
• Combinations of the above.