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, you can retry that 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. 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)
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 failed 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/upgrad
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
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.
