Skip to main content

The concurrent snapshot for publication is not available because it has not been fully generated or the Log reader agent is not running to activate it.

Hi everyone.

Welcome to my first post.

In my environment, we still utilize replication.

What in the world is replication?

Replication is a way to copy data from your source to destination server continuously.

Imagine if I am adding records to a database on your source server throughout the day and I would like the data updated to the target server. That's what is possible with replication.

Here's a great article for further reading:
https://www.sqlshack.com/sql-server-replication-overview-of-components-and-topography/

Back to the issue at hand.

1.
After reinitializing replication on the QA server, I received this message under the replication monitor > Distributor To Subscriber History:

The concurrent snapshot for publication is not available because it has not been fully generated or the Log reader agent is not running to activate it.

replication distributor to subscriber history















This was the other error message I was receiving under the replication monitor > Publisher To Distributor History:

Replicated transactions are waiting for next Log backup or for mirroring partner to catch up.

replication publisher to distributor history
















While still in SSMS, I went to check on my replication and noticed my subscription was missing:

replication local publication local subscriptions



But It was still missing even after running my script below to generate a publication and new subscription:

USE [replication database name]
GO
EXEC [dbo].[usp_ReplicationCreatePublication_publicationname]
WAITFOR DELAY '00:00:30';  -- Wait for snapshot agent job to finish before continuing
EXEC  [dbo].[usp_ReplicationCreateSubscription_subscriptionname] 'server','publication database'

2.
It turns out the stored procedures used in creating the publication and subscription were missing from my replication database. I went back to the Production version of my database and copied the script to recreate both stored procedures. You can do that by right clicking your stored procedure > 'Script Stored procedure as' > 'create to' > 'new query editor window' . Then you will be able to copy your stored procedure scripts from Production to QA.

Note: A word of caution... check the script to make sure it is not referencing specifically the Production server so there are no conflicts on your QA server.

3.
After I executed my 2 scripts to recreate the publication and subscription stored procedures on the QA server, I found these 2 stored procedure were dependent on 2 other stored procedures:

error#1
The module 'usp_ReplicationCreatePublication_publicationname' depends on the missing object 'dbo.usp_ReplicationChangeJobOwner'. The module will still be created; however, it cannot run successfully until the object exists.

error#2
Msg 2812, Level 16, State 62, Line 4
Could not find stored procedure 'dbo.usp_Replication_Drop'.


So I also copied those stored procedures from Production to my QA server.

Now I have to test and see if adding back those 4 stored procedures fixed my issue by running the script above in step 1 again to generate a publication and new subscription.

Sigh... this still did not solve the issue.

When I launch the replication monitor in QA  I still receive this message under the replication monitor > Distributor To Subscriber History:

The concurrent snapshot for publication is not available because it has not been fully generated or the Log reader agent is not running to activate it.

4.
The best thing to do in this scenario is restore the latest copy of your replication database from Production to QA and add back permissions and replication (with publication and subscription).

Note: If your replication database is part of an Availability group or mirroring, you will have to remove it from the availability group first before you can restore the database to QA.

If you have any further questions, please post below.

Thank you and Happy reading,

-marshé hutchinson
#learnSQLwithME
Labels:

Comments

Post a Comment

Popular posts from this blog

event id 101 task start failed - task scheduler event id 101 launch failure

Hello again. This post is related to automating SQL server tasks with Task Scheduler. In this example I was tasked with exporting SQL server agent jobs twice a month. To achieve this, I setup a task scheduler task that ran a PowerShell script that: establishes a local connection to the SQL server. cleans the file before writing to the .sql file to avoid adding on (appending) results on subsequent runs of the task scheduler task. when a connection is established, export the SQL agent jobs on the server to a .sql file on a remote server. sends a confirmation email via the SQL server database mail profile that the SQL agent jobs were exported to the specified remote server path. That was a mouthful. Now that you know my task scheduler task is calling a PowerShell script, let's get back to why it is failing.  The good news is this error is not related to the script. The error launch failure means the task could not even run. This is most likely due to a permissi...
Post a Comment
Read more

ERROR: must be owner of database databaseName - postgres error

Hi everyone! Today's post is about Postgres SQL. In my environment we are using Postgres SQL as one option for the backend of AWS (Amazon Web Services). That's right. We also have another option - MySQL. This post however will focus on the Postgres SQL error: "ERROR: must be owner of database databaseName" Scenario : I encountered this error when I was trying to drop a database from an AWS cluster. Amazon allows you to group databases inside of containers. These containers still have the same logic as SQL schemas which hold our database in SQL server. You can read more about AWS clusters here . Solution : This is very easy. It's in the error. All I have to do is make myself the owner of the database so I can delete the database. I. If your user account does not already have read/write privileges, then you will need to sign in to the Postgres cluster with an admin account so you can grant read/write access to your user account. II. If your ...
Post a Comment
Read more

How to export SQL agent jobs from your SQL Server instance

Hi everyone! As a database administrator, you always need a copy of your data and data processes for: migrating servers disaster recovery backup procedures/best practices This post covers a simple Powershell script. The script is to take a backup of all the SQL agent jobs on your SQL server instance. If you ever needed to recreate all the jobs on another server, all you would have to do is execute the SQL script. I. In SSMS (SQL Server Management Studio), create an empty .SQL file and save it with this naming convention: I.e. SqlAgentJobs_PROD01.sql } This file will represent all the SQL agent jobs on the primary production SQL server. II. Copy the "SqlAgentJobs_PROD01.sql" file from above to a network share. III. Run the Powershell script below in  Powershell ISE as administrator: ##migrating jobs from one server to another with the replace command $SqlConnection = New-Object System.Data.SqlClient.SqlConnection $SqlConnection.ConnectionStrin...
Post a Comment
Read more