I have a secondary server in a log shipping scenario on an Azure SQL Server 2014 Enterprise VM where the log shipping restore job stalls at the step where is disconnects users from the replica database in preparation to restore logs.  This occurs frequently especially after disabling the job for an extended period of time.  There are no errors in the log or from the job and eventually the job begins to restore logs and restores every log available except the last log in the shared folder.  I want to know why the job stalls for sometimes hours before it begins to restore logs.

"While restoring it disconnets users from replica database" It eplains that you are secondary is stand by and you are using it for read only purpose.

Log restore job requires Exclussive access, So it will disconnect all users and starts the restore job. After finishing restore job it will allow connections.

The reason for your job to stall could be

1) it takes some time to get exclusive access

2) YOur transaction log is too big so it take some time to restore.

3) depends on how often you are running the restore job.

4) if you stop the logshipping and resumes all pending logs will be restored using log sequence number.

None of those things are occurring.  The logs are of reasonable size (100 MB) and when I check to see what's connected to the replica there are no active or otherwise connections.  The restore job runs every 10 minutes but of course since it is running for 50 minutes sometimes it gets behind schedule.  This doesn't seem like a reasonable explanation for what I'm experiencing.  It's stuck on disconnecting users but not because there are users to disconnect.  There is something else going on that has the executable hung.

1. What is the size of transaction log (LDF) file?
2. How many rows do you see when you run DBCC LOGINFO command in the same database on primary server.
3. When restore is running, have you checked the percent_complete column in sys.dm_exec_requests