I have a test suite result DB that a few users run some heavy reporting queries against which conflict with the actual creation of test suite run results so I figured I would configure a read only version using log shipping and thus offload the reporting to that DB. Did this with T-sql many years ago in earlier version but am now running 2014. So I have used the wizard to set everything up, smooth process however I get one error all the time and another a bit intermittently. To briefly explain the configuration; the secondary DB is on the same host machine and SQL Server instance as the primary and I setup the restore with STANDBY mode and to disconnect users when restoring. At first I didn't have a copy job and tried to backup/restore from the same directory. I ran into the same issues I keep having, even after separating the backup/restore folders. As for the schedules of backup/copy/restore they initially ran the same minute on a 15 minute interval. The file retention is the default (120 minutes). The first issue I get all the time is the following message in the job log:Message2016-04-12 07:55:01.12 *** Error: An error occurred restoring the database access mode.(Microsoft.SqlServer.Management.LogShipping) ***2016-04-12 07:55:01.12 *** Error: Alter failed for Database 'FrostingReadonly'. (Microsoft.SqlServer.Smo) ***2016-04-12 07:55:01.12 *** Error: An exception occurred while executing a Transact-SQL statement or batch.(Microsoft.SqlServer.ConnectionInfo) ***2016-04-12 07:55:01.12 *** Error: Failed to update database "FrostingReadonly" because the database is read-only.The above is [b]always [/b]in the log, even if the actual restore step [b]succeeds [/b]:w00t:.What is the logshipping .exe trying to alter? I do believe I caught it in Profiler and its trying to set it to SINGLE USER mode. I was also suspecting that the reporting application used was constantly refreshing connection to the DB, I did get a higher success rate when I added a T-SQL step prior to restore that just KILLed every session to the secondary DB.Some mornings I am greeting by many failed restore jobs and this is additionally in the log:2016-04-12 07:55:01.14 *** Error: The file 'E:\Logshipping\restorefrom\Frosting_20160411223000.trn' is too recent to apply to the secondary database 'FrostingReadonly'.(Microsoft.SqlServer.Management.LogShipping) ***2016-04-12 07:55:01.14 *** Error: The log in this backup set begins at LSN 1335000000245100001, which is too recent to apply to the database. An earlier log backup that includes LSN 1206000012058200001 can be restored.So I understand that I have an broken sequence and there is a tlog that hasn't been restored but I don't know what causes it. I am suspecting the tlog file was actually deleted before it was restored? I would be surprised if this is the case, I mean the "delete" of tlogs should be based not only on age of file but also the LSN of the tlog file and the secondary database. If it hasn't been restored then don't delete it. I assumed this would be the functionality. Is this a common issue that can arise for certain job schedule/file retention/restore delay configurations? Any help would be greatly appreciated!Timo
↧