IMS10a Why OSAM - IMS UG June 2013 Sydney

© 2009 IBM Corporation

Why OSAM?

Bhups NarsiIMS L2 Technical [email protected]

IMS Technical ConferenceJune, 2013

2IMS Technical Conference 2013 2

Agenda

� Origins of OSAM• Where OSAM was first used• Where IMS Uses OSAM

� Benchmarks• Online Workload • BMP workload• Full Function Dynamic Buffer Pool

� Some important features and benefits of OSAM • Specific purpose software• OSAM sync point processing• OSAM sequential buffering (SB)• Buffer Pool Quiesce Processing• OSAM 8GB Datasets


Agenda…

� Some things to watch out for• OSAM requires care when allocating datasets

• Allocating a Multi-Volume OSAM database for non-SMS managed DASD

• Allocating a Multi-Volume OSAM database for SMS managed DASD

� Summary


Origins of OSAM


� Before VSAM there was ISAM• Index Sequential Access Method

� HISAM DB• Root at start of ISAM logical record• Root Key = ISAM record key• Dependent segments stored, in sequence, following root

• as many as will fit in ISAM logical record

• Remaining dependent segments must go into a BSAM overflow

� The IMS code written to access segments in the BSAM overflow• OSAM (Overflow Sequential Access Method)

Where OSAM was first used


� Message Queue Data Sets� Optionally for HDAM, PHDAM, HIDAM and PHIDAM data

� SM

Where IMS Uses OSAM

LMSQ

SMSQQBLKS

HDAM

OSAM or ESDSOSAM or ESDS

HIDAM PrimaryIndex

HIDAM

KSDS


Benchmarks


� The database set up was as follows:• A 32-partition 64 GB HALDB database with 2 GB per

partition• Access method of PHIDAM/OSAM and PHIDAM/VSAM• Multi-volume databases spanning three volumes each• Specific customer-like DBD and database data• Equivalent buffer settings for both OSAM and VSAM

environments

Online workload


Online workload

+504 (+12%)4,5734,096CPU efficiency(transactions per second)

+6 (+.01%)1,2151,209Transactions completed (per second)

-3.14% (-11%)26.57%29.71%CPU usage (%)

Delta (%)PHIDAM/OSAMPHIDAM/VSAM


BMP workload

-141 seconds (-22%)

8 minutes 7 seconds

10 minutes 28 seconds

Total CPU time

-2321 seconds (-36%)

minutes 33 seconds

107 minutes 14 seconds 68

Elapsed time

.78 (+13%)6.96%6.18%CPU usage (%)

Delta (%)PHIDAM/OSAMPHIDAM/VSAM


� Benefits:

• OSAM databases were able to complete 10% more transactions per processor cost over the VSAM database workload environments.

• For IMS BMP workload IMS OSAM databases shows 30%+ total elapsed time saving and 20%+ savings in CPU time respectively than VSAM databases.

Summary


Dynamic Buffer Pool impact against online activity

41 msec43 msec44 msecTransit execution time

35.7% / 28.6% / 36.4%

36.7% / 29.2% / 37.1%

36.2% / 36.2% /36.2%

CPU busy % before/during/after UPD

.7 sec / 17 sec16 sec.7 secTotal time to process UPD POOL (sec)

632.9 tx/sec628.1 tx/sec846.3 tx/secTran Rate during UPD POOL

852.6 tx/sec852.2 tx/sec851.3 tx/secTran Rate before UPD POOL

OSAM & VSAM

VSAMOSAM

Single Image IMS FF workload with 128 MPP regions a t approximately 850 tx/sec


Dynamic Buffer Pool impact against online activity

43 msec43 msec42 msecTransit execution time

41.1% / 22.1% /37.2%

33.5% / 29.4% / 37.4%

40.9% / 42.5% /36.4%

CPU busy % before/during/after UPD

.7 sec / 36 sec36 sec.7 secTotal time to process UPD POOL (sec)

605.5 tx/sec603.7 tx/sec850.1 tx/secTran Rate during UPD POOL

852.6 tx/sec852.7 tx/sec852.2 tx/secTran Rate before UPD POOL

OSAM & VSAM

VSAMOSAM

Single Image IMS FF workload with 128 MPP regions a nd 4 BMP’s at approximately 850 tx/sec


� Benefit

• A ~26% transaction rate impact to the online system was observed during the command execution against our VSAM database resource pool vs a ~1% transaction rate impact when the command was issued against our OSAM buffer pools.

• Issuing the command with BMPs active slightly increased the online transaction rate impact from 26% in the VSAM case to 29% but remained ~1% for the OSAM buffer pool case.

Full Function Dynamic Buffer Pool


Some important features and benefits of OSAM for databases


� OSAM was written for specific IMS usage and is optimized for this function.

� OSAM is implemented within about seven modules; VSAM is a general purpose access method.

� We can conclude that the more specific the function, the more efficient the process.

� The benefit is reduced CPU cost, less maintenance, and the maintenance is done within IMS.

Specific purpose software


� For transactions, BMPs and checkpointing batch programs, all IMS DB writes should take place at sync point time

� At sync point, VSAM writes each buffer individually (one at a time). OSAM chains together blocks for the same data set by using a single I/O operation, for non-page-fixed subpool, which is limited to 49 blocks per start I/O (SIO).

� OSAM does parallel writes, for multiple subpools to multiple volumes and in parallel with VSAM. This way leads to reduced elapsed time and region occupancy.

OSAM sync point processing


� Sequential buffering is implemented with chained reads (10 consecutive blocks) instead of single-block reads. Sequential buffering assumes that if you need the first block, you will also need the immediately following ones.

� OSAM SB is “enabled” by the user but is dynamically switched on or off by IMS, according to the estimated or measured benefit calculated by various algorithms.

� OSAM SB is exploited by BMPs (and theoretically, MPPs), stand-alone batch, utilities, online image copy (IC), unload, scan, prefix update, surveyor, HALDB online reorganization.

� Totally sequential processes can run in less time, but jobs with some element of sequential processing can see a benefit.

OSAM sequential buffering (SB)


� OSAM• When subpool ownership goes to zero, subpool is

destroyed• Applications can own one OSAM (or VSAM) buffer at a

time• UPDATE POOL command quieces buffers

• Only after application ownership of buffer goes to zero� VSAM

• Activity against affected subpools is quiesced, subpool is destroyed

• IMS looks at PSTs to find PSBs with intent on databases• If intent found, PST is quiesced at commit point

• When all PSTs are quiesced• Buffer pools are purged

• Open database data sets are closed and reopened

Buffer Pool Quiesce Processing


� OSAM• OSAM datasets can be up to 8GB in size• Non-HALDB only• If blocksize is even, pointer values are always even

• Rightmost bit is ZERO• Can be used as high-order 33rd bit

� VSAM is limited to 4 GB

OSAM 8GB Datasets


Some things to watch out for


� The number off OSAM Secondary Extents is limited• between 52 and 60 (dependent on blocksize)

� OSAM can use JCL or Access Method Services (AMS) to allocate database data sets

� Allocating multi--volume OSAM database data sets must be done carefully• There are different rules for SMS managed DASD and

non-SMS managed DASD� Care is also required in reusing an OSAM multi--volume

dataset• You potentially could leave an EOF on a volume that is

not used on a reload

Allocating OSAM datasets


Allocating a Multi-Volume OSAM database for non-SMS managed DASD// EXEC PGM=IEFBR14//DD1 DD DSN=HIGHNODE.MIDNODE.ENDNODE,// DISP=(NEW,KEEP),// SPACE=(CYL,(200,100)),// UNIT=3390,// VOL=SER=VOL111//*// EXEC PGM=IEFBR14//DD2 DD DSN=HIGHNODE.MIDNODE.ENDNODE,// DISP=(NEW,KEEP),// SPACE=(CYL,(200,100)),// UNIT=3390,// VOL=SER=VOL222//*// EXEC PGM=IEFBR14//DD3 DD DSN=HIGHNODE.MIDNODE.ENDNODE,// DISP=(NEW,KEEP),// SPACE=(CYL,(200,100)),// UNIT=3390,// VOL=SER=VOL333//*// EXEC PGM=IEHPROGM//SYSPRINT DD SYSOUT=*//DD1 DD UNIT=3390,VOL=SER=VOL111,DISP=SHR//DD2 DD UNIT=3390,VOL=SER=VOL222,DISP=SHR//DD3 DD UNIT=3390,VOL=SER=VOL333,DISP=SHR//SYSIN DD *CATLG DSNAME=HIGHNODE.MIDNODE.ENDNODE,VOL=3390=(VOL111,VOL222,VOL333)


� You must allocate and catalog the data as shown � If you try VOL=SER=(VOL111,VOL222,VOL333)

DISP=(NEW,CATLG) or� VOL=(,,,3),DISP=(NEW,CATLG)

• you will get a primary extent only on the first volume• The other volumes will get only secondary extents

Allocating a Multi-Volume OSAM database for non -SMS managed DASD


Allocating a Multi-Volume OSAM database for SMS managed DASD

// EXEC PGM=IEFBR14//DD123 DD DSN=HIGHNODE.MIDNODE.ENDNODE,// DISP=(NEW,CATLG),// SPACE=(CYL,(200,100)),// UNIT=3390,// VOL=SER=(VOL111,VOL222,VOL222),// STORCLAS=GTDSPACE

� You must use an SMS storage class with the Guaranteed Space attribute

� You must specify the volume serial numbers• If you do not do these two things you will get a primary extent

only on the first volume• The other volumes will get only secondary extents


� OSAM is more efficient than VSAM• less CPU• chained writes• parallel writes• chained and look-ahead reading with OSAM SB

� OSAM supports up to 8GB datasets (for non--HALDB)� If performance or cost are key factors in your system

• USE OSAM

Summary

IMS10a Why OSAM - IMS UG June 2013 Sydney

Technology

Transcript of IMS10a Why OSAM - IMS UG June 2013 Sydney