Using Trace to Monitor and Audit Analysis Services - Microsoft SQL Server 2008 Analysis Services - page 760

through the log, and it allows other applications to access the log programmatically. But
like any log, it has inherent problems:

. You have no control over what is being logged.

. A log typically has a rigid structure that resembles a relational table, which means

that every event has the same number of columns.

. Logs usually don't have good mechanisms for controlling the problem of excessive

increase in its size.

. There is no real-time message notification. The typical logging infrastructure doesn't

give you immediate notification of events. The event is first written to the log file,
and only then can you access it when you want to search for an event.

Trace Architecture

The end of our discussion of logging brings us naturally to the concept of trace. In
contrast to logging, trace gives you a lot of control over the events that are gathered by
the system and what the system does with them. In simple terms, you create a series of
filters (trace objects) so that the system pays attention to only the events you specify. And
you can specify that those events are stored in a trace file, sent to a client computer for
display, or both. Let's start with a look at Analysis Services' trace architecture, shown in
Figure 38.1.

Trace infrastructure is governed by the Trace Manager component of Analysis Services. To
subscribe to a trace, any component of Analysis Services creates a Trace object and regis-
ters it with the Trace Manager. Properties of the Trace object define what events are
produced.

Analysis Services uses a single-file TraceDefinition that contains the definition and para-
meters of all trace events. When subscribing to a trace, the subscriber creates a Trace
object containing set of events she wants to see. Sets of these events from all the trace
objects are merged by the Trace Manager and form a global filter that is used to determine
which events are produced and should be entered into a single global linked list of events
( TraceQueue ). The subscriber reads events from the TraceQueue according to their Trace
object definitions and streams them either over the network, where you can see them as
they occur, or into a file, where you can view them at your convenience.

After an event has been received by all subscribers, it is discarded from the queue. In case
of overload, Analysis Server might decide to discard trace events from the queue even
before they are consumed by all subscribers.

There are three types of Trace objects (administrative trace, session trace, and flight
recorder trace):

. The most common trace is the administrative trace, which is created when the user

sends a Create command for a Trace object. It can send events to the user or write
them into a trace file.

. A session trace is created automatically by the server for every session.