Idea ID: 2877663

Make the Schema Upgrade more fault tolerant

Status: Under Consideration

It's a fair ask, and I put this under consideration to evaluate the effectiveness of a change from a code vs best practices perspective. Once I understand the cost of this change, I will change the status accordingly.

See status update history

We're testing the upgrade from 10.0.401.1033 to 23.4, and the schema upgrade has failed 2 out of 3 times. We're requesting that OpenText put more diligence into the upgrade process and make it more fault tolerant. 

We want to deploy in a weekend, and a failure in the 8-hour long upgrade makes that nearly impossible. It requires us to restore the entire database, which takes several hours itself.

The updates should be against a table at a time, so if it could direct us to restore an individual table and pick up where it left off, that would be faster. 

Tags:

Parents
  •  ,

    you mention the 8 hour long upgrade, it may be worth while investigating upgrading using CTAS for your upgrade.   Video: Content Manager CTAS Schema Upgrade Options 

    In addition to this, often when the schema upgrade fails it has to do with the following:
    1. running out of space/autogrowth issues. 

    2. 'playing' with the window which performs the upgrade. 

    3. Database settings that automatically kill transactions that a long-running.

    I have not had an issue with the upgrade failing since ~2016 so I am unsure what exactly the issue is.

    I do however love the concept of being able to continue an upgrade from where it failed and/or rollback a failed upgrade, the biggest issue with this is that there may be data loss due to the failed transaction but that could be fixed by restoring a table from a backup, but all this capability will likely extend the duration of the backup.

Comment
  •  ,

    you mention the 8 hour long upgrade, it may be worth while investigating upgrading using CTAS for your upgrade.   Video: Content Manager CTAS Schema Upgrade Options 

    In addition to this, often when the schema upgrade fails it has to do with the following:
    1. running out of space/autogrowth issues. 

    2. 'playing' with the window which performs the upgrade. 

    3. Database settings that automatically kill transactions that a long-running.

    I have not had an issue with the upgrade failing since ~2016 so I am unsure what exactly the issue is.

    I do however love the concept of being able to continue an upgrade from where it failed and/or rollback a failed upgrade, the biggest issue with this is that there may be data loss due to the failed transaction but that could be fixed by restoring a table from a backup, but all this capability will likely extend the duration of the backup.

Children