Architecture of Query Execution—Retrieving Data from Storage - Microsoft SQL Server 2008 Analysis Services - page 555

single request, and so resources are left for other users' requests. Because this property can
negatively affect performance of individual queries, use it with caution.
If bitmap indexes were created for a given segment and attribute, Analysis Services uses
indexes to detect which pages of the segment to read. For example, if a query requests
data about sales of customers that lived in Redmond in 1998, Analysis Services needs to
use indexes of the City and Year attributes to find pages that contain data. If indexes are
not found for the given attributes, Analysis Services must scan all the pages of the
segment.
After Analysis Services detects pages that contain data, it reads data from the granularity
attribute of the partition or aggregation and decodes data to the granularity defined in the
request using the data decoder. Analysis Services creates the data decoder using informa-
tion about the segment's compression stored in the segment's header. Reading the
segment's header, Analysis Services might find out that the current segment doesn't
contain the requested data and will then skip this segment.
Analysis Services starts decoding from attributes specified in a slice of requested subcube
to filter records by this slice. Among attributes used in a slice, Analysis Services first
chooses the attribute with a larger number of members because this attribute has better
selectivity. (That is, it has a better chance to filter out a large number of records.) In our
example, Analysis Services first decodes the City attribute, and skips records that don't
contain data for Redmond. Then Analysis Services decodes the Year attribute and skips
records that don't have information for the year 1998.
In the last phase, Analysis Services aggregates all records that weren't filtered out and
passes them to the MapQuery object. The MapQuery object collects data from all the
segments of all the partitions and forms the resulting Datacache object.
Querying ROLAP Partitions
ROLAP partitions don't store data; they contain only metadata that Analysis Services uses
to generate a query to a relational data source. In the first phase of data retrieval, Analysis
Services analyzes the partition slice and detects whether the partition contains the
requested data. If the slice matches the request subcube, Analysis Services creates the
Query ROLAP Partition job.
Data retrieval from a ROLAP partition during query execution is similar to loading of rela-
tional data into a MOLAP partition during partition processing. (For more information
about partition processing, see Chapter 21.) But whereas Analysis Services processes the
MOLAP partition in three phases—read data, process data, and write data—during a
ROLAP query, it skips the third phase: write data. Analysis Services generates a SQL request
to the relational source by translating the request subcube into SQL. It translates slices
defined in a subcube into a WHERE clause of a SQL query and granularity into a SELECT
clause.