WCI Collaboration Search Server re-indexing

Oracle’s Upgrade Guide for WebCenter Interaction Collaboration Server include “Rebuild the Oracle WebCenter Collaboration search collection“.

A while back, I ran into an issue where the rebuild process was spiking the CPU on the Collab Server at 100% forever (which, I suppose, is more of a plateau than a spike).  In viewing the PTSpy logs, I saw hundreds of thousands of messages that included this SQL statement:

select * from csIndexBulkDeletes where status = 1

Checking that table, I found over 110 MILLION rows. Which is particularly odd, given that this client only had 42,000 Collab Docs. Now, I have no idea how the table got that enormous, but it’s clear that Collab’s Search Rebuild process uses that table to determine which documents to update, much like the Search Update job uses the PTCARDSTATUS table – which, incidentally, can also get messed up.

It was clear that if the search rebuild process goes haywire, Collab starts queuing up search server updates in this table, and if the table gets too big, cascading failures start to occur where the queue grows faster than it can get purged.

The solution is: before starting the Collab Search Re-index process, clear this entire table, which is rebuilt during the re-index process anyway. To do so, just run:

truncate table csIndexBulkDeletes

I should note that this isn’t all that common, as I’ve only seen it once, but at least now you know one possible solution if your rebuild process can’t seem to gain escape velocity.

Tags: , , , , ,

Leave a Reply