Creating a Customized Data Collection Set
Although you cannot change or delete the built-in
system Data Collectors, you can define your own custom data collection
sets. However, currently, you can define them only in T-SQL. There are
four different collector types that you can use to build a collector
set:
T-SQL query—
Executes a user-provided T-SQL statement as an input parameter, saves
the output from the query, and then uploads the output to the management
data warehouse.
SQL Trace—
Uses SQL Trace to monitor the SQL Server Relational Engine, with trace
data coming from the system default trace or from one or more custom
traces.
Performance counters— Collects specific performance counter information from Windows Performance Monitor on the computer running SQL Server 2008.
Query activity—
Collects query statistics and query activity information along with the
query plan and query text for queries that meet predefined criteria.
Essentially, this collector type collects the same information as the
Query Statistics collection set, so it is recommended that you simply
use the predefined Query Statistics collection set.
One of the reasons you might create a customized data
collection set is that the default system Data Collector for Query
Statistics does not store all the statements. It captures only the
worst-performing queries based on the algorithms specified in the
collection set. You might want to collect more queries than the top
three worst performing ones. However, if you create your own data
collection for query statistics, you should probably disable the default
system collector to reduce data collection overhead.
Tip
To see an example of a collection set based on
performance counters, DMVs, and T-SQL queries, you can look at the
definition of the default Server Activity collection set. You can easily
see this definition by right-clicking on Server Activity in the System Data Collection Sets folder in SSMS and selecting Script Data Collection.
There is also GUI support for creating a collection
set based on a SQL Server Profiler trace. After you define a trace in
SQL Server Profiler with the events you want to capture, select Export
from the File menu; then choose Script Trace Definition and select For
SQL Trace Collection Set. Doing so generates a T-SQL script that you can
use to create a custom Data Collector Set based on a SQL Server
Profiler Trace definition.
Assuming you’ve already set up your MDW, you can
begin by creating the data collection set and adding the collection
items you want it to contain. To create the data collection set, use the
sp_syscollector_create_collection_set procedure. Next, you need to create the collection_items
to indicate what information you want the collection set to collect. If
you are creating collection items for Performance Monitor counters, The
Performance Counter collector type takes three input parameters:
Objects— The SQL Server objects running in an instance of SQL Server
Counters— The counters associated with a SQL Server object
Instances— The instances of the specified object
Some input parameters support wildcard characters,
which enable you to include multiple counters in a single statement.
However, you can use wild cards only at the Counters and Instances
levels and, even then, only at the beginning of the string (for example,
'* Processor') or at the end of the string (for example, 'Memory *').
An example of the creation of custom collection set for capturing information for the Logical Disk and Process Performance Monitor counters is shown in Listing 1.
Listing 1. Creating a Custom Collection Set
Use msdb
go
Declare @collection_set_id_1 int
Declare @collection_set_uid_2 uniqueidentifier
EXEC [dbo].[sp_syscollector_create_collection_set]
@name=N'Disk I/O Perf and SQL CPU',
@collection_mode=1, — non-cached
@description=
N'Collects logical disk performance counters and SQL Process CPU',
@target=N'',
@logging_level=0,
@days_until_expiration=7,
@proxy_name=N'',
@schedule_name=N'CollectorSchedule_Every_5min',
@collection_set_id=@collection_set_id_1 OUTPUT,
@collection_set_uid=@collection_set_uid_2 OUTPUT
Select collection_set_id_1=@collection_set_id_1,
collection_set_uid_2=@collection_set_uid_2
/********************************************
** Now, create the desired collection items
*********************************************/
Declare @collector_type_uid_3 uniqueidentifier
Select @collector_type_uid_3 = collector_type_uid
From [dbo].[syscollector_collector_types]
Where name = N'Performance Counters Collector Type';
Declare @collection_item_id_4 int
EXEC [dbo].[sp_syscollector_create_collection_item]
@name=N'Logical Disk Collection and SQL Server CPU',
@parameters=N'<ns:PerformanceCountersCollector xmlns:ns="DataCollectorType">
<PerformanceCounters Objects="LogicalDisk"
Counters="Avg. Disk Bytes/Read"
Instances="*" />
<PerformanceCounters Objects="LogicalDisk"
Counters="Avg. Disk Bytes/Write"
Instances="*" />
<PerformanceCounters Objects="LogicalDisk"
Counters="Avg. Disk sec/Read"
Instances="*" />
<PerformanceCounters Objects="LogicalDisk"
Counters="Avg. Disk sec/Write"
Instances="*" />
<PerformanceCounters Objects="LogicalDisk"
Counters="Disk Read Bytes/sec"
Instances="*" />
<PerformanceCounters Objects="LogicalDisk"
Counters="Disk Write Bytes/sec"
Instances="*" />
<PerformanceCounters Objects="Process"
Counters="% Privileged Time"
Instances="sqlservr" />
<PerformanceCounters Objects="Process"
Counters="% Processor Time"
Instances="sqlservr" />
</ns:PerformanceCountersCollector>',
@collection_item_id=@collection_item_id_4 OUTPUT,
@frequency=5,
@collection_set_id=@collection_set_id_1,
@collector_type_uid=@collector_type_uid_3
Select @collection_item_id_4
Go
|
After you create the collection set, you can start
this data collection, either through SSMS (your user-defined collection
sets will be listed directly within the Data Collection node) or with the following stored procedure call:
Declare @collection_set_id int
select @collection_set_id = collection_set_id
from syscollector_collection_sets
where name = 'Disk I/O Perf and SQL CPU'
EXEC sp_syscollector_start_collection_set
@collection_set_id = @collection_set_id
go
Because there aren’t any custom reports available for
displaying the results of the custom collection set just defined, you
need to run a query in the MDW database to view the collected
Performance Monitor counter values. A sample query (which could serve as
the basis for a customer report) is provided in Listing 2.
Listing 2. Querying the MDW for Custom Data Collection Values
Use UnleashedMDW
Go
select spci.path as 'Counter Path', spci.object_name as 'Object Name',
spci.counter_name as 'counter Name', spci.instance_name,
spcv.formatted_value as 'Formatted Value',
spcv.collection_time as 'Collection Time',
sii.instance_name as 'SQL Server Instance'
from snapshots.performance_counter_values spcv
inner join
snapshots.performance_counter_instances spci
on spcv.performance_counter_instance_id = spci.performance_counter_id
inner join
core.snapshots_internal si
on si.snapshot_id = spcv.snapshot_id
inner join
core.source_info_internal sii
on sii.source_id = si.source_id
where
sii.collection_set_uid = '5D9849BE-1526-4159-99EB-6B0E690C31EA'
order by spcv.collection_time desc
|
It
is possible to create your own custom reports using SQL Server
Reporting Services that query the information for your custom collection
sets in the MDW database.
Data Collector Limitations and Recommendations
Although the Data Collector is a great start to a
built-in performance monitoring tool, it does have some limitations
still, which are not wholly unexpected in a product that’s still early
in its release cycle. One key limitation is the limited number of
built-in data providers and the reports available. It is hoped that
future versions will make it easier to extend the Data Collector to add
additional collection sets and reports.
If you are defining your own custom Data Collectors, consider these recommendations:
Combine multiple performance counter or query collection items into a single collection item wherever possible.
Combine
collection items into a single collection set whenever possible unless
you need separate data retention periods or different collection
schedules for the collection items.
If
you collect data frequently, it is more efficient to run the collection
set in cached collection mode than starting and stopping a new process
every time new data must be collected. In cached collection mode, the
collection process runs continuously. As a general rule, if you will be
capturing data every five minutes or less, consider using a collection
set that runs in cached collection mode.
If
you are collecting data less frequently than every five minutes, using
noncached mode is more efficient than leaving a generally idle process
running all the time.
Although the
collection frequency for cached collection sets can be set to run as
frequently as every five seconds, be aware that more frequent collection
has correspondingly high overhead. Always choose the lowest collection
frequency that will meet your needs.
Currently, removing data collection after it has been
configured is not supported. You can disable data collections but
cannot remove them or the SSIS packages and jobs associated with them
after they have been defined. Attempting to manually remove data
collection may lead to errors if you try to re-implement data collection
in the future. In addition, you should not drop or change the name of
the MDW database because all the jobs are based on the original database
name.
Another key limitation in the Data Collector
is the lack of built-in alerting in the event that certain performance
thresholds are crossed while monitoring the system. In contrast, the SQL
Server Utility, which performs more limited monitoring and data capture
than the Data Collector, does provide a threshold and alerting
mechanism.
