Build an index with keys A B C. It will create an access path for that index.
Now build an index with keys B C
Since the system already has an access path for B C (it will ignore the A in this case) the system will build the index but share the access path already built earlier.
Not in this way!
If you create an access path for the keys A, B, C (in this sequence)
Creating an Index for the Keys B, C will create a new access path!
Creating an Index for the Keys A, B wil share the access path of the Index with the Keys A, B, C.
It depends on the sequence of the key fields and which index/access path is created first!
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
Modernization – Education – Consulting on IBM i
IBM Champion since 2020
"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
„Train people well enough so they can leave, treat them well enough so they don't want to.“ (Richard Branson)
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jim Oberholtzer
Sent: Saturday, 1 April 2023 15:26
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Do any of you have a policy on rebuilding indexes?
An index uses an access path built by the system to actually get to the data.
Build an index with keys A B C. It will create an access path for that
index.
Now build an index with keys B C
Since the system already has an access path for B C (it will ignore the A in this case) the system will build the index but share the access path already built earlier.
Now build another index B D C. Since there is no commonality between the keys once the index is built it will also create an access path for the index to use.
When you restore a library the system will do its best to share access paths and build them widest to narrowest attempting to reuse as much as possible. You will see messages in the job log about sharing access paths on restoring the tables/indexes.
As to your question about saving access paths, you are correct, 90+% of the time we save access paths during a save now. Back in time when backups took longer and we did not have save while active we traded backup time (not saving access paths) for the unlikely event of recovery (not really so unlikely in the S/38 days with the disk units of the time) where it would take potentially very significant time to rebuild access paths on restore. It was a calculated risk that paid off more that it cost, usually ……
On Sat, Apr 1, 2023 at 5:49 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:
Hello Jim,
Am 31.03.2023 um 18:04 schrieb Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx>:
Part of the reason that helped, was it by definition rebuilt all the
access paths in the library (or system). The system is smart enough
to restore access paths such that they will share each other as much
as possible, so it cuts down on the index maintenance as well as
saving space. Access paths were laid down widest to narrowest to
allow the system to share them. Smart system.
Your comment raises more question than it answers for me. :-)
What is the difference between an access path and an index? As far as
I've understood, it's the same. Index is often used in an SQL context,
while Access Path is more AS/400'ish.
Restoring access paths is dependent if you have set ACCPTH(*YES) on save.
If you didn't, the system creates them anew after restore. From your
description I assume you're talking about ACCPTH(*YES) on save?
You claim the system behaves differently on index sharing after a
restore vs. at index creation time. May I ask for more details?
:wq! PoC
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.
--
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
