Re-running the Cluster Edition Upgrade

Failures while upgrading a server installation fall into one of two categories: failure to upgrade an individual database, or failure to complete configuration changes after all databases have been upgraded.

If an individual database fails to upgrade, try upgrade manually. Begin by correcting the problem that caused the failure. Output from the upgrade utility should identify the problem. The most common cause of failure is running out of some resource: space (either data or log), locks, auxiliary scan descriptors. You can add space to the database using the alter database command. You may be able to correct other resource failures by changing the server’s configuration via the sp_configure stored procedure.
Having set this trace flag, user “sa” can now use the offline database and make the necessary changes to correct the upgrade failure.
If an upgrade failure leaves a database offline, and the failure can be corrected only by making data changes in the database, you can gain access to the failed database by using isql or a similar program to connect to the affected server as user “sa” and issuing:
```
 dbcc traceon(990)
```
Note: This trace flag grants access only to user “sa”. It is not sufficient to use an account having “sa_role”. If you have disabled the “sa” login, you must reenable it to get access using this method.
To restart a failed upgrade::
```
 online database <failed_db_name>
```
The server restarts that database’s upgrade from the point of failure.
If the failure occurs after all databases have been upgraded or if a failure somehow causes the upgrade utility to stop responding, you can re-run the utility manually. First diagnose and correct the failure, then run the upgrade utility:
```
 $SYBASE/$SYBASE_ASE/upgrade/upgrade
```
When restarted in this way, the upgrade process says it is “verifying” the upgrade rather than “starting” it, but it makes all the same checks as for the original upgrade.
To verify that a database has upgraded successfully, you can check any database’s upgrade status using the online database command. If any upgrade is required for a database, this command performs it. You may also use a procedure such as this to check all databases at a given installation:
```
declare @dbname varchar(255) 
select @dbname = min(name) 
from master..sysdatabases 
while @dbname is not null 
begin 
online database @dbname 
select @dbname = min(name) 
from master..sysdatabases 
where name > @dbname 
end
```
Note: There are certain upgrade failures from which the server cannot recover. For example, attempts to upgrade system tables to version 15.0 format are quite sensitive to failures at certain points during the required changes. If you encounter such a failure, restore the failed database from backup. To prevent the upgrade from failing again, correct the problem that caused the original failure before issuing the online database command for that database. These catastrophic failures are nearly always caused by running out of resources, as described above, which then causes a failure to undo the aborted transaction.