MSSearch.exe error window: "Tracer"

My company has a client using SQLServer 2000 SP3a.
Every so often (approx. once a week), the full-text indexing will fail on
one of our database tables. We are unsure why, but have noticed some rather
bizarre behavior associated with this failure. (Normally, we restart the
MSSearch service and everything works again.)
Just today, the client called to tell us it didn't work. So, using
LogMeIn.com, I controlled their server computer to see what was going on.
Immediately I noticed a messagebox window with a title of "Tracer" and text
of "Release products should NOT call tracer!". The only button was "OK".
I didn't know for sure where this message was coming from, so I used
SysInternals' Process Explorer to list the processes and their window titles.
Lo and behold, MSSearch.exe was the process tied to "Tracer".
Obviously, this is a SQL Server bug, but I've not found reference to it in
any online searches. Has anyone seen this? Is it fixable by upgrading to
SP4 (this client is still using NT4, though).
Thanks for any information.
John,
Basic troubleshooting of SQL Server 2000 and MSSearch is somewhat of a black
art (as I can attest to), but the first place you should look for
information on what is causing the full-text indexing failure is the
server's Application event log as this is the only place where errors,
warning and information events are recorded for the MSSearch service. Look
for all related "Microsoft Search" or MssCi source events (errors, warning
and information) near the time of the failure. This will be the best source
of info as to what is causing the problem.
While I've never have used LogMeIn.com, I have known Microsoft to attach
debuggers to both SQL Server and the MSSearch.exe to identify bugs. If you
believe this to be a bug, then I'd highly recommend that you open a support
case with Microsoft PSS SQL Server support and get this resolved for your
client.
Regards,
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
"John" <John@.discussions.microsoft.com> wrote in message
news:FAE1B226-FF90-41EC-9465-575285E412FF@.microsoft.com...
> My company has a client using SQLServer 2000 SP3a.
> Every so often (approx. once a week), the full-text indexing will fail on
> one of our database tables. We are unsure why, but have noticed some
> rather
> bizarre behavior associated with this failure. (Normally, we restart the
> MSSearch service and everything works again.)
> Just today, the client called to tell us it didn't work. So, using
> LogMeIn.com, I controlled their server computer to see what was going on.
> Immediately I noticed a messagebox window with a title of "Tracer" and
> text
> of "Release products should NOT call tracer!". The only button was "OK".
> I didn't know for sure where this message was coming from, so I used
> SysInternals' Process Explorer to list the processes and their window
> titles.
> Lo and behold, MSSearch.exe was the process tied to "Tracer".
> Obviously, this is a SQL Server bug, but I've not found reference to it in
> any online searches. Has anyone seen this? Is it fixable by upgrading to
> SP4 (this client is still using NT4, though).
> Thanks for any information.
|||We have the same thing happening sparodically at one of clients as well, The Tracer message pops up, the fulltext search quits working, if we restart mssearch it starts working again.
Only real difference I see, is that our client is running Small Bussiness Server, (Windows 2000, SP4) and I was blaming it on that, since they have all kinds of strange limitations they try to put in it.
I am switching it to update at 4AM each day instead of the continuas background update, and see if that makes a difference.
It only causes trouble when indexing 1 of the two tables we are indexing. The table has 550,000 items and a 5303 MB catalog, with a key count 6 million.
************************************************** ********************
Sent via Fuzzy Software @. http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...

msmq missing messages after applying SP3a to SQL server

Used to work fine:
(windows 200 server, sql server 2000, JDBC driver SP2.)
Two java processes, one sending messages (using jdbc and sql as temp storage), second is receiving and placing on msmq.

After installing SP3a for SQL server, under high load (200 a sec) there are missing messages in msmq.
Installed everything from scratch on separate machine, works fine until SP3a is applied.
Any help is highly appreciatedCheck for error messages on the box with SP3. M$ closed the hole for buffer overflow. JDBC by default is declaring @.Px as NVARCHAR(4000). If you are not handling TYPEing correctly, post-SP3 machine will post something like "Invalid TDS packet sent by client" error to the log.|||That would be where I look first. With sp3/3a microsoft modified quite a bit on the security side which has caused problems in other areas as well. Check your event logs and sql server logs. If nothing there, use sql profiler on the test machine and trap on "errors and warnings".|||actually, i belive it was a good thing they addressed this, but a bad thing the way they did it. now the bewildered and confused jdbc coders are looking out the window and wondering if the world's really ending or it's just their code...

MSDTC resource in a Cluster

I've read and heard some conflicting information about the best method for
setting up a MSDTC resource in a cluster. I am running MSSQL 2000 SP3a and
Windows 2003. 2 node cluster with currently only once instance of MSSQL
with a great chance of growing.
A few questions I have:
Should the resource be in the cluster group or the virtual server group?
What else does it need, ip address, name...?
If it's not yet being used, is it safe to have it on the quorum drive
(currently 1GB RAID1)?
Has anyone found a white paper specific to Win2k3, MSSQL2k and MSDTC?
Thanks,
Joseph
Hi,
I've found this paper
http://support.microsoft.com/default...b;en-us;301600
It suggests to put MSDTC in its own group with its storage resource(disk).
On other hand if that is not possible you can put it in a group with disk.
Anyway I would mess with quorum drive, so I would put it in a Virtual Server
group.
Danijel
"Joseph" <Joseph@.discussions.microsoft.com> wrote in message
news:OEv$n4M%23EHA.2552@.TK2MSFTNGP09.phx.gbl...
> I've read and heard some conflicting information about the best method for
> setting up a MSDTC resource in a cluster. I am running MSSQL 2000 SP3a
> and
> Windows 2003. 2 node cluster with currently only once instance of MSSQL
> with a great chance of growing.
> A few questions I have:
> Should the resource be in the cluster group or the virtual server group?
> What else does it need, ip address, name...?
> If it's not yet being used, is it safe to have it on the quorum drive
> (currently 1GB RAID1)?
> Has anyone found a white paper specific to Win2k3, MSSQL2k and MSDTC?
> Thanks,
> Joseph
>
|||The official best practice is "put MSDTC in its own group" but to do that
you will need an extra disk, Network Name and IP Address.
Unless you know you will be hitting MSDTC hard, like in a BizTalk
environment for example then leave it in the cluster group. In the event of
an MSDTC failure the Cluster Group will failover to the passive node. The
only "outage" will be for admin's connected to the Virtual Cluster Name in
Cluster Administrator as the resources are re-started on the new node. It
will not affect any other groups.
Alternatively, if MSDTC was in the SQL Group then a failure would cause a
SQL Server outage. If your application is entirely dependant on MSDTC, this
might be fine but its more likely that you wouldn't want that to happen.
You can set MSDTC to not affect the group but then you don't have the
benefit of failover.
In summary, leave MSDTC in the Cluster Group. It makes sense and we support
it
Christian Bolton
Microsoft
"Danijel Novak" <danijel.novak@.snt.si> wrote in message
news:nVfFd.8296$F6.1420730@.news.siol.net...
> Hi,
> I've found this paper
> http://support.microsoft.com/default...b;en-us;301600
> It suggests to put MSDTC in its own group with its storage resource(disk).
> On other hand if that is not possible you can put it in a group with disk.
> Anyway I would mess with quorum drive, so I would put it in a Virtual
> Server group.
> Danijel
> "Joseph" <Joseph@.discussions.microsoft.com> wrote in message
> news:OEv$n4M%23EHA.2552@.TK2MSFTNGP09.phx.gbl...
>

MSDTC and Full Text Indexing

Happy Christmas everyone,
I have just visited an active/active win2K(sp2) and SQL 2000(sp3a) cluster
that is not too happy. The virtual servers will not fail over between the
nodes as the MSDTC will not restart if moved. Full text indexing exists
only in one virtual server and needs to be on both instances.
I suspect that comclust wasn't run at installation but has been subsequently
run on one node only. Is there a safe way of now recreating the MSDTC or
reinstalling somehow without reinstalling SQL?
Thanks in advance.
Tim
I never wish I was not what I was not when I didn't wish what I was not was
not what I am not.
Hi Tim!
Yes, you can remove and reinstall MSDTC 'underneath' SQL.
However, the health of this cluster sounds pretty suspect!
I would caution you to BACK EVERYTHING UP before you do anything to this
cluster.
:-)
All system db's...everything.
If it's not moving, back it up!
Ok, with that said, you can follow this KB article on moving and rebuilding
the MSDTC resource:
294209 How to rebuild or move MSDTC used with a SQL failover cluster
There is also this article:
Microsoft Distributed Transaction Coordinator (MSDTC) Recovery Techniques
in Windows 2000 Cluster Server (243204)
Which is not really SQL specific.
As for the FTSearch issue...that is a little more complicated.
Generally there are two reasons FTS doesn't work in a cluster.
1. Search setup was not successful
2. You have missing registry keys.
For number 1, you will need to do some detective work.
First collect the most recent sqlstp#.log from both nodes.
Look for the searchsetup.exe section.
Any errors? If there is an error number, go to a cmd prompt, type net
helpmsg <errornumber>
What's the error? This will be important. At that point you should engage
PSS to rebuild FTS, as it's tricky at best.
For number 2, follow this article to confirm you have the correct registry
entries for FTS:
http://support.microsoft.com/default...B;EN-US;810056
INF: You Must Use Resource-Specific Registry Keys for SQL Server Cluster
Resources (810056)
If missing, put them in there. If that doesn't fix it, again, call PSS,
you probably have more at play than just missing registry keys.
Hope your sickly cluster recovers!
Thanks!
Donna Lambert
SQL Server Product Support