Unanswered: migrating from Sybase ASE 184.108.40.206 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 220.127.116.11 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.
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!