Database Reference
In-Depth Information
°
BuildEvalNode End
(
4
)
°
RunEvalNode Start
(
7
)
°
RunEvalNode End
(
8
)
°
BuildEvalNode Eliminated Empty Calculations
(
100
)
°
BuildEvalNode Subtracted Calculation Spaces
(
101
)
°
BuildEvalNode Applied Visual Totals
(
102
)
•
Serialize Results Begin
(
75
)/
Serialize Results End
(
77
): These have
no related subclass events. They mark the start and end of query results
that are sent back to the client. The
Serialize
Results
Begin
event might
be raised before the calculation of all of the cell values in a cellset has been
completed, although it often starts just after all calculation is finished (for
example, a
Non
Empty
statement in an MDX query could force this behavior).
Monitoring queries with Performance Monitor
counters
Analysis Services Performance Monitor counters are more useful for monitoring
general query behavior than understanding what is happening when individual
queries are run. Logging these counters can help us to understand the characteristics
of all of the queries our users are running, and therefore help us to find query
performance bottlenecks. Here's a list of all of the relevant categories and the
important counters in them:
•
MSOLAP: Cache
category: The following are the counters present:
°
CurrentEntries
: This is the number of entries in the cache.
°
Total Direct Hits
: This is the number of subcube queries
answered from existing cache entries—this number should be
compared to total misses to evaluate the percentage of subcube
queries that are resolved using cache.
°
Total Misses
: This is the number of cache misses—this number
should grow after the cache has been cleared (for example, after the
Analysis Services service has been restarted, or after cube processing)
and should not grow too much once the cache is warm. If this
number continues to grow, we need to evaluate if there is not enough
memory for cache or if the queries that are being run cannot take
advantage of existing cache.
Search WWH ::
Custom Search