ims parallel sysplex best practices

Post on 27-Jul-2015

739 Views

Category:

Technology

14 Downloads

Preview:

Click to see full reader

TRANSCRIPT

IBM Software Group

© 2009 IBM Corporation

IMS Parallel Sysplex Best Practices

Dave Viguers

IMS Performance

dviguers@us.ibm.com

IMS User Group

March 30,2010

2

Session description

This session will deal with what are considered to be best practices for

running IMS in a parallel sysplex environment. All aspects of IMS will be

discussed including DBRC, IMS database and data sharing, Shared

queues, RRS, and other sysplex functions used by IMS.

3

Presenter disclaimer

• The best practices discussed in this session have been contributed and reviewed by many people with IMS skills, both IBM and customers, HOWEVER there are always situations where these recommendations may not be the best for your particular environment. Always keep in mind that these are guidelines and not absolutes.

• There are many other best practices in addition to the ones covered in this session. This session will deal primarily with parallel sysplex.

4

DBRC considerations

• Allocate each RECON data set with different sizes• The spare should be the largest

• Convert the hardware RESERVE to GRS enqueue• Eliminate any problem should a RECON be moved to a different volume

• Place each RECON on a separate volume along with catalog• May not be necessary if convert is done however• Avoid what might happen if the conversion list got modified or deleted

• Implement Recon Loss Notification• Prevent delays at some critical time

• Consider Parallel Recon Access.• Can reduce contention and improve thruput for large requests• But uses Transactional VSAM

• Requires careful planning and tuning

5

Databases

• Consider Fast Path MADS for critical databases• Up to 7 copies on separate volumes on separate controllers possible

• Fast Path Data Entry Databases• Even without MADS• Multiple AREAS to limit unavailable data• Reduced recovery time

• HALDB• Multiple partitions to limit unavailable data• Reduced recovery time

• Review internal database definitions• RAP’s, RAA, Randomizing routines, Pointer options

• Too much to discuss here

6

Database Cache Structures

• VSAM – directory only structure• Make large enough to avoid directory reclaims• Use CFSIZER tool on the web

• OSAM – directory only structure• Avoid directory reclaims also

• OSAM – with data caching• Use selectively if at all• Product publications and redbooks for options and considerations

• FP VSO structures• Preload and non preload• May improve access times which can reduce transaction time

7

Cache structure considerations

• Duplex FP VSO structures• IMS duplexing performs best• Avoid loss of structure causing recovery being needed

• Specify INITSIZE and SIZE for all cache structures• Allows size to be adjusted if necessary

• Specify MINSIZE equal to INITSIZE if using AUTOALTER

• Monitor the structures to insure no directory reclaims• Look for CASTOUTS in the RMF CF structure activity report

8

IRLM (1)

• Set MAXUSRS no larger than necessary• Maximum IRLM’s expected in data sharing group• Minimize size of each lock table entry

• 2, 4, or 8 bytes depending on setting• 1-7 = 2 bytes, 8-23=4 bytes, 24+ = 8 bytes

• Maximizes hash table size which keeps false contention low

• Set DEADLOK value low• 1 second or less for production

• IRLMNM• Consider making the same for all IRLM’s• Allows IMS to connect to any IRLM on any LPAR

• Do not specify LOCKTABL in IRLM procedure• Use CFNAMES in DFSVSMxx

9

IRLM (2)

• SCOPE NODISCON if running batch datasharing jobs• If online IMS not active then avoids structure connect/disconnect

• PC=YES• Only value used with IRLM 2.2

• Avoid LTE= value• Default is ½ the structure size for hash entries• Might give undesired results if structure size altered

• Set LOCK structure size to power of 2• IRLM will adjust LTE’s down to power of 2 after dividing structure in half

• Specify MINSIZE, INITSIZE, and SIZE• Allow for possible ALTER

• Carefully consider system managed duplexing• Only use if necessary for availability

10

MISCELLANEOUS DB related

• DFSVSMXX• Use same member if clones

• Avoids oversights if multiple members and changes being made• New member could be used to verify changes

• FDBR• Be sure it runs on separate LPAR• Preferably also a separate physical machine

• FDBR PSB pool sizes the same or larger than active IMS

• Set LOCKTIME with IRLM command or DFSVSMxx• Default of 300 seconds is too high• Monitor for DXR162I – Long lock timeout

11

Applications

• Review PROCOPT settings• Many applications use A when only G is needed• Avoid lock contention when possible

• Watch for ‘CONTROL’ type databases • Avoid single segment updates by parallel applications

• Avoid calls outside of IMS• Especially when holding locks

• Could be IMS or DB2• Like APPC, MQ, Sync callout

12

Shared Queues

• Automate CQS System Checkpoints• SYSCHKPT value can not be changed dynamically• SYSCHKPT value is for each CQS

• A failing CQS must read records created by all CQS’s• Using DS8000 DASD, CQS can read about 56,000 records per second

• Automate CQS Structure Checkpoints• No IMS defined way to cause these• Affects structure recovery time if necessary

• Stagger EMH and FF structure checkpoints if using both• Minimize delays

• Place SRDS’s on separate volumes and paths if possible• Avoid single point of failure

• Use MSGBASED processing for CFRM CDS• Minimize time to quiesce and resume at checkpoint

13

Shared Queues Structures

• Specify both SIZE and INITSIZE• Facilitate structure alter

• Allocate Overflow structure larger than primary• In case one or two queue names filling the primary

• Specify correct OBJAVGSZ• Determines entry to element ratio• CQS monitors only elements for overflow• 1:1 if in doubt

• Use AUTOALTER • XES can dynamically adjust ratio• Specify MINSIZE to prevent XES from reducing size

14

CQS and the MVS logger (1)

• Use external CF’s to avoid use of Staging Data Sets• Might need staging for D.R. however

• If using staging data sets allocate enough space• Much larger than structure • Either one reaching threshold causes offload

• Set structure size and full threshold carefully• Try to allow time to react if offload should fail

• Set offload data set size large• Reduce allocations for new data sets• Takes longer than just offloading to existing

• Set LOWOFFLOAD value to 0• For CQS logging it makes no sense to do otherwise

15

CQS and the MVS logger (2)

• Set HIGHLOWOFFLOAD value to 50 – 60%• You never want to reach full • Some time should offload fail

• Set MAXBUFSIZE to 65276• Largest size to use 256 byte elements• Minimize wasted space

• Specify ALLOWAUTOALT(NO) for logger str.• Logger monitors and will alter if necessary

• Use separate structures for FF and FP logstreams• Different characteristics

• Use IXGRPT to monitor• Redbook on MVS Logger (SG24-6898)

16

SMQ false scheduling

• Use PWFI and dedicated regions for high volume transactions• Avoids scheduling – real and false• IMS algorithm tends to keep more transactions local

• Use PARLIM of 2 or more if possible• Avoids local false schedules in V10 and below• V11 enhanced to handle 0 and 1 better

• CFCC 16• z/10• Notify change to reduce global false schedules

17

RRS

• Disable RRS archive logstream• SETRRS ARCHIVELOGGING,DISABLE

• z/OS 1.10 otherwise shut down and delete archive log

• Use commit mode 0• Avoids RRS cascaded transaction support

• Allocate RRS Delayed structure to avoid offload• UOW’s are deleted when no longer needed• Use IXGRPT to monitor

18

IMS Connectivity

• Set HWSHWS00 as non-swappable in PPT• If not then response times could vary widely

• Specify to IMS connect a DATASTORE for each IMS• Allow for routing to multiple IMS subsystems• Workload balancing and availability

• Set TCPNODELAY=ENABLE and NODELAYACK for TCP/IP• Minimize delays with TCP/IP

• Use VTAM generic resources for SNA • Workload balancing and availability

• Use IMS RM with STM • End user availability especially with conversations

• Exercise care with DRA (DFSPZPxx) resources• Adding new connections can have multiplication effect

19

Miscellaneous

• Be aware of CF microcode updates• Use CFSIZER web tool prior to any upgrades• Usable structure size may be impacted

• DASD mirroring• Both synchronous and asynchronous can impact response times• WADS tend to be especially critical• RRS and CQS logger staging data sets also

• Workload Manager with IMS• Keep simple – avoid going lower than IMS transaction class• Set server address spaces high

• IRLM, DBRC, CTL, DL/I, CQS

20

Summary

• Tried to hit the main best practices• Health checks good for looking at YOUR

environment

• Primarily sysplex related• Redbook due out soon with more details

• Many more for specific components• IEFUTL to prevent S322 & S522•And related U0113

• IEFUSO to prevent S722• And many more

21

Dave Viguers

Dave Viguers

IBM

dviguers@us.ibm.com

top related