Results 1 to 15 of 15
  1. #1
    Join Date
    May 2013
    Posts
    25

    Unanswered: DB2 major version upgrading with no downtime

    Hello people,

    I was wondering if it is possible to move from one db2 major version to another with no downtime. I know that for fixpacks this is possible to be done with the HADR mechanism, but this solution won't work for upgrading to a different major version.

    Any info is welcome. Thanks

  2. #2
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    That is not supported. I talked to the IBM architect in charge of HADR at the Toronto Lab and he said he can do it, but his boss with not give him the resources to implement that feature. At some point that feature might be available with pureScale.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  3. #3
    Join Date
    May 2013
    Posts
    25
    Hmm I see. Thanks for the info Marcus

  4. #4
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by Haros View Post
    I was wondering if it is possible to move from one db2 major version to another with no downtime. I know that for fixpacks this is possible to be done with the HADR mechanism, but this solution won't work for upgrading to a different major version.
    You could do this using replication.
    ---
    "It does not work" is not a valid problem statement.

  5. #5
    Join Date
    May 2013
    Posts
    25
    Can you provide more info n_i ?

  6. #6
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    There are several replication options that may already be included in your DB2 license. You will install the new DB2 version separately, create a database, and set up replication from the old database to the new one. Replication, e.g. Q Replication or CDC, will accommodate different versions for the source and target databases. You will then prepare the client applications to connect or fail over to the new database, suspend writes for a moment on the source, and connect to the new database. If all goes well I'm pretty sure you can limit downtime to under a minute while the applications reconnect.

    Of course, you will pay for that by setting aside the appropriate server hardware and networking gear to support high volume continuous replication (I'm assuming it's high volume, otherwise you wouldn't need zero downtime).
    ---
    "It does not work" is not a valid problem statement.

  7. #7
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    By the way, you may already have a DR solution in place that you can use for that, instead of setting up a new replication group.
    ---
    "It does not work" is not a valid problem statement.

  8. #8
    Join Date
    May 2013
    Posts
    25
    I see. Because my knowledge on db2 is limited, I have one more question about the write suspension.

    If write is suspended on the first db and then we connect our application to the second (replicated) db, will the memory commits that were happening when first db was in write suspension be committed to the second db or they will be lost?

    Thanks for the help.

  9. #9
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by Haros View Post
    If write is suspended on the first db and then we connect our application to the second (replicated) db, will the memory commits that were happening when first db was in write suspension be committed to the second db or they will be lost?
    Since you'll have to switch database connections, uncommitted transactions on the old database will be lost if your application(s) can't handle connection failover.
    ---
    "It does not work" is not a valid problem statement.

  10. #10
    Join Date
    May 2013
    Posts
    25
    So with write suspension it is a matter of how the application will handle the transactions in memory after the first db is off? If it has a failover mechanism they will be committed in the failover db (newer version db2) else they will be lost. Did I understand everything correct?

    I am having in mind a concept with IBM's Websphere db failover (don't know if you are familiar with it).

  11. #11
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by Haros View Post
    So with write suspension it is a matter of how the application will handle the transactions in memory after the first db is off? If it has a failover mechanism they will be committed in the failover db (newer version db2) else they will be lost. Did I understand everything correct?
    I think it's correct, more or less. It's not about write suspension, which is just to ensure that while you fail over and process remaining log data on the source, no new transactions change data. Once you disconnect from the old database, the application will receive an error for each transaction in progress, it would need to process that error, reconnect (to the new database now) and retry the transaction.
    ---
    "It does not work" is not a valid problem statement.

  12. #12
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    You might want to test how long it takes to do a DB2 major release upgrade, since the down time may be shorter than you think and may be acceptable. Be sure to do it on an exact copy of the database you are upgrading (or as close as possible).
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  13. #13
    Join Date
    May 2013
    Posts
    25
    Thank you for your replies guys.

    I was also thinking the concept of having in the same machine the newest version of db2 binaries installed in parallel with the old and somehow use the same instance files.

    Do you think something like that is possible in a way? Can I just "hook" the instance data from the old db2 without file recreation?

  14. #14
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by Haros View Post
    Thank you for your replies guys.

    I was also thinking the concept of having in the same machine the newest version of db2 binaries installed in parallel with the old and somehow use the same instance files.

    Do you think something like that is possible in a way? Can I just "hook" the instance data from the old db2 without file recreation?
    What you are describing is standard procedure.

    Assuming you have Linux or UNIX:
    1. First, as root, install the DB2 code to a new directory such as /opt/ibm/db2/V10.1.2
    2. Stop DB2 for the instance to be upgraded (db2stop) as instance owner
    3. Then as root, run /opt/ibm/db2/V10.1.2/instance/db2iupgrade <instance-name>
    4. Start DB2 - logon as instance owner and run db2start
    5. refer to the following to see if any of these post-upgrade tasks need to be done, and whether they will affect your availability of the database before it can be used:
      Post-upgrade tasks for DB2 servers
    6. You are done - practice this on a test database (preferably exact copy of the one you want to upgrade) to see how long the outage is.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  15. #15
    Join Date
    May 2013
    Posts
    25
    Hello Marcus,
    I know that this is the standard procedure but I had in mind something which doesn't involve stopping the old database. Something like write suspending, hooking the data to the new database and then use the failover mechanism.

Posting Permissions

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