mssearch cannot merge master catalog

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Matiu Carr - 21 Jun 2005 09:17 GMT

Hi

This may be an ancient query -but I have not found answers searching across
MS's WWW site or the wider internet.

I have

SQL 7sp4 + combined security update for sql7sp4

I have recently tried to enable full text indexing, so went back to the SQL
7 CD and added the component.

As far as SQLserver is concerned, everything seems to work until I build a
catalog. The indexer and gatherer seem to do what they are supposed to, and
lots of files are generated in the appropriate places
<MSSQLSVR7>\FTDATA\etc.

However, every catalog built on this server has properties similar to the
following:

items: n
catalog size: 1 MB
unique words: 1

MssCi reports an error in the servers Application log

event ID: 4105
Master merge cannot be started on <catalog>\build\indexer\cifiles\
due to error 3221225488

the files exist -though I am not sure whether they are "correct".

The MS support site suggests a lack of disk space may be the cause. There is
heaps of space free -many times the demands of the whole database. The
database is set to grow automatically as required -though I cannot see
anywhere I can tweak the catalog container size. The database and log
containers are mostly empty (data would need to quadruple to fill up the
allocated space -even with automatic growth switched off).

To test this size issue I indexed the Northwind.Shippers table on
'CompanyName' (using the default version that comes with SQL7) -4 records, 1
unique word, broken search functions, error in the applications log (as
above).

The other thing I am indexing has only got 130 records at this stage, but
these contain quite large chunks of "academic" (n)text (and more will be
added), so there will be quite a high hit rate for unique words.

My suspicion is that the server version is too far ahead of the version of
the files associated with the integrated MSSearch agent.
There is no way I can add whatever changes may have been made by the service
packs subsequent to 7.0. Whether this is an issue or not, I am not sure.

Other than upgrading to a more current version of MS SQLserver, are there
any suggestions as to how this may be resolved?

Mat IT Manager, NICAI
-------------------------------------
http://www.people.auckland.ac.nz/Mat/
-------------------------------------

Reply to this Message

Daniel Crichton - 21 Jun 2005 11:38 GMT

Matiu wrote on Tue, 21 Jun 2005 20:17:50 +1200:

> Hi
>
[quoted text clipped - 7 lines]
> I have recently tried to enable full text indexing, so went back to the
> SQL 7 CD and added the component.

Did you reinstall the SQL service pack and updates? It's possible that the
FTS service had updates in the SP/updates to match with the SQL binaries.

While the error you are seeing may be related to disk space, it's a device
i/o error code. Check that the account the FTS service is running under has
sufficient permissions for the location of the catalog files, and that it is
a member of the builtin\administrators group. The code could also mean "file
not found" indicating that the file wasn't in the expected location.

Dan

Reply to this Message

Matiu Carr - 21 Jun 2005 22:30 GMT

> Matiu wrote on Tue, 21 Jun 2005 20:17:50 +1200:
>> I have
[quoted text clipped - 6 lines]
> Did you reinstall the SQL service pack and updates? It's possible that the
> FTS service had updates in the SP/updates to match with the SQL binaries.

This is part of the problem. The service packs cannot be installed over the
top of a later version. The build is 7.00.1094. Attempting to install sp4
terminates saying you cannot install an older version over a newer one, and
some advice along the lines of "contact your local SQL 7 support" is given.

Re-applying the KB815495 patch does not seem to help -this is the last
update for SQL7 I can find in the public support areas.

I have seen manual installation described for FTS @ SQLsvr 2000, but not for
7. They may be similar.

> While the error you are seeing may be related to disk space, it's a device
> i/o error code. Check that the account the FTS service is running under has
> sufficient permissions for the location of the catalog files, and that it is
> a member of the builtin\administrators group. The code could also mean "file
> not found" indicating that the file wasn't in the expected location.

mssearch runs as the system account. builtin\administrators literally own
the hierarchy where FTDATA resides (and most of the rest of the machine).
SQL runs as SYSTEM. builtin\administrators is a member of sysadmin, etc.

Is there a way of figuring which file was not found where?

The gatherlogs are not particularly helpful -they reflect the information
events posted by mssearch as it runs which are all positive until MssCi
reports the catalog build issue.

Is there a decent "man page" for the mssearch suite? If I could manually
have a go at the process, I could probably work out where the issue lies -I
am guessing this could all be done via a command line.

BTW. the server is
Windows 2000 server sp4 + current patches

Mat IT Manager, NICAI
-------------------------------------
http://www.people.auckland.ac.nz/Mat/
-------------------------------------

Reply to this Message

John Kane - 23 Jun 2005 05:27 GMT

Matiu,
After SQL Server 7.0 SP4 has been applied you cannot re-apply any services
packs as you would of been able to do this prior to installing SP4. I've
tested and can confirm it. If the best solution is re-installing the SP,
your only solution is to un-install SQL Server 7.0 and then re-apply SP3 to
confirm if that SP will fix this issue for you, if not the apply SP4.

Troubleshooting SQL Server 7.0 FTS issue is sorta like trying to discern
what is behind a black hole as no light escapes and you cannot see behind
it. You may want to try the following approach to remove the tracking key
for the FTS components on SQL 7.0 and then re-install the FTS components via
your SQL 7.0 CD and if successful, then re-apply SP4. NOTE: this tracking
key is specific to SQL Server 7.0 and be sure to be logged on to the server
as either Administrator or as a member of the server's Admin Group!

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\<Instance_Name>\Tracking\{E07FDDA7-5A21-11d2-9DAD-00C04F79D434}

Once you've done removed the above tracking key, then delete the MSSearch
directory from either:
drive_letter:\Program Files\Common Files\Microsoft Shared\
or
drive_letter::\Program Files\Common Files\System\

Then using your SQL Server 2000 installation CD re-install via "Custom
Installation" the Full-Text Search component (it should be un-checked). When
this completes find and save these files: SearchSetup.log (usually under
\windows or \winnt folders) and sqlsp.log. If any problems, please post
these files.

Re-install SQL Server 2000 SP3 (or SP4), so that the newly installed
MSSearch components are upgraded to SP3 or SP4 levels.

Re-boot &/or restart the MSSearch and MSSQLServer services.

If the above fails, there are other methods, that may also require the
re-installation of SQL Server itself.

Regards,
John

Signature

SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/

> > Matiu wrote on Tue, 21 Jun 2005 20:17:50 +1200:
> >> I have
[quoted text clipped - 45 lines]
> http://www.people.auckland.ac.nz/Mat/
> -------------------------------------

Reply to this Message

John Kane - 23 Jun 2005 06:17 GMT

Matiu,
A *minor* correction... Use the following SQL Server 7.0 tracking key:
HKLM\SOFTWARE\MICROSOFT\MSSQLSERVER\TRACKING\{E07FDDA7-5A21-11d2-9DAD-00C04F
79D434}

Thanks,
John

Signature

SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/

> Matiu,
> After SQL Server 7.0 SP4 has been applied you cannot re-apply any services
[quoted text clipped - 97 lines]
> > http://www.people.auckland.ac.nz/Mat/
> > -------------------------------------

Reply to this Message

Daniel Crichton - 23 Jun 2005 15:16 GMT

Matiu wrote on Tue, 21 Jun 2005 20:17:50 +1200:

> Hi
>
[quoted text clipped - 52 lines]
> Other than upgrading to a more current version of MS SQLserver, are there
> any suggestions as to how this may be resolved?

Gah, typical. I started working on my development server again today after a
long time not needing to use it, and found FTS wasn't installed but SQL7 SP4
was. I installed FTS, created a catalog, started a full population ... and
started getting the same errors as you.

I think I've found a solution, but I won't know until the full population I
just kicked off finishes. However, when I first ran it I was getting these
errors by now, so I think I've solved it. I didn't have to reinstall SQL7
either ;) So far it's complete 2 master merges with no errors.

First up, stop SQL Server and the MSSearch service. Backup the following
files (you don't need to do this, but I always find a backup makes me less
nervous :P) from the MS SQL7 installed dir:

Binn\schema.txt
Binn\sqlfthndlr.dll
Binn\sqlftqry.dll
Binn\sqlftwiz.dll
Binn\sqlftwiz.exe
Binn\Resources\1033\sqlftwiz.rll

That last one might be in a difference resources dir depending on your
locale settings. I think these are just used by the EM for the FTS wizard
dialogs.

Next, copy the above files from the SP4 CD/extracted dir \x86\FULLTEXT\
into the SQL7 installed Binn dir overwriting the above files you've made a
copy of. with the file in the res\1033 folder going into the Resources\1033
folder.

Final step is to install the MSSearch service from the SP4 installation. The
command line is

x86\FULLTEXT\mssearch\mssrchstp /c:"searchstp /a:SQLServer
/AppPath:c:\Mssql7\ftdata"

but replace the AppPath value with the appropriate one for your
installation. This will install the SP4 version of MSSearch, answer yes to
each replace file question (there is no Yes To All button unfortunately),
and at the end it'll ask to to reboot - do so. On reboot the MSSearch
service will complete installation and dlls will be registered.

That should be it. Please note that this is not a supported method, I made
this up as I went along. Following my advice is entirely at your own risk.

Dan

Reply to this Message

Daniel Crichton - 23 Jun 2005 16:14 GMT

Daniel wrote to Matiu Carr on Thu, 23 Jun 2005 15:16:03 +0100:

> Gah, typical. I started working on my development server again today after
> a long time not needing to use it, and found FTS wasn't installed but SQL7
[quoted text clipped - 40 lines]
> That should be it. Please note that this is not a supported method, I made
> this up as I went along. Following my advice is entirely at your own risk.

It worked! Over 417,000 records all correctly indexed, no errors in the
event log, and a test using CONTAINS brings back the correct results :)

Dan

Reply to this Message