ca.portal.admin

resolving EXTEND SPACE

Discussion created by ca.portal.admin on Feb 24, 2009
Latest reply on Feb 24, 2009 by ca.portal.admin
i am interested in how other IDMS sites deal with this

when you EXTEND SPACE to ""dynamically"" give more space to an area,

do you immediately (within a week) follow up with an unload/reload/reorg to=
make the entire area calc-available, or do you wait for a pre-existing op=
en window (within 3 months), or do you never revisit the area to resolve th=
e extend space?

thanks,

Chris Hoelscher
Senior IDMS & DB2 Database Administrator Humana Inc
502-476-2538
choelscher@humana.com




The information transmitted is intended only for the person or entity to wh=
ich it is addressed and may contain CONFIDENTIAL material. If you receive =
this material/information in error, please contact the sender and delete or=
destroy the material/information.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: resolving EXTEND SPACE
"We used to do something tricky invented by a former DBA that worked like an EXTEND SPACE. We would let a file fill up, then add an additional file to the area for the VIA records only. Every time we did this, the performance got worse - slow response time and lots of lock manager abends on space management pages. What we finally realized was that every time a record was stored, IDMS was bouncing through the space management pages in all of the full files until it found some empty space. Since the empty space was all in the most recently-added file, everyone was then trying to update the same space management page at once.

While this was an extreme example, I believe that EXTEND SPACE will always add this type of overhead. While most situations may not be bad enough to cause lock managers abends, be aware that, under the covers, you are adding additional I/O and lock manager waits. I vote for doing the unload/reload as soon as possible.

Outcomes