DB2 UDB Gets Organized
Reorganize support enhancements added in V5R3
by Jim Flanagan
Reorganize support for tables and physical files can be used to boost data-access performance or
reduce the amount of storage a table requires (i.e., after a massive delete operation). In the past,
you may have been unable to see these benefits because you couldn’t afford to take your tables
offline long enough to perform a complete table reorganization.
In V5R3, DB2* Universal Database* (UDB) reorganize support has taken a big step forward. It
can now be stopped and later resumed, which should make it viable to reorganize heavily used
tables. In addition, reorganize support can now be run online with options for allowing readlevel, or even update-level, access to rows in the table while the reorganization is running. This
article details these new features along with the iSeries* Navigator database interface that
enhances them.
Why Would I Want to Reorganize My Tables?
How you access your tables determines why you would want to reorganize them. For example,
some applications are written to process a table in arrival-sequence order, but you chose to not
reuse deleted records in the table. In this case, you would use the reorganize support to compress
out deleted rows, thereby reducing overall table size without affecting the remaining rows’
arrival sequence.
Tables created with SQL syntax are becoming more popular. These tables can reuse deleted
records, so table size may not grow with each inserted row. Rows can be added anywhere there’s
an open space in the table. However, this reuse behavior isn’t always good for querying the table.
If you access the data sequentially by a specific key sequence, or if you typically access a set of
rows with the same key, reorganization of the table can provide benefits for you. The query
optimizer takes the query statement being requested to run and decides on the best method to
access the rows. Consequently, the rows should be organized as efficiently as possible to help the
query optimizer accomplish this goal. The reorganization should make queries against the table
more efficient.
What are Reorganize’s New Capabilities?
Suspended reorganize support—With V5R3, reorganize support can be suspended and
resumed later. This is useful for large tables that you may not have reorganized in the past
because you didn’t have a long enough window to take the table offline to run the reorganization.
This capability lets you start the reorganize support during a time that suits your business needs
and then suspend the support when that window expires. You effectively get an incremental
reorganization of your table. Then when you have another window available, you can resume the
reorganize support from where it left off last time, or you can start from scratch if you made
significant changes to the table since you suspended the reorganization. Even this incremental
reorganization may increase the efficiency of accessing your table.
Online reorganize—You can also choose whether users can access a table during reorganization
(i.e., online reorganize). Online reorganize is beneficial to those who need to reorganize a table
but simply can’t allocate the table exclusively. This gives you two options for allowing user
access to the table while reorganize support is running—allow users read-level access or readand update-level access. Depending on your business needs, these two options can help keep
your business running while improving table-access performance.
Keep in mind that the reorganization takes longer if you allow users to access the table. Read
access allows you to keep running queries or reports while the table is being reorganized. If you
choose to allow update access, the reorganize support may be unable to put the rows in the exact
key order.
Index rebuild options—You can choose when (or if) to rebuild indexes built on the table you’re
reorganizing. This also has implications on the length of time required for the reorganization.
You can choose to have the indexes maintained during the reorganization (so a rebuild isn’t
necessary), after the reorganization or separate from the reorganization.
Having the indexes maintained during the reorganization provides faster access for query users
because changes to the index are made simultaneously with the data reorganization. Having the
indexes rebuilt at the end provides faster reorganization. However, queries that typically use the
indexes will be substantially impaired until the indexes are rebuilt, and any applications that
depend on the indexes will attempt to rebuild the indexes during open. Rebuilding the indexes
separate from the reorganization allows the reorganization to be done faster, but the indexes
won’t be rebuilt as part of the reorganization itself. They will be rebuilt in the background by a
separate system process. All of these new capabilities are available on the Reorganize Physical
File Member (RGZPFM) command.
One additional benefit to the new reorganize support is that if you have the symmetric
multiprocessing (SMP) option installed, it can run in parallel, enabling the reorganization to run
even faster. Prior to this support, only the index rebuild could be run in parallel. The
recommended degree to use is *NBRTASKS on the Change Query Attributes (CHGQRYA)
command. You would enter this command in the same job as, but prior to entering, the RGZPFM
command.
With the addition of the new capabilities, you now have a choice between two methods of
reorganize: traditional and new. One key difference between the two is that traditional needs
space to do a full copy to reorganize the table. The new method works on the table itself by
moving rows within the table as it’s performing the reorganization. Each of these has benefits
and drawbacks. In some cases, the traditional reorganize support is the best method and in others,
the new reorganize support is best. For more information on choosing the right method for your
situation, see Table 1. (Note: To take advantage of the new reorganize support, your table must
be journaled during the reorganization.)
Let’s Examine an Example
I’ll use the iSeries Navigator interface to highlight these new capabilities. First, launch the
iSeries Navigator application. Then on the left side, expand the system folder that you want to
work with. Next, expand the database folder within that system that you want to work with. Then
expand the schemas folder to find and expand the desired schema’s folder. Click on the Tables
folder to see a list of tables in the right pane. Finally, right-click on the table that you want to
reorganize, and select the Reorganize option (see Figure 1). Selecting the Reorganize menu
option displays the reorganize dialog in Figure 2.
The first choice on the reorganize dialog is whether to reorganize the table based on compressing
out existing deleted rows or based on a particular index. The latter option is useful if you have
specific applications that need fast access based on a certain index order. The options available
are SQL index or Table key, which means it’s a keyed physical file or has a primary key.
Next on the dialog are the new capabilities, the first of which is whether to allow the
reorganization to be suspended. If you want it to be suspended, then you can also select whether
you want users to read and/or write to the table during reorganization. Finally, you can select
when to rebuild the access paths. (Note: The Show Command button can be used to display the
RGZPFM command that will be submitted on your behalf.)
Once you’re satisfied with the selected reorganize dialog options, press the OK button, which
launches the reorganization progress dialog (see Figure 3). This dialog, a key enhancement to the
usability of the reorganize support in V5R3, allows you to see the various stages of the
reorganization as they occur. They’re represented in a tree structure and can be expanded or
collapsed based on what you want to see.
Figure 3 shows that there are two phases of reorganization. The Preparation phase is where the
reorganize process analyzes what needs to be done to reorganize the table and how many rows
will be reorganized. This is shown in the details area of Figure 3. The details area also shows the
options you chose to start the reorganize support. When the preparation phase is complete, it
starts the reorganization phase. The green arrows represent the steps the reorganize process is
working on, the blue arrows represent the steps that are yet to be run and the check marks
represent steps that have been completed.
Pressing the Suspend button processes the suspend request and suspends the reorganization. A
stop sign appears to the left of the steps that haven’t completed to signify they’ve been
suspended (see Figure 4).
If you chose to suspend the reorganize, resume it by selecting the table in iSeries Navigator and
reselecting the Reorganize option. This action checks the server to see if reorganization has been
suspended and asks if you’d like to resume the reorganization for that table.
At this point, you’ll see a dialog as shown in Figure 5, which allows you to either resume the
reorganization from where it was previously suspended or restart it from the beginning. This
flexibility is useful for situations when you forgot you suspended reorganization on a table or
when a batch job started running the reorganize support and ended abnormally so that the
reorganization wasn’t completed. If you answer no or the table has changed such that the
reorganize support determines the table needs a full reorganization, the reorganize support
resumes from the beginning.
Another feature of the Reorganize option on a table in iSeries Navigator is the ability to see a
currently running reorganization that was started by someone else either from iSeries Navigator
or the RGZPFM command. Select the table in iSeries Navigator, and select the Reorganize
option. The dialog shown in Figure 6 should be displayed. The question indicates that someone
has started the reorganize support on this table, and it’s still running. This will be useful for when
you arrive at work and want to view the status for any of your tables that you setup in a nightly
batch job. If you answer yes, you can view the reorganization progress, but you won’t be able to
cancel the reorganization from iSeries Navigator.
Constrained No More
The reorganize support’s new capabilities in V5R3 mean you’re no longer constrained to run
reorganize support in a dedicated time window. You can reorganize your tables that previously
couldn’t be reorganized, and with greater flexibility than ever before. So give it a try—you may
just be able to get that boost you’ve been looking for.
About the Author(s):
Jim Flanagan: Jim Flanagan has worked in database development for DB2 UDB for iSeries for
the last 10 years. He’s currently the team leader for the iSeries Navigator Database team. Jim can
be reached at jflanaga@us.ibm.com.