Browse extremely slow; z02 duplicates.
- Article Type: General
- Product: Aleph
- Product Version: 16.02
Description:
After running p_manage_102 / p_manage_02, browse searches are extremely slow. (p_manage_02 was run with "Y,Y": setenv p_force_chk "Y" and setenv p_duplicate_mode "Y".)
What can be done?
Resolution:
When I did UTIL-A-17-14 for z01 and z02, I found that the z02_id Oracle index was missing..
The p_manage_02 log shows this:.
"Error : Only 1 indexes out of 2 for table z02 were created." And the./xxx01/scratch/create_ora_tables_z02_id.log shows that there are duplicates..
I tried to run UTIL-A-17-2 for z02_id to build it, but it showed that there were duplicates..
I did this to locate the duplicates:.
SQL-xxx01> select Z02_REC_KEY from z02 group by Z02_REC_KEY having count(*) > 1;.
The result showed two z02_rec_keys:.
002202986000313333.
002202986000340982.
So I did this:.
SQL-xxx01> delete from z02 where z02_rec_key in (002202986000313333, 002202986000340982);.
The response was "4 rows deleted". (There were two rows for each key.).
Then I did "commit;".
You need to do this:.
* stop ue_01, stop the www_ and pc_servers -- or wait until they are not busy -- and then do util a/17/2 for z02_id..
This will take 5 to 30 minutes, depending on the size of the z02 table..
* Resend the following xxx01 records to the server:
V16, rep_change 904 could be relevant: "p_manage_02 - a duplicate keys problem occured in the z02 table when starting from the beginning and choosing the "Update headings index" or "Update headings index (when using a multilingual thesaurus)" options. This has been corrected. "
Note: Running p_manage_02 with "p_duplicate_mode Y" ("Run in Duplicate mode") can result in such duplicates. This is similar to p_manage_17 in "A" mode. We recommend that you always specify p_duplicate_mode N.
- Article last edited: 10/8/2013