Results 1 to 12 of 12
  1. #1
    Join Date
    Oct 2004
    Posts
    268

    Unanswered: HADR Setup Issues

    RHEL Linux 6.2, DB2 V9.5 FP7

    We are in the process of setting up 2 DB2 Linux servers with HADR production database. The primary database will be on one SAN drive and the Standby database will be on another SAN drive with each drive will be attached to their own server.

    Here is the issue, management also want to another Disaster Recovery area on another network (LAN). For this purpose, they are looking at a software called "Dell Compellent".

    It seems to me this software is an alternative to a HADR setup but can it be used to create another standby database on the other disaster recovery area (Different LAN) ? If so, can it use either the primary or the standby databse to get a snapshot backup and data replays ?

    or without using the "Dell Compellent", how can we get another standby database to the other disaster recovery area that is on another network ?

    Is there any one has experience with Dell Compellent" tool ?


    Please let me know your feedbacks.

    Thanks.

  2. #2
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by mdx34 View Post
    or without using the "Dell Compellent", how can we get another standby database to the other disaster recovery area that is on another network ?
    Don't know about Dell Compellent, but you can "roll your own" standby database by restoring the primary's backup on your DR server, manually shipping log files (e.g. by a userexit program), and continuously rolling forward the standby database.

  3. #3
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    I am not familiar with Dell Compellent , but having looked at a few websites like

    Disaster Recovery, Data Protection Solutions

    I assume it is based on snapshot technology - transporting incremental changes on a periodic basis from the primary site to DR site.
    If you think this assumption is correct - read on.

    You can have HADR on the primary site.

    Once an hour(say), you can suspend writes on the primary database using " set write suspend on database " command.
    Take a snapshot using the Dell Compellent technology
    Then resume writes on the db using the set write resume command.

    "Transport" the changes to the DR site.

    Make sure you make your archive logs available to the DR site.

    In case of a HADR takeover, on the new primary , the Dell Compellent has to intialize the snapshot . Then you can follow the same procedure as above.

    Write suspend is necessary to ensure the data and logs are consistent. You can do the write suspend only on the Primary database.

    When you need to use the DR site database, use db2inidb command and ROLLFORWARD command to bring the db online.

    Search on the keywords - db2inidb , set write suspend to get more information.

    HTH

    Sathyaram
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  4. #4
    Join Date
    Oct 2004
    Posts
    268
    Thank you for all your responses. Restrictions apply on this database and manual copying is out of question as data loss needs to be minumum if any. It will be a 24/7 system.

    My question is how will the primary database will react when it now there is another resource trying to get changing data to reply on another target by Dell Compellent. I assume the standby database is useless to do any mirroring or usage by this tool.

    Thanks.

  5. #5
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by mdx34 View Post
    Thank you for all your responses. Restrictions apply on this database and manual copying is out of question as data loss needs to be minumum if any. It will be a 24/7 system.

    My question is how will the primary database will react when it now there is another resource trying to get changing data to reply on another target by Dell Compellent. I assume the standby database is useless to do any mirroring or usage by this tool.

    Thanks.
    If you do a snapshot, the database must be placed in write suspend mode for a minute or so, using most disk mirroring technologies. If you want to take a snapshot of the HADR standby, you will have to take it out of HADR, write suspend with snaphot, then back into HADR, and it will catch-up, however, you will technically be without a HADR standby during that short period.

    I have heard that IBM is considering adding the capability for multiple HADR standby databases at some future date, but I have no specifics on that.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  6. #6
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    Quote Originally Posted by mdx34 View Post

    My question is how will the primary database will react when it now there is another resource trying to get changing data to reply on another target by Dell Compellent.
    Unlike HADR or a normal DB2 backup, the database does not have any idea about the backups being taken.
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  7. #7
    Join Date
    Oct 2004
    Posts
    268
    Thank you Marcus. Much Appreciated.

    Is there a benefit of setting up logarchmeth2 too along with logarchmeth1 with HADR ? Would it use additional resources ? What is a best prctice ?


    I think we will give up on Dell Compellent tool since we can not afford any downtime.

    Thanks again.

  8. #8
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    Quote Originally Posted by mdx34 View Post
    I think we will give up on Dell Compellent tool since we can not afford any downtime.

    Thanks again.
    There will not be any downtime. But a short blip - the duration depends on the number of tablespaces. During this suspend, applications will not be terminated, but they will be waiting for the database response.
    This snapshot technology is getting very popular and is being adopted widely.

    In essence, no availability issue as long as you can take about 30 seconds of app suspension each time you run the snapshot.

    HTH

    Sathyaram
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  9. #9
    Join Date
    Oct 2004
    Posts
    268
    Thank you Sathyaram.........Are you sure it is 30 seconds only and it depends on the number of tablespaces and not the size of the tablespaces/databse ?

    30 second may not be a big deal.

    Thanks.

  10. #10
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    I will try to elaborate a bit more. Last post was incomplete. Apologies

    When you issue a write suspend, the dirty pages from the bufferpool is written to the disk, log file is archived and the tablespaces are suspended (I assume, some change in header info).

    When the database is in write suspend state, select queries work as normal .. so no downtime here. Database changes are written to the bufferpool. No direct writes thoguh. When a commit is issued, the database waits as it cannot flush the log buffer.

    When the db is in write suspend, a snapshot should be taken (takes a matter of a second or two only, normally)

    Then when you issue write resume, a new log file is allocated, tablespaces are changed to normal state and then write is resumed.

    So, how long the whole process takes depends on the dirty pages in the bufferpool and number of tablespaces - and not on the size of the tablespace or database itself.

    30 seconds is reasonable in my experience. Though it may take longer as well.
    Give it a try on the test system and use a multiplication factor of 2 or 3 and you should get an idea.


    Split Mirror using Suspended I/O in IBM DB2 Universal Database Version 7

    HTH

    Sathyaram
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  11. #11
    Join Date
    Oct 2004
    Posts
    268
    Thank you. Much Appareciated.

  12. #12
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    If you want to take a snapshot of the HADR standby, you will have to take it out of HADR, write suspend with snaphot, then back into HADR
    You do not have to take the standby out of HADR. Just deactivate it gracefully, take a snapshot and then activate the standby database.

    If the snapshot is restored, the stop hadr can be done on the restored image.

    I prefer this approach to stopping and starting HADR.
    Visit the new-look IDUG Website , register to gain access to the excellent content.

Posting Permissions

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