• VastSQL - Monday, February 11, 2019 5:17 AM

    Eirikur Eiriksson - Tuesday, February 5, 2019 7:25 AM

    Jeff Moden - Tuesday, February 5, 2019 7:02 AM

    VastSQL - Tuesday, February 5, 2019 12:19 AM

    barsuk - Monday, February 4, 2019 11:21 PM

    Was backup completed? you need to ensure that backup is completed before moving to the Robocopy step.

    The copy job runs every 15 mins and some backup takes more than hour to complete and that was the issue

    If you have compressed backups available, you should use those.  They really do make a performance difference.  You might also want to check out some of the lesser known settings for BACKUP, like the number of buffers used, etc.  They can also make a pretty decent difference.

    I would also consider avoiding the method of doing a backup to one spot and then using RoboCopy or anything else to copy from there to their final resting place.  Consider backing up directly to the final place, especially if the drives being used for the current backups is on the same SAN/drives as the databases themselves.

    Further on Jeff's good points, consider striping the backups if you have multiple IO paths.
    😎

    Thanks Erikku, Now all backup to one back drive

    Hopefully that location is on a different physical box than the database files themselves.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)