- Article Type: General
- Product: Aleph
- Product Version: 20, 21, 22, 23
p_manage_18 was run with an input file which contained incorrect doc numbers (such as "01493nam" or "2008005672"). This resulted in incorrect bib record keys and in a too-high last-doc-number in the abc01 util g/2.
Having large 'holes' (greater than 300,000 and more than 20% of the total) in the bib record numbers is undesirable. (It causes the keyword bitmaps to be unnecessarily large.)
To delete these records and reduce the last-doc-number to a reasonable value, do the following.
1. (Optional) save/export the records using p_print_03 if the records were created in the GUI and you want to reload them later (with legitimate doc numbers).
2a. Run p_ret_01 (or use "vi"), to create a file with the doc numbers in this form:
(This file is the format which p_manage_33 expects the input file to be in.)
2b. Run p_manage_33 with the file created in step 2a as input to delete the records. You need to make sure that any BATCH-DELETE lines in the xxx01 check_doc table are commented out. If they are not, then they will prevent the proper deletion of the ADM record, the links, etc. (See the article " Delete BIB Recs Incl. Related ADM/HOL Recs (manage-33): BATCH-DELETE lines " (KB 5726.)
3. Or, if there are relatively few records, instead of 2a and 2b you can delete the records in GUI Cataloging doing the "Total Delete" in the nav tree in the left-hand frame.
4. Run this SQL:
SQL> select max(z95_doc_number) from z95;
The purpose of the above SQL is to confirm that the deletion of the bib records has resulted in corresponding correct deletions of the z95 Word index records. If you find that there are still z95 records with the high keys, there's nothing in particular to do about it. The z95's are connected to z98's and deleting them could cause problems. There will be Word entries for documents which no longer exist and users will get a "document not found" or similar error when clicking on them, but these will be a small percentage of total words and rarely encountered. If, after the steps in this article are performed, the bib records are reloaded with correct/low doc numbers assigned, they *will* also be indexed with the words pointing to the correct documents. If you find these "orphaned" words to be a problem, running the manage-01 Service as a final step, after this is all over, will definitely correct the situation with these "orphaned" words.
5. Use SQL to physically delete the "DEL Y" stub records which remain after step 3.
If the bib doc numbers are in sequence, the following SQL could be used:
SQL-abc01> delete from z00 where z00_doc_number >= 'nnnnnnnnn' and z00_doc_number <= 'yyyyyyyyy';
Otherwise, you will need to run the SQL individually for each doc record you have deleted.
6. Use SQL "select max (z00_doc_number) from z00" to locate the highest key in the bib file.
7. Use util g/2 to reset the last-doc-number to the value found in step 6.
You should then be able to run p_manage_05, p_manage_01, etc., OK.
Note: Sites have found that even after the deletion of these records with bad keys that the keyword indexes are corrupted (failing to give correct results on certain searches) and that p_manage_01 needs to be run to recreate the keyword index. (Contact email@example.com if you find this with your indexes.)
A scenario from a specific customer is attached. The steps are basically the same as those described in the Resolution, but with a few variations.
- Article last edited: 1/29/2014