p_manage_32 Creates Duplicate Entries in Local Catalogs' Browse Indexes

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 18.01

Description:
p_manage_32 creates duplicate entries in local catalogs' Browse indexes.

Each of the titles in the title Browse is there twice, with exactly the same text.

Resolution:
As noted in the p_manage_32 Service Help: "the Update counters option is only functional when adding a new base".

This means that "Update counters" ("Procedure to Run" 0) can be used only in the case where Z0102 records for the base do not already exist.

"Rebuild counters" ("Procedure to Run" 1) drops/creates the z0102 table in its entirely. Thus, it can not be run for an individual base.

In this case, the p_manage_32 log shows that "Procedure to Run" *was* 1 (Rebuild entire). But log also has the following:

DROP TABLE ABC01.Z0102
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

....
CREATE TABLE ABC01.Z0102 (
*
ERROR at line 1:
ORA-00955: name is already used by an existing object

The first step in p_manage_32 locks the library:

lock_library b
if ($lock_lib_exc_st == not_locked) then
abort_exit
endif

And if the library is locked, then there should not be any conflicts for the z0102 with the www_server or pc_server.

Could it be that some other batch job (p_manage_15? p_manage_17?) was running at the same time as p_manage_32?

Also, the drop/create of the z0102 occurs immediately after the library lock command. It's possible that a www_server transaction which is in process could be allowed to continue to its conclusion (and to use the z0102) even though the lock has been issued.

To allow for this possibility, I have added a "sleep 60" line (sleep for 60 seconds) to the $aleph_proc/p_manage_32, between the "lock_library b" command and the "$aleph_proc/util_a_17_b table z0102". (I saved the original as p_manage_32.beforejschange.)

If this problem persists despite the preceding, I *have* seen cases where the only way to solve an inexplicable "resource busy" has been to stop/start Oracle prior to running the job.

Article last edited: 10/8/2013