locked
Full Crawl Never Ends RRS feed

  • Question

  • I have a full crawl that the status shows "Full Crawl" and the Current Crawl Duration shows "433:29:09" and does not appear to be ending.

    I have already looked over an article online by Mike Hanley and read the MS KB (http://support.microsoft.com/kb/930887/en-us ) and ran the query on the SSP Search DB as reccomended on the 9 indexes and all returned a "1" as they should. Also, checked and we are using SQL 2005 SP3 (read that 2005 SP1 would be an issue).

    The only thing I have not done is created a new SSP and remove the old one as I have read that is a last resort step and for some it has not resolved the issue.

    Any other suggestions as to how to correct this? Thanks.

    Monday, January 25, 2010 9:58 PM

Answers

  • We have seen this a couple of times in the past (though your errors are unknown to me). We also use x64 farm with dedicated search query server. On of the problems that might occur is that an external application (in our case it was arcserver backup) pauses the index. During this pause, the ui simply states that the crawl is still running. You can find any crawl being paused in the eventlog. If this happens, you must stop the crawl manually and (therfore) do a full crawl after.

    Somebody might als suggest to reset all crawl content. If this might work for you, you can give it a try. FOr us with 3.5 mljn docs this would mean a full day without index. People here are depending on the accuracy of the index and so this would not be a valid option for us.

    My experience is that is a crawl takes so long, it is probably stuck. There is no need for it to let it run. You can stop is manually and try to start (a mandatory) full crawl. Look at errors in the log. We had a site customaization with an lookup field. this cause the crawler to not crawl anything in this site (though the site def was acctually correct). SO you might want to investigate that.

    Did you try net stop osearch and net stop spsearch. Look at any mssearch process still active. Can you explain that process. I bleiev (but am not sure) by stopping osearch and spsearch all mssearch workerproecess should be eliminated.

    If you recreate the ssp you will need to do a full crawl on all your content sources... so that might be your last resort, but untill now we always managed to solve the rpoblemes without content reset or recreating the ssp.

    good luck!

    Sander

    • Marked as answer by Lu Zou-MSFT Wednesday, February 3, 2010 9:30 AM
    Friday, January 29, 2010 10:27 AM

All replies

  • I am experiencing similar issues. I first thought it was the PDF iFilter and updated to a newer version, but that did not fix the problem.  I am getting several Event ID 10036.

    Description: Object 'dbo.membership_updateRecursiveMemberships' was successfully marked for recompilation.

    Description: Transaction (Process ID 140) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

      Description: Divide by zero error encountered.

    Monday, January 25, 2010 10:45 PM
  • Please verify if this article can help.
    "When you perform a crawl in a SharePoint Server 2007 site, the crawl runs indefinitely"
    http://support.microsoft.com/kb/967209/en-us
    André Lage Microsoft SharePoint, CRM and Sybase Consultant
    Blog:http://aaclage.blogspot.com
    Codeplex:http://spupload.codeplex.com/http://simplecamlsearch.codeplex.com/
    Tuesday, January 26, 2010 12:23 AM
  • We have SP2 installed. The hotfixes are prior to SP2 and will not install with the error "The expected version of the product was not found on the system" (guessing they were included in SP2?)

    Still stuck...
    Tuesday, January 26, 2010 7:19 PM
  • Hi njb1966,

    There are different reasons for this issue. I suggest you restart IIS Services to see if it works.

    Do you use 32-bit or 64-bit machine? When you use 32-bit machine, the problem may occur because of the memory leak. It’s suggested to have IIS recycle automcatcally to avoid this problem. For this topic, please read this blog:

    http://blogs.msdn.com/opal/archive/2008/04/14/what-may-happen-when-i-crawl-millions-of-files-in-moss-mss-part-ii-why-i-need-x64-instead-of-x86.aspx

    If this is not the issue, do you use any disk disk defragmentation utility? It may cause the index to become corrupted and the WFE would detect that the index is corrupted and stop crawling.

    Do you have any scheduled backup operation on SharePoint server? It may pause and resume the indexing operation of the search service automatically. You can reset the MaxBackupDuration to 120 (2 hours). This will cause the index to resume after 2 hours regardless of whether the backup completes successfully or not. For more information, Please refer to:
    http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.search.administration.spsearchservice.maxbackupduration.aspx

    I also suggest you check your event viewer to see if there is relevant error there for thoubleshooting.


    Hope this helps.

    Lu Zou

     

    Wednesday, January 27, 2010 6:45 AM
  • Restarted IIS, did not resolve issue.

    We are using 64-bit.
    No disk defragmentation utility is being used.

    The log file is showing quite a few Windows SharePoinit Services 3 errors (Event ID 6762) all stating the same thing:

    Error initalizing Safe control - Assembly:BCCS.MOSS.EH.CAtegories.Veersion=1.0.0.0,Culture=neutral, PublicKeyToken=******* TypeName:BCCS.MOSS.WP.PortalSCheduler Error: Could not load type 'BCCS.MOSS.WP.PortalScheduler' from assembly 'BCCS.MOSS.EH.Categories, Version 1.0.0.0, Culture=neutral, PublicKeyToken=(same as previous PKT)".

    Another common warning is Office Server Search (Event ID 2423):

    The update cannot be started because all the content sources were excluded by crawl rules, or removed from the index configuration.
    Context: Application 'OurSSP', Catalog "Portal_Content"
    Details: Unspecified error (0x80004005)

    Thursday, January 28, 2010 4:59 PM
  • We have seen this a couple of times in the past (though your errors are unknown to me). We also use x64 farm with dedicated search query server. On of the problems that might occur is that an external application (in our case it was arcserver backup) pauses the index. During this pause, the ui simply states that the crawl is still running. You can find any crawl being paused in the eventlog. If this happens, you must stop the crawl manually and (therfore) do a full crawl after.

    Somebody might als suggest to reset all crawl content. If this might work for you, you can give it a try. FOr us with 3.5 mljn docs this would mean a full day without index. People here are depending on the accuracy of the index and so this would not be a valid option for us.

    My experience is that is a crawl takes so long, it is probably stuck. There is no need for it to let it run. You can stop is manually and try to start (a mandatory) full crawl. Look at errors in the log. We had a site customaization with an lookup field. this cause the crawler to not crawl anything in this site (though the site def was acctually correct). SO you might want to investigate that.

    Did you try net stop osearch and net stop spsearch. Look at any mssearch process still active. Can you explain that process. I bleiev (but am not sure) by stopping osearch and spsearch all mssearch workerproecess should be eliminated.

    If you recreate the ssp you will need to do a full crawl on all your content sources... so that might be your last resort, but untill now we always managed to solve the rpoblemes without content reset or recreating the ssp.

    good luck!

    Sander

    • Marked as answer by Lu Zou-MSFT Wednesday, February 3, 2010 9:30 AM
    Friday, January 29, 2010 10:27 AM
  • Hi Nick,

    How did you find current crawl duration?

    Friday, August 18, 2017 11:46 AM