Results 1 to 13 of 13
  1. #1
    Join Date
    Sep 2006
    Posts
    33

    Arrow Unanswered: Delta updates for during cross platform migration

    Hi !

    During migration using dump and load mechanism (from Solaris 8 to Solaris 10 and target ASE 12.5.3) - how do we take care of updating delta changes (which might have been done at source site while load activity is in progress at target instnace) from the pre-migration source instance to migrated target instance. I mean, can we apply transaction logs to target databases after dump is loaded into tagret?? (Assuming there are no changes at metadata level or system configuration)

    Kindly advise.

    Thanks in advance!

  2. #2
    Join Date
    Jan 2003
    Location
    Geneva, Switzerland
    Posts
    353
    Yes, you can load transaction dumps to the target, provided that you haven't put the target database on-line.

    However, at some point you'll have to have a bit of downtime while the you finalize the new database and switch to it for application use.

    Michael

  3. #3
    Join Date
    Sep 2006
    Posts
    33
    Thanks a lot Michael for this information.

    So what I have understood is - Downtime at source database will be required when freeze the updates before taking the dumps of all the databases, and later changes at source can be applied by applying transaction logs to the target database by taking target database offline. Please correct me if I understood it wrong.

    Regards,
    Vasanti

  4. #4
    Join Date
    Sep 2002
    Location
    Sydney, Australia
    Posts
    255
    syb_dmn

    1 You do not have to "freeze" the updates on the source db during the dump cycle, as Sybase does a completely online dump, collecting all updates to the end of the dump cycle. Just dump the db. (This will set the logical point in time from which you will have updates to the source db which are not migrated to the target db, therefore you will need a tran dump at some later stage.)
    2 Create your target server, the target db, and load the db dump. The db is offline.
    2.1 Do not "online database ...", which is what you would normally do to open the db for use.
    2.2 Upgrade your objects, in place. Check that they have been upgraded.
    2.3 Check everything, particularly that the db allocations (fragments) are correct.
    .
    3 There are now updates to the source to worry about. Shutdown the source db (usually set single-user mode and kill all conections), and disallow further connections. This is the beginning of your downtime. Dump tran source db. This will collect the updates since the db dump [1].
    4 Load tran target db. You are now up to date on the target.
    5 Open the target for connections. Online db target db. This is the end of your downtime.

    To get a very quick overview of db/tran logs, you may find http://www.dbforums.com/showthread.php?t=1604945, Post 5,of value.

    Test everything to do with the migration on a test server/db before you attempt it on production. Script all commands unless you like pain.

    Cheers
    Last edited by DerekA; 09-29-06 at 12:40. Reason: Further Detail
    Derek Asirvadem
    Senior Sybase DBA/Information Architect derekATsoftwaregemsDOTcomDOTau
    Anything worth doing is worth doing Right The First Time
    Spend your money on standards-compliant development or spend 10 times more fixing it

  5. #5
    Join Date
    Sep 2006
    Posts
    33
    Thanks a lot Derek for explaining it so well !

  6. #6
    Join Date
    Sep 2002
    Location
    Sydney, Australia
    Posts
    255

    There is a "Migration Guide"

    syb_dmn

    Thanks for the feedback.

    The 12.5.x migration is not a simple matter, it depends on if you are migrating from 11.5/11.9 (big step) or 12.0 (small step):
    It should not be attempted until you have read and understood the migration guide "Sybase Migrating to ASE 12.5" and web pages for Migration.
    There are quite a few gotchas, which is what I am trying to draw your attention to in Post 4, which I have edited for further detail. Check everything. Especially for objects not being upgraded properly (which means you still run without errors, but at 11.5/12.0 speeds), so you have to check [I did the last of my 12.5 migrations a few years ago, I am o/s right now with little at hand, but IIRC ...] sysobjects.version and sysindexes.version = 12500.
    Ensure you have a Roll Up release (ESD #something) and not a bleeding edge EBF release, as is appropriate for production.
    Ensure you have rebuilt your text/image chains as per the Guide, otherwise they too will be sitting there in a 12.5 server with 11.5/12.0 formats/speeds.
    Surf a bit and RTFM.
    If you have not completely tested one complete database migration on one of the new servers, including the execution of the procs and checked the results, and a full dbcc checkalloc (checkstorage is fine but requires a fair amount of set up), you may be in for a surprise. This (and not our advice) will give you some idea of the estimated timeframes you are seeking. The downtime is a minor issue in the context of the whole project plan.

    Cheers
    Last edited by DerekA; 09-29-06 at 13:20. Reason: Clarity
    Derek Asirvadem
    Senior Sybase DBA/Information Architect derekATsoftwaregemsDOTcomDOTau
    Anything worth doing is worth doing Right The First Time
    Spend your money on standards-compliant development or spend 10 times more fixing it

  7. #7
    Join Date
    Sep 2006
    Posts
    33
    Thanks much Derek fo sharing your experiences.

    Please help me clarify one more doubt - cross platform dump/load is not supported for transaction logs. What would be the most suitable strategy for applying delta changes in case of migrating from Linux to Solaris? Would the replication server approach for migration be more suitable in this case? Or simply bcp? Kindly suggest.

    Thanks for your time!
    Last edited by syb_dmn; 10-01-06 at 09:54.

  8. #8
    Join Date
    Sep 2002
    Location
    Sydney, Australia
    Posts
    255
    (Sorry for the delay in responding, I am travelling and not picking up every day)

    1 I do not think it is correct that "cross-platform dump/load is not supported for transaction logs", but I cannot check that while I am travelling. I believe the problem really is that you are mixing the upgrade (in place as you have decided) with the move to new servers, and thus end up with restrictions in the load ... upgrade sequence. Often we answer questions on the forums which are narrow, and get into trouble when the answers are applied in some specific context - post 4 above is thus incorrect. If you do one of the following (as opposed to attempting upgrade and move and no downtime all at once) you will not have any problems.
    • upgrade in place, then move to new server (two separate small downtime windows)
    • load db on new server, upgrade in place, then online db (but live with the larger downtime window)

    2 Replication works well, but it is a pain to set up (once off) and really not worth the effort if you are going to turn it off after the migration. Plus you will have to test the hell out of it and iron out any problems before attempting the real migration event.

    3 bcp out/in is the best by far for many reasons.
    a. For those of us who already have scripts (required anyway for logical db restore or db/object rebuild), this is easy; but if you do not have such scripts, it is a chore to set them up and test them.
    b. It allows a true rebuild, resize and placement of both the db and the objects. Of particular note is the clustered and non-clustered indexes which have been heavily enhanced in 12.0 (completed in 12.5), to take advantage of that, you need to create them under 12.5. (Ditto for the text/image chains but they can be rebuilt with sp_rebuild_text.) The 12.5 non-clustered indexes can be take 30 to 90% less space than 11.5.
    c. due to importing the DDL only, you do not have the issues of object upgrade and check/verify, because the objects are truly created in 12.5 format. No dbcc upgrade_object required.
    I have done about twenty 12.5 upgrades. Being heavy on the P&T side, and having had mature and tested scripts, there was never any question, I always:
    • rebuilt the db from scratch
    • exported DDL and built all objects (minus indexes) in 12.5 format
    • bcp out data/bcp in data
    • create all indexes
    which needed a very small downtime window and left very little clean-up to do, and most important, no revisiting previously performed tasks. However, in the last two years, I have been attending to four other sites who have delayed their migration until there was no choice, upgraded in place, and are still having performance problems, which are the result of outstanding 12.5 upgrade clean-up tasks, all because they did not RTFM the Migration Guide and check that the objects were in fact upgraded. Hence my warnings.

    Cheers
    Last edited by DerekA; 10-03-06 at 07:45.
    Derek Asirvadem
    Senior Sybase DBA/Information Architect derekATsoftwaregemsDOTcomDOTau
    Anything worth doing is worth doing Right The First Time
    Spend your money on standards-compliant development or spend 10 times more fixing it

  9. #9
    Join Date
    Sep 2006
    Posts
    33
    Thanks a lot for taking time to answer my query.
    We are thinking of dump_load approach over bcp - the db sizes total upto 250GB for a single instance. upgrade_object will be critical check as we have 12.0.x as source to be migrated to 12.5.3 on new machine with solaris10 and few source servers have linux.
    Thanks again!

  10. #10
    Join Date
    Sep 2002
    Location
    Sydney, Australia
    Posts
    255
    syb_dmn

    Ok, you are doing an upgrade (in place) either before or after the move. So are you clear that, due to not being able to dump/load tran (across versions not across platforms), for a 250gb db, you will have a reasonable downtime window, during the upgrade process ?

    In addition to dbcc upgrade_object, don't forget to sp_rebuild_text for your text/image chains (sysindexes.indid = 255)

    Cheers
    Last edited by DerekA; 10-04-06 at 08:41.
    Derek Asirvadem
    Senior Sybase DBA/Information Architect derekATsoftwaregemsDOTcomDOTau
    Anything worth doing is worth doing Right The First Time
    Spend your money on standards-compliant development or spend 10 times more fixing it

  11. #11
    Join Date
    Sep 2006
    Posts
    33
    Actually I was thinking that there will not be any issue with applying transaction log dumps from 12.0.x to 12.5.3 - source OS being solaris 9 and target Os being solaris 10 - and downtime will start when we need to switch over to target instance and apply transaction log dumps from source instance. But with source OS as Linux and target OS Solaris10, (since cross-platform transaction log dumps are not supported as per sybase documentation) it would be needed to bcp out copies of transactions....

  12. #12
    Join Date
    Sep 2002
    Location
    Sydney, Australia
    Posts
    255
    David

    You cannot bcp the transaction log. Unlike Oracle, Sybase's tran log is completely internal and automatic, there is no oracle-style handling, no rollforwards, etc.

    There IS an issue with applying 12.0.x tran log dumps to a 12.5.3 database, the tran log dump and the db have to be at the same version).

    The problem of cross-platform tran log dumps is easy to overcome (when you have set up the Backup Server on the new box, make it accessible from the old box, and write your old_db dump there). The problem you are left with is, I think you cannot load a 12.0 tran dump into a 12.5.3 db. This is what you need to test (easy enough, just upgrade one of your small dbs and try it).

    Cheers
    Derek Asirvadem
    Senior Sybase DBA/Information Architect derekATsoftwaregemsDOTcomDOTau
    Anything worth doing is worth doing Right The First Time
    Spend your money on standards-compliant development or spend 10 times more fixing it

  13. #13
    Join Date
    Sep 2006
    Posts
    33
    Yes; we need to test.
    Thanks a lot for taking time to reply my queries!
    Last edited by syb_dmn; 10-05-06 at 12:50.

Posting Permissions

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