When migrating server data, sybmigrate requires
that the target Adaptive Server catalog contain only default data.
Default data on Windows machines is different from UNIX machines.
This causes problems when migrating from UNIX to NT machines. To
successfully migrate from a UNIX machine to an NT machine, delete
the XP Server name and the mon_user login
on the target NT machine.
Data migration is not supported while you are in high availability. You must stop high availability before beginning database migration.
Stopping high availability before beginning database
migration
Decouple primary and secondary Adaptive Servers.
Migrate primary source Adaptive Server and secondary source Adaptive Server data to the primary target Adaptive Server and secondary target Adaptive Server separately.
Configure the target Adaptive Server for high availability.
WARNING! The primary and the secondary Adaptive Server must be configured to the same logical page size to run high availability.
sybmigrate does not support major cross-version migration. Both the source and the target servers must be Adaptive Server version 12.5.0.1 or later.
To verify that you are running version 12.5.0.1 or later of Adaptive Server, run @@version on the server.
sybmigrate does not do any special processing for a DTM/XA environment. The status of open transactions and outstanding prepared transactions should be given consideration. If any special handling is required, you must do it manually.
There is no reliable way for sybmigrate to determine the dependency of various objects. sybmigrate does not attempt to create an order in which objects are migrated based on their dependencies on other objects. Table re-creation can fail if foreign keys or common keys are defined using sp_foreignkey or sp_commonkey. Views can be dependent upon other views, and they will not be re-created if the view on which they are dependent has not yet been migrated. The migration of stored procedures and triggers may not be successful if the data on which they depend has not yet been migrated. Cross-database dependencies mean that you need to coordinate the migration of related objects. If dependencies are within the selected set, sybmigrate takes care of those dependencies. However, if dependencies exist outside the selected set, you may need to run sybmigrate through migration more than one time. For this reason, you may need to perform some partial retries to successfully complete the data migration.
The name of the source and the target databases must be the same. SQL schema generated by ddlgen may have objects that must be qualified with the source Adaptive Server name.
sybmigrate does not support any kind of auditing for migration activities.
When renaming any of the compiled objects (procs, views, rules, defaults) the object name in syscomments is not updated.
During the migration, the DDLGen query the object from syscomments with the old name in the text. This old name in the text causes problems for sybmigrate during the DDL migration.
