Home

	Expand Search

Installation Guide Adaptive Server Enterprise for IBM RISC System/6000 AIX

Chapter 8 Upgrading Sybase Servers

Overview of the upgrade process

Overview of the upgrade process

You can upgrade to Adaptive Server 12.5 from any of these versions:

• 11.5.x

• 11.9.x

For a server installation older than version 11.5.x, Sybase recommends that you upgrade to one of the versions above, then upgrade to version 12.5.

You can upgrade Adaptive Server from a 32-bit version to a 64-bit Version, but you cannot move from a 64-bit version to a 32-bit version. Likewise, you can only upgrade from an earlier version of Adaptive Server to a more recent version.

Only upgrades from 2K pages to 2K pages are supported. Changing the server schema from a 2K page to nK page size is a database migration, not an upgrade.

For information about migrating your database schema from a 2K page to a 4K, 8K, or 16K page, see "Migrating from 32-bit to 64-bit versions".

Upgrading Adaptive Server consists of four processes:

• Installing the new server into it own installation directory.

  You must have both the old server and the new server to perform an upgrade.

• Performing the pre-upgrade checks on the old server using the preupgrade utility, from the new server installation.

• If necessary, fixing any problems that pre-upgrade process reports.

• Running the upgrade utility from the new server against the databases to update the underlying schema so that their structures are correct for the new server.

The preupgrade and upgrade utilities are internally called by the sqlupgrade utility.

Each new version of Adaptive Server contains different features that introduce new parameters, commands, reserved words, and so on. For this reason, the new Adaptive Server to which you are upgrading is responsible for preparing the old server for the upgrade.

The new server provides a utility, sqlupgrade, that runs various checks, such as reserved word checks, to determine how much space you must add to the old server to successfully upgrade the old server to the new.

As part of the pre-upgrade tasks, sqlupgrade scans all databases and catalogs and determines how much free space is required for each to upgrade successfully. Essentially, sqlupgrade searches for the largest catalog, then calculates the required free space by doubling the size of the largest catalog, and adding approximately 10 percent for logging the upgrade changes for each catalog.

During the pre-upgrade process, sqlupgrade returns informational messages as it checks the old server. You must fix all reported problems, and run sqlupgrade cleanly before beginning the upgrade process. Once the old server is eligible for upgrade, sqlupgrade shuts down the old server, starts the new server against the existing databases, and begins the upgrade process.

System catalog changes during upgrade

Adaptive Server 12.5 introduces support for wider columns, more columns, a larger number of user logins, and multiple logical page sizes. To support these extended limits, there have been several changes to existing system catalogs. See What's New in Sybase Adaptive Server 12.5? for a complete list of catalogs that are affected by the relaxed server limits.

Warning!

As system catalogs are copied during the upgrade process, the size of these catalogs might cause the upgrade step to take a long time. Do not attempt to abort the process using Ctrl-C, as this can cause unknown corruptions in the catalogs.

Any user-written stored procedures or applications that query system catalogs to obtain information must be changed to use the new datatypes for various columns. For instance, existing stored procedures and tools to regenerate table schema that look up information in syscolumns, will continue to work immediately following the upgrade. However, if new tables are created using the new limits, existing stored procedures are unable to retrieve the information from various catalogs.

For example, if a new table is created in with 300 columns, and an existing stored procedure declares a tinyint datatype to retrieve the column ID from syscolumns, this procedure cannot return the right information for this table because the table has more than 255 columns.

Similarly, other tools and procedures that access catalogs such as sysusers, syslogins, sysprotects, sysconstraints, and so on, must be updated to reflect the new column definitions. In general, all local variables in user applications and procedures need to be re-defined to match the datatype of the columns in system catalogs that are modified during the upgrade.

All Sybase stored procedures have been upgraded to reflect this change.