locked
Log Shipping Copy Job Failure RRS feed

  • Question

  • I'm getting an error with Log Shipping.

    SQL Server 2012

    The Primary creates the backups.  The Secondary Copy Job fails on .trn files with this error:

    Error: An unexpected network error occurred.  (mscorlib)

    Permissions on the Secondary folders with the service account have been verified to be correct.  Both Primary and Secondary use the same service account.  Copying files manually thru windows works from primary to secondary.  Also it seems that a .wrk is created on the first run of the job on the secondary, but after that, no new .trn files are copied over.

    Network has been checked and nothing wrong there.

    Any solutions to this problem?



    • Edited by Sundeev Thursday, June 30, 2016 2:41 PM
    Thursday, June 30, 2016 2:40 PM

Answers

  • Hi Sundeev,
     
    Could you please post the full error message to us for analysis? You can get this error message by right-clicking 'copy job' and selecting 'view history'. Besides, we need to know what is your agent service account.
     
    Based on the above error message and our experience, this issue may occurs in the following two scenarios besides the scenario mentioned by Uri.
     
    1.Accumulating a lot of '.trn' file for 'copy job' causes timeout, which will throw such network error. In this case, you can select an appropriate time interval of backup job based on recovery point objective, recovery time objective and network speed, after that, configure the copy job to run one or two minutes behind the backup job. For more information, you can review this article: http://searchsqlserver.techtarget.com/tip/Log-shipping-Four-tips-to-maintain-RTO-and-RPO-with-SQL-Server
     
    2.Is your secondary server involved in different log shipping models ? If so, you would have several copy jobs at the same time and large files are copied across the same network line, which can easily cause network error. Make sure that you schedule these copy jobs to run at different time in such scenario.
     
    Regards,
    Teige
    Friday, July 1, 2016 9:42 AM

All replies

  • >>>Copying files manually thru windows works from primary to secondary. 

    Copy Job  task is running under SQL Agent account., make sure that it has an appropriate permissions to copy the files over.


    Best Regards,Uri Dimant SQL Server MVP, http://sqlblog.com/blogs/uri_dimant/

    MS SQL optimization: MS SQL Development and Optimization
    MS SQL Consulting: Large scale of database and data cleansing
    Remote DBA Services: Improves MS SQL Database Performance
    SQL Server Integration Services: Business Intelligence

    Friday, July 1, 2016 3:41 AM
  • Hi Sundeev,
     
    Could you please post the full error message to us for analysis? You can get this error message by right-clicking 'copy job' and selecting 'view history'. Besides, we need to know what is your agent service account.
     
    Based on the above error message and our experience, this issue may occurs in the following two scenarios besides the scenario mentioned by Uri.
     
    1.Accumulating a lot of '.trn' file for 'copy job' causes timeout, which will throw such network error. In this case, you can select an appropriate time interval of backup job based on recovery point objective, recovery time objective and network speed, after that, configure the copy job to run one or two minutes behind the backup job. For more information, you can review this article: http://searchsqlserver.techtarget.com/tip/Log-shipping-Four-tips-to-maintain-RTO-and-RPO-with-SQL-Server
     
    2.Is your secondary server involved in different log shipping models ? If so, you would have several copy jobs at the same time and large files are copied across the same network line, which can easily cause network error. Make sure that you schedule these copy jobs to run at different time in such scenario.
     
    Regards,
    Teige
    Friday, July 1, 2016 9:42 AM
  • It appears to me a permission issue. Can you post the error here. 

    Regards,

    Rama

    Tuesday, July 5, 2016 9:09 PM