Which three actions should you perform in sequence?

You are developing a SQL Server Analysis Services (SSAS) multidimensional project that is
configured to source data from a Microsoft Azure SQL Database database. The cube is
processed each night at midnight.
The largest partition in the cube takes 12 hours to process, and users are unable to access
the cube until noon. The partition must be available for querying as soon as possible after
processing commences.
You need to ensure that the partition is available for querying as soon as possible, without
using source data to satisfy the query.
Which three actions should you perform in sequence? (To answer, move the appropriate
actions from the list of actions to the answer area and arrange them in the correct order.)

Answer: See the explanation.

Explanation:

Box 1:

Box 2:

Box 3:

Note:
* Processing mode has two possible options.
Regular. This is the default setting. When set to regular, partitions will be available to users
after data has been loaded and aggregations are created completely.
Lazy Aggregations. When set to lazy aggregations, partitions will be available to user
queries immediately after data has been loaded. Aggregations will be created as a separate
background process while users start to query the partition.
* Lazy processing performs the task of building indexes and aggregations for dimensions
and measure group partitions at a lower priority to reduce foreground processing time and to
allow users to query the cube sooner. For lazy processing to occur, you must switch the
ProcessingMode = LazyAggregations of your measure group partitions; by default this value
is Regular (lazy processing is turned off). When processing a dimension with flexible
aggregations such as parent-child or virtual dimension by using the processing enumeration
of ProcessUpdate (such as to take into account of member name or hierarchy changes),
lazy processing is initiated to ensure that the aggregations are rebuilt on the associated
measure group partitions.
* Configure Lazy Processing for the cube, measure group, or partition. If you configure Lazy
Processing, the dropped aggregations are recalculated as a background task. While the
flexible aggregations are being recalculated, users can continue to query the cube (without
the benefit of the flexible aggregations). While the flexible aggregations are being
recalculated, queries that would benefit from the flexible aggregations run slower because
Analysis Services resolves these queries by scanning the fact data and then summarizing
the data at query time. As the flexible aggregations are recalculated, they become available
incrementally on a partition-by-partition basis. For a given cube, Lazy Processing is not
enabled by default. You can configure it for a cube, measure group, or partition by changing
the ProcessingMode property from Regular to LazyAggregations. To manage Lazy

Processing, there are a series of server properties such as the LazyProcessing \
MaxObjectsInParallel setting, which controls the number of objects that can be lazy
processed at a given time. By default it is set to 2. By increasing this number, you increase
the number of objects processed in parallel; however, this also impacts query performance
and should therefore be handled with care.
* Incorrect: With Bring Online Immediately enabled, during cache refresh all queries are
directed to the relational source database to retrieve the latest data for end users. While this
provides users with refreshed data, it can also result in reduced query performance given
that Analysis Services needs to redirect queries to the relational source database.