Unanswered: Estimating downtime during sybase migration
I would like to know any experiences about estimating downtime for sybase ASE migration (impact factors like size of dump, load speed, network, storage sharing, etc.) We plan to use dump/install/load approach for sybase migration on a new set of servers on higher version of OS. Any pointers to speed up process will be really helpful.
Thank you for your time!
If the duration is critical, my advice is to code scripts for most of the activities, specially
1 - Long activities. To avoid time gaps between the end of a long task and the time you realized it's done, you may code several sequential tasks in a script.
2 - Complex activities. They are difficult to code into a script, but the
alternative (doing them manually) is not funny. The D-day, stress may drive
you to forget details or have errors. As a minimum, if you don't place the
complex tasks in scripts, have a detailed workplan describing them; don't
put yourself on the need of looking at the manuals on migration day.
IIRC, coding between 5 and 10 migration scripts costed more than five days of coding to us. It's not cheap, but you may recover the cost if you use them several times during pre-migration tests.
Write into the work plan any new task you discover while running pre-migration tests. Believe me: you may think now that you know well every detail, but on migration day you will forget some if you don't have a checklist.
If you can avoid planning many manual tasks, most of the migration time will be devoted to dump, transfer and load user databases, whose duration is dependent on size and speed.
Try to make some activities the Friday before the migration. For instance, we assumed no login should be added or changed during the last Friday, so we migrated the logins on Friday. One task less for the weekend.
The details doesnt seem to be clear enough. You havent mentioned what versions you are migrating from/to... If you are migrating to a new set of servers and if the dump/load is compatible between versions, then thats probably the safest way to go.
1. Build the new servers before hand.
2. Do a test load (it will get automatically upgraded to the new version) and ask Apps to test etc.
This way your only downtime is dump/load.
But if you cant afford a new set of storage, then, the only way is to do an inplace upgrade, which could depend on a lot of factors.
Thanks much for your responses.
Actually we will have a new set of servers for target env. The source versions vary from 12.0.X to 12.5.X and the target Sybase ASE version would be 12.5.3. Source OS is Solaris 8 and target OS is Solaris 10 (cluster)