Proactive Caching and Real-Time Updates - Microsoft SQL Server 2008 Analysis Services - page 434

<ForceRebuildInterval>-PT1S</ForceRebuildInterval>
<Enabled>true</Enabled>
<OnlineMode>OnCacheComplete</OnlineMode>
<AggregationStorage>MolapOnly</AggregationStorage>
<Source xsi:type=”ProactiveCachingInheritedBinding” />
</ProactiveCaching>

Most of the properties of a ProactiveCaching object define the frequency of notification
to Analysis Services about data changes and at the time that the MOLAP cache should be
dropped and rebuilt. Later in this chapter, we cover each property.

Timings and Proactive Caching

Quite a few intricate timing issues are involved in defining a well-balanced system that
performs well and enables you to see recent updates—that is, it doesn't spend most of the
time processing the MOLAP cache.

Update Frequency

If you were to define a proactive caching scheme that would rebuild a MOLAP cache after
every single update from the relational database, you might find that updates are coming
too often. Suppose that Analysis Services starts to process a partition soon after a new
notification arrives. Then a second notification arrives. The system examines the list of
objects currently being processed and cancels the ongoing processing of the partition
because Analysis Services doesn't allow multiple processing operations to run for the same
object at the same time. If updates are frequent, your system will keep canceling the
processing of the MOLAP cache. Figure 24.3 shows a diagram of this cycle of beginning
and canceling processing.

Cancel,
Begin
Process

Cancel,
Begin
Process

Begin
Process

End
Process

Update 1 Update 2 Update 3

FIGURE 24.3 Multiple notifications in a short period of time delay object updates.

The processing of the object begins after the first update. That processing cannot complete
because another update arrives, causing proactive caching to start processing the MOLAP
cache. That processing cannot finish because of a third update. And so on. The Proactive