DB2 - L

Expand all | Collapse all

Db2 for z/OS Extended Common Service Area (ECSA) Issues

  • 1.  Db2 for z/OS Extended Common Service Area (ECSA) Issues

    Posted Oct 20, 2021 10:39 AM
    Team,
    I am working with a customer which over the past several months has lost Db2 for z/OS Parallel Sysplex Data Sharing Group members multiple times because Extended Common Service Area (ECSA) has been exhausted.
    • Have others experienced this problem?
    • What are you doing to address it?
    Thanks in advance!

    Cheers,
    Frank

    ------------------------------
    FrankFillmoreThe Fillmore Group, Inc.
    ------------------------------


  • 2.  RE: Db2 for z/OS Extended Common Service Area (ECSA) Issues

    Posted Oct 24, 2021 10:17 PM
    Edited by Mark Wieczorkowski Oct 24, 2021 10:18 PM
    Hey Frank,

    If they're exhausting ECSA, it's a miracle if Db2 is the only thing coming down...normally that would cause whole LPARs to go belly-up.

    Db2 is a high user of ECSA, but they've been moving a lot of their memory to shared-private, so especially if you've only got one subsystem on the LPAR, Db2 shouldn't be CAUSING this problem. Which makes me wonder...who is??

    Questions you'd need answers to:

    • How much ECSA is allocated to the MVS LPAR at IPL-time? We've run multiple Db2 subsystems and dozens of CICS regions on LPARs with 500-600MB of ECSA, and from my experience, that shop is on the high-end. Most shops will have a couple hundred MB allocated. For something as severe as ECSA exhaution/LPAR loss, your MVS guys might want to temporarily throw another 100MB at it...most subsystems should be fine with that. But double-check your IFCID0225 numbers just to be on the safe side. Every MB you allocate to ECSA comes off the private region, so make sure you have it to give. And if it's a "leak" (something allocating storage and then either "orphaning" it or just not de-allocating it), adding more ECSA just buys you time.

    • Who's using the ECSA? I think RMF Mon III will show you a breakdown. Some of the vendor MVS monitors will as well. Identify who the big consumers of ECSA are. Db2 subsystems typically show on the high-end, with 5-10MB between MSTR and DIST. The heavy hitters have always been MVS itself and VTAM/CS.

    • If it's Db2 consuming the ECSA, check for any HIPERs or IBM.DB2.StorageLeak PTFs related to ECSA. If you're up-to-date, get a dump and send it to IBM. If it's some other piece of software, you'd have to look that direction. Try to determine whether it's legit ECSA usage, or some kind of memory-leak/orphaned ECSA. I.e. once you reach steady-state operating, does the number stay pretty stable for the major consumers, or does it increase rapidly?

    • If you can't identify an over-consumer, it's possible that there's just too much "stuff" on the LPAR. Every STC or subsystem you run on the LPAR needs some ESQA/ECSA just to exist.

    IBM and all of the vendors have made a major push with the introduction of 64-bit processing to get as much stuff as possible out of ECSA and into either HVCOMMON or HVSHARE space. So it's really surprising to see ECSA exhaustion unless it's configured way too low, the LPAR is egregiously overloaded with address spaces, or there's a defect.

    ------------------------------
    MarkWieczorkowski...
    ------------------------------