Results 1 to 9 of 9
  1. #1
    Join Date
    Aug 2002
    Posts
    76

    Unanswered: HADR and Version 9 Upgrade

    LUW 8.2 Fixpack 14 on Solaris, planning upgrade to 9.1 fixpack 4

    Since db2 migrate will not work on a database in rollforward mode, how do you upgrade your HADR standby database from version 8 to version 9?

    You have to start over on the standby after upgrading the primary and do the full restore and rebuild the hadr peer state again?

  2. #2
    Join Date
    Apr 2006
    Location
    Belgium
    Posts
    2,514
    Provided Answers: 11
    for the migration period, you could switch from standby to primary with takeover command. andafter the migrate takeover again on standby machine
    Best Regards, Guy Przytula
    Database Software Consultant
    Good DBAs are not formed in a week or a month. They are created little by little, day by day. Protracted and patient effort is needed to develop good DBAs.
    Spoon feeding : To treat (another) in a way that discourages independent thought or action, as by overindulgence.
    DB2 UDB LUW Certified V7-V8-V9-V9.7-V10.1-V10.5 DB Admin - Advanced DBA -Dprop..
    Information Server Datastage Certified
    http://www.infocura.be

  3. #3
    Join Date
    Aug 2002
    Posts
    76

    takeover

    Are you sure?

    To do the takeover after upgrading the one, you have to have HADR up and running on both primary and secondary, and I dont think it will let you do that if one is version 9 and one is version 8.

  4. #4
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    I did not try it myself, but in theory, since DB2 9 should be backwards-compatible, you would upgrade the stand-by first, take over, then upgrade the primary. At least that's how fixpaks work in an HADR environment.
    ---
    "It does not work" is not a valid problem statement.

  5. #5
    Join Date
    Aug 2002
    Posts
    76
    Yeah, i think it works for fixpacks but in version 9 the format of the logs changed and I am pretty sure it wont be supported on HADR. I thought maybe some out there would have gone thru this, but I will setup a test and give it a try. Thanks.

  6. #6
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    I would deactive the standby database, the do a db2stop force. Then upgrade DB2, then db2start. Then activate the standby database. See if it catches up correctly and comes back into peer mode.

    Last time I checked, IBM hinted that HADR would be backward compatible, but I don't know if it is officially supported.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  7. #7
    Join Date
    Aug 2002
    Posts
    76

    nope

    Although I could find nothing formal in any documentation from IBM and will probably open ticket just to make sure, I did just confirm in a test that this wont work.

    Did these steps

    1) Had 2 test dbs in peer mode at version 8
    2) Stopped hadr, shutdown both instances
    3) Upgraded the primary instance to v9
    4) migrated the primary db to v9
    5) started both instances
    6) tried to start hadr on standby

    It complained right away with the incompatability indicating that the primary was "configured worng"

    A couple reasons this is not too suprising:

    1) During the database migration, active logs are renamed from .LOG extension to .MIG extenstion. My dbs were on log S0000001.LOG when they were in peer mode.

    When the primary was migrated to v9, it had jumped to S0000013.LOG and logs 1 thru 3 were renamed to .MIG

    2) The log formats are different. The version 8 standby database can not parse version 9 logs in order to get caught up.

    3) How would it even catch up anyways? The activity in logs 1 thru 12 were migration to codebase 9 activities, things that would not work or make sense to the version 8 database manager since it is still in a version 8 codebase/instance. When it caught up it would in effect be a version 9 db inside a version 8 db, how then would you do the db2imigr and the db2 migrate on the database.


    If you look at the chain of events, it doesnt surprise me anymore that this is not supported, I just will have to pay the cost of the backup/restores abnd rebuild my hadr cluster after I migrate my production primaries.

  8. #8
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Did you try the other way around - upgrading the standby first?
    ---
    "It does not work" is not a valid problem statement.

  9. #9
    Join Date
    Aug 2002
    Posts
    76

    u cant do that

    Yep, tried that, you cant update an instance that contains a database in rollforward mode which is what the standby is in.

    So you cant do what I had planned originally which was just stop both of them and update both of them and then restart.

    What they are doing here I suspect is enforcing integrity, they dont want any transactions still in the log, they want the database in a consistent state, complete on all units of work and able to be migrated.

    They also on top of that error on this side with HADR, I suppose for our own protection that there is integrity between the 2 databases.

Posting Permissions

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