Databases Reference
In-Depth Information
.
The flight recorder cannot expand indefinitely, so it has to be restricted somehow.
See the “Configuring Flight Recorder Behavior” section later in this chapter for infor-
mation about restricting flight recorder size.
.
The flight recorder records only activity that happened during the past hour (the
default period of time the flight recorder records). So, much of the time you can't
tell what happened by just looking at the record. Imagine that you suspect that
some stale or inactive connections are consuming server resources. You can look at
the flight recorder data for the current hour of server activity, but you won't be able
to find information about connections that users made to the server a few days ago.
The flight recorder trace file is of no help in such a situation.
How the Flight Recorder Works
To overcome the problem of not being able to tell exactly what happened when you look
at the flight recorder record, you have to either make sure that the flight recorder trace
spans several days (which is impractical because you would consume a lot of server space)
or configure the server to take snapshots of server state as the flight recorder records.
These snapshots would contain requests for information about the current server state.
The primary role of a server-state discover request is to give you information about the
server state. The snapshots that you see in Figure 38.7 contain server-state discover
requests. The events that result from these requests are recorded into the flight recorder
trace file.
Last hour
FIGURE 38.7
Taking periodic snapshots of server activity enables you to conserve server
space.
In Figure 38.7, you see four snapshots taken during the past hour. In our example, the
server sends four requests for each snapshot:
DISCOVER_SESSIONS
,
DISCOVER_CONNECTIONS
,
DISCOVER_JOBS
, and
DISCOVER_LOCKS
. (You can also see these requests listed in the SQL
Server Profiler screen shown in Figure 38.8.)
Search WWH ::
Custom Search