Databases Reference
In-Depth Information
Any query that comes to Analysis Services is first checked to see if it can be
served with the existing MOLAP cache. If the current cache is valid based on
proactive caching settings, results are retrieved from that. If the current cache
is not valid, that means a new cache is being rebuilt. Because Analysis Ser-
vices does not know how long it will take to rebuild the cache, it will then dir-
ectly go to the relational data warehouse to retrieve the data. Analysis Ser-
vices creates SQL queries to retrieve the correct data. The SQL queries gen-
erated by Analysis Services are optimized to efficiently retrieve data from the
relational data warehouse. Any calculation that cannot be done in the rela-
tional data warehouse is then computed within Analysis Services after retriev-
ing the data, and the results are returned to the user.
Keep in mind that there might be slight performance degradation during the
time data is being retrieved from a relational data source; this is likely due to
involvement of query translation as well as network activity — nonetheless,
users get the real-time data. If the users do not mind getting the data from the
existing cache and they only want to see the refreshed data with good per-
formance, they can set a proactive caching property called latency , which is
the time up to which the current MOLAP cache will be valid even after the no-
tification of change in data in the relational data warehouse. Setting the
latency (inactivity time interval) close to the rebuilding time helps in getting
MOLAP-level performance — keep in mind that a slight delay in the real-time
data to users is to be expected.
Fortunately for the users, MOLAP cache building is done as a background
thread and assigned a low priority. This means that if queries are submitted to
Analysis Services databases, the queries will be given higher priority than the
background proactive caching thread. If at any time during this rebuild pro-
cess the user initiates a process that will change the data in the cube — for
example, by re-processing the cube or doing a writeback to the cube — the
background proactive caching thread to rebuild the MOLAP cache will be
cancelled. Similarly, if Analysis Services receives another notification of a
data change, the MOLAP cache rebuilding process will be cancelled unless
you have explicitly specified not to do so through a proactive caching prop-
erty. It is important for you as an administrator or database designer to be
aware of this behavior so that you can make sure the proactive caching prop-
erties are set with desired values based on your business requirements.
Search WWH ::




Custom Search