IMS10a Why OSAM - IMS UG June 2013 Sydney

  • 331 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
331
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. © 2009 IBM Corporation Why OSAM? Bhups Narsi IMS L2 Technical Support narsi@au1.ibm.com IMS Technical Conference June, 2013
  • 2. 2 IMS 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
  • 3. 3 IMS Technical Conference 2013 3 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
  • 4. 4 IMS Technical Conference 2013 4 Origins of OSAM
  • 5. 5 IMS Technical Conference 2013 5 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
  • 6. 6 IMS Technical Conference 2013 6 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 Primary Index HIDAM KSDS
  • 7. 7 IMS Technical Conference 2013 7 Benchmarks
  • 8. 8 IMS Technical Conference 2013 8 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
  • 9. 9 IMS Technical Conference 2013 9 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
  • 10. 10 IMS Technical Conference 2013 10 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
  • 11. 11 IMS Technical Conference 2013 11 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
  • 12. 12 IMS Technical Conference 2013 12 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 at approximately 850 tx/sec
  • 13. 13 IMS Technical Conference 2013 13 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 and 4 BMP’s at approximately 850 tx/sec
  • 14. 14 IMS Technical Conference 2013 14 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
  • 15. 15 IMS Technical Conference 2013 15 Some important features and benefits of OSAM for databases
  • 16. 16 IMS Technical Conference 2013 16 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
  • 17. 17 IMS Technical Conference 2013 17 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
  • 18. 18 IMS Technical Conference 2013 18 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)
  • 19. 19 IMS Technical Conference 2013 19 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
  • 20. 20 IMS Technical Conference 2013 20 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
  • 21. 21 IMS Technical Conference 2013 21 Some things to watch out for
  • 22. 22 IMS Technical Conference 2013 22 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
  • 23. 23 IMS Technical Conference 2013 23 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)
  • 24. 24 IMS Technical Conference 2013 24 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
  • 25. 25 IMS Technical Conference 2013 25 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
  • 26. 26 IMS Technical Conference 2013 26 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