• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
Several enhancements we are working on for our OPAC have revealed to us that we have a lot of inconsistencies in our Aleph indexing. We had one set of indexing rules when we migrated from our legacy system back in 2000, and sometime in (I think) 2003 we changed several important indexing rules, but never reindexed the database. We have a lot of inconsistencies we need to clear up by reindexing all our marc records.

I attended the Parallel Indexing session at the 2008 Ex LIbris Tech Seminar. During the session a customer raised a question about having to do reindexing of all the libraries (not just XXX01) if they have an indexing setup that indexes data from one library into another, and that the order of reindexing the libraries is very important.

How do I discover whether I need to reindex just XXX01 or XXX01 plus XXX60, plus XXX50, etc?

Additionally, how much disk space can I expect parallel indexing to consume?

Resolution:
There is no need to reindex the xxx50 or xxx60 just because you are reindexing the xxx01. The xxx01 indexing programs include information from the other libraries via expands. They do *not* read the indexes in other libraries. (Generally, sites do not have many if any xxx50 or xxx60 indexes. I see that you do have an abc50 z13 and an abc60 z11 and z13, but there is no need for these to be redone unless you believe they are incorrect.)

My guess is that the discussion in the Parallel Indexing class had to do with the p_manage_12 links, where doing one
library *can* necessitate doing others. (See KB's 3841, 4037, and 8192-4600 in this regard.) As described in these KB's and section 2.4 of the "How To Run Index Jobs", you should *not* normally need to run p_manage_12.

The disk work space requirements for running a job in a parallel library are exactly the same as they are for running it in the actual library. See section 5.1 of "How To Run Index Jobs".

And the Oracle space requirements for the table will, of course, be the same as the actual table is currently taking. (You can see this by doing util a/17/11/2.)

• Article last edited: 10/8/2013