Results 1 to 7 of 7
  1. #1
    Join Date
    Apr 2003
    Location
    Florida
    Posts
    79

    Question Unanswered: Replication on DB2 UDB v8 on Linux



    I'm looking for performance information on Replication Center - Is it reliable enough to support real-time replication?

    If not, how close to real-time can it get?

    I'm wanting to have insert/Update/Delete activity occur on OS/390 but use DB2 UDB on Linux for most query requirements.... Query costs are too high on OS/390.

    Thanks for sharing any expirence you may have with Replication Center -
    Rick

  2. #2
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650

    Re: Replication on DB2 UDB v8 on Linux

    If you want to copy every table from the os/390 subsystem on a 'real time' basis, then it is quiet expensive in terms of resources(CPU, I/O and network), I think ...

    'Realtime', ideally could be about 5 mins , but in practice this may extend .. Of course, parameters are configurable ...

    Again remember, DPropR is not real-time .... It is asynchronous and hence there is no gurantee that the data will be available on the target side immediately ...

    Well, can we do this way .... If you can explain a bit more in detail, what you are trying to achive, I'm sure, you will get a better explanation from one of the forum members ...

    Cheers

    Sathyaram

    Originally posted by Rick-dba


    I'm looking for performance information on Replication Center - Is it reliable enough to support real-time replication?

    If not, how close to real-time can it get?

    I'm wanting to have insert/Update/Delete activity occur on OS/390 but use DB2 UDB on Linux for most query requirements.... Query costs are too high on OS/390.

    Thanks for sharing any expirence you may have with Replication Center -
    Rick

  3. #3
    Join Date
    Apr 2003
    Location
    Florida
    Posts
    79
    My expirence so far is "reading the book" - I guess DataPropegator is required on OS/390 and it will be Monday of next week before I can inquire about that - the SYSADMIN at our data center is at IDUG.

    In "A practical guide to DB2 UDB Data Replication v8" (PDF by IBM) - It states replication data latencies of about 15-20 seconds can be expected..... I believe that would be an exceptable trade-off compared to what our query costs are now. Insert/Update/Delete activity is fairly slow during the day - a batch nightly process handles most of the workload.

    We would want no more than 10 - 15 tables to be a part of any one subscription set.

    B.T.W. - A different CAPTURE engine can be setup for each different set of replication source/target subscriptions to improve throughput.

    Anyone out there even using replication?
    What has your expirence with it been like so far?

    Thanks!
    Rick

  4. #4
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    Data propogator needs to be licensed and installed on OS/390 ... I do not have a clear idea of having multiple CAPTURE Engines ...

    The general recommended configuration is to have the control server and apply program running at the target system(DB2 UWO, in your case) ... In this case you will have to additioanlly license DB2 Connect to get the data from the mainframe ... Of course, you can run the apply program also on the mainframe and write to the target UWO database system ...

    As you have mentioned, if the data changes are light, on just 15 tables, 15-20 secs latency is easily achievable (you can even go in for <10) .... But for the batch job, you should see how the performance is ...

    One other thing you need to consider is 'If your Replication fails (it is not a strange thing ), how will my application be affected?' ...

    For the replication setup I did recently, if the replication does not work, we will end up with some unhappy customers (which is obviously not desirable), but the failure will not affect the core business (if it does, it is not acceptable) ... On a non-recoverable failure of replication, we can very well get into the batch mode being practised prior to implementing replication ....

    IMHO, it will not be too good for your applications to rely on this 15-20 secs latency of the replication process .... It is not that reliable ....

    HTH

    Cheers

    Sathyaram



    Originally posted by Rick-dba
    My expirence so far is "reading the book" - I guess DataPropegator is required on OS/390 and it will be Monday of next week before I can inquire about that - the SYSADMIN at our data center is at IDUG.

    In "A practical guide to DB2 UDB Data Replication v8" (PDF by IBM) - It states replication data latencies of about 15-20 seconds can be expected..... I believe that would be an exceptable trade-off compared to what our query costs are now. Insert/Update/Delete activity is fairly slow during the day - a batch nightly process handles most of the workload.

    We would want no more than 10 - 15 tables to be a part of any one subscription set.

    B.T.W. - A different CAPTURE engine can be setup for each different set of replication source/target subscriptions to improve throughput.

    Anyone out there even using replication?
    What has your expirence with it been like so far?

    Thanks!
    Rick

  5. #5
    Join Date
    Apr 2003
    Location
    Florida
    Posts
    79
    Thank you!
    That is exactly the information I was looking for....

    I suppose if the replication process is not that reliable, I should put some sort of plan in place would switch their application connection to OS/390 when replication fails and switch the connection back to Linux when successful? Not sure how I can do that efficently yet.....

    We are not really faced with these issues yet, but I want to be prepared.

    Thanks again for your thoroughness -

    Rick - FSU

  6. #6
    Join Date
    Apr 2003
    Location
    Florida
    Posts
    79
    B.T.W. Here is some information out of the IBM manual about multiple capture programs.....

    Creating multiple sets of Capture control tables
    If you want to use more than one Capture program on a server you must create more than one set of Capture control tables and ensure that each set of tables has a unique Capture schema. This schema identifies the Capture program that uses a set of tables. Multiple Capture schemas enable you to run multiple Capture programs concurrently.

    You might want to run multiple Capture programs in the following situations:
    v To optimize performance by treating low-latency tables differently from
    other tables. If you have low latency tables, you might want to replicate
    those tables with their own Capture program. That way, you can give them a different run-time priority. Also, you can set the Capture program parameters, such as pruning interval and monitor interval, to suit the low latency of these tables.
    v To potentially provide higher Capture throughput. This may be a significant benefit in a source environment with multiple CPUs. The trade-off for the higher throughput is additional CPU overhead associated with multiple log readers.

  7. #7
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    Thanks Rick ....

    Multiple Capture programs seems to be a new V8 thing .... Yet to venture into the world of Replication in V8 ...

    Thanks

    Cheers

    Sathyaram

    Originally posted by Rick-dba
    B.T.W. Here is some information out of the IBM manual about multiple capture programs.....

    Creating multiple sets of Capture control tables
    If you want to use more than one Capture program on a server you must create more than one set of Capture control tables and ensure that each set of tables has a unique Capture schema. This schema identifies the Capture program that uses a set of tables. Multiple Capture schemas enable you to run multiple Capture programs concurrently.

    You might want to run multiple Capture programs in the following situations:
    v To optimize performance by treating low-latency tables differently from
    other tables. If you have low latency tables, you might want to replicate
    those tables with their own Capture program. That way, you can give them a different run-time priority. Also, you can set the Capture program parameters, such as pruning interval and monitor interval, to suit the low latency of these tables.
    v To potentially provide higher Capture throughput. This may be a significant benefit in a source environment with multiple CPUs. The trade-off for the higher throughput is additional CPU overhead associated with multiple log readers.

Posting Permissions

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