Replication Extended Events, Not a Tool in your Toolbox (Yet)

There are already a number of data sources you can reference when investigating replication issues.  One data source on my wish list was to have a one-stop shop in Extended Events similar to the AlwaysOn Health Session.

It turns out that SQL Server 2012 does have a few new replication related events, but don’t get too excited… Books Online manages our expectations in the following text (underlined text added by me):

“Replication supports Extended Events, however, this feature is for internal use only at this time. Replication extended events were added to help customer support engineers collect information to troubleshoot replication problems. The information collected is not useful for replication performance tuning or monitoring.”

There was a dash of hope in the “at this time” qualifier, but that was the only good news I could get from this. But even then, I wanted to be absolutely sure that there were truly no hidden diagnostic data sources that could be leveraged for replication issues.

I found the following potentially promising events in sys.dm_xe_objects:


The first one was what I decided to investigate today was “repl_event”.  It is described in sys.dm_xe_objects as “Occurs when sp_repl_generateevent is called. this event is an internal repl event for tracing repl stored procedures. The data that is returned from user_event includes the event_id that was specified in the call to sp_repl_generateevent. This can be a value between x and y.“ :

ADD EVENT sqlserver.repl_event 
ADD TARGET package0.ring_buffer

I started this event session and set up transactional replication (configured the distributor, simple publication, one subscriber).  No events were triggered when I did this.

I then investigated the sp_repl_generateevent procedure itself.  Looking at the definition (or trying), returned the message “replgenerateevent extended procedure”. 

Which objects reference sp_repl_generateevent?  All I could find was sys.sp_MSaddmergetriggers_internal.  The referencing section of the system stored procedure was as follows:

select @command2 = ‘

       — update any ppm row that already exist with this gen

       update ppm set ppm.generation = case when @is_mergeagent = 1 then 0 else @newgen end

       from ‘ + @quoted_past_mappings_viewname + ‘ ppm with (rowlock) inner join deleted v

       on ppm.tablenick =@tablenick  and ppm.rowguid = v.’ + @quoted_rgcol + ‘

       — insert the past partition mapping into gen 0 if this is the merge agent

      insert into ‘ + @quoted_past_mappings_viewname + ‘ with (rowlock) (publication_number, tablenick, rowguid, partition_id, generation,reason)

      select distinct ‘ + convert(nvarchar(100), @publication_number) + ‘, @tablenick, v.’ + @quoted_rgcol + ‘, v.partition_id, case when @is_mergeagent = 1 then 0 else @newgen end, 1

      from ( ‘ + @partition_deleted_view_rule + ‘ ) as v  
      if (@@ROWCOUNT <= 0)


           select @xe_message = CAST(”replica_id: ” + convert(nvarchar(100), @replnick) + ”, article_id: ” + convert(nvarchar(100), @tablenick) + ”, rowguid: ” + case when @article_rows_deleted = 1 then convert(nvarchar(100), @rowguid) else N”0” end + ”, generation: ” + case when @is_mergeagent = 1 then N”0” else convert(nvarchar(100), @newgen) end + ”, Reason: -1” AS varbinary(1000));

          exec master..sp_repl_generateevent 1, N”Event : ppm_insert”, @xe_message



Since I was on a test SQL Server instance, I thought I would test out a direct call to this procedure just to indeed see that this procedure was hooked to the repl_event:

DECLARE @xe_message varbinary(1000) = 
    CAST('Event payload' AS varbinary(1000));

EXEC sp_repl_generateevent 1, N'Event: Am I captured?', @xe_message;

Sure enough – the repl_event was fired:



Whether repl_event gets leveraged in the future, we’ll see.  If Microsoft implements this in the future, my wish list would include the following events (and knowing that we can capture these in other areas – but again I’m interested in a consolidated session):

  • Replication configuration events (creation, dropping, changes)
  • Agent statistics, like periodic reader/writer thread latency statistics
  • Subscription expirations
  • Conflicts
  • Failed replication jobs and retries
  • Data sync warnings
  • Interoperability events (for example – database mirroring failovers of the publication database)

I may investigate the logreader_* related events at some point, but based on the naming and descriptions of these events I don’t see significant use cases at this time.

If you run across any other replication related events that you find useful, please share your comments on this post.  Thanks!

2 thoughts on “Replication Extended Events, Not a Tool in your Toolbox (Yet)

  1. Thanks Robert,

    That one looks interesting (from an edge case perspective) – and I haven’t tried it yet either.

  2. Hi Joe-

    There’s another log reader XE, logreader_add_tran_info, its description is "Outputs transactions which are added to the repl hash table as well as some hash table statistics." I haven’t tested it, but might that have some use for replication monitoring?

Comments are closed.

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.