Proactive Caching (Behind the scene)

I have written on Proactive caching earlier in my posts. Proactive caching provides developer automatic management of cube processing when changes happens on relational database. Proactive caching feature provides different standard settings on how frequently you want to detect changes and get real time data. This article will be covering internal processing which happens behind the scene. Let me take example of "Automatic MOLAP" where different parameter values are: 1) Silence Interval = 10 seconds 2) Silence Override Interval = 10 minutes

Snapshot1 I have set "SQL Server Notification" on "Targets" table.

Now deploy changes on cube and we are ready for receiving changes from relational database. Lets configure "SQL Server Profiler" on analysis server so we can track all the changes happening on the server. We will change Target table data and see events in profiler: view plainprint? 1. UPDATE [dbo].[TARGETS] 2. SET InternetSalesRevenue = 15000000 3. WHERE CalendarYear = 2005

Step 1: Analysis Services recieves notification on changes in "Target" table. Step2: Analysis Services waits for "Silence Interval" time period. Step3: If no changes detected in "Silence interval" time period then it reprocess the cube. If you view snapshot1 closely then you will see one informational message related to login access on bottom.

Implementation of Proactive Caching in Sql Server 2005

In the post Analysis Services Storage Modes, I have explained different storage modes in Analysis Services like ROLAP, MOLAP and HOLAP. In ROLAP data will not be obsolete because for each analysis services query, we connect to relational database but in MOLAP and HOLAP, data becomes old after the cube processing(if there are DB changes). Now if there are changes happening on relational database then it can come in Analysis Server only on reprocessing. Proactive caching feature of Analysis Services provides the way to detect new changes and reprocess cube to reflect new changes by its own.Proactive Caching tries to minimize latency and maximize performance.Proactive caching can be set for partitions as well as for dimensions. Before starting "How to implement Proactive caching", lets understand few terminologies which will be useful in configuring different strategies in Proactive caching.Proactive Caching can be configured by using SSMS(Sql Server management studio) as well as BIDS. 1) If you are using SSMS then browse cube till partition level, right click properties and select "Proactive Caching". 2) If you are using BIDS solution then open Partition tab, select one partition and click "Storage Settings". There are Standard "Storage Settings" which enables Proactive Caching with predefined values of few parameters(Slice Interval, Slice Override interval,rebuild interval etc.) which will be described below: Different Standard Storage Settings:

1. Real time ROLAP 2. Real Time HOLAP 3. Low Latency MOLAP

4. Medium Latency MOLAP 5. Automatic MOLAP 6. Scheduled MOLAP 7. MOLAP Different Parameters and their explanation: Cache Settings: 1. Silence Interval 2. Silence Override Interval 3. Latency 4. Rebuild Interval Options: 1. Bring Online Immediately 2. Enable ROLAP Aggregation 3. Apply Settings to Dimension For example, Consider different parameter settings of Low Latency MOLAP option mentioned in below screen shot:

1) Silence Interval: For "Low Latency MOLAP", Silence Interval has been set 10 seconds. Whenever relational database change happens and notification comes to Analysis Server.

Silence Interval start its stopwatch and if no other Database changes comes before 10 seconds then it will start reprocessing cube with new changes. If new database changes comes <10 seconds then Silence interval Stopwatch will be reset to zero so if frequent changes are coming then analysis services will wait till all the changes complete. 2) Silence Override Interval: As soon as first database change comes after last reprocessing of cube then analysis services start one more stopwatch "Silence Override Interval". It basically overrides "Silence Interval" for reprocessing cube. For the same example, if frequent database changes are happening and silence interval is getting reset each time then SSAS will forcibly process cube after it passes "Silence Override interval" so in this example, cube will be processed after 10 minutes. 3) Latency: Old MOLAP cache will be dropped after time interval specified in Latency. Latency ensures the time interval after which data will not be old. If new cache is not available after Latency period then queries will be addressed by relational database and user will see significant performance drop in query response time. 4) Update the cache frequently(Rebuild Interval): MOLAP cache will be rebuild after specified "Rebuild interval" irrespective of database changes. It means if database changes doesn't occur then also MOLAP cache will be rebuild. 5) Bring Online Immediately: If you select this option then queries will be addressed by relational DB when new cache is not up and old cache has been dropped. 6) Enable ROLAP Aggregation: If you select this option then Aggregation objects will be created in relational database. a) Indexed Views in SQL Server 2005 and SQL Server 2008 b) Materialized Views in Oracle 7) Apply Settings to Dimension: If you select this option then same cache settings will be applied to all related dimensions from partition. This will not be available for HOLAP standard setting. Here is the chart which compares different Standard Storage Settings in SSAS. You can customize and create your own settings by clicking on "Custom Settings" and then specifying different parameters.

Storage Mode

Enable Proactive Caching

No

Silence Interval

Silence Override Interval

Latency

Rebuild Interval

Bring Online Immediately

MOLAP Scheduled MOLAP Automatic MOLAP Medium Latency MOLAP Low Latency MOLAP Real Time HOLAP Real Time ROLAP

MOLAP

MOLAP

Yes

1 Day

MOLAP

Yes

10 Sec

10 Min

MOLAP

Yes

10 Sec

10 Min

4 hours

Selected

MOLAP

Yes

10 Sec

10 Min

30 Min

Selected

HOLAP

Yes

0 Sec

0 Sec

Selected

ROLAP

Yes

0 Sec

Selected

One more important aspect, Notifications Services needs to be specified before we are done with proactive caching implementation. There are three types of notification services available in analysis services: 1. SQL Server 2. Client Initiated 3. Scheduled Polling

1) SQL Server Notification: Once this option is selected then SQL Server 2005 notification services will be used to identify changes in underlying table. We can specify table names under "Specify Tracking Tables". If table names has not been mentioned then SSAS tries to find out relevant tables by its own. 2) Client Initiated Notifications: This option is usually selected when you are planning to use client based notification process. 3) Scheduled Polling Notifications: This option tries to identify changes by running SQL Queries mentioned in "Polling Query", "Processing Query" fields.

Proactive caching is mostly useful in which UDM is based on OLTP data and has requirement of low latency. In Data warehouse and Data Mart, data will be pulled in specified time(ETL batch processing) then Proactive caching doesn't give much, i will prefer to use other option (SSIS based solution) to pull the data.