Re-running the 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.

First correct 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. Other resource failures may be correctable by changing the server’s configuration via the sp_configure stored procedure.
If an upgrade failure leaves a database offline, and the failure can only be corrected 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 this command:
```
 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 re-enable it to get access using this method.

Having set this trace flag, user “sa” can now use the offline database and make the necessary changes to correct the upgrade failure.
To restart a server that has failed to upgrade, use the online database command:
```
 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 crash, 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, 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.x 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.