IBM Data and AI Ideas Portal for Customers

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:

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

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

Additional Information

To view our roadmaps:

Reminder: This is not the place to submit defects or support needs, please use normal support channel for these cases

IBM Employees:

The correct URL for entering your ideas is:

Status Future consideration
Workspace Db2
Created by Guest
Created on Feb 15, 2017

Enable classic reorg with "allow write access"

Many customers want to REORG their tables quickly and efficiently. The classic REORG is by far the fastest option but puts the table in read only mode. Inplace reorg allows write access but is much slower and not suitable for tables that have a high amount of changes in a short period of time. The ADMIN_MOVE_TABLE stored procedure can be utilized to " online reorg" a table. It would nice to build in this functionality in the normal Reorg command by adding an option " allow write access"
  • Guest
    Mar 11, 2020

    It seems "sharelevel change" would be good. A point that I see in the Db2 z/Os is that the "sharelevel change" is for tablespaces.

    For Db2 LUW, it must be in table level (I don't know Db2 z/Os.. not sure about concept difference about tablespaces between Db2 LUW and Db2 z/OS).

    I am not sure about the best option but "sharelevel change" seems to be a good one in the table level.

  • Guest
    Mar 11, 2020

    The desired way of operation of the Reorg in this particular case is the same as is used in Db2 z/OS. Reorg with sharelevel change

    REORG with SHRLEVEL CHANGE reloads the reorganized data into a shadow copy of the area that is being reorganized. For REORG TABLESPACE SHRLEVEL CHANGE, a mapping table correlates RIDs in the original copy of the table space or partition with RIDs in the shadow copy. Applications can read from and write to the original area, and Db2 records the writing in the log. Db2 then reads the log and applies it to the shadow copy to bring the shadow copy up to date. This step executes iteratively, with each iteration processing a sequence of log records. Near the end of reorganization, Db2 switches the future access of the application from the original data to the shadow copy. Applications have read-write access during unloading and reloading, a brief period of read-only access during the last iteration of log processing, and a brief period of no access during switching.

  • Guest
    Dec 20, 2019

    It would be nice having a real online reorg.

    I am not sure that using ADMIN_MOVE_TABLE in the normal reorg command could solve that, because checking the InfoCenter it says:

    REPLAY: Copies into the target table any rows that have changed in the source table since the COPY phase began. REPLAY can be used only after the COPY phase has completed.


    SWAP: Executes the REPLAY phase until the number of changes applied during the last scan of the staging table is less than the REPLAY_THRESHOLD value stored in the protocol table. The source table is then taken offline briefly to finish the final REPLAY, and then this command swaps the source table with target table and brings the table back online. SWAP can be used after the COPY phase has completed, but ideally after the REPLAY phase has been called.

    So.. "The source table is then taken offline briefly to finish the final REPLAY". 

    Let's suppose that are 1 million rows.. It would be worst than using reorg inplace, because the table would be unavailable even for reading...

    I don't know how, but we need an efficient real Online Reorg..