Finding Undistributed commands in Transactional replication

-> Below query can be used to find undistributed command count in transactional replication.

set nocount on
declare @publisher varchar(255)
declare @publisher_db varchar(255)
declare @Subscriber varchar(255)
declare @Subscriber_db varchar(255)
declare @subscription_type int
declare @subscriber_id int

set @publisher = ‘<Publisher SQL Instance Name>’
set @publisher_db = ‘<Publisher Database>’
set @Subscriber = ‘<Subscriber SQL Instance Name>’
set @subscriber_db = ‘<Subscriber Database>’

set @subscriber_id = (select distinct b.subscriber_id from master.dbo.sysservers a INNER JOIN MSsubscriptions b on a.srvid = b.subscriber_id where a.srvname=@Subscriber)

Declare @PublicationName VARCHAR(1000)
DECLARE CheckUndistributedcmdinbadway_cursor CURSOR FOR

select distinct b.publication,a.subscription_type from MSsubscriptions a inner join MSpublications b on a.publication_id = b.publication_id where a.subscriber_id = @subscriber_id

OPEN CheckUndistributedcmdinbadway_cursor
FETCH NEXT FROM CheckUndistributedcmdinbadway_cursor INTO @PublicationName,@subscription_type
WHILE @@FETCH_STATUS = 0
BEGIN
print ‘Publication: ‘+@PublicationName
EXECUTE sp_replmonitorsubscriptionpendingcmds
@publisher = @publisher,
@publisher_db = @publisher_db,
@publication =@PublicationName,
@subscriber =@Subscriber,
@subscriber_db =@subscriber_db,
@subscription_type =@subscription_type
print ‘————————————————————————‘
print ‘ ‘
FETCH NEXT FROM CheckUndistributedcmdinbadway_cursor INTO @PublicationName,@subscription_type
END
CLOSE CheckUndistributedcmdinbadway_cursor
DEALLOCATE CheckUndistributedcmdinbadway_cursor

-> Before running this query, select “Results to Text (CTRL + T)” from SQL Server management studio and execute it.

-> The query is not the best way to get the undistributed command count in transactional replication. But helped me solve my purpose. Can be useful for someone else.

-> The query will be blocked if distribution cleanup is running.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Advertisements

Logshipping metadata table log_shipping_monitor_secondary is not getting updated

-> I worked on a datacentre migration recently. One of the server involved in the migration was a Logshipping Primary and Monitor server. Logshipping primary and Monitor server were in new datacentre, but the logshipping secondary was at old datacentre.

-> After the migration, all of the logshipping jobs like Backup, copy and restore were working as expected. But the LS_Alert job was failing with below error,

Executed as user: <LOGIN>. The log shipping primary database <ServerName>.<DatabaseName> has backup threshold of 45 minutes and has not performed a backup log operation for 320 minutes. Check agent log and logshipping monitor information. [SQLSTATE 42000] (Error 14420). The step failed.

-> I checked the metadata tables msdb..log_shipping_monitor_primary and msdb..log_shipping_monitor_secondary to get more details.

-> Metadata table msdb..log_shipping_monitor_primary was updated recently. But msdb..log_shipping_monitor_secondary table was not updated recently. The time it was last updated was the time when we moved the Logshipping Primary and monitor server to new datacentre.

-> I started a profiler trace on the primary and monitor server without much luck.

-> I then started a profiler trace on the secondary server and found below messages,

OLE DB provider “SQLNCLI10” for linked server “LOGSHIPLINK_<Monitorserver>_-1140148506” returned message “Login timeout expired”.
OLE DB provider “SQLNCLI10” for linked server “LOGSHIPLINK_<Monitorserver>_-1140148506” returned message “A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.”.

-> I tried connecting the monitor server using SQL Server management studio from secondary server without much luck. I tried pinging the monitor server from secondary server and got the below,

C:\Users>ping <MonitorServer>
Pinging <MonitorServer> [192.152.0.3] with 32 bytes of data:
Reply from 10.0.0.9: TTL expired in transit.
Reply from 10.0.0.9: TTL expired in transit.
Reply from 10.0.0.9: TTL expired in transit.
Reply from 10.0.0.9: TTL expired in transit.

Ping statistics for 192.152.0.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

-> Updated my network team and they corrected it. Tried connecting the monitor server using SQL Server management studio from secondary server and this time it worked.

-> Metadata table msdb..log_shipping_monitor_secondary started getting updated normally.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.