locked
Backup BizTalk Server (BizTalkMgmtDb) job failed after upgrade from BizTalk 2013 R2 to BizTalk 2016 RRS feed

  • Question

  • Hello, after successful upgrade of BizTalk 2013 R2 to BizTalk 2016 "default" Backup BizTalk Server (BizTalkMgmtDb) job failed with error: Could not find stored procedure 'SSODB.dbo.sp_CleanUpMarkLog' this SP is called during last step #4 Clear Backup History so not so "big deal" because backup files are created successfully but in "real environment" SQL job failed = create error in app log = create alert in monitoring tool etc. 

    Solution: script this SP from already installed environment of 2016 version and run it against upgraded environment, after that backup job is running well.

    I checked SSO db before upgrade and this SP doesn't exists. So it seems that SSO db is not including during upgrade process as is also visible

    Anybody faced same issue? Thanks for reply.

    Note: All tests made on one Azure VM - Windows Server 2016, SQL Server 2014 DEV, BizTalk 2013 R3 DEV + BizTalk 2016 DEV, no SQL upgrade to 2016 DEV


    Monday, March 5, 2018 1:08 PM

Answers

  • For future reference, upgrading a BizTalk Group is not the procedure I would recommend.

    The reason this happened is at some point, Log Shipping was setup and someone ran Backup_Setup_All_Procs.sql on the SSODB and added it to the Other Databases to be backed up.

    So, correct way to address this is to run Backup_Setup_All_Procs.sql again on SSOSB.

    Or, unconfigure Log Shipping.

    • Marked as answer by Vaclav Spacek Wednesday, March 7, 2018 9:09 AM
    Monday, March 5, 2018 1:31 PM
    Moderator

All replies

  • For future reference, upgrading a BizTalk Group is not the procedure I would recommend.

    The reason this happened is at some point, Log Shipping was setup and someone ran Backup_Setup_All_Procs.sql on the SSODB and added it to the Other Databases to be backed up.

    So, correct way to address this is to run Backup_Setup_All_Procs.sql again on SSOSB.

    Or, unconfigure Log Shipping.

    • Marked as answer by Vaclav Spacek Wednesday, March 7, 2018 9:09 AM
    Monday, March 5, 2018 1:31 PM
    Moderator
  • Hi, thanks for reply I agree with that is better to create new machines instead of upgrade. In my test scenario wasn't set Log Shipping, it was simple installation and configuration of SQL 2014 with BizTalk 2013 R2 and later upgrade to BizTalk 2016 nothing else.
    Monday, March 5, 2018 1:52 PM
  • To be clear, at some point, someone did something with Log Shipping.  That is the only way this error could have occurred.

    Monday, March 5, 2018 4:16 PM
    Moderator
  • To be clear :) that machine is used only by me and I'm sure that I haven't used Log Shipping on that machine.
    Tuesday, March 6, 2018 7:18 AM
  • Either way, you should run the Log Shipping script to create the SP instead of copying it from another since that's proscribed way or creating it.
    Tuesday, March 6, 2018 2:28 PM
    Moderator
  • I'm still not following run Log Shipping script in case I don't need Log Shipping but thanks for pointing me to Backup_Setup_All_Procs.sql again on SSOSB, this works and is better than copy missing SP from another machine. 
    Wednesday, March 7, 2018 9:08 AM