I have received the following error (over a period of days): Event Type:ErrorEvent Source:Office Server SearchEvent Category:Gatherer Event ID:10027Date:6/9/2008Time:10:11:32 AMUser:N/AComputer:MOSSDV1Description:Failed to update committed transaction in SQL, DocID is 26211786. Context: Application 'SharedServices1', Catalog 'ProfileImport' Details:One or more errors occurred during processing of command. (0x80040e14) For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Not sure what caused the error; however, after a machine reboot, I no longer gets these errors in the event log. If I try to "Reset all crawled content" or just "Stop" incremental crawls, it looks like these functions just time out or hang. Our Sharedservices 1 search database is now really large - about 10 times the size it should be. Any ideas on how to reduce the size of the database?

You can try to re-schedule the search plan. And you can modify it in Shared Services Administration > Search Settings > Content sources and crawl schedules, but in the page if your status is always crawling full, you may need to view this article and try to solve it.-lambert

My mistake, looks like the Dev instance is 20000 times bigger with the same basic content. Dev MSSCrawlURL: 60616166 (83.97 GB) MSSCrawlURLLog: 7058214 (7.98 GB) MSSCrawQueue: 21458972 (4.63 GB) Prod MSSCrawlURL: 4775 (4.3 MB) MSSCrawlURLLog: 38 (24 KB) MSSCrawQueue: 0 (248 KB) Any feedback on this idea from above? stsadm -o osearch -action stop stsadm -o osearch -action start How about the process to create a new SSP idea?

There must incorrect operations during daily work with your Dev instance. I suggest you to do these steps: 1. create a new SSP. 2. delete and recreate a search database. 3. perform a full crawl and user profile import. -lambert

you need local administrator right, try to add you account to buildin administrators group -lambert

The account I was using was an admin account. After reviewing the issue more, stsadm was a 0 byte file size. I'm not sure how it got like this. I copied stsadm.exe from another installation and tried it again. I got the error "command line error". I'm not sure what I had wrong as I was using the command line in this post. I decided to try using the GUI again. The site was still marked as "unprovisioning". This time (with more disk space added), it deleted SSP1. It looks like I had an SSP that was corrupted somehow. Now I can monitor disk space and see if the new SSP has the same problem. After 3 days however, it has not grown appreciably different than production. The basic steps to resolve the problem was: 1. Create a new SSP in a new application pool. 2. Associate all web sites applicable to the new SSP 3. Change the default application pool to the new SSP 4. Delete the old SSP.

It could be your system is completely out of HD space? - Delete the databases from within SQL Server Management studio. Search databases are expendable, you don't need a backup. - Delete all other unnecessary data from the HD of the server (tempfiles etc.) you might have - check all other databases: check their size and % effective size. Shrink the logfiles of all databases and free up the space. Whenyou recreated the SSP and everything works again: make sure your search db sizeis limited below the space available on disk. Never let it run out of diskspace. If a logfile wants to be bigger than the size it has set, it can't complete someactions but it will recover. If the diskspace is running out it's unpredictable what's going to happen. If the two search databases are unequal, it might be that seach rules are prevented on prod but not on dev or vice versa. F.I. (also) use a read only search account on dev, you surely need a readonly search account on prod.