Recovering from database corruption during switch version to 8.5(1) SU3

To address this issue,  changes have been in the switch version code in 8.5(1) SU3 to detect this corruption during switch version and
to aid in easy recovery.
Traditionally during switch version, a database backup is taken as the first step in the database switch version script.
The scenario where the database gets corrupted during switch version is as follows :
1. Customer initiates first switch version. A good database backup is taken in the db switch version script. Customer subsequently restarts the box before switch version completes.
2. At this point the server comes up with a corrupt database due to the restart in step 1.
3. Customer initiates second switch version. A new database backup is taken in the db switch version script which overwrites the good backup taken in Step 1 and rules out any chance of recovery using the good database backup.

As part of the new changes introduced in 8.5(1) SU3, the CCX database is first checked for corruption before a database backup is taken in the db
switch version script. If the database is found corrupted, the switch version is aborted without taking a new backup and hence the original good
database backup taken in Step 1 is protected from being overwritten..

Cisco Unified CCX DB appears to be corrupt.
Please use the CLI command "utils uccx switch-version [db-check | db-recover]" to recover the CCX DB before retrying the switch version
If this CLI command is not available in your release of CCX software, please contact Cisco Technical Assistance. for this problem...

Note: The following message in the install logs can be ignored when upgrading from lower versions to 8.5(1) SU3.
/partB//opt/cisco/uccx/bin/uccx_db_l2_upgrade_partA.sh: line 220: /base_scripts/xml_writer.sh: No such file or directory

For recovery from this issue when it happens when upgrading from lower releases to 8.5(1) SU3 or later, a recovery script (tac_sv_recover_db.sh) is being provided to TAC.

(Script Location: http://zed.cisco.com/confluence/display/CRSSU/List+of+ETs+given+to+customers)

It can be used only in the following specific scenario :
-Switch version failure happened when migrating to 8.5(1) SU3 or later
-Install logs indicate that switch version failed due to detection of database corruption.
-The last switch version attempt was not successful.
-The script must be run during a maintenance window without no call activity in the system.

The script will display the timestamp of the database backup that was taken prior to Step 1 and offer to restore this backup.

Once the script has completed the recovery of the database, a new switch version can be attempted.

If this recovery is performed immediately upon detection of the database corruption, there will be no loss of data.

If the system goes operational without immediate recovery and subsequently this script is used to recover from the database backup taken during switch version, then any changes done on the database after the time of the backup will be lost.