GroupWise Quickfinder Indexing Question

I have Quickfinder Indexing scheduled to run at 3:00 AM Daily. I also have a weekly scheduled event for Content.

The daily POA logs show the Quickfinder Indexing takes roughly 30 minutes to complete.

I noticed in the logs the following message for 19 different users.

03:04:06 3B1C Updating QuickFinder index: userld2.db (2242104)
03:04:11 3B1C Error: Memory Allocation error [F03E] in Squeeze.QFSqzIndex.2 ()
03:04:11 3B1C The database function 87 reported error [F03E] on userld2.db
03:04:11 3B1C Error updating QuickFinder indexes: [F03E]

The stats for all 19 of these users show a very high Quickfinder: Pending jobs =

Yesterday I ran through the recommended procedures to Rebuild the Quickfinder Indexes for a specific user, which I did for a single user. Once completed the results showed that user had no Quickfinder: Pending jobs =

This morning at 3:00 AM the normal Quickfinder Indexing initiated and has been running for 7 hours.

Is there something about running an individual user Quickfinder Index that triggers a full scale PO Quickfinder Index Rebuild or what may have caused the daily Indexing to still be running?

Tags:

  • Hi,

    In your log snippet the user in question had more than 2 million outstanding items. If the other users had similar numbers that would explain why your QF Indexing is still running if you've shaken lose the corrupt file/files preventing QF from correctly functioning.

    Cheers,
  • Unfortunately I have 19 total users that look like that or worse.

    I'm manually rebuilding/indexing each user.

    I run a daily scheduled 'Structure' event and then a weekend 'Content' event.

    Can you please provide the recommended selections to include in both the 'Structure' and 'Content' events so I'm performing the correct database maintenance once I get the users Quickfinder issues resolved?

    Thanks Laura.
  • Hi dkerbaugh,

    Firstly - QF Indexing --> in your log snippet there's a "Squeeze" error. Manually rebuilding the user's quick finder indexes is typically sufficient to resolve this. Just be aware that sometimes that's not enough. You might need to identify the .idx and .idc files associated with that user and manually delete them and then go ahead with the rebuild of indexes for that user. For your POA to catch up on millions of outstanding items is going to take a long time. I'd recommend doing one user and check, via the POA Web Console, when the QF Index thread goes idle. Then run a quick Structure check on that user account and check the log file to ensure that there are no pending QF jobs. Rinse repeat for each individual user until you've caught up.

    Now with regards to maintenance --> I personally do a Structure check each night with Fix Problems selected and nothing else. On a weekend I do a Content Check with Fix Problems and update User Disk Space Totals. I tend to leave the rest of the options alone until I see a specific problem that needs addressing. For me the real trick is to be dedicated and disciplined enough to check the log files. Just go to the end and read the summary, but do that for every log file! On a Monday, after my Content check, I pick a few random users and double check their parts of the log files to see if there's anything suspicious, like QF Indexing ;)

    Cheers,
  • QF Indexing - Manually rebuilding each user has been correcting the errors for most of the users. There are a couple users that it appears I will need to delete the .idx and .idc for in order to fix them so thanks for that info.

    Maintenance - The settings and schedule you described are the same settings I have configured. Thanks for that verification.
  • You are welcome :) Shout in this direction if QF doesn't come right for you :)