On 11-Jan-2012 14:10 , rob@xxxxxxxxx wrote:
Is this possible (RGZPFM) while the member is active?
Yes, data for a member can be reorganized using RGZPFM while the
member is actively being accessed either for read-only or for update in
other jobs\threads. The capability of the effective "Reorganize While
Active" is via the ALWCANCEL(*YES) specification. But the later
question and comment seem to acknowledge that possibility exists, so the
quoted\preceding question may intend to ask something other than what I
infer.?
Can I do it without invoking some option to create numerous journal
entries?
The "traditional" RGZPFM ALWCANCEL(*NO) deposits just one entry, but
the request requires exclusive access to the data. That request
performs effectively one dataspace operation versus individual row I\O
which involves potentially numerous row-level operations.
I am reading the ALWCANCEL(*YES) may involve numerous
journal entries.
Moving the data requires some level of tracking and the ability to
ensure atomicity of the movements. As such, there necessarily will be
logging which could be "numerous journal entries" when using the
row-level invocation versus the dataspace-level reorganize invocation.
There could instead be very few entries logged for the row-level
implementation, if either the deleted rows are already at the location
where they can be purged or when ordering the data much of the physical
data is already in the expected RRN.
Even if there is a large amount of logging required to complete all
of the work of reorganize, the effect can be spread over many separate
requests instead of tracked to just one request. For example using
*RPLDLTRCD, the work could be limited to 15 seconds at a time, having
obtained an *EXCLRD lock, easily allowing for 30-second waiters with
probably little impact; each 15-seconds of work limits the overall
logging required for each burst of work, after which any review and
cleanup can be done. Eventually after repeating the request many times,
over perhaps even days, the final effect eventually could be completed
within one final 15-second request. The locking level noted is just one
idea [to further limit the times when the request can run] and may not
be compatible with some applications [where the file will never be open
only for read-only], but any of the supported lock levels could be used;
then only row locks versus member\data locks and sufficient allowance
for any waiters.
Another option is to take a copy from a prior sync-point or save
[presumably of the database file network], and then apply any active
changes to the original [since the copy\save] to that alternate copy
after that copy has been reorganized; the copy can be reorganized
without any logging, or created as a copy without any deleted rows and
optional ordering. Of course any applied changes must by effected by
key rather than by RRN. Then /switch/ the active applications to the
new TABLE or database. If the application is not capable of switching,
probably easier to deal with the increased logging. However, great
benefits can come from enabling suspend and switch capabilities in an
application.
<<SNIP>>
Regards, Chuck
midrange.com
