1

I have to migrate the Sybase Database from 11.5 version to 15. I would like to know few things mentioned below - i) What are the neccessary steps I need to follow in this migration. ii) What are the changes required for table, Stored Proc, etc., for this change to work as per the current execution? iii) Any bottle necks if exist for this transiton

Note :- We have a Unix server that executes these procs with the help of Perl Script?

Thanks Utkarsh

2
  • 1
    This is not the right site for that kind of question. Maybe serverfault.com ?
    – ikegami
    Feb 26, 2013 at 12:19
  • Are you installing the new database on new hardware, or are you transitioning on the existing hardware. Feb 26, 2013 at 18:13

1 Answer 1

1

Sybase ASE does not support a direct upgrade from version 11.5 to version 15, so you will have to export your database from the ASE 11.5, and import it to ASE 15.

From the $SYBASE/$SYBASE_ASE/scripts/ directory in your ASE 15 installation, run the installupgrade file into your ASE 11.5 installation, to install some utility stored procedures to assist with the migration.

isql -Usa -Ppassword -SOLD_SERVER_NAME -iinstallupgrade

Now login to each database, and run the sp_checkreswords command to make sure none of your DDL is using words reserved for the system. If reserved words are found, you will need to alter the code, and remove/change the reserved words.

Use the ddlgen utility to export your full database structure (Tables, indexes, stored procedures, defaults, user defined datatypes, etc.)

At this time, you may want to review the code generated by ddlgen, to make sure it makes sense in your new environment. You may want to make changes to device locations, device names and device sizes. For example, ASE versions prior to 12.5 had a device size max of 2 Gb, so if your database was 10 Gb, you were forced to have 5 devices. ASE 15 will allow device sizes of up to 1 Tb (on a server with a 2k page size), so you would only need one device to store the entire database.

You may also want to seperate the index and trigger creation scripts from the rest of the DDL, to allow you to run those independantly. This comes in handy when you import data into the new server.

Once you are satisfied with the scripts, you can run them against the new server, and it will create all of your database structure on the new server.

At this point it's a matter of transitioning the database, using the bcp utility, you will need to export your data on a Table by Table basis. Depending on the size of your databases, and the number of tables in each database, this can take a while. I would recommend trying the -n (native) version of bcp instead of the -c (character) if it's possible.

To import the data into your new database, you will also want to use the bcp utility, but you will likely want to make sure that your databases do not have triggers or indexes as this will enable the 'unlogged' version of bcp to run, allowing it to run faster and not fill the transaction log as it runs. If you can not run the unlogged bcp then you will want to make sure you have the appropriate database options ('truncate log on checkpoint', 'abort tran on log full') and set the batch size for your import to a reasonable value.

At this point, you can create in indexes and triggers (if they haven't been created up to this point), and start testing the server.

I would also recommend reviewing Sybase's Migration Guide, as it will likely go more in depth, and cover things I may have forgotten/skipped over. A lot of the details will depend on the migration environement, so planning and preparation are key.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.