 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / Other Technologies / Full-Text Search / June 2005An unknown full-text failure (80004005) occurred in function EnumCatalogs
We are using Full Text Search on our production SQL Server (Active/Active Cluster, MSSQLSERVER EE). Within the last week we have not been able to rebuild the FTC on any database on one node/instance. We get the following message: Server: Msg 7608, Level 17, State 1, Procedure sp_fulltext_database, Line 46 An unknown full-text failure (80004005) occurred in function EnumCatalogs on full-text catalog ''. This roughly corresponds with when we moved a database from one logical drive to another by means of detach/attach. I believe that there is now some inconsistency between the FTDATA folders, the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0 registry, and the FTC metadata in sysfulltextcatalogs. It's taking me a while to verify this because off the large number of databases and FTDATA folders on multiple drives. The first question is that when calling "sp_fulltextdatabase 'enable'" is the consistency between database, registry and folder being verified by SQL Server or MsSearch? It seems to be because I can't do a "sp_fulltextdatabase 'enable'" in a new database now on the instance in question, which leads me to believe that when there is one inconsistency you won't be able to make catalog metadata changes until the inconsistency is resolved. The second question is, if the first question is true, is there an easy or even automated way to check the consistency and possibly repair it? Jim Roberts Hire.com Senior Database Engineer MCSE, MCDBA Jim, You are mostly correct... When you moved your FT-enabled table via detach/attach that "broke" not only the Registry key, FTDATA folder, but also caused inconsistency system tables, not only sysfulltextcatalogs, but sysdatabases, sysobjects, sysindexes and syscolumns. To resolve this takes several steps, that can include modifying the registry as well as updating all affected files and system tables via manually de-referencing the FT Catalog info from the Registry, FTDATA folder as well as from all system tables. I have a procedure to do this, that because of the above changes is not documented and if incorrectly executed can cause problems. So, while this procedure has worked very successfully in many instances, while I was at Microsoft as well as in this newsgroup, caution is advised. First of all, I need to know the exact version of SQL Server, you are using. Could you post the full output of SELECT @@version -- as the procedure is very specific to the SQL Server version. Additionally, you should backup your detached/attached database as well as make a Registry backup of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\ hive. Regards, John > We are using Full Text Search on our production SQL Server > (Active/Active Cluster, MSSQLSERVER EE). [quoted text clipped - 30 lines] > Senior Database Engineer > MCSE, MCDBA SQL Server Version (@@VERSION): Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 3) A collegue of mine had suspected that there would problems associated with moving a database in this fashion, but I don't think that even he considered it this risky. Obviously, this should be one of those items that goes under Best Practices dos and don'ts (specifically don'ts). With this information I should have no problem convincing others that it is in our best interest NOT to move databases by dettaching and re-attaching them. I really appreciate your time. Your posts are always illuminating and thanks for replying. You're welcome, Jim, Let me know if you need the script. I suspect that it can be turned into a "reporting" script with a little bit of effort and check the components.... However, a detach/attach will still breaks the relationships between the database system tables and the FT Catalogs... Regards, John > SQL Server Version (@@VERSION): > Microsoft SQL Server 2000 - 8.00.760 (Intel X86) [quoted text clipped - 16 lines] > I really appreciate your time. Your posts are always illuminating and > thanks for replying. Yes I would like the script that you were refering to. We have a production database that we can't rebuild or even enable full text catalogs on. Thanks again -Jim Done. > Yes I would like the script that you were refering to. We have a > production database that we can't rebuild or even enable full text [quoted text clipped - 3 lines] > > -Jim Hi John, Thanks for you previous advise, unfortunately I was missing a vital piece to this puzzle. This error is occuring even on a freshly minted database after running (in the new database): exec sp_fulltext_database 'enable' We're waiting for a maintenance window to come around before attempting to run the script that you provided, but anticipate that the script will not have an effect on this problem because of the scenario that I describe above. -Jim Hello, I have the same problem exacly the same :( I check the account service of SQL, MSSEARCH, and MS AGENT. Ir´s ok. I don´t know what going on. Any clue? I see you talking about. Please help me is you know how :) Regards. GCZ > *Hi John, > [quoted text clipped - 17 lines] > *** Sent via Developersdex http://www.examnotes.net *** > Don't just participate in USENET...get rewarded for it! * :what -- gabrielcz did you review this kb article? http://support.microsoft.com/default.aspx?scid=kb;en-us;295772  SignatureHilary Cotter Looking for a SQL Server replication book? http://www.nwsu.com/0974973602.html Looking for a FAQ on Indexing Services/SQL FTS http://www.indexserverfaq.com > > Hello, [quoted text clipped - 35 lines] > ------------------------------------------------------------------------ > View this thread: http://www.mcse.ms/message490897.html |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.