- SQL Profiler Events for Analysis Services
- SQL Profiler Columns for Analysis Services
SQL Profiler Columns for Analysis Services
Each category of SQL Profiler events has a number of columns that you can include in the trace. Table 2 provides an overview of the most useful columns.
Table 2
Useful Columns for Tracing Analysis Services Events
Column |
Description/Explanation |
Event Subclass |
Identifier and name of the event subclass; for example, "6 - object created" is a subclass under notification events. |
TextData |
Full text of the command/query or of the current step of an operation. For example, the query subcube event will show a string such as "0000,0001,00011,0011" displaying 1 for the attributes mentioned in the query and 0 for any attributes that weren't requested. |
Start Time, Current Time, End Time |
These columns help to build the timeline of events. |
Connection ID, Session ID, SPID |
These columns help to identify the session, connection, and process that triggered events. You can correlate these columns to IDs shown in the Analysis Services Activity Viewer or in the output of dynamic management views. Not familiar with the Analysis Services Activity Viewer? You can download this sample tool from CodePlex. |
Duration |
Duration of each step of query, processing, or other operation, reported in milliseconds. |
Database name, object name, object path |
Helps to identify the object being processed or queried. |
NTUserName, NTCanonicalUserName, NTDomain Name |
Helps to identify the user who instigated the event. |
Error/Severity |
Shows the actual error number and corresponding severity. |
ClientHostName |
IP address of the client computer that submitted the request. |
SessionType |
Helps to determine whether the activity is from a user or due to lazy aggregations. |
IntegerData |
Shows the progress of a particular activity. For example, this column shows the number of rows read during processing. |
Summary
In this article, I've discussed Analysis Services events and columns you can capture by using SQL Profiler. Once you're familiar with events and columns, you should be ready to collect the Profiler trace, and its output should make sense. Part 2 of this series concludes this discussion with an examination of how you can discover the bottleneck of querying, processing, and backup jobs. I'll show you how Profiler output should change once you mitigate the problems. I'll also discuss using Profiler for load testing and collecting traces for historical performance analysis.