IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
2 replies Latest Post - ‏2012-12-18T22:26:00Z by GlenSakuth
36 Posts

Pinned topic Parallelize by single table

‏2012-12-17T03:49:56Z |
I am using an oracle to oracle replication using CDC 6.5.2 2 InterimFix7. We are trying to configure fast apply by isolating one of the large table (around 20 million per day ) but the error message I get is 
 Event ID: 9715

Publisher(S)/Subscriber(T): T


Event Text: Target parallel apply is disabled because it can only be used with an optimizer for standard apply and no derived expressions.

Where as documentation  states as below .Any help appreciated.
 This fast apply mode is enabled for a subscription by specifying the following text in the Class Name box of the subscription-level user exit dialog box:

This mode is useful if a subscription contains a single table and only inserts occur on the target database for that table. This is often the case for a subscription with a single table and a LiveAudit™ mapping type.

Updated on 2012-12-18T22:26:00Z at 2012-12-18T22:26:00Z by GlenSakuth
  • Rphilo
    375 Posts

    Re: Parallelize by single table

    ‏2012-12-17T08:19:56Z  in response to AbhilashJoseph
    I think the documentation is incorrect and you cannot use the fast apply for the audit mapping and I will flag this up.
    If you have a concern that replicating the transactions will cause latency you might look at splitting the table between multiple subscriptions and having filtering so that roughly equal number of transactions are in scope for each subscriptions, So if you have say some branch id with possible range of 01 to 99, you could simply have two subscriptions for the table with a row filter for the first subscription of branch id < 50 and a row filter for the second subscription of branch id > 49. However this will not work if you are not able to sequence the transactions on the source independently of arrival sequence, in other words if you have multiple updates for the same row, you will need to be able to process them in the correct order, and this is probably the reason why the audit mode does not support the fast apply. You may find that even if you have timestamps down to milliseconds you may have multiple updates for the same row in the same commit transaction, and the only way then to sequence the updates correctly is to use an incrementing sequence on the target side, which would obviously not work for multiple subscriptions, Even if you can implement this, you will also need to consider the additional impact of the filtering on the source system.
    • GlenSakuth
      68 Posts

      Re: Parallelize by single table

      ‏2012-12-18T22:26:00Z  in response to Rphilo
      There has been an enhancement released in 6.5.1 IF 4 to allow fast apply to work with Live Audit.  That enhancement has not been dual maintained yet into the 6.5.2 code stream.  Please open a PMR and request it.   This is certainly something that is to be added.