• State Not Answered
  • Replies replies
    23
  • Subscribers subscribers
    15
  • Views views
    1750
  • Users 0 members are here
  • Locked Locked
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Rebuild of Quickfinder-Index with error F041 for one user

MigrationDeletedUser
GW8 POA 8.03 12-03-14 (on Windows)

This POA is used as dedicated Quickfinder-Index-Machine.

Background: One user found the search function in the client running well for old e-mails. The search result window shows them at once, but then stays running and takes nearly forever trying to find more recent e-mails. As the e-mails of this user are sorted in the cabinet by folders (... 2013, 2014 and 2015) focusing the search on one of these folders 2014 or 2015 works perfect again. Due to this the decision was made to delete and rebuild all quickfinder-indices.

After this run in the log-file following entry was found for a different user: "database function 87 reported error F041 on userxxx.db". After some reading in the forums this different user was treated from standalone-gwcheck with "structural rebuild" and "database analyze and fix", which both went trough without major problems. Afterwards the delete and rebuild of all quickfinder-indices was done again with the same outcome (function 87 and error F041).

The search-function for the user it all started with is still hampered, but much more important for me is this F041-error and how to get rid of it.

Any hints on the further procedure are highly welcome.

Sincerely

Karl

Tags:

Parents
  • 0
    Hi Karl,

    Typically a F041 error on indexing means that said user has an attachment that is very large and contains the same word too many times - I'm not sure what the "too many times" limit is!

    With regards to the user who is having issues, you may want to rebuild just their indexes. Perhaps this TID is of some use: https://www.novell.com/support/kb/doc.php?id=7012997

    I would also suggest that you double-check your QuickFinder indexing settings. The first thing that I do is set, in the POA startup file, the qflevel 999 switch which forces the POA to index absolutely everything instead of the default, which I think is just the first 1000 messages. Next, after ensuring that the full index has run through to completion, I set the process to run at least every four hours in order to keep the indexes up to date. I'm not sure what you have set your dedicated indexing POA to, but perhaps check this?

    Please do let us know how it goes.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    first I did another GWCHECK-run, which came out fine.

    Then I limited the Quickfinder to the one user with the error by adding qfuserfidbeg/end-tags in the poa-config-file.

    But when indexing this one user the problem persists ending with the followin log-snippet:

    14:26:33 0BC8 QuickFinder: 12020 items indexed
    14:26:33 0BC8 Indexing on attachment (00000001.Disk Day.32.224.txt)
    14:26:33 0BC8 Indexing on attachment (gwcheck.log)
    14:29:38 0BC8 The database function 87 reported error [F041] on userhi9.db
    14:29:38 0BC8 Error updating QuickFinder indexes: [F041]
    14:29:42 0BC8 QuickFinder indexing thread finished
    14:29:42 0A1C Scheduled Event: QuickFinder Indexing completed schedule

    From my point of view the indexing for this user is not finished, it just stopped. Probably there is an attachement or something like this, which causes this error. I would like to delete this E-Mail, but I do not know, how to find it.

    Any suggestions?

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    Just a stab in the dark here....

    14:26:33 0BC8 Indexing on attachment (gwcheck.log)


    The above attachment appears directly before the error. Perhaps it's this attachment causing the issue?

    Please let us know how it goes.

    Cheers,
  • 0 in reply to 
    It is the admin´s mailbox. That is full of these gwcheck.logs. That would be quite a huge darkness to run into and test around.

    What does the indexer do with this zip-files? There is one e-mail with some whopper size of 73.535.817 kb with a zip-file as attachement.

    Should I try to config the POA for avoiding those files just as a test? From the log there is a 3-minute-gap before the error, what could be an hint on a longer lasting and therefore much bigger file.

    Would that make sense?

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    It may very well be that huge zip file. Perhaps you can save the file and delete the e-mail? Is that feasible for you to do?

    Please let us know.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    this specifc e-mail was received at central account and got relayed to a users account. From there it was again relayed to the admin´s mailbox. All the other accounts do not suffer, only admin. From what I know about the database-structure of GW, this huge attachment should be save somewhere in the PO only once.

    Could activation of the /dcafilter-tag for zip-files in the poa-config help? From the the documentation I do not understand, if this tag works, when /nodca is active also (which is active in our case!).

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    As far as I am aware the /dcafilter switch only works if you have the Document Conversion Agent running, which in your case it isn't.

    You are correct that if the user who received the mail with this large attachment is in the same Post Office as your Admin mailbox the attachment is only stored once in a database in the OFFILES directory.

    Other than removing the mail from the Admin mailbox, I'm not too sure what to suggest!

    Having said that, you initial post had two questions in it - one to do with the error, and another about a user who is unable to find mail. What is happening with the user who is unable to use the Find feature?

    Please let us know how it goes.

    Cheers,
  • 0 in reply to 
    Hi Karl,

    I stand to be corrected with regards to the /dcafilter switch and the DCA. Perhaps you would like to test this switch /dcafilter-zip - think about it, you have nothing to lose and everything to gain!

    Please let us know how it goes.

    Cheers,
  • 0 in reply to 
    Hi Laura!

    Ok, with the DCA-filter-switch there was no success.

    My next step would be putting the biggest mails to archive. Am I right, that archived mails with their attachements are not drilled by the quickfinder-indexer?

    SIncerely

    Karl
  • 0 in reply to 
    Hi Karl,

    Correct - archives are not indexed by the POA. Give that a try.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    the problem with error F041 persits. I archived all the huge mails/attachements and it errored. I archived all mails up to 1 month before and 1 month after the mail, which from the verbose log fall in the problematic corridor, and it errored.

    At time I am archiving all mails with a gwcheck.log-attachement (around 10.000 mails, what will last some time) and will then do another try of delete and regenerate the index.

    What will happen when I delete all index-files in \po\ofuser\INDEX?

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    Perhaps try this if you haven't done so already:

    To enable the "Delete and Regenerate All Quickfinder Indexes", set the log level for the POA to Diagnostic. Open the POA HTTP console. Click on Configuration -> QuickFinder Indexing and check the box that says Delete and Regenerate All Indexes.


    In order to accomplish the above your POA HTTP Console will need to be Username/Password enabled as you will have to authenticate in order to see these advanced options.

    Please let us know how it goes.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    I am doing this from the windows-console (not web) of the poa and the "Delete and Regenerate"-option is already available under Actions/Quickfinder. I am using this action all the time. An diagnostic-log-setting is not available there.

    What happens when manually clearing out the index-directory?

    Sincerely

    Karl
Reply
  • 0 in reply to 
    Hi Laura,

    I am doing this from the windows-console (not web) of the poa and the "Delete and Regenerate"-option is already available under Actions/Quickfinder. I am using this action all the time. An diagnostic-log-setting is not available there.

    What happens when manually clearing out the index-directory?

    Sincerely

    Karl
Children
  • 0 in reply to 
    Hi Karl,

    I personally have never manually deleted these files before and thus do not know what impact it would have on your system.

    Perhaps take a look at the dates on the files in that directory? Let us know what you see - thanks.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    the files (.idx and .inc) range from 2015 October 21st till 26st what seems ok to me, since my runs (delete and regenerate) in the beginning included all users. Inbetween I concentrate and work on only one maibox.

    Do the idx-files correspond with single users?

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    As far as I am aware a single IDX file is created per user. What I do not know is how to identify which IDX file is associated to which user, unfortunately :(

    By the sounds of it your previous indexes have been successfully deleted so there's no need to manually delete the file.

    Try running a GWCheck, just against the affected user, with the following options:

    Analyze/Fix Databases, uncheck Structure, Check Content and Fix Problems, both User and Message database, on the Misc tab use the following switch: attclip

    You might have to run this twice, with the attclip option, to clear up orphaned attachments.

    Please let us know how it goes.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    there are much more idx-files then users. All gwcheck.log-mails are archived now and I am running a "delete-regenerate-index" for this user. In case all runs through this time, I will proceed with the gwcheck-runs as advised. But I am still unsure with this far to much idx-files on what to think about or do with this.

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    Each "prime user" database also creates an IDX file. Do you have more than one Post Office with users in your system? I also think that each Resource also has an IDX file.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    this is what I have done since yesterday:

    1. Archived out all mails with an GWCHECK.LOG-attachement. This ran into one error and left one mail unarchived. A manual try of archiving this specific mail was successfull, so all mails were archived. The mail and attachement opened without problems.
    2. Watched the client updating the index of the archive what ran through without any error.
    3. Did two GWCHECK-runs as advised by you, what was without errors and problems after the second run.
    4. Did a relete/regenerate-index-run on the user in question, what ran through without the F041-error this time.
    5. Unarchived all mails with an GWCHECK.LOG-attachement.
    6. Did GWCHECK-runs again without errors and problems.
    7. Did another relete/regenerate-index-run on the user in question, what this time ran into the F041-error again.

    At least we now know, that the problem lies in one of these mails. Do you have an idea, how to identify the mail in question?

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    Sorry, I do not know how to identify the problem mail/attachment :(

    I am at a loss as to what to suggest next :( I'd say open a Service Request with Novell Technical Support but GroupWise 8 is no longer supported and I'm not sure if they would assist you.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    I was afraid to hear this, but guess, you are right.

    Thank you very much for your help in this.

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    I've been thinking about this... if this were me, I would, one last time, run a Structural Rebuild on the user database but ensuring that the user is logged out of both GroupWise and Notify.

    I would then run another Structural Rebuild on the message database - though I don't think that this is where the problem lies!

    Cheers,

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.