While taking an ADABAS Basics class with Software AG, the instructor said we should look at any file that has gone over 3 extents and reorganize the file to make better use of the space and possibly improve performance of accessing the file. We have a few files with indexes that have gone into as much as 25 extents, with the data at 11 extents.
To address this, I did an unload of the data into a flat file. Then did an ADADBS DELETE, ADADBS RECOVER and then an ADALOD LOAD FILE=nnn and in my test system, saw that the number of extents didn’t change for the index or upper index, and increased from 4 extents to 5 extents on the data. This file has approximately 1.5 million records. I ran the process on 2 other files, and saw the extents go down, but these where much smaller files. Is this the expected result?
The production files in this condition have over 200 million records.
In all my years of doing this, I’ve never used ADADBS RECOVER. It sounds like this is why your extents are the same/worse after you reload the file as it is described as performing this function:
The RECOVER function recovers allocated space by rebuilding the free space table (FST). The RECOVER function subtracts file, DSST, and alternate RABN extents from the total available space.
If you skip doing the ADADBS RECOVER and instead do an ADALOD LOAD FMOVE=004, it will load into different RABN ranges. Depending on how you size DSSIZE, NISIZE, UISIZE and if you have enough contiguous blocks, you may get it all into single extents.
However, I would recommend not doing any of that, but instead of using ADAULD, ADADBS DELETE, ADALOD, I would simply use ADAORD REORFILE which would be faster and easier for getting your file into single extents (if possible).
Thank you Brian. I just ran this process on our quality assurance system, and again, it caused the files to go into more extents. I will let you know when we re-run this with ADAORD REORFILE
Just for clarification, I could not find any documentation on ADALOD LOAD FMOVE= but did find documentation for FMOVE under ADASAV RECOVER FMOVE=nnn. I do remember seeing the extents getting cleaned up when we did an ADA SAVE FILES=n-n followed by an ADASAV RECOVER FMOVE=nnn, OVERWRITE
You’re right, Sandy. I think the signs of old age are starting to show on me for saying that. FMOVE= is only possible with ADASAV RESTORE where a file is free to use any RABNs and is not limited to where the file existed when the ADASAV SAVE FILE=n was performed.
With ADALOD LOAD, the positioning of the file and extent sizes are controlled by the parms:
ACRABN
DSRABN
DSSIZE
NIRABN
NISIZE
UIRABN
UISIZE
Still, though, if the goal is to get a file in many extents to 1 or the fewest number of possible extents, ADAORD REORFILE (or REORFASSO or REORFDATA if you just want to focus on one or the other) is the best, most efficient way to do that.
ADAORD reads the file in place and writes to intermediary storage, and then after the “point of no return” it lays it back to the database with data blocks filled to set padding factors and compressing the indexes while filling those to set padding factors as it goes. You can optionally release the unused DS, NI and UI space that was not written to, which is nice but guarantees you will soon grab extent #2.
The testing team needs to copy files from the main quality assurance ADABAS system to 2 other testing ADABAS systems. It turns out they were using the ADABAS unload on the main QA system followed by an ADADBS DELETE, ADADBS RECOVER and ADALOD LOAD FILE=nnn on the target testing systems. The same files are flagged on the target systems because they’ve gone over 3 extents using this approach.
I am one of the system administrators who monitors the environments and would like to “clean up” the number of extents in use. It sounds like the best approach for me the ADAORD utility.
Do you see any issues with having the testing team use ADASAV SAVE FILE=n on the main QA system followed by the ADASAV RESTORE FMOVE=n on the target systems?
If the database layout is consistent (same DEVICE type, same RABN size) you should be able to save the file on source and restore on the target. If the device types differ or RABN is 3 bytes on one and 4 bytes on the other, then you will need to continue using the unload/load approach.
A side note, if the load is resulting in a file being in multiple extents, it could either mean that the load parameters are not configured at sufficient sizes consistent with the space used on the source database, or it could mean your target database is so fragmented that you don’t have large enough unused extents to fit it all in one extent. If it is load parameters, you may want to ask your team member to check how many blocks / cylinders are used in the source database. If it is that you have small ununsed extents (and perhaps many of them), you may want to schedule an ADAORD REORDB on that database or increase/add space to it.
I have a feeling you may have a lot of small unused extents if your general practice is to run ADADBS RECOVER. I believe this exists solely to place unused extents back on the list of those available since that list had a limited size.