Forum Discussion

GertjanA's avatar
GertjanA
Moderator
11 years ago

Upgrade from DA90SP4 to DA10SP4CHF1 breaks SQL replication

FYI.

We had the below issue occur twice in different environments. This might or might not be happening to you, but if it does, you know now...

Starting situation:

Windows 2008 R2 x64 standard edition (EV and SQL server). SQL 2008R2SP2 standard edition, with log-shipping as DR solution (replication). Enterprise Vault 9.0SP4, and DA9SP4

Upgrade DA9SP4 to DA10SP4 - upgrade config-database, upgrade customer-db, verify evbaadmin is ok, verify DA10SP4 client connects ok.

Apply CHF1 for DA10SP4 - upgrade etc. Verify DA10SP4CHF1 client connects ok.

Logoff.

Monitor SQL logshipping. You might see error:

The log shipping primary database PROD SQL SERVER\INSTANCE.xxxEVDACM has backup threshold of 60 minutes and has not performed a backup log operation for 61 minutes. Check agent log and logshipping monitor information.

Case 05907358

 

  • Thank you, Gertjan, for the comments.  Our current upgrade instructions for CA and DA include a paragraph about stopping SQL db mirroring as it can cause the db upgrades to fail.  We even reference TECH64763 to provide information related to the SQL db mirroring issue.

    We are talking about modifiying that section in the upgrade instructions to include stopping the log shipping if configured.  Such a change could be as soon as in the documentation starting with the EV/CA/DA 11.0.0 release.

     

     

  • Hello Ken,

    Thanks for answering. I had a case opened on this also. 06239019

    Main reason for the case is that I understand the reason, but there is no mentioning of this in the upgrade-instructions nor the readme. It is either fix it, or put it in the notes somewhere. As you state 'we recommend', it would be nice to have that in the readme/upgrade instructions.

    But, I've taken a mental note.

    Thanks for answering

  • As a standard practice, we recommend stopping all SQL db replication during upgrades as the replication activities can (and has been known to) cause issues during the upgrade, either with the upgrade itself or with the replication.  This is likely due to the fact that we put all upgrade transactions into the log, thn commit when all of the needed transactions are there.  This can (and does) cause the log to change and grow very quickly, which may cause some replication processes to fail with overlimit errors.