IMS HALDB Online Reorganization - IBM

Copyright IBM Corp. 2009 IMS HALDB Online Reorganization 1

®

IBM Advanced Technical Support, Americas

© 2009 IBM Corporation

IMS HALDB Online Reorganization

Rich LewiszSeries Software - IMS

This presentation describes HALDB Online Reorganization (OLR). HALDB databases remain available to applications throughout the OLR reorganization process. OLR provides greater database availability by eliminating the major reason for database outages in many installations.

HALDB Online Reorganization was introduced in IMS Version 9. It is included in all subsequent releases of IMS.



2IMS HALDB Online Reorganization

HALDB Online Reorganization

HALDB Online Reorganization (OLR) is a standard part of IMS DBNot a feature, product, tool, etc.

BenefitsPHDAM and PHIDAM databases are reorganized100% availability of database during reorganization

Zero outagesApplications are unaffected– They never get data unavailable conditions

Full integrity and recoverability are maintainedEliminates database outages for reorganizationsSimple setup

HALDB Online Reorganization (OLR) is part of IMS Database. It is not a feature of IMS. It is not a separate product. It is included with the base IMS DB product without extra cost. This means that all users of full function databases have OLR available to them. OLR applies only to HALDB. It cannot be used to reorganize non-HALDB full function databases.

OLR reorganizes PHDAM and PHIDAM databases without taking any outages. The databases and partitions are never deallocated from the online system. Applications which are running concurrently with OLR are unaffected in the sense that they never receive data unavailable conditions.

Of course, full database integrity and recoverability are provided.

OLR provides greater database availability by eliminating the major reason for database outages in many installations.

The setup for OLR is extremely simple. This will be shown later in this presentation.




HALDB Online Reorganization Overview

EnvironmentsRuns in TM/DB or DBCTL systemConcurrent online and data sharing updates are allowedXRF and RSR are supported

RecoverabilitySystem, IMS, or media failuresDBRC support, standard recovery utilities, and DRF

PerformanceExternal parameter for pacingOLR is a “good citizen” in the online environment

OLR runs in an IMS online environment. This includes both IMS Transaction Manager with Database Manager and DBCTL systems.

While OLR is running, applications may update the database. These applications may run in the same IMS online system or in other data sharing IMS online systems or data sharing batch jobs. Both XRF and RSR are supported. All online environments in which HALDB is supported also support OLR.

Facilities are provided for recovery from system failures, IMS failures, and DASD media failures. This support uses the same techniques, utilities, and tools that are used for HALDB without OLR. DBRC tracks database recovery requirements as it does for all HALDB databases. Standard utilities such as Image Copy, Change Accumulation, and the Database Recovery utility may be used. Alternatively, the Database Recovery Facility tool may be used.

This presentation will include performance information. You will see that the speed at which OLR runs and at which it consumes resources may be adjusted with a parameter. OLR has been designed to be a good citizen in the online environment. Of course, it must do a lot of I/Os and do locking and logging as other online processes would do. But, it has been designed to limit the impact of these on other work in the system. Being a good citizen primarily means that OLR does not hold a lot of locks at any time and does not hold any locks for a long time. Its performance impact is similar to running a well-designed update BMP in the system.





HALDB PHDAM and PHIDAM onlyReorganize by partition

PHDAM data componentPHIDAM data component and primary index

Secondary indexes and logical relationshipsDatabase with secondary indexes can be reorganized

But secondary index (PSINDEX) CANNOT be reorganizedDatabase with logical relationships can be reorganizedILDS (ILEs) updated with new target RBAs

RestrictionsNo DBD changes (DBDS space allocation changes are OK)

An instance of OLR reorganizes a partition. Multiple instances of OLR may run concurrently and reorganize multiple partitions concurrently. OLR reorganizes the data component of PHDAM partitions. PHDAM does not have an index. OLR reorganizes both the data and index components of PHIDAM partitions.

OLR cannot be used to reorganize secondary indexes, but PHDAM and PHIDAM databases which have secondary indexes can be reorganized. Databases with logical relationships may be reorganized. The indirect list entries (ILEs) in the ILDS (Indirect List Data Set) are updated when secondary index or logical relationship targets are reorganized. This allows HALDB’s self-healing pointer process to resolve logical relationship and secondary index pointers when they are next used.

OLR cannot be used to restructure a database. DBD changes are not allowed. There are some changes that may be made to a database with OLR. These are changes to the space allocation of the database data sets. For example, the primary and secondary allocations and the KSDS free space parameters for the PHIDAM primary index may be changed with OLR.





OLR is an IMS task, not a batch jobStarted by IMS commandRuns under the DLISAS address spaceNot a dependent region or batch utility

Each OLR task reorganizes a partitionMultiple OLR tasks may run concurrently

Any number of partitions may be reorganized at the same time

OLR is NOT a batch job, dependent region, or batch utility. OLR is an online process which is started by an IMS command. The process runs as an IMS task (ITASK) under the DLI separate address space in an IMS online system.

Each OLR task reorganizes only one partition. You may reorganize any number of partitions in any number of HALDB databases concurrently by starting multiple OLRs concurrently.




HALDB Online Reorganization Technique

Online reorganization (OLR) is into new “partner” data setsA-J and X data sets alternate with M-V and Y data setsOnly one ILDS (L) per partition

Both sets of data sets are used during OLR

At end of OLR, old data sets may be discarded

100% availability of database during the reorganizationNo outagesNo data set renames

OLR reorganizes a partition by reading the segments from the existing data sets in a partition and writing the segments to new data sets. The existing PHIDAM index (X) and data (A-J) data sets have partner data sets. The partner for X is Y. The partner for A is M. The partner for B is N, etc. There is only one ILDS (L) for a partition. The updates to the ILEs are always done in this data set.

While an OLR is in progress both sets of partner data sets are actively used. When the OLR completes, the old data sets may be discarded.

Since both sets of data sets are actively used, there is no need to rename data sets at the end of OLR processing. IMS knows about all of the data sets used in the reorganization. This allows IMS to provide complete availability of the partition through the OLR process. There is no outage for the reorganization.




HALDB Naming ConventionsDDNAMEs

Partition name and data set letterPartition name: DJXK21DDNAMEs:– DJXK21L, DJXK21X, DJXK21A,

DJXK21B,…

Data set namesData set name prefix, data set letter, and partition id

DSN prefix: IMSP.DB.DJXABPartition id: 00001Data set names:– IMSP.DB.DJXAB.L00001– IMSP.DB.DJXAB.X00001– IMSP.DB.DJXAB.A00001– IMSP.DB.DJXAB.B00001– …

1 to 1001 partitions

…

…

ILDS

IndexPHIDAM only

Data set groups

L

…X

A

B

J

L…

X

A

B

J

…

…

…

This diagram shows the data sets in a HALDB database, their DDNAMEs, and their data set names. The data sets shown here are those that are used without OLR.

Each partition in a database has the same number of data sets. Each PHDAM or PHIDAM partition has an Indirect List Data Set (ILDS). The letter associated with the ILDS is L. Each PHIDAM partition has a primary index data set. The letter associated with the primary index data set is X. Each PHDAM or PHIDAM partition has one to ten data data sets. The letters associated with these data sets are A through J. If there is only one data set group, only the A data set exists. If there are two data set groups, the A and B data sets exist, etc.

DDNAMEs for the data sets are formed by adding the letter associated with the data set type to the partition name.

Data set names for the data sets are formed from the data set name prefix for the partition. This prefix is defined by the user. The suffix is composed of ‘.’ followed by the letter for the data set type and the partition id. The partition id is assigned by IMS when the partition is defined. Each partition in a database has a unique partition id.




Partner Data SetsIndex and data set group data sets have partners

Each X data set has a Y partnerEach A data set has an M partnerEach B data set has an N partner…

DDNAMEs differ by the letterFor example:

DJXK21ADJXK21M

Data set names differ by the letterFor example:

IMSP.DB.DJXAB.A00001IMSP.DB.DJXAB.M00001

1 to 1001 partitions

…

…

ILDS

IndexPHIDAM only

Data set groups

L

…X

A

B

J

Y

M

N

V

L…

X

A

B

J

Y

M

N

V

…

…

…

… …

When OLR is used each partition includes partner data sets. During the reorganization both sets of data sets exist. Typically, after a reorganization completes, only one set of data sets exists for a partition.

The HALDB naming convention is used for DDNAMEs and data set names. These naming conventions apply to the partner data sets as shown here.




Terminology

Before or after reorganizationActive data sets (either A-J, X or M-V, Y))

Data sets being accessed by applicationsInactive data sets

Data sets not being accessed by applications

During reorganizationAll data sets (A-J, X and M-V, Y) are active data setsInput data set: Contains unreorganized data

Includes both active and inactive dataOutput data set: Contains reorganized dataCursor

Dividing line between active data and inactive dataOnly used while reorganization in progress or suspended

This page explains the terminology used with OLR.

Active data sets are those that hold current data. During a reorganization both sets of partner data sets are active. Between reorganizations one set of partner data sets is active and the other set is inactive.

During a reorganization the input data sets are those being read by OLR and the output data sets are those being written by OLR. The reorganized segments are written into the output data sets.

A cursor is used to keep track of which database records have been written to the output data sets. For PHDAM the cursor is a Root Anchor Point (RAP). For PHIDAM the cursor is a root key. The cursor is only used during a reorganization. When a reorganization completes, the cursor is not needed.




Reorganization

Reorganize by copying segmentsRead segments from one set of HALDB data sets (e.g. A-J, X)Write (insert) segments to another set (e.g. M-V, Y)

Update ILDS for secondary index and logical relationship targetsUse locking protocols to provide concurrent access integrityLog inserts for recoverabilityUse cursor to identify which "set" to use to access a database record

Database records before cursor, use output data setsDatabase records after cursor, use input data sets

A-J

InputData Sets

OutputData Sets

YCopy

Copy X

L

ILDS

M-V

OLR reorganizes a partition by reading the segments from the input data sets and inserting them in the output data sets. If the inserted segment is a target of a secondary index or logical relationship its ILE is inserted or updated in the ILDS.

Since OLR runs in an online environment and since application programs may be reading and updating the partition, OLR must use locking protocols to provide integrity. It locks each database record that it reorganizes. If the online system uses block level data sharing for the reorganized database, OLR must also get block locks for any OSAM blocks or VSAM CIs which it updates.

Logging is required to support recoverability. Offline reorganizations do not produce a log. They require the user to image copy the database data sets after the reorganization. OLR does not require image copies, but it logs the inserts that it makes to the output data sets during the reorganization process. Since the segments in the input data set are not deleted, they are not logged.

The cursor is used to keep track of which database records have been copied to the output data sets. IMS uses the cursor when processing DL/I calls. The cursor tells IMS in which set of data sets the database record resides or should be inserted.




Copying Records During Reorganization

Unit of Reorganization (UOR) is a set of database records

Records are copied from input to output data setsRecords in UOR are locked while being copiedAt end of copy for UOR, the locks are releasedNumber of records in UOR is dynamically adjusted

Algorithm limits time taken, bytes copied, and locks held during copy

20

19

18

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

20

19

18

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

CopyUnit ofReorg.

A M

Already copied

Being copied

Active data

Not yet used

Cursor

This is conceptual diagram. It is not intended to show the physical location of segments before and after the reorganization. In practice, the segments could be in almost any block of the data set.

OLR reorganizes a set of database records at a time. This is called a Unit of Reorganization (UOR). OLR locks all of the database records in a UOR before it copies any of them to the output data sets. When the copy is complete, OLR commits the updates, moves the cursor, and releases the locks.

OLR has an algorithm to dynamically adjust the number of database records in a UOR. The algorithm attempts to make OLR a "good citizen" in the online system. It does this by limiting the number of locks held in any UOR, the time to complete the UOR, and the number of bytes moved in an UOR. The algorithm tends to limit the number of locks in a UOR to be less than 1000, to limit the time required for a UOR to be less than one second, and to limit the number of bytes copied to be less than 1M. It does this by dynamically adjusting the number of database records based on previous experience in the same execution of OLR.




Application Access During Online Reorganization

Cursor points to last committed reorganized record

PHDAM RAP RBAPHIDAM root key

Data set used is based on cursor valueCursor on record 6Access Record 5:

Access from M data setAccess Record 14:

Access from A data setAccess Record 9:

Wait for lock, – then access from M data set

* Access includes gets and updates

20

19

18

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

20

19

18

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

CopyUnit ofReorg.

A M

Already copied

Being copied

Active data

Not yet used

Cursor

This diagram shows that the cursor has been moved and OLR is processing a new UOR. This example is not realistic since it seems to show that the UOR contains only four database records. Typical UORs would have many more records.

In this example, the cursor is on database record 6. Records 7 through 10 are in the current UOR.

If an application program issues a DL/I call that requires record 5, IMS will access the record in the output data set which is M. IMS knows that the record is in the output data set since the cursor is on record 6.

If an application program issues a DL/I call that requires record 14, IMS will access the record in the input data set which is A. IMS knows that the record is in the input data set since the cursor is on record 6.

If an application program issues a DL/I call that requires record 9, IMS will force the application to wait since its call will result in a request for the database record lock on record 9. This record has already been locked by OLR since it is in the UOR. When the UOR has been processed, OLR will move the cursor to record 10 and release the lock on record 9. Then IMS will access the record from the output data set which is M.




Completion of Reorganization

When OLR completesA-J,X becomes the "inactive" set - may be deletedM-V,Y becomes the "active" set

Cursor reset to inactive

ILDS (ILEs) updated during reorganization

A-J

InputData Sets

OutputData Sets

YX

L

ILDS

M-V

When OLR completes for the partition, all of the data is in the output data sets. The cursor is inactive. It is no longer needed to determine where the data records are. The input data sets are no longer used. The ILDS has been updated with the new locations of the targets of secondary indexes and logical relationships.




Next Reorganization

Next reorganizationReorganize from M-V,Y to A-J,XA-J, X data sets may be reused

OrA-J, X data sets may be reallocated

A-J

OutputData Sets

InputData Sets

YCopy

Copy X

L

ILDS

M-V

When the next reorganization of the partition is done, the data will be read from the M-V and Y data sets and written to the A-J and X data sets.

When using OLR a set of data sets will typically be in use about half the time. HALDB has been designed to handle this. As we will see, users typically don’t have to know which data sets are active. IMS determines this from the information in the RECONs.




Setting Up Online Reorganization

DBRC is used to set online reorganization capability for a database

INIT.DB DBD(HALDB_master) OLRCAP|OLRNOCAP

CHANGE.DB DBD(HALDB_master) OLRCAP|OLRNOCAP

OLRCAP allows online reorganization for partitions of the database

Implementing online reorganization is simple. You only have to issue a DBRC command to make the HALDB eligible for OLR and then issue a command to invoke OLR for a partition. The CHANGE.DB command with the OLRCAP is used to do this. It makes all of the partitions in a database eligible for OLR. If you use the INIT.DB command to register a new HALDB you may specify OLRCAP or OLRNOCAP on the command. The "online reorganization capable" flag must be set for a database before OLR may be invoked for any of its partitions.

Since the M-V and Y data sets are only used with databases which are OLR capable, OLRNOCAP cannot be set when they are active.

Since online reorganization cannot be used for secondary indexes, OLRCAP is invalid for CHANGE.DB and INIT.DB with PSINDEX databases.




Setting Up Online Reorganization

Simple setupOne command completes OLR set up for a database

CHANGE.DB DBD(master_dbname) OLRCAP

User does not have to do the following:Allocate new database data setsRegister new database data sets in DBRCAdd news database data sets to database buffer pool definitionsCreate different Image Copy jobs for the new database data setsAdd new database data sets to Change Accum groups

These tasks are done automatically by IMS

As stated before, implementing online reorganization is simple. Most of the set up is done automatically by IMS. All the user has to do is to set the “online reorganization capable” flag for the database by issuing the CHANGE.DB command with the OLRCAP parameter.

OLR can automatically allocate the new database data sets. These data sets are automatically registered in the DBRC RECONs. DBRC commands are not required to do this registration. The new data sets are automatically assigned to the same database buffer pool to which their partner data sets are assigned. The same job may be used to image copy either of the partner data sets. The image copy utilities copy only the active data set. The new data sets are automatically included in the same Change Accum group to which their partner data sets belong.




Output Data Set Creation

Output data set allocation optionsPreallocation by userAutomatic allocation by OLR

Invoked for each data set which is not cataloged– Invoked on data set by data set basis

Why preallocate?Want to allocate on specific volumeChange space allocation

Blocks/CIs– Primary and secondary allocationsFor PHIDAM Primary Index– Free space percentageMay be used to avoid or react to an out-of-space condition (U0844 abend)

You may preallocate the output data sets before OLR is invoked. Alternatively, you may let OLR allocate the data sets. If OLR allocates the data sets, they are allocated with the same characteristics as the existing data sets. If you want to change any characteristics, you may allocate the data sets before OLR is invoked.

The most typical reason for preallocation would be to change the primary or secondary space allocations or to change the free space percentage in a PHIDAM primary index.

The PHIDAM primary index CI size cannot be changed during an OLR. It must remain the same.

OLR can be used to avoid or react to out-of-space conditions for database data sets. When IMS cannot find space to insert a segment in a database, that application program receives a U0844 abend. The database is still usable, but inserts cannot be done unless deletes create sufficient free space. If an installation notices that the available free space in a data set is becoming critical, it may preallocate a larger data set and invoke OLR. This could avoid the abend.

Even if the abend occurs, OLR may be used. Without OLR recovery requires an outage. The partition is unloaded, new larger data sets are allocated, and the partition is reloaded. This requires an outage for the partition. With OLR a larger data set may be created and an OLR started. The outage is not required and the time over which more segments cannot be inserted in the database is reduced.




Output Data Set Creation

Automatic output data set creationSpace is equivalent to existing input data set

Requested as a number of OSAM blocks or VSAM recordsSMS-managed

Same storage class as input data setSame number of volumes as input data setWith guaranteed space attribute, primary space allocation is taken on all volumes

Non-SMS, OSAMUNIT=SYSALLDA is used (storage or public volume)If input is multivolume data set, output data set is not created

Non-SMS, VSAMData set is allocated on the same volume(s) as input data set

When OLR allocates the data sets, it attempts to allocate them with the same characteristics as the input data sets. In order to reserve approximately the same amount of space that was allocated for the input data set regardless of the DASD types involved, the output data set's space is requested as a number of OSAM blocks or VSAM records.

If the input data set is SMS-managed, the output data set is also SMS-managed. The same SMS parameters, such as storage class, are used.

Non-SMS managed OSAM data sets are allocated as though UNIT=SYSALLDA had been specified on a DD statement. SYSALLDA contains all direct access devices assigned to the system. If a storage volume is available, it is used. If a storage volume is not available, a public volume is used.

Non-SMS managed VSAM data sets are allocated on the same volume(s) as the input data set. This makes the use of dynamic allocation for non-SMS managed VSAM data sets impractical in many environments.




Starting Online Reorganization

Command to initiate OLROM command (type-2 command):INIT OLREORG NAME(partname1, partname2,...)

Classic command (type-1 command):/INIT OLREORG NAME(partname1)

May be issued by an application program CMD or ICMD callCommand parameters:

Delete input data sets at completion of reorganizationOPTION(DEL|NODEL)

Set rate of executionSET(RATE(100|nn)

OLR may be started with an INIT command or a /INIT command. INIT is a type-2 command. /INIT is a type-1 command. IMS Version 9 introduces new terminology for commands. Type-2 commands are those that were called OM commands or IMSplex commands in IMS Version 8. Type-1 commands were called classic commands in IMS Version 8. Type-2 commands are entered through the Operations Manager (OM) interface. They may be issued from the TSO SPOC, the IMS Control Center, a REXX exec, or any other user of the OM interface. Type-1 commands may be issued from an IMS terminal, such as the master terminal, or from an application program.

The INIT and /INIT commands have two optional parameters.

OPTION(DEL) or OPTION(NODEL) specifies if the input data sets should be deleted when the OLR completes. Typically, you would want to specify DEL since the old data sets are no longer useful. When the data sets are deleted the RECON records for them are NOT deleted. That is, the DBDS, IC, ALLOC, REORG, and RECOV records for the data sets remain in the RECONs.

The RATE(nn) parameter sets the rate at which the OLR will run. This is explained on the next page.




Rate Parameter

RATE parameter on INITRATE parameter determines how fast the reorganization runs

RATE(100) - runs at maximum speedRATE(nn) - online reorganization waits after each commit so that average speed of reorganization is nn% of maximum speed

Examples:If RATE(50), after each commit reorganization waits for the time that the last interval took– Possibly, run 1 second, wait 1 second, run 1 second, wait 1 second,...If RATE(25), after each commit reorganization waits for 3 times as long as the last interval took– Possibly, run 1 second, wait 3 seconds, run 1 second, wait 3 seconds,...

The RATE parameter may be used to limit the rate at which resources are used by OLR. Most installations will choose to run at RATE(100) which is the default. This allows OLR to complete as quickly as possible. On the other hand, RATE can slow down OLR’s consumption of resources such as CPU and I/Os. When a RATE of less than 100 percent is specified, OLR waits at the end of each Unit of Reorganization (UOR). OLR runs at full speed while processing a UOR. It does this to limit the time over which it holds locks on database records and blocks.




Modifying Reorganization in Progress

Command to modify OLR in progressOM command (type-2 command):UPD OLREORG NAME(*|partname1, partname2,...)

Classic command (type-1 command):/UPD OLREORG NAME(partname1)

Command parameters:Change delete option for input data setsOPTION(DEL|NODEL)

Change rate of executionSET(RATE(100|nn)

The UPD and /UPD commands may be used to change the delete option (DEL or NODEL) or the RATE while OLR is executing. The new selections are invoked immediately.




Suspending and Restarting Online Reorganization

Reorganization may be suspendedCommands:

TERM command (type-2) example:TERM OLREORG NAME(PVHDJ5A)

/TERM command (type-1) example:/TERM OLREORG NAME(PVHDJ5A)

Input and output data sets remain activeCursor remains active

Suspended reorganization may be restartedINIT and /INIT command will restart the reorganization

Restarts from the point of the cursor Restart may be on the same IMS system or another IMS system

The type-2 TERM command or type-1 /TERM command may be used to suspend an OLR. The OLR stops but both sets of data sets remain active and the cursor remains active. The OLR will need to be restarted so that it can complete. The restart is done by issuing the INIT or /INIT command. The restarted OLR will begin at the point of the cursor.

You may move a OLR from one IMS data sharing system to another by using the TERM command on one system followed by the INIT command on the other.




OLR Messages

OLR startDFS2970I OLR STARTED FOR NAME=partname

Normal completionDFS2974I OLR COMPLETED FOR NAME=partname

Termination before completionSuch as suspended by TERM command

DFS2971W OLR TERMINATED FOR NAME=partname RC=xx RS=yy

ResumptionSuch as after suspension by TERM command

DFS2970I OLR RESUMED FOR NAME=partname

When OLR is initiated, the DFS2970I message with OLR STARTED is issued.

When the OLR completes, message DFS2974I is issued.

If OLR terminates before completion, the DFS2971W message is issued with a return code and reason code. They indicate the reason for the termination. The termination could be the result of a TERM command.

When OLR is resumed after a termination, the DFS2970I message with OLR RESUMED is issued.

Installations may want to react to these messages for automation purposes.




Commands to Show Status of Reorganization

QRY command (type-2) example:QRY OLREORG NAME(POHIDKA) SHOW(ALL)

Response:Partition MbrName CC LclStat Rate Bytes-Moved Segs-MovedPOHIDKA IMS1 0 WAITRATE 50 334720 2310

Roots-Moved Option Start 250 NODEL 2009.027 11:50:41.35

/DIS command (type-1) example:/DIS DB OLR

Response:DATABASE PART RATE BYTES SEGS ROOTS STARTTIM DBHDOJ01 PDHDOJD 50 72156778 423551 72686 08107/115049

STATUS WAITRATE, OPTNODEL

The type-2 QRY OLREORG command or the type-1 /DIS DB OLR command may be used to show the current status of OLR.

The responses in these examples include the enhancements made as a result of IMS 10 APARs PK54615 and PK54616 and IMS Version 9 APARs PK36909 and PK43203. Before these enhancements only the number of bytes moved was shown in the response. The enhancements added the number of segments moved and the number of roots moved as well as the start time fo the OLR. These statistics allow you to estimate how far the OLR is in completing the reorganization.

The first example shows a QUERY OLREORG command. The response is shown as it would be displayed by the TSO SPOC.

The second example shows a /DIS DB OLR command. The response shows all OLRs that are currently active in this IMS.

Both examples include "WAITRATE" in the status of the OLRs. This indicates that the reorganization is currently waiting as a result of the RATE parameter. Since the rate parameters are 50 in these examples, the reorganizations should have a WAITRATE status approximately 50 percent of the time.

If a reorganization is suspended with a TERM or /TERM command and restarted, the data shown will include the bytes, segments, and roots moved during the entire reorganization, including those moved before the TERM or /TERM command.




DBRC LIST Command with Suspended OLR

LIST.RECON or LIST.DB output includes suspended OLR statisticsThese statistics are saved in the RECONs by the /TERM or TERM command

They are deleted from the RECONs when the OLR is restarted

Example statistics:

ONLINE REORG STATISTICS: OLR BYTES MOVED = 72156486 OLR SEGMENTS MOVED = 423256 OLR ROOT SEGMENTS MOVED = 72234

This capability was delivered through APARs PK54615 for IMS Version 10 and PK36909 for IMS Version 9. When an online reorganization is suspended with a TERMINATE or /TERMINATE command, the statistics are stored in the RECONs. A LIST.RECON or LIST.DB command may be used to see these statistics. When the online reorganization is restarted with an INIT or /INIT command, the statistics are deleted from the RECONs but are used by the restarted OLR. QUERY OLREORG or /DIS DB OLR commands will show the statistics for the entire reorganization including the bytes, segments, and roots moved before the suspension.




IMS Normal Termination with OLR Active

If OLR is running when IMS is shutdown/CHE FREEZE or /CHE DUMPQ

OLR is terminated at next commit– Cursor remains active– Ownership of OLR by this IMS is not relinquished

/CHE PURGEWaits for OLR to complete

When IMS is restarted after termination with OLR active/NRE

Authorizes, allocates, and opens all input and output data setsResumes OLR automatically

If OLR is active when IMS is terminated by a /CHE FREEZE or /CHE DUMPQ command, OLR is suspended when the current UOR is committed. The cursor remains active and the ownership of the OLR by this IMS is not relinquished. OLR cannot be resumed on another IMS.

If OLR is active when IMS is terminated by a /CHE PURGE command, IMS termination waits for OLR to complete before IMS termination completes.

When IMS is restarted after a termination by /CHE FREEZE or /CHE DUMPQ with OLR active, the OLR is automatically restarted. No commands are required on the restarted system.




IMS Abnormal Termination with OLR Active

If OLR is running when IMS failsIf FDBR is active, FDBR

Backs out in-flight Unit of ReorganizationReleases data sharing locks

/ERE Backs out in-flight Unit of Reorganization – If FDBR has not done itResumes OLR automatically

If an IMS system fails with OLR active, OLR is treated much like an in-flight application program.

If a Fast Database Recovery (FDBR) system is active for this IMS, it backs out the in-flight UOR and releases its locks. This allows other IMS systems to access and update all of the data. If an FDBR is not active for this IMS, emergency restart backs out the in-flight UOR and releases the locks.

In either case emergency restart automatically restarts the OLR.




IMS Cold Start

If OLR is running when IMS is terminated normally before a cold startOLR is not restarted by cold startINIT or /INIT command may be used to resume OLR

A better procedure:Before IMS normal termination operator should suspend OLR

Use TERM OLR commandIf data sharing user

OLR may restarted on another IMS immediately– Use INIT OLR command

If not data sharing user,After restart operator may restart OLR– Use INIT OLR command

If, instead of a warm start, IMS were restarted with a cold start, OLR would not be resumed automatically. The operator should restart the OLR with an INIT or /INIT command. Since the OLR is owned by this IMS, OLR could not be restarted on another IMS system.

If you are planning on terminating an IMS system and then cold starting it, you would probably let any active OLR complete. Alternatively, you may suspend any active OLR with a TERM or /TERM command before terminating IMS. This releases ownership of the OLR. Then, the OLR may be restarted on another data sharing IMS system. Of course, you may also restart the OLR on the same IMS system after it is cold started.




Logging By Online Reorganization

Log records writtenScheduling (x’08’)Termination (x’07’)UOR sync point (x’3730’)

For each UORUOR statistics (x’2950’)

For each UORDatabase change (x’50’)

For all output data in the partition– This will be voluminous!

OLR writes an x'08' log record when it is scheduled. This is the application program schedule log record which is also written for IMS application programs. The PSB name used for OLR is generated from the partition name. An x'F0' (C'0') is prefixed to the partition name to form the PSB name.

OLR writes an x'07' log record when it terminates. This is the application program termination log record which is also written for IMS application programs.

When each UOR is committed, an x'3730' sync point log record and an x’2950’ UOR statistics record are written.

Database change log records (type x'50') are written for inserts and updates to the output data sets. In IMS Versions 9 and 10 these are the same log records that are written for other updates to full function databases. Since OLR writes every segment in a partition, these log records will be voluminous. IMS Version 11 makes changes to logging. Instead of logging each segment as it is inserted in an output data set, it accumulates changes in the same OSAM block or VSAM CI and writes one log record for multiple updates. This is explained later under "Performance Enhancements in IMS Version 11."




Logging By Online Reorganization

UOR statistics log record (x’2950’)Written for each UORData:

Total segments moved before this UORTotal bytes moved before this UORRoots moved in UORSegments moved in UORBytes moved in UORLocks held by UORStart time of UORExecution time (elapsed time) of UORTime interval waited before this UOR (due to RATE parameter)

The x'2950' is written for each UOR. It includes the new location of the cursor and statistics about the UOR. These statistics may be used to understand the performance characteristics of an OLR execution.




Image Copies

Any image copy utility or tool may be used:Image CopyImage Copy 2Online Image CopyHigh Performance Image Copy

Active data set is copiedControl statement may specify A-J or M-V DDNAME

Image copy utilities determine which data set to copy– Copies active data set even when inactive partner is specified

Dynamic allocation allocates the active data set

Image Copy is not allowed while cursor is activeOnline reorganization is active

or Online reorganization is suspended

The Image Copy, Image Copy 2, and Online Image Copy utilities and the High Performance Image Copy tool may be used to create image copies of HALDB data sets.

The Image Copy utilities and tool always copy the active data set of a pair of partner data sets. If your control statement specifies the A data set, but the M data set is active, the M data set will be copied. This means that you do not need to be aware of which data sets are active when running image copies. Dynamic allocation will allocate the active database data set. This simplifies the use of image copy. There is a case where the use of static allocation will cause a failure. If the DD statement specifies an inactive data set which no longer exists, the job will fail due to a "data set not found" condition. For this reason, you should not include a DD statement for the input data set. Let dynamic allocation allocate the correct data set.

Image copy writes only one output data set, so image copies are not allowed while OLR is running or suspended. In other words, image copies are not allowed while both partner data sets are active. This is OK. Image copies are not required to recover the output data sets of OLR. Recoveries using only log data are allowed.




Change AccumulationDBRC places partner data sets in the same change accum group

A and M data sets for a partition are in the same groupB and N data sets for a partition are in the same groupC and O data sets for a partition are in the same group…

GENJCL.CA treats start of OLR as purge time for output data setsLog records from times before start of OLR are not used in later recoveries

Change Accumulation utility is unchanged for online reorganizationAccumulates changes for all data sets specified on its control statements

GENJCL.CA generates the correct control statements

High Performance Change Accumulation tool It may be used in place of the Change Accumulation utility

DBRC places partner data sets in the same Change Accum groups. This is done automatically. The user does not have to issue any DBRC commands for this. Instead, when the first OLR is done for the partition, IMS automatically creates the appropriate records in the RECONs.

The start time for OLR should be treated as a purge time for the output data sets by Change Accumulation. This is similar to the requirement for offline reorganizations. Purge times are used to exclude previous database change log records from recoveries after the reorganization. GENJCL.CA creates the correct control statements including the purge time for the output data sets.

Changes to support Change Accum with OLR were done in DBRC. No changes were required for the Change Accumulation utility. The utility processes whichever data sets are included in its control cards. DBRC always places partner data sets in the same Change Accumulation group. So, when GENJCL.CA is used, partner data sets will always be in the same group.

The High Performance Change Accumulation tool may be used in place of the Change Accumulation utility. HPCA has full support for HALDB database data sets.




Database Recovery

Database Recovery (DFSURDB0)Recovers A-J or M-V data setFull recovery

Allowed at any timeMay be to time when OLR was active or suspended

Timestamp recovery Not allowed to time when OLR was active or suspended– DRF tool may be used for this type of timestamp recovery

Recovery of data set reorganized by OLR (output data set)Does not require image copy– Log only recovery is valid

The Database Recovery utility (DFSURDB0) is used to recover database data sets. This includes the partner data sets used with OLR. Database Recovery recovers one data set. This data set must be correctly specified in the utility's control statement. Unlike other uses of HALDB, dynamic allocation is not used by Database Recovery. The correct DD statement must be included. GENJCL.RECOV will include the DD statement.

Full recoveries may be done at any time for database data sets that are participants in OLR. Of course, the partition must be /DBRed for the full recovery.

Timestamp recoveries cannot be done to a time in the middle of an OLR. This is true even if the time is one at which the OLR was suspended with a TERM command. If a user attempts a timestamp recovery to a time between the start and stop times of an OLR, the utility detects this and will not execute. GENJCL.RECOV also detects this situation and will not generate recovery JCL. We will see later that the Database Recovery Facility tool may be used for timestamp recoveries.

The Database Recovery utility does not require an image copy input. If the data set was the output of OLR, it can be recovered from log records and/or a Change Accumulation data set without image copy input. In this case, the DFSUDUMP DD statement must specify DUMMY.




Database Recovery Facility (DRF)

Database Recovery Facility (IBM Tool)Recovers active data sets

Understands which data sets to recoverFull recovery

Allowed at any timeTimestamp recovery

Allowed to any time– Includes PITR (point-in-time) capability

The Database Recovery Facility (DRF) tool (5655-N47) uses DBRC information to decide which data sets, A-J or M-V, to recover. It recovers the data sets which were active at the time specified for the recovery. If OLR was in process at the time to which the recovery is being done, then both active and inactive are selected, otherwise only the active data sets are recovered. This is true even when a data set DDNAME is specified with the /REC ADD DBDS dbname ddname command. If the ddname specified in the command was inactive at the recovery time, its partner data set is recovered.

DRF may be used for timestamp recoveries. The recovery time may be one at which OLR was active. This capability does not exist for the Database Recovery utility (DFSURDB0). The timestamp recovery capability in DRF includes Point-in-Time Recovery (PITR). This allows the user to specify any time, even a time at which there were uncommitted updates for the partition. When PITR is used, DRF only applies the updates that have been committed.




Buffer Pool Assignments

Partner data sets are assigned to the same buffer poolsNew buffer pool assignments in DFSVSMxx are not required

Assigning X data set to a pool also assigns Y data set to the pool Assigning A data set to a pool also assigns M data set to the poolAssigning B data set to a pool also assigns N data set to the poolAssigning C data set to a pool also assigns O data set to the pool…

When implementing OLR you do not need to make any changes to the buffer pool definitions in the online DFSVSMxx member or the DFSVSAMP DD data set used by batch jobs or utilities. The M-V and Y data sets are assigned to the same buffer pools as their partner data sets.




DBRC with OLROLR data kept in the RECONs

OLR capable flag for databaseIndicators of which data sets are active (A-J and X, M-V and Y, or both)SSID of the IMS which has ownership of an OLR

Each partner data set has its own DBDS, IC, ALLOC, RECOV, and REORG records

These records are kept even when the data sets are deleted

Image Copy Records in the RECONsGENMAX and RECOVPD values are propagated to their partner data setsGENMAX values apply to the pair of partner data sets

GENMAX(3) means that DBRC will keep the last 3 IC records for A or M.– It could be 2 IC records for A and 1 IC record for MImage Copy of data set M could delete IC record for data set A

DBRC maintains data about OLR in the RECONs. The OLR capable flag is maintained in the database record for the master database. It is also propagated to the database records for the partitions of the database. The database record for each partition indicates which set of data sets (A-J and X or M-V and Y) is active. If both sets are active, the partition database record indicates which is the input set and which is the output set. When an OLR is active or suspended for a partition, the database record for the partition indicates which IMS system has ownership of the OLR.

Each data set has it own DBDS, IC, ALLOC, RECOV, and REORG records in the RECONs. The DBDS record for the M-V and Y data sets are created when the first OLR is done for the partition. These data sets are placed in the same Change Accum groups and Data Set groups as their partners. The DBDS, IC, ALLOC, RECOV, and REORG records are kept in the RECONs even when the database data sets are deleted. This allows DBRC to generate correct JCL for timestamp recoveries to times preceding executions of OLR.

The Image Copy GENMAX and RECOVPD values for data sets apply to both partners. If you specify a value for A, the same value is used for M. DBRC treats partner data sets together when evaluating GENMAX. The GENMAX value indicates the minimum number of IC records to keep for the pair of partner data sets. For example, if you specify GENMAX(3) for the A data set, DBRC maintains at least three IC records for the combination of the A and M data sets. You could have two IC records for A and one IC record for M. This means that an Image Copy of the M data set could delete an IC record for the A data set.




Performance Considerations

OLR will use more resources than offline reorganizationsLocking, logging, and buffer sharing overhead

Similar to overhead of an update BMP

Logging may affect performanceAll data is logged when moved

Bytes logged by OLR will exceed the number of bytes in the partitionA few additional log records

Buffer pool contentionPartner data sets use the same buffer pool

Appropriate for times when reorganization is not runningCould cause buffer contention during reorganization– Contention is less likely with large buffer pools

OSAM sequential buffering may be usedRecommended

OLR uses more resources than an offline reorganization of the same partition. Since OLR runs in an online system, it must acquire locks, log updates, and share the online system buffer pools. This is similar to the requirements of an update BMP. These processes use more resources than an offline process. Of course, OLR has the advantage that the partition remains available while the reorganization is done.

Since OLR logs all of the data that it places in the output data sets, the logging increase can be substantial. Each log record has a prefix. So, the number of bytes logged by OLR will be greater than the number of bytes for the segments in the partition. OLR writes some additional log records, such as those for initiation and termination, but their effect should be insignificant when compared to the database change log records for the output data sets. IMS Version 11 reduces the logging done by OLR. This is explained later.

OLR makes intensive use of buffer pools for the data sets it is reading and writing. Partner data sets always use the same pool or subpool. This is appropriate for the times when OLR is not active. When OLR is active it could increase the contention for buffers. Contention is minimized when buffer pools or subpools have a large number of buffers.

OSAM sequential buffering is recommended since the reads of the input data sets will tend to be sequential. OSAM sequential buffering is automatically used by OLR when it is enabled in the online system. This is done by including a SBONLINE statement in the DFSVSMxx member.





Lock contentionShould be minimal

OLR has dynamic algorithm to limit the time that locks are heldOLR rarely causes a deadlock

Asks for database record locks conditionally– If lock is not available, the UOR is shortenedOLR is always the victim in its deadlocks– Application continues– OLR is dynamically backed out

– Only the current UOR is backed out– OLR is automatically restarted at the current cursor position

OLR could create lock contention, but this is likely to be minimal. OLR limits the size of its UORs in an attempt to hold locks for no more than a second. That is, its algorithm for UOR size includes an adjustment to limit the times that locks are held. The data base record locks on PHDAM RAPs and PHIDAM roots are exclusive locks. Applications requesting locks on these resources will wait until they are released at the end of a UOR. Block locks are obtained on output data set OSAM blocks and VSAM CIs. Data sharing users could be affected by these locks. They prevent updates of the same block or CI. They do not prevent reads of other database records in the blocks and CIs.

Locking of database records by OLR never causes a deadlock. This is true because OLR always uses conditional lock requests when already holding a lock. This means that if the requested lock is not available, OLR does not wait for it. Instead, it ends the UOR at the current location.

OLR requests block locks unconditionally. These lock requests could cause a deadlock in a data sharing environment. When OLR creates a deadlock, it is the victim. The other participant(s) in the deadlock are not affected. OLR is dynamically backed out and automatically restarted.





Online reorganization runs in DL/I address spaceEach reorganization uses one of 10 database TCBs

Same TCBs that are used for allocation and open/close/EOV processing

Online reorganization may run on any data sharing IMS systemSome installations may choose to dedicate an IMS to OLR

Buffer pool definitions may be tuned for OLRAvoids buffer contentionAvoids logging contentionLimits the number of data sets with updates on the log– Logs are not required for change accum or recovery of other data sets

OLR runs under a TCB in the DL/I separate address space of the online system. Each OLR process uses one of the ten database TCBs. These are the TCBs also used for open/close/EOV processing. This does not limit the number of OLRs that may run at any time. It only limits the number that may be dispatched at any time. Since OLR tends to be an I/O intensive process, this should have minimal effects.

Installations using Parallel Sysplex IMS data sharing might create an IMS online system dedicated to OLRs. There are several advantages to this. There would be no buffer contention with applications. Buffer pools could be tuned for OLR work. The most important advantage would be the isolation of the logs. The log records written by OLR would be on the “OLR system” logs. If a CA Group does not contain any of these database data sets, it will not need logs produced by this IMS system. Similarly, if a database recovery is run for a data set not using OLR, it would not need logs produced by this IMS system. This could reduce the number of log records read by Change Accum or Database Recovery.




Performance Enhancements in IMS Version 11

Invoke sequential access for VSAM KSDS get processingReduces CPU and elapsed time

Eliminate GNP Call for Root-only DB Reduces CPU and elapsed time

Reduce use of the data set busy (ZID) lock Updates for PHIDAM primary index are saved for insertion at the end of each unit of reorganization (UOR) so that the ZID lock is requested once per UOR. Reduces CPU and elapsed time

Eliminate block locks for ILDS updatesReduces CPU and elapsed time

IMS Version 11 improves the performance of HALDB Online Reorganization in six ways.

OLR VSAM KSDS Sequential AccessOLR is enhanced to take advantage of the VSAM sequential access option when issuing KSDS GET requests to retrieve sequentially from the input data set(s). This results in reduction in CPU and elapsed time.

Eliminate GNP Call for Root-only DB For a root-only database, there is no reason to issue the GNP call since there is no dependent segment to be read. Eliminating the GNP call saves CPU and elapsed time.

Reduce use of the data set busy (ZID) lock during OLR For a PHIDAM partition undergoing reorganization by OLR the updates for the primary index (KSDS) can be saved for insertion at the end of the unit of reorganization (UOR). By saving all the KSDS updates until the end of the UOR, the usage of the ZID lock for the primary index can be UOR changed. The change will be to obtain the ZID once before starting to insert all the saved primary index updates, and then released once. When the UOR covers many roots, many ZID lock requests will be eliminated which will result in a reduction of CPU usage and elapsed time.

Eliminate block locks for ILDS updatesFor a HALDB partition with logical relationships or secondary indexes the updates for the indirect list dataset (ILDS) by OLR do not need to obtain the block (BID) lock. The BID lock is used for serialization of the updates to a block across IMS subsystems. The design of HALDB doesn't allow the ILDS to be updated by more than one IMS at a time since the ILDS is updated only by reorganizations and reorganizations for a partition are serialized.




Performance Enhancements in IMS Version 11

Consolidate multiple updates for a block into one log recordReduces logging, CPU, and elapsed time

Implement IRLM lock look-aside Avoids requesting a lock which is already heldReduces CPU and elapsed time

BenefitsReduced CPU consumptionShortened elapsed timesReduced logging

Log reduction

For a HALDB partition undergoing OLR, the database update log records (type '50'x) will be consolidated when possible into full block updates. By combining all the updates for a full block into a single type '50'x log record, many of the small type '50'x log records will be eliminated. This will result in a reduction in the log volume generated by OLR. This can be significant. Typically, OLR has created three log records for each segment. There is one for the segment, one for the update of the pointer to the segment, and one for the change in free space. Since each type x'50' log record has a prefix of approximately 200 bytes, each segment generates log records of approximately 600 bytes plus the size of the segment. The reduction in the number of log records will significantly reduce the logging volume.

Lock reduction

Provide a lock look-aside function to reduce the number of times a lock request goes to the IRLM. The OLR process issues many lock requests to the IRLM. Many of these locks are already owned. By providing an IMS managed look-aside table for these locks, we can reduce the number of calls to the IRLM.

These improvements result in less CPU consumption, shortened elapsed times, and reduced logging with IMS Version 11.




Performance Considerations Summary

OLR is similar to an update BMP in its performance costsBMP which reads and updates every segment in a partition

I/Os– Reads every block of the input data sets– Writes every block of the output data sets– Heavy user of database buffer poolsLocking– Locks every database record– Locks every block in the output data sets if data sharingLogging– Logs everything it writesSimilar to well behaved BMP– OLR does not hold many locks at any time– OLR does not hold any locks for a long time

The performance affects of running OLR are similar to those for running an update BMP which updates every segment in a partition.

OLR reads every segment from the input data sets. Thus, it must read every block or CI unless there are empty blocks or CIs. OLR writes every block or CI in the output data sets. This makes OLR a heavy user of I/Os and a heavy user of database buffer pools.

OLR must lock every database record. For PHIDAM this is a lock on each root segment. For PHDAM this is a lock on each RAP. If data sharing is used, OLR must get a lock on every block or CI that it writes. This is what an update BMP that updates every database record and writes updates to every block would do.

OLR must log everything that it writes. This is similar to what a BMP that replaced every byte of every segment in a partition would do. Generally, update BMPs would not update every byte of every segment, so OLR is likely to log more than any update BMP that processed the partition. Before IMS Version 11, OLR logs every segment update with its own log records. IMS Version 11 changes this. IMS Version 11 attempts to log all changes to an OSAM block or VSAM CI with one log record. This can reduce the number of log records written and the amount of logging that is done.

The good news is that OLR does not hold a lot of locks at any time and does not hold any lock for a long time. In this sense, it has the performance characteristics of a well behaved heavy update BMP.




HALDB Online Reorganization Summary

HALDB Online Reorganization is included in IMS DBNot a feature, product, tool, etc.

BenefitsFast and efficient reorganizations

Full integrity and recoverability are maintained

Eliminates database outages for reorganizations

Simple setup

OLR is the next large step in the enhancements to IMS full function databases. It provides greater database availability by eliminating the major reason for database outages in many installations.

If your installation uses IMS HALDB, you can take advantage of HALDB Online Reorganization. It does not require additional features or products.

OLR is designed to provide fast and efficient reorganization of HALDB databases while being a “good citizen”in the online environment.

As you would expect with IMS, full database integrity and recoverability are provided.

OLR eliminates any outage to reorganize a database. The data remains available throughout the process.

Finally, the setup for OLR is extremely simple. You can use it after issuing the CHANGE.DB command with the OLRCAP parameter.

IMS HALDB Online Reorganization - IBM

Documents

Transcript of IMS HALDB Online Reorganization - IBM