|
midrange.com
It might be a good time to figure out what physical file is involved...
If possible I would consider seeing if there were any records I could eliminate
from the subject file...
Run a reorg on that file after to get rid of the deleted records and rebuild the
indexes.
Depending on what file is involved... If it's a transaction and/or audit file
that can be purged on a regular basis I would add that to the houskeeping...
As Paul suggests you could increase the ACCPTHSIZ size again but you might want
to see if you could decrease the size of the files involved...
This will do more improve your system performance, In the long run...
Also read the help text behind this keyword in the CHGLF command:
Access path size (ACCPTHSIZ) - Help
Specifies the maximum size of auxiliary storage that can be occupied by
the following kinds of access paths:
o The access paths that are associated with a database file that has a
keyed sequence access path.
o The access paths that are created for referential or unique
constraints, and that can be added to this file with the Add
Physical File Constraint (ADDPFCST) command.
Changing the value for this file causes the access paths that are owned
by the file to be rebuilt.
Note: This parameter does not apply to access paths that are
created for queries that refer to the data in the file.
----- Performance Tip -------------------------------
- -
- For optimum performance, consider whether -
- there is high contention for keys within -
- the access path when selecting the value on -
- this parameter: -
- -
- o When there is little or no contention for keys,-
- specifying the *MAX4GB value generally -
- provides better performance. -
- o When there is high contention for keys, -
- specifying the *MAX1TB value generally -
- provides better performance. -
- -
--------------------------------------------------- -
The possible values are:
*SAME
This value does not change.
*MAX4GB
The access paths associated with this file can occupy a maximum of
four gigabytes (4,294,966,272 bytes) of auxiliary storage. This
value provides compatibility with releases of the operating system
earlier than Version 3 Release 6 Modification 0.
*MAX1TB
The access paths associated with this file can occupy a maximum of
one terabyte (1,099,511,627,776 bytes) of auxiliary storage.
Note: This value is not supported on releases of the system
earlier than Version 3 Release 6 Modification 0 (V3R6M0).
Therefore, if an attempt is made to save a database file that
has this attribute, and the save operation specifies a target
release earlier than V3R6M0, the save operation might be
unsuccessful, or if successful, the access paths are not saved.
If the save operation is successful, the saved version of the
file is then used to restore the file, and the system rebuilds
all of the access paths.
Eva SooHoo <EvaS@circacorp.com> on 01/13/2003 12:44:06 PM
Please respond to "GEAC/JBA System 21 Users" <jbausers-l@midrange.com>
To: JBAUSERS-L@midrange.com
cc: (bcc: Jeff Klipa/Harvard)
Subject [SYS21] Access path problems...
:
Checked the archives and found this discussion on Access Paths rebuilding
everytime a program option is run. We are having this same problem with
Routes/Structures maintenance. Please excuse my ignorance, but what is the
remedy if to the situation if the 'ACCPTHSIZ parameter is *MAX4GBand it is
full." In other words, how do I fix this problem?
Thanks for any help that you can provide.
Previous thread:
RE: Access Path rebuilding even though *IMMED ?
----------------------------------------------------------------------------
----
Subject: RE: Access Path rebuilding even though *IMMED ?
From: "Heffner, Art" <AHeffne@xxxxxxxxxxxxx>
Date: Thu, 1 Mar 2001 09:23:28 -0500
----------------------------------------------------------------------------
----
I would bet the rebuild is done because the ACCPTHSIZ parameter is *MAX4GB
and it is full.
Art Heffner - Production Tool Supply
-----Original Message-----
From: andy.jeffery [mailto:andy.jeffery@ntlworld.com]
Sent: Wednesday, February 28, 2001 7:05 PM
To: JBAUSERS-L@midrange.com
Subject: Access Path rebuilding even though *IMMED ?
Our G/L LF GLBLTRAN keeps attempting to rebuild the access
path everytime we
use Reversing Journals, just what we needed at Period End.
I've checked the LF Definition and it's *IMMED so why is it
being rebuilt?
The file has not been restored in anyway. Unfortunately the
LF has 21
Million Indexes.
Any help would be much appreciated!
Thanks in advance.
Andy
+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to
JBAUSERS-L@midrange.com.
| To subscribe to this list send email to
JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to
JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner:
doug333@aol.com.
+---
************************************************************************
Eva SooHoo
Management Information Systems, Circa Corporation
Internet: EvaS@CircaCorp.com
Phone 415/822-1600 ext. 208, Fax: 415/822-1700
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40";> <meta http-equiv=Content-Type content="text/html; charset=windows-1252"> <link id=Main-File rel=Main-File href="cid:.htm@01C2BAE7.F8BDDF80";> <span style='color:black;mso-color-alt:windowtext'><span style='color:black;mso-color-alt:windowtext'>Document2</ span><span style='color:black;mso-color-alt:windowtext'>, Page <span style='color: black;mso-color-alt:windowtext'><span style='color:black; mso-color-alt:windowtext'>1<span class=MsoPageNumber><span style='color:black;mso-color-alt: windowtext'><span style='mso-element:field-end'> <span style='color: black;mso-color-alt:windowtext'><span style='color:black; mso-color-alt:windowtext'> of <span style='color: black;mso-color-alt:windowtext'><span style='color:black; mso-color-alt:windowtext'>1<span class=MsoPageNumber><span style='color:black;mso-color-alt: windowtext'><span style='mso-element:field-end'>
_______________________________________________ This is the GEAC/JBA System 21 Users (JBAUSERS-L) mailing list To post a message email: JBAUSERS-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo.cgi/jbausers-l or email: JBAUSERS-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/jbausers-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
