IBM Data and AI Ideas Portal for Customers


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 updates on 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,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Employees should enter Ideas at https://ideas.ibm.com


Add a new idea Subscribe
Status Delivered
Workspace Db2 for z/OS
Created by Guest
Created on Aug 28, 2019

RELATED IDEAS

Ensure data consistency in even the biggest LOBs without compromising availability

The only way to ensure data consistency in Db2 LOBs, is by regularly checking – and by always to ensure that we have at least one full and consistent image copy of all LOBs.

Not to compromise availability, all CHECK LOB utilities must use SHRLEVEL CHANGE, which trigger use of Flashcopy.

 But, as documented in PMR TS002527571, this causes availability issues for large tablespaces, where lots of extents are needed for Flashcopy.

In the very beginning of in the CHECK LOB execution process, the utility change tablespace availability to UTRO (Utility Read Only) – and this status make the whole LOB unavailable for anybody else than this CHECK LOB utility. If this outage only last for very short time, nobody will notice, but with lots of extents, we see this outage last for minutes.

 This is a major issue for data integrity as more and more business critical data seems to be stored in LOBs.

 The optimal solution would be, if CHECK LOB did not change Tablespace availability to UTRO until the receiving dataset was allocated and ready for Flashcopy.

 To avoid availability disasters, a temporary circumvention could be to add parameters to define how long time we can accept UTRO status for this LOB during CHECK LOB execution – this mean, that we will be able to submit CHECK LOB for any LOB, but also that some LOBs might not be checked because of time limit to allocate Flashcopy datasets are exceeded and the CHECK LOB utility is not completed.

The described circumvention is NOT able to ensure consistency in all our current LOBs.

RW-UTRO check l...
RW-UTRO check lob shrlevel change.pdf
Open full size
RW-UTRO check lob shrlevel change.pdf
  • Admin
    Janet Figone
    Reply
    |     Apr 19, 2021

    Hello, Thank you for your patience. Db2 development has reviewed your comments.

    The shadow dataset is allocated by DFSMSdss FlashCopy, not by Db2. Therefore UTRO must be set first.

    Ultimately what is required here is a redesign of CHECK utilities such as CHECK LOB to avoid the dependency upon the use of FlashCopy and operate truly online against active pagesets. This is something we have been considering but it is not on our roadmap at this time.


  • Admin
    Janet Figone
    Reply
    |     Mar 18, 2021

    Hello, Thank you for your patience. I have reminded our development team to please review the recent Idea comments and respond here.

  • Admin
    Janet Figone
    Reply
    |     Feb 17, 2021

    Hello, Thank you for your additional information. Db2z developments' response will be shared with you shortly.

  • Guest
    Reply
    |     Jan 28, 2021

    It looks like IBM in general don't reply when customer ask or comment on Ideas?
    Is that true?
    If not I suggest Janet Figone try to get a response.


  • Guest
    Reply
    |     Jan 20, 2021

    And even more....We just completed a new test of CHECK LOB SHRLEVEL CHANGE.

    The results look the same, with tablespace in UTRO for minutes while Flashcopy is allocating.

    As long as you UTRO lock the tablespace prior to activating Flashcopy, you will see an outage with a duration depending on the number of extents needed. This design will never be able to support 24/7 availability.

    This scenario will be easy to recreate in the LAB, as all you need is a huge LOB for testing purpose.

  • Guest
    Reply
    |     Jan 20, 2021

    One more thing. I received a bit of info from local CE regarding the APAR. But when I try to look it up it appears like something that doesn't exist yet. I can't read about the parameter named SETSMS BYPASS_CLUSTER_PREFERENCING(YES|NO). Could I ask you to be more specific and detailed in your responses?

  • Guest
    Reply
    |     Jan 20, 2021

    Isn't 'all you need' from DB2 side this?
    Take the UTRO lock AFTER Flashcopy has allocated datasets and ready to receive data? That would lower the outtage dramatically.

  • Admin
    Janet Figone
    Reply
    |     Jan 19, 2021

    Hello Søren,

    IBM is providing APAR OA59041, OA59042 and OA59043 information to Kasper. He will follow up with you.

    Kind Regards,

    Janet

  • Admin
    Janet Figone
    Reply
    |     Jan 4, 2021

    Hello Søren,

    The design of CHECK utilities with SHRLEVEL CHANGE is that Db2 will drain updates whilst performing a FlashCopy. The intent being that the copy is quick enough that no application impact is noticed. This is in fact what you see except when lots of extents are necessary. The DFSMSdss performance improvement in this area is significant, but we could not guarantee that no impact would be noticed by applications since it's dependent upon a number of factors such as your IRLM lock timeout interval. The design of the utility temporarily setting UTRO remains in place and there are no plans to change that design at the current time.

    Kind Regards,

    Db2 for z/OS Development

  • Guest
    Reply
    |     Dec 18, 2020

    Not sure i understand this.

    Will the mentioned APARs make the utility full concurrent so we avoid outtages? Otherwise I must ask you to elaborate and infororm us how we can implement such a function in our production environment with 24*7 availibility.

  • Admin
    Janet Figone
    Reply
    |     Dec 18, 2020

    Thank you for submitting this enhancement request. Db2 for z/OS development reviewed it and determined the CHECK utilities run SHRLEVEL CHANGE do require the use of FlashCopy. There are no plans at this time to remove that dependency or redesign this. However, the underlying issue reported here is the performance of FlashCopy when multiple extents are required. DFSMSdss has investigated this and provided a significant performance improvement via APARs OA59041, OA59042 and OA59043.

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.