Results 1 to 3 of 3
  1. #1
    Join Date
    Sep 2006

    Unanswered: migrating from Sybase ASE on Solaris 8 to Sybase ASE 12.5.3 Solaris 10

    Hi, I am Oracle DBA new to Sybase ASE. We are in process of migrating from Sybase ASE on Solaris 8 to Sybase ASE 12.5.3 Solaris 10. Please advise on an overview of steps needed if we opt for Install/Load approach.

    Thanks in advance!

  2. #2
    Join Date
    Aug 2002
    Madrid, Spain
    In summary, migrating with the dump/load approach has these tasks:
    - Install the new software in a different $SYBASE file system
    - Create every app database with the same size and the same
    "segment layout". For instance, if a database has some data
    devices totalling 4 GB, then a 1 GB log device, then data devices
    for 8 GB, your new database must have the devices that way.
    Get the order of the devices by listing master..sysusages in lstart
    sequence, for a particular database.
    - Redo configuration. Some config parms have changed, so you
    shall find the equivalents. For instance, the default data
    cache size must be configured with sp_cacheconfig, as it no
    longer gets the remaining memory declared by the old parm
    "total memory". Another example: "procedure cache percent"
    must be translated into "procedure cache size" (in pages).
    - Prepare the copy of the logins. syslogins can be copied by
    bcp, if you take care of a couple of details: exclude suids 1 and 2
    (accept those existing in the new server) and handle the
    small changes in syslogins columns. We created a temp_logins
    table in tempdb with the 12.0 layout, bcp-in syslogins into it
    and copied into syslogins with
    insert into syslogins select *, NULL from tempdb..temp_logins
    where suid not in (1,2)
    This requires setting 'allow updates' to 1 for a moment.
    - The copy of syslogins doesn't copy all. Some login-related
    info as "max failed_logins" is stored in sysattributes, instead.
    We prefered to re-apply these kind of logins attributes by
    repeating the sp_modifylogin command, instead of playing
    with risky copies of some rows of the sysattributes table.
    - Any other cofiguration info stored in the master database
    must be redo: roles, database cache bindings, remote
    server definitions, etc.
    - Every stored procedure created in sybsystemprocs by you
    must be copied. You can use defncopy.
    - The obvious task: dump every app database from the old
    server, and load it into the new.
    - If you have stored procs in your app databases, test if
    they work properly. We needed to recreate them, using
    - If you can afford the duration and CPU cost, update
    statistics for all your tables. Use your weekly or monthly
    script, if you have one.

    In our experience, every migration has two or three nasty
    surprises: new bugs, some queries get much worse performance,
    etc. To prevent hitting them on the Production env, I strongly
    suggest to get enough help from the Development dept
    as to test most of the app programs before going into Prod;
    even run a whole batch executing all its programs!

    Mariano Corral

  3. #3
    Join Date
    Sep 2006
    Thanks Mariano for very prompt reply. I needed details about handling metadata / system databases specific issues on target environment. Thanks again!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts