So the job must run on its original schedule and also if 1st of month is Sunday.

So you don’t want to change out the existing schedule or make changes to...

Whenever anyone talks about merge, I always send them to this link first and if they still want to use it, then OK

Merge has a number of issues which are...

There is no command or check for this I'm afraid, you will just have to hope that your application teams have configured all of the connection strings to point to...

OK, that doesn't answer any of the questions above.

If you don't know what caused the log to grow so much, then you need to enable monitoring into the growth events.

Once...

Not possible, only one log reader is created per published database.

What is the problem you are trying to overcome?

You should just be able to simply change the name using an ALTER LOGIN command.

The original "old" name should still be present in the views as your getting duplicate errors,...

Firstly do you know what caused the log file to grow that large?

Without knowing the cause, there is a great possibility that the log will once again reach the size...

Have you been able to verify that when this is happening the UserA session is indeed in workload group 1?

Do you have any monitoring of sys.dm_exec_sessions when this happens to...

The same is true for the following

NT SERVICE\CluSvc

NT SERVICE\HealthService

NT SERVICE\SQLTelemetry

NT SERVICE\SQLWriter

NT SERVICE\Winmgmt

If you have removed any of these I would add them back with the correct permissions they had

Yes you will need a different solution.

Your options are

1 - Logshiping 2008R2 to 2019

2 - upgrade your 2008R2 to 2012/2014/2016/2017, then again to 2019, then use merge replication to merge...

OK so for that you would need 2 machines in AWS.

One on 2019 for the distributor, one of 2008R2 for the subscriber.

SQL2008Rs Publisher -> SQL2019 Distributor -> SQL2008R2 Subscriber

If you...

So for that situation I would be looking at use logshipping, it is backup and restore which will suffice the needs and is a supported upgrade path of 2008R2 to...

You should not be removing the NT SERVICE\MSSQLSERVER, NT SERVICE\SQLSERVERAGENT, NT SERVICE\MSSQL$<InstanceName> or NT SERVICE\SQLAGENT$<InstanceName> accounts under any normal circumstances.

These are used as proxy/virtual accounts for the actual service accounts...

This is not possible, replication only works where the publisher and subscriber are within specific versions of each other.

Merge replication, where the publisher is SQL 2008 / SQL 2008 R2...

No need to do a DAG, for this.

You can simply add 3 new nodes to your existing cluster, Windows 2019, SQL2019.

Once done add them as replicas, sync all the data,...