How it Works

The service will query for all databases in a restoring or standby state on the destination server, excluding any databases with SIMPLE recovery model where log backups don't apply. The date of the last backup restored is also retrieved. It will loop over each database in parallel. The degree of parallelism is configurable with the MaxThreads parameter.

For each database, it will query for any new log backup files in the UNC path or Azure blob container. The {DatabaseName} token in the LogFilePath parameter will be replaced with the name of the database. This provides flexibility to use different folder structures. The date of the last backup restored is used to get a list of new log files to be restored. An OffsetMins parameter can be used to handle timezone differences if needed.

The MaxProcessingTimeMins parameter is used to limit the amount of time that will be spent processing an individual database. If this is set to 60, the service will move on to the next database after 60 minutes of processing log restores for a single database. This limits the impact that a single database can have on log shipping for the whole server. If a database reaches the max processing time it will pick up where it left off on the next iteration.

Once the service has looped through all the databases, it will start the next iteration after a delay (DelayBetweenIterationsMs)