This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Specific links you will want to bookmark for future use
stop offloading queries to IDAA when incremental update is no longer updating a table
need to accelerate OLTP DBs for IDAA. As we keep telling that we can now merge both OLTP-Operational queries together on Z., this is something that is already in our way to resolve.
First thing they came up with was the fact that they need a way to load DB2 tables into an IDAA and start replication without putting the table in Lock mode (RO), so we came up with the solution in IDAA v4.1 PTF2 to allow CDC to conduct adaptive-apply (catch up with the log), and load the table in ROW mode to allow OLTP to continue updating the OLTP DB. We can also resolve the issue of the delays in the update in the IDAA through the new stored procedure "WaitforReplication" function, so we get the same answer regardless of where the query gets served (DB2 or IDAA).
Having pictured all this in the above paragraph, the customer now wants to know what would happen in the event of a 'disconnection' between CDC (z/OS part) and IU (IDAA part). I guess we can resolve the issue on the CDC side by having CDC setup in a highly available configuration (multiple CDC standby tasks with DVIPA in a DB2 DSG), and TCPIP with VIPA,
I guess a possible error in IU portion of this puzzle would be a failure of the IDAA, where the customer would then have to have IDAA configured in a high availability configuration as well, having multiple IDAAs with the same table, being updated. Then, it would make sense to have 'that' table enabled for replication in IDAA #1 to go into disabled state while the surviving IDAA #2 copy of the same table stays enabled, so results don't vary between DB2 and the IDAA(s) version of the table. But like you say, the table will continue to be available for offload into the IDAA even though it has stopped getting updates from z/OS-CDC,,, that doesn't sound right to me !!..
Do not place IBM confidential, company confidential, or personal information into any field.