SQL Server Agent Jobs Statistics

This sql script will give you thorough report about sql server jobs based on historical data.

The user can change the dates to narrow down the stats.

Make sure you are monitoring DB health especially when you are running it against PRODUCTION Databases.

SELECT
sJobHis.[server] AS [Server],
sJobStep.database_name [Database],
SJob.name [Job],
SJob.enabled [Enabled],
sLogin.name [JobOwner],
sJobHis.step_id [StepId],
sJobHis.step_name [StepName],
sJobStep.subsystem [CommandType],
sJobStep.command [Command],
sJobHis.run_date [RunDate],
[sJobSch].next_run_time [ScheduledTime],
STUFF(STUFF(RIGHT(REPLICATE('0', 6) +  CAST(sJobHis.run_time as varchar(6)), 6), 3, 0, ':'), 6, 0, ':') [RunTime],
STUFF(STUFF(STUFF(RIGHT(REPLICATE('0', 8) + CAST(sJobHis.run_duration as varchar(8)), 8), 3, 0, ':'), 6, 0, ':'), 9, 0, ':') [RunDuration (DD:HH:MM:SS)]
FROM sysjobs AS [SJob]
LEFT JOIN sysjobhistory AS [sJobHis] ON SJob.job_id = sJobHis.job_id
LEFT JOIN sysjobsteps AS [sJobStep] ON sJobHis.job_id = sJobStep.job_id AND sJobHis.step_id = sJobStep.step_id
INNER JOIN master.dbo.syslogins [sLogin] ON SJob.owner_sid = sLogin.sid
INNER JOIN dbo.sysjobschedules [sJobSch] ON SJob.job_id = [sJobSch].job_id
WHERE  SJob.[enabled]=0 OR (sJobHis.step_id > 0  AND (sJobHis.run_date > 20131002 AND sJobHis.run_date < 20181002))
ORDER BY SJob.enabled DESC, SJob.name, sJobHis.run_date DESC

Implementing Change Data Capture (CDC)

In this article, we’ll show how to enable and use the SQL Server Change Data Capture feature.

Enabling Change Data Capture on a Database

Before changes to any individual tables within a database can be tracked, change data capture must be explicitly enabled for the database. Because CDC is a table-level feature, it then has to be enabled for each table to be tracked. You can run following query and check whether it is enabled for any database.

USE master 
GO
SELECT [name], database_id, is_cdc_enabled
FROM sys.databases
GO

1

You can run the following system stored procedure in the context of each database to enable CDC at database level. (The following script will enable CDC in Allens database.)

GO
USE [Allens]
GO
EXEC sys.sp_cdc_enable_db    
GO

Additionally, in the database Allens, you will see that a schema with the name ‘cdc’ has now been created.

2

Some System Tables will have been created within the Allens database as part of the cdc schema.

3

The tables which have been created are listed here.

  • cdc.captured_columns – This table returns result for list of captured column.
  • cdc.change_tables – This table returns list of all the tables which are enabled for capture.
  • cdc.ddl_history – This table contains history of all the DDL changes since capture data enabled.
  • cdc.index_columns – This table contains indexes associated with change table.
  • cdc.lsn_time_mapping – This table maps LSN number and time.
  • dbo.cdc_jobs – This table stores configuration parameters for capture and cleanup jobs and is the only system table created in the msdb database.

Enabling Change Data Capture on Database Table

The CDC feature can be applied at the table-level to any database for which CDC is enabled.  It has to be enabled for any table which needs to be tracked. First run the following query to show which tables of database have already been enabled for CDC.

USE [Allens]
GO
SELECT [name], is_tracked_by_cdc 
FROM sys.tables
GO

The above query will return a result that includes a column with the table name, along with a column which displays if CDC is enabled or not.

4

You can run the following stored procedure to enable each table. Before enabling CDC at the table level, make sure that you have enabled SQL Server Agent. When CDC is enabled on a table, it creates two CDC-related jobs that are specific to the database, and execute using SQL Server Agent. Without SQL Server Agent enabled, these jobs will not execute.

Following script will enable CDC on dbo.TAT_TIME table.

EXEC sys.sp_cdc_enable_table                 
@source_schema = 'dbo' --mandatory
, @source_name = 'TAT_TIME' --mandatory
, @role_name = 'cdc_test' --mandatory
, @supports_net_changes = 1
, @index_name = N'TAT_TIME6'
, @captured_column_list = N'TIME_UNO,SOURCE,ENTRY_STATUS,WIP_STATUS,TAXABLE,LAST_MODIFIED'
, @filegroup_name = N'PRIMARY';
GO

When the feature on the table is successfully enabled, the following messages are shown.

Job ‘cdc.Allens_capture’ started successfully.
Job ‘cdc. Allens_cleanup’ started successfully.

Let’s discuss about the parameters of the sys.sp_cdc_enable_table stored procedure.

By default, all columns in the table are tracked. If you want to track only the specific ones, use the @captured_column_list parameter.

The @filegroup_name parameter can be used to change the default location of the change tables. By default, the change table is located in the default file group of the database. Database owners who want to control the placement of individual change tables can use the @filegroup_name parameter to specify a particular file group for the change table associated with the capture instance. The named file group must already exist.

By default, all members of the sysadmin and db_owner roles have full access the captured records. To limit access to the captured change data, create a new role that provides necessary permissions on the captured information, and use the @role_name parameter to grant the permissions only to the role members

When the @role_name parameter is set to NULL, only members of sysadmin and db_owner roles have full access to captured information. When set to a specific role, only the members of the role (called a gating role) can access the changed data table.

The @supports_net_changes parameter enables to show multiple changes aggregated as a single one. This parameter can be used only on tables that have a primary key or unique index. For instance, if stock market prices are tracked per stock and the price column is updated several times a day, the net change would result in only one change row per stock with the final price in the data.

When the CDC feature is enabled on the table, a capture table and up to two query functions are automatically created. For the dbo.TAT_TIME table, these are the cdc.dbo_TAT_TIME_CT table, and cdc.fn_cdc_get_all_changes_dbo_TAT_TIME and cdc.fn_cdc_get_net_changes_dbo_TAT_TIME table valued functions. The latter one is created only when the @supports_net_changes parameter is set to 1. These functions are used to query change tables.

5

Change Table

By default, the name of the change data capture change table is of the source table. Its associated change table is named by appending _CT to the capture instance name.

6

The first five columns of a change data capture change table are metadata columns. These provide additional information that is relevant to the recorded change. The remaining columns mirror the identified captured columns from the source table in name and, typically, in type. These columns hold the captured column data that is gathered from the source table.

Each insert or delete operation that is applied to a source table appears as a single row within the change table. The data columns of the row that results from an insert operation contain the column values after the insert. The data columns of the row that results from a delete operation contain the column values before the delete. An update operation requires one row entry to identify the column values before the update, and a second row entry to identify the column values after the update.

Each row in a change table also contains additional metadata to allow interpretation of the change activity. The column _$start_lsn identifies the commit log sequence number (LSN) that was assigned to the change. The commit LSN both identifies changes that were committed within the same transaction, and orders those transactions. The column _$seqval can be used to order more changes that occur in the same transaction. The column __$operation records the DML operation that is associated with the change: 1 = delete, 2 = insert, 3 = update (before image), and 4 = update (after image). The column __$update_mask is a variable bit mask with one defined bit for each captured column. For insert and delete entries, the update mask will always have all bits set. Update rows, however, will only have those bits set that correspond to changed columns. The column __$command_id tracks the order of operations within a transaction.

References

https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-db-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/cdc-capture-instance-ct-transact-sql

Introduction to Change Data Capture (CDC)

Introduction

SQL Server Change Data Capture (CDC) was introduced in SQL Server 2008 as part of the new data tracking and capturing features. It captures information about data changes – INSERTs, DELETEs and UPDATEs applied to SQL Server tables, and makes a record available of what changed, where, and when, in simple relational ‘change tables’. As captured data is stored in relational tables, it can be easily accessed and retrieved subsequently, using regular T-SQL.

When you apply Change Data Capture features on a database table, a mirror of the tracked table is created with the same column structure of the original table, but with additional columns that include the metadata used to summarize the nature of the change in the database table row.  The SQL Server DBA can then easily monitor the activity for the logged table using these new audit tables.

In Change Data Capture, the information is retrieved by periodic querying of the online transaction log. The process is asynchronous. Database performance is not affected; performance overhead is lower than with other solutions (e.g. using triggers).

Because the capture process extracts change data from the transaction log, there is a built in latency between the time that a change is committed to a source table and the time that the change appears within its associated change table. While this latency is typically small, it is nevertheless important to remember that change data is not available until the capture process has processed the related log entries.

As Change Data Capture reads committed transactions from the online transaction log, it uses the transaction commit time, so there are no problems in determining the sequence of long-running and overlapping transactions. There is a built-in clean-up solution that removes old captured information after a specified time.

SQL Server Change Data Capture requires no schema changes of the existing tables, no columns for timestamps are added to the tracked (source) tables, and no triggers are created. It captures the information and stores it in tables called change tables. For reading the change tables, Change Data Capture provides table-valued functions.

Advantages

  • Very easy to implement. Doesn’t require additional programming. Only requires configure database and objects.
  • It only tracks changes in user-created tables. It can be configured to only track certain tables or columns. Because captured data is then stored in relational tables, it can be easily accessed and retrieved subsequently, using regular T-SQL.
  • The source of change data for change data capture is the SQL Server transaction log. As inserts, updates, and deletes are applied to tracked source tables, entries that describe those changes are added to the log. The log serves as input to the change data capture process.
  • It reads the log and adds information about changes to the tracked table’s associated change table.
  • High performance implementation.
  • You have auto clean-up. You don’t need to worry about deleting the information collected; it is deleted automatically based on the retention period

Disadvantages

  • The history data takes some time to catch up (1 second), because it is based on the transaction logs.
  • It depends on the SQL Server Agent. If the Agent is not running or crashes, no history is being tracked.
  • Depending on the amount of changes it will add some overhead to the server, although, this doesn’t seem to be significant. It does not affect performance as heavily as triggers because it works with the transaction logs.

References

https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server

https://www.simple-talk.com/sql/learn-sql-server/introduction-to-change-data-capture-cdc-in-sql-server-2008/