Recovering from a Failed Upgrade

Upgrade issues may be due to a failure to upgrade an individual database, or a failure to complete configuration changes after all databases have been upgraded.

Use the output from the upgrade utility to correct the problem that caused the failure.

If the upgrade failed because the process ran out of some resource, such as data or log space, locks, or auxiliary scan descriptors, add space to the database using the alter database command.
You may also correct other resource failures by changing the server’s configuration using the sp_configure stored procedure.
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 this command:
```
dbcc traceon(990)
```
Having set this trace flag, user "sa" can now use the offline database and make the necessary changes to correct the upgrade failure.

Note: This trace flag grants access only to user "sa"; "sa_role" does not work. If you have disabled the "sa" login, reenable it to get access using this method.
To restart a server that has not successfully upgraded, use:
```
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 fail, manually re-run the utility. After you diagnose and correct the failure, 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
```
Reinstall system stored procedures using the scripts from the new version:
```
isql -Usa -Ppassword -i $SYBASE/$SYBASE_ASE/scripts/installmaster
```
Note: When a server fails during an upgrade process, it attempts to upgrade the databases when it restarts. When the installation is fully recovered, re-run the upgrade utility to ensure that all postupgrade configuration work is done. Then reinstall the system stored procedures.
During the upgrade process, the log may become too full due to recorded catalog changes. If so, log in to the new server using isql, and issue:
```
isql> dump tran dbname with truncate_only
```
1. If truncate_only indicates that it cannot truncate the log, retry the command as no_log instead.
2. If this does not truncate the log successfully, use the alter database command to extend the database as explained below.
In some cases, preupgrade space estimations are insufficient for the data copy phase of upgrade. You see a message that there is insufficient space in the system segment for the upgrade. When this happens, the upgrade process stops responding, waiting for space to be provided. To increase the size of the database, log in to the new server using isql, and use alter database:
```
isql> alter database dbname on device_name = "2m"
```
alter database allows you to specify the size to alter the database with the unit specifier "m", or "M".

Note: There are certain upgrade failures from which the server cannot recover. For example, attempts to upgrade system tables to version 15.x 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.