- Article Type: General
- Product: Aleph
- Product Version: 17.01
After upgrading to version 17 and starting ue_01, we see these errors in the $data_scratch run_e_01.nnnn log:
Oracle error: io_z01_write
ORA-00001: unique constraint (ABC01.Z01_ID2) violated
IO_Z01: WRITE ERROR
What should be done?
The util g/2 last-acc-number was set to 9256645 while the actual max acc number, as shown by the following SQL, was 012083031:
SQL-ABC01> select max(Z01_ACC_SEQUENCE) from z01;
The last step of p_manage_02 sets the z52 last-acc-number, but It seems that sometime after p_manage_02 had set the last-acc-number a load of the z52 from the v14 prod overlaid the z52. (I say this because 009185071 is the number we see in the /sc/conversion/delta/abc01_files/z52.seqaa and I see this in the abc01 $data_scratch:
Dec 25 22:55 create_ora_tables_z52
The solution is to correct the util g/2 last-acc-number to 012083031 -- which I have done.
Since I was concerned that other util g/2 values might be incorrect, , I checked the others as well. I found that, though the last-doc-number and the last-word-number were both OK, the last-z0101-sequence was set to "4696" while the actual last z0101 was 3655548:
SQL-ABC01> select max(Z0101_REC_KEY) from z0101;
I have corrected that as well.
But there is still the problem of the records which were processed by ue_01 during the time that the incorrect last-acc-number was in place. I find that the earliest log containing the unique constraint z01_id2 is:
The Delta-processing z07h records need to be reloaded into the z07, so that they can be re-processed with the correct last-acc-number in place.
Records loaded by the oclc_server or updated by GUI Cataloging during this time also need to be re-sent to the server so they will be re-indexed.
- Article last edited: 10/8/2013