haldb and olr - ims ug may 2013 helsinki

HALDB Online Reorganization

·Click to add text

5.4

© Copyright IBM Corporation 2013


Jouko Jäntti

Senior IT Specialist

IMS Worldwide Technical Specialist Team

[email protected]

Availability. References in this presentation to IBM products, programs, or services do not imply that they will be available in all

countries in which IBM operates.

Acknowledgements and Disclaimers

The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They

are provided for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other

guidance or advice to any participant. While efforts were made to verify the completeness and accuracy of the information

contained in this presentation, it is provided AS-IS without warranty of any kind, express or implied. IBM shall not be responsible

for any damages arising out of the use of, or otherwise related to, this presentation or any other materials. Nothing contained in

this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers

or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results

·Click to add text

5.4

© Copyright IBM Corporation 2013. All rights reserved.

• U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule

Contract with IBM Corp.

IBM, the IBM logo, ibm.com, IMS, DB2, CICS and WebSphere MQ are trademarks or registered trademarks of International

Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are

marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or

common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or

common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark

information” at www.ibm.com/legal/copytrade.shtml

Other company, product, or service names may be trademarks or service marks of others.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results

they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing

contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you

will result in any specific sales, revenue growth or other results.


• HALDB Overview

• HALDB Online Reorganization – OLR


• HALDB OLR vs IMS ORF

– IMS ORF refers to IMS Online Reorganization Facility for z/OS product in IMS Tools portfolio

HALDB Highlights

• Hierarchic structure is maintained

– A database record resides in one partition

• Minimal (or no) application changes required:

– Cannot initially load logical child segments

• New status code for load programs

– Some secondary index segment formats change


– Some secondary index segment formats change

• Might require I/O area changes when secondary index is processed

as a database

• HALDB database types:

– PHDAM: Partitioned HDAM

– PHIDAM: Partitioned HIDAM

• Index is partitioned

– PSINDEX: Partitioned secondary index

High Availability Large Database - HALDB

• Large Database

– Databases are partitioned:

• Up to 1001 partitions per database

• Partitions have up to 10 data set groups

• High Availability Database:


• High Availability Database:

– Partition independence

• Allocation, authorization, reorganization, and recovery are by partition

– Self healing pointers

• Reorganization of partition does not require changes to secondary

indexes or logically related databases

Highlights

• OSAM and VSAM (ESDS and KSDS) are supported

• Partition selection is done by key range or user exit routine

• Logical relationships and secondary indexes are supported

– Secondary indexes may be partitioned


– Secondary indexes may be partitioned

• DBRC is required

– Databases must be registered

> (IMS Catalog is a HALDB, and an exception to this)

• Dynamic allocation uses DBRC information

– DFSMDA is not used

High Availability Large Database

• Benefits:

– Greater database capacity

• Without application changes

– Increased database availability:

• Partitions, not databases, are removed from system


• Shortened reorganization process

• Batch window is shortened with concurrent processing

– Improved manageability

• Data sets might be smaller

HALDB Summary

� HALDB Database Types are defined by using a single DBD that creates the same structure for each partition. The partitions are defined for access in the DBRC Recons.

� Each HALDB Partition is treated as a single dataset and may be allocated and reorganized individually, in sequential


groups or all together as a single database. HALDB allows for a maximum of 1001 partitions per database.

� A reorganization of the partitions does not require rebuilding of a secondary index or of logical relations. These can be self healed during regular processing.

HALDB Summary

A single DBD defines the structure to IMS. A DBRC definition describes the required partitioning. This combination results in a single database where multiple partitions remain available during a reorganization of individual partitions.


�

�

�

�

Up to 1001 datasets of up to 4 Gigabytes as partitions means up to 4 Terabytes of data in a single database structure.


• HALDB Online Reorganization (OLR) is a standard part of

IMS DB

– Not a feature, product, tool, and so on

• Benefits:

– PHDAM and PHIDAM databases are reorganized


– PHDAM and PHIDAM databases are reorganized

– 100% availability of database during reorganization:

• Zero outages

• Applications are unaffected

– They never get data unavailable conditions

– Full integrity and recoverability are maintained

– Eliminates database outages for reorganizations

HALDB Online Reorganization Overview


Online Reorganization Overview

• Environments:

– Runs in TM/DB or DBCTL system

• Executes in DLISAS address space

– Concurrent online and data sharing updates are allowed

– XRF and RSR are supported


• Recoverability:

– System, IMS, or media failures

– DBRC support, standard recovery utilities, and DRF

• Performance

– External parameter for pacing

Online Reorganization Overview

• HALDB PHDAM and PHIDAM only

– Reorganize by partition:

• PHDAM data component

• PHIDAM data component and primary index

• Secondary indexes and logical relationships:

– Database with secondary indexes can be reorganized


– Database with secondary indexes can be reorganized

• But secondary index (PSINDEX) CANNOT be reorganized

– Database with logical relationships can be reorganized

– ILDS (ILEs) updated with new target RBAs

• Restrictions

– No DBD changes

• (DBDS space allocation changes are OK)

• (IMS 13 HALDB Alter is based on OLR)

� Each partition has an ID number – Assigned by IMS when partition is defined

� Each partition has an ‘data set name prefix’– Assigned by user when partition is defined– 1-37 character

� Data set name is formed from ‘data set name prefix’, data

Partition IDs and Data Set Names

14

� Data set name is formed from ‘data set name prefix’, data

set letter, and partition ID– Data set names are registered in the RECON– If data set name prefix: IMSTESTS.PARTSDB– If partition ID: 00007

• PHIDAM index: IMSTESTS.PARTSDB.X00007

• Primary data set group: IMSTESTS.PARTSDB.A00007

• ILDS: IMSTESTS.PARTSDB.L00007

DSN prefix Partition ID

Data set letter

Online Reorganization Technique

• Online reorganization (OLR) is into new partner data sets:

– A-J and X data sets alternate with M-V and Y data sets

– Only 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 reorganization:

– No outages

– No data set renames

Online Reorganization Technique


…

…

ILDS

IndexPHIDAM only

L

X

L

X…

HALDB Naming Conventions

• DDNAMEs

– Partition name and data set letter:

• Partition name: DJXK21

• DDNAMEs:

– DJXK21L, DJXK21X, DJXK21A,

DJXK21B,…

• Data set names


1 to 1001 partitions

…Data set groups

…

A

B

J

…

A

B

J

…

…

– Data set name prefix, data set letter, and partition ID:

• DSN prefix: IMSP.DB.DJXAB

• Partition ID: 00001

• Data set names:

– IMSP.DB.DJXAB.L00001

– IMSP.DB.DJXAB.X00001

– IMSP.DB.DJXAB.A00001

– IMSP.DB.DJXAB.B00001

– …

…

…

ILDS

IndexPHIDAM only

L

XY

L

XY

…

Partner Data Sets

• Index and data set group data sets have partners:

– Each X data set has a Y partner

– Each A data set has an M partner

– Each B data set has an N partner

– …

• DDNAMEs differ by the letter– For example:


1 to 1001 partitions

…Data set groups

…

A

B

J

M

N

V

…

A

B

J

M

N

V

…

…… …

– For example:

• DJXK21A

• DJXK21M

• Data set names differ by the letter

– For example:• IMSP.DB.DJXAB.A00001

• IMSP.DB.DJXAB.M00001

Terminology

• Before or after reorganization:

– Active data sets (either A-J, X or M-V, Y))

• Data sets being accessed by applications

– Inactive data sets

• Data sets not being accessed by applications

• During reorganization:


• During reorganization:

– All data sets (A-J, X and M-V, Y) are active data sets

– Input data set: Contains unreorganized data

• Includes both active and inactive data

– Output data set: Contains reorganized data

– Cursor

• Dividing line between active data and inactive data

• Only used while reorganization in progress or suspended

Reorganization

• Reorganize by copying segments:

– Read segments from one set of HALDB data sets (for example, A-J, X)

– Write (insert) segments to another set (for example, M-V, Y)

• Update ILDS for secondary index and logical relationship targets

– Use locking protocols to provide concurrent access integrity

– Log inserts for recoverability


A-J

Input

Data Sets

Output

Data Sets

YCopy

Copy

X

L

ILDS

M-V

– Log inserts for recoverability

– Use cursor to identify which set to use to access a database record

• Database records before cursor, use output data sets

• Database records after cursor, use input data sets

9

8

7

6

5

4

3

2

1

9

8

7

6

5

4

3

2

1

CopyUnit ofReorg.

A M

Cursor

Copying Records During Reorganization

• Unit of Reorganization (UOR) is

a set of database records:

– Records are copied from input to output data sets

– Records in UOR are locked while being copied

– At end of copy for UOR, the locks


20

19

18

17

16

15

14

13

12

11

10

9

20

19

18

17

16

15

14

13

12

11

10

9

Already copied

Being copied

Active data

Not yet used

– At end of copy for UOR, the locks are released

– Number of records in UOR is dynamically adjusted

• Algorithm limits time taken,

bytes copied, and locks held

during copy

9

8

7

6

5

4

3

2

1

9

8

7

6

5

4

3

2

1

CopyUnit ofReorg.

A M

Cursor

Application Access During Reorganization

• Cursor points to last committed reorganized record:

– PHDAM RAP RBA

– PHIDAM root key

• Data set used is based on cursor value:

– Cursor on record 6


20

19

18

17

16

15

14

13

12

11

10

9

20

19

18

17

16

15

14

13

12

11

10

9

Already copied

Being copied

Active data

Not yet used

– Cursor on record 6

– Access Record 5:

• Access from M data set


• Access from A data set


• Wait for lock,

– then access from M data set

– Access includes gets and updates

Completion of Reorganization

• When OLR completes:

–A-J,X becomes the inactive set - may be deleted

–M-V,Y becomes the active set

• Cursor reset to inactive

• ILDS (ILEs) updated during reorganization


A-J

Input

Data Sets

Output

Data Sets

YX

L

ILDS

M-V

• ILDS (ILEs) updated during reorganization

Next Reorganization

• Next reorganization:

– Reorganize from M-V,Y to A-J,X

– A-J, X data sets might be reused

Or

– A-J, X data sets might be reallocated


A-J

Output

Data Sets

Input

Data Sets

YCopy

Copy

X

L

ILDS

M-V

Setting Up Online Reorganizations

• 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


– OLRCAP allows online reorganization for partitions of the database

Output Data Set Creation (1 of 2)

• Output data set allocation options:

– Preallocation by user

– Automatic 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 volume

– Change space allocation

• Blocks/CIs

– Primary and secondary allocations

• For PHIDAM Primary Index

– Free space percentage

Output Data Set Creation (2 of 2)

• Automatic output data set creation:

– Space is equivalent to existing input data set

• Requested as a number of OSAM blocks or VSAM records

– SMS-managed:

• Same storage class as input data set

• Same number of volumes as input data set


• Same number of volumes as input data set

• With guaranteed space attribute, primary space allocation is taken

on all volumes

– Non-SMS, OSAM:

• UNIT=SYSALLDA is used (storage or public volume)

• If input is multivolume data set, output data set is not created

– Non-SMS, VSAM

• Data set is allocated on the same volume(s) as input data set

Starting Online Reorganization

• Command to initiate OLR:

– Type-2 command:

INIT OLREORG NAME(partname1, partname2,...)

– Type-1 command:

/INIT OLREORG NAME(partname1)

– Command parameters:


– Command parameters:

• Delete input data sets at completion of reorganization

OPTION(DEL|NODEL)

• Set rate of execution

SET(RATE(100|nn)

Rate Parameter

• RATE parameter on INIT:

– RATE parameter determines how fast the reorganization runs:

• RATE(100) - Runs at maximum speed

• RATE(nn) - Online reorganization waits after each commit so that

average speed of reorganization is nn% of maximum speed

– Examples:


– 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,...

Commands to Show Status of Reorganization

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

– Response:Partition MbrName CC LclStat Rate Bytes-Moved Segs-Moved

POHIDKA IMS1 0 RUNNING 100 72315678 244597

PVHDJ5A IMS1 0 RUNNING 100 8454630 30029

Roots-Moved Option Resumed StartTime

22511 NODEL Y 2009.196 10:20:21.61


22511 NODEL Y 2009.196 10:20:21.61

3775 DEL 2009.196 10:20:21.84

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

– Response:DATABASE PART RATE BYTES SEGS ROOTS STARTTIME

STATUS

DBHDOJ01 PDHDOJA 10 53330 217 31 09195/143354

WAITRATE, OPTDEL

*09195/143362*

Logging By Online Reorganization (1 of 2)

• Log records written:

– Scheduling (x’08’)

– Termination (x’07’)

– UOR sync point (x’3730’)

• For each UOR

– UOR statistics (x’2950’)


• For each UOR

– Database change (x’50’)

• For all output data in the partition

– This will be voluminous!

Logging By Online Reorganization (2 of 2)

• UOR statistics log record (x’2950’):

– Written for each UOR

– Data:

• Total segments moved before this UOR

• Total bytes moved before this UOR

• Roots moved in UOR

• Segments moved in UOR


• Segments moved in UOR

• Bytes moved in UOR

• Locks held by UOR

• Start time of UOR

• Execution time (elapsed time) of UOR

• Time interval waited before this UOR (due to RATE parameter)

Suspending and Restarting Online Reorg

• Reorganization might be suspended:

– Commands:

• TERM command (type-2) example:

TERM OLREORG NAME(PVHDJ5A)

• /TERM command (type-1) example:

/TERM OLREORG NAME(PVHDJ5A)

– Input and output data sets remain active


– Input and output data sets remain active

• Cursor remains active

• Suspended reorganization might be restarted:

– INIT and /INIT command will restart the reorganization

• Restarts from the point of the cursor

– Restart might be on the same IMS system or another IMS system

Performance Considerations (1 of 3)

• OSAM sequential buffering can be used

– Recommended

• Logging might affect performance:

– All data is logged when moved

– A few additional log records


• Buffer pool contention

– Partner data sets use the same buffer pool:

• Appropriate for times when reorganization is not running

• Could cause buffer contention during reorganization


• Lock contention:

– Should be minimal

• OLR has dynamic algorithm to limit the time that locks are held

– OLR rarely causes a deadlock:

• Asks for database record locks conditionally

– If lock is not available, the UOR is shortened

• OLR is always the victim in its deadlocks:


• OLR 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


• Online reorganization runs in DL/I address space

– Each reorganization uses one of 10 database TCBs

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

processing

• Online reorganization can run on any data sharing IMS system

– Some installations may choose to dedicate an IMS to OLR:


– Some installations may choose to dedicate an IMS to OLR:

• Buffer pool definitions can be tuned for OLR

• Avoids buffer contention

• Avoids logging contention

• Limits the number of data sets with updates on the log

– Logs are not required for change accum or recovery of other data sets

IMS 11 OLR Performance Enhancements

• One log record written for updates to a block

• Sequential access for VSAM KSDS get processing

• GNP calls eliminated for root-only databases

• Reduced use of data set busy (ZID) lock


– PHIDAM index inserts are batched at end of unit of reorganization

• Block locks eliminated for ILDS

• IRLM lock look-aside

– Avoids requesting locks already held

HALDB Online Reorganization Summary

• HALDB Online Reorganization is included in IMS DB

– Not a feature, product, tool, and so on

• Benefits:

– Fast and efficient reorganizations


– Full integrity and recoverability are maintained

– Eliminates database outages for reorganizations

OLR vs ORF

• OLR

• HALDB Online Reorganization

• ORF


• ORF

• IMS Online Reorganization Facility for z/OS

Data Base Supported

OLR

PHDAM

PHIDAM

Internal Logical relationships

ORF

HDAM

HIDAM

SHISAM

PHDAM


PHDAM

PHIDAM

Secondary Indexes

Internal Logical Relationships

Requirements

OLR

– DBRC

– IMS DLI address space LSO=S

ORF

– DBRC

– IMS Tools Online System Interface


Interface

– IMS Tools Common Services

Methodology

OLR

– Single partition per task

– Invokes Get and Insert processing

ORF

– Single partition per job

– Invokes IMS utilities

– Invokes IMS High Performance


processing

– Uses Partner datasets that may be deleted or reused

– Invokes IMS High Performance Tools

– Uses Shadow data bases that may be deleted or reused

Features

OLR

– Online

– DBD changes accepted

• Free Space, dataset size

ORF

– Online or Offline

– DBD changes accepted

• Free Space, dataset size


– DBD changes not accepted

• Segment expansion, restructure

– Uses Partner datasets that may be deleted or reused

– Reorganization is recoverable

– DBD changes not accepted

• Segment expansion, restructure

– Uses Shadow data bases that may be deleted or reused

– Reorganization is restartable

Performance

OLR

– Runs under the DLI region

– Uses up to 10 DLI TCBs – 10 OLR tasks

– Increase in IMS Log traffic

ORF

– Runs as an IMS BMP

– As many BMPS as resources allow

– Relies on current IMS logging


– Increase in IMS Log traffic

– Parameter to meter reorg

– No data base access interruption

– Relies on current IMS logging

– Momentary data base access interruption (twice)

OLR vs ORF

OLR

– IMS Base Feature

ORF

– IMS Tool

– May require additional tooling


haldb and olr - ims ug may 2013 helsinki

Technology

ibm products

ibm logo

database haldb database

haldb partition

database availability

use of ibm software

ibm trademarked terms

database partitions