none
Crawl Status stuck on computing ranking - Backups do not complete

    Question

  • Hi,

    We have a newly built sharepoint 2010 farm, using a WFE and Application server with a backend SQL.

    As part of a previous issue we have recreated the seach service application. Since that point we are unable to complete a backup using the backup-spfarm command. (Backup-SPFarm -Directory \\xxx\spbackup -BackupMethod Full -Verbose)

    The backup never completes, it does not error or complete sucessfully, and has to be terminated manually. The backup is then not restorable via the central admin.

    We have attempted a backup of the search application only using the switch -Item "Search Service Application" on backup-spfarm, and this does not complete, but we are able to back up other components ok.

    We have also noticed that the crawl status background activity changes to "computing ranking" and will  not change unless a full index reset is done. The crawl and searching is working as expected regardless of if its computing ranking or not.

    We have already recreated the search application.

    Here is a similar situation I found for 2007

    http://social.technet.microsoft.com/Forums/en-US/sharepointsearch/thread/40270ed3-73b2-4133-925f-1daa71ea4ac0/

    However this does not apply to us on 2010.

     

     

    Friday, January 14, 2011 12:06 PM

Answers

  • Hi Rock,

    Removing the query component was not possible as we were unable to see the config page of the search application at the time. The issue is now resolved - here is a summary of what was done for anyone else with similar issues:

    1 - Reset Timer job

    On both servers:
    1. Stop the Timer service.
    To do this, follow these steps:
    a. Click Start, point to Administrative Tools, and then click Services.
    b. Right-click Windows SharePoint Services Timer, and then click Stop.
    2. Delete or move the contents of the following folder:
    a. %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\GUID
    b. Leave the cache.ini alone
    c. Delete all other files (all guid.xml) these are all timer job definitions
    d. Open cache.ini in notepad and change whatever number you see there to 0

    3. Start the Timer service:
    To do this, follow these steps:
    a. Click Start, point to Administrative Tools, and then click Services.
    b. Right-click Windows SharePoint Services Timer, and then click Start.
    Note: The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm on which the Timer service is running.

    Go back to the %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\GUID folder and make sure you see a bunch of xml files.
    Open the cache.ini and see if the 0 is replaced by a higher value.
    You have now synched all your servers with the same timer job definitions from the config db.
    2- Deleted all search applications via Central Admin.
    Get-spserviceapplication in powershell to get any ID's
    Removed ID's using stsadm  -deleteconfigurationobject -id command.
    3 - Recreated Search app with only 1 Query component and using 2 new app pools, 1 for query , 1 for crawl.
    4 - Recrawled and attempted backup of search application only. This was confirmed to work without being stuck on computing ranking.
    Thanks
    • Marked as answer by spryan Monday, January 24, 2011 12:30 PM
    Monday, January 24, 2011 12:29 PM

All replies

  • Hi Spryan,

     

    How many search applications do you have?

     

    Could you tell me the detailed information about your search application topology? Such as which component runs on which server. For ex ample, crawl component 0 runs on the server WFE, index partition 0 runs on APP. If this were your case, try to change the crawl component to APP server, then check the effect.

     

    Did you remove the old crawl database before you create a search application? If not, please remove the old database.

     

    In addition to that, try to delete the old index file on your SharePoint server, then check the effect.

     

    For more information about Search 2010 Architecture, please refer to the following articles:

     

    http://blogs.msdn.com/b/russmax/archive/2010/04/16/search-2010-architecture-and-scale-part-1-crawl.aspx

     

    http://blogs.msdn.com/b/russmax/archive/2010/04/23/search-2010-architecture-and-scale-part-2-query.aspx

     

    For the backup issue, please post it into a new thread. If you have any questions, please let me know.

     

    Rock Wang


    Regards, Rock Wang Microsoft Online Community Support
    Wednesday, January 19, 2011 8:25 AM
  • Hi Rock,

    Thanks for the reply. The search configuration is a a crawl component 0 on the application server, a query component 1 on the app server, and query component 2 on the WFE server.

    The search service DB has been recreated in the past to fix another search issue but I havent removed it since this current issue.

    Can you tell me where the index file is held on the Sharepoint server, all the information I could find related to 2007.

    The backup failing is the main issue, the search itself continues to work but the "computing ranking" only occurs after a backup has been attempted, so the 2 are linked.

    An index reset does stop the computing ranking, unless another backup is then run.

     

    Wednesday, January 19, 2011 10:16 AM
  • Hi Spryan,

     

    From your reply, you had two query components, one is on the APP server, the other is on the WFE server. Please try to remove the query component on the WFE server, then check the effect.

     

    Select query component, then click edit properties, you will see the location of Index file.

     

    Hope this helps.

     

    Rock Wang


    Regards, Rock Wang Microsoft Online Community Support
    • Marked as answer by spryan Monday, January 24, 2011 12:30 PM
    • Unmarked as answer by spryan Monday, January 24, 2011 12:30 PM
    Monday, January 24, 2011 3:54 AM
  • Hi Rock,

    Removing the query component was not possible as we were unable to see the config page of the search application at the time. The issue is now resolved - here is a summary of what was done for anyone else with similar issues:

    1 - Reset Timer job

    On both servers:
    1. Stop the Timer service.
    To do this, follow these steps:
    a. Click Start, point to Administrative Tools, and then click Services.
    b. Right-click Windows SharePoint Services Timer, and then click Stop.
    2. Delete or move the contents of the following folder:
    a. %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\GUID
    b. Leave the cache.ini alone
    c. Delete all other files (all guid.xml) these are all timer job definitions
    d. Open cache.ini in notepad and change whatever number you see there to 0

    3. Start the Timer service:
    To do this, follow these steps:
    a. Click Start, point to Administrative Tools, and then click Services.
    b. Right-click Windows SharePoint Services Timer, and then click Start.
    Note: The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm on which the Timer service is running.

    Go back to the %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\GUID folder and make sure you see a bunch of xml files.
    Open the cache.ini and see if the 0 is replaced by a higher value.
    You have now synched all your servers with the same timer job definitions from the config db.
    2- Deleted all search applications via Central Admin.
    Get-spserviceapplication in powershell to get any ID's
    Removed ID's using stsadm  -deleteconfigurationobject -id command.
    3 - Recreated Search app with only 1 Query component and using 2 new app pools, 1 for query , 1 for crawl.
    4 - Recrawled and attempted backup of search application only. This was confirmed to work without being stuck on computing ranking.
    Thanks
    • Marked as answer by spryan Monday, January 24, 2011 12:30 PM
    Monday, January 24, 2011 12:29 PM
  • thanks, it worked on my sp.

    Monday, July 06, 2015 1:06 PM