Microsoft SQL Server 2000

Ich verwette schon mal meine linke Niere, dass mir keiner helfen kann

Problem ist folgendes:
Wenn man eine Query ausführt, die auf volltextindizierte Tabellen mittels "Contains()" zugreift, dauert das Aufnehmen der Verbindung zu lange: 0,7 Sekunden einschließlich der Query selbst. Wenn man selbiges nochmal macht 0,02 Sekunden. Und so gehört es ja auch...
Nachdem man dann 5 Minuten wartet: wieder--> 0,7 Sekunden. Das heißt auf gut Deutsch (bin durch empirisches Herantreten ans Problem draufgekommen *g*), dass alle 5 Minuten die Verbindung zwischen Microsoft SQL Server und Microsoft Fulltext Search Engine getrennt wird.

woooo zum geier *Schluchz* *mich erschiess* kann ich das aber ändern??? Ich habe jetzt glaube ich eine Stunde lang im Web gesucht...und nirgends die Antwort auf meine Frage gefunden...

Ich will nur dieses 5 Minuten-Timeout auf ein grösseres Intervall stellen, so dass man z.B. wenn man einmal so eine CONTAINS Abfrage verwendet, dann 10 Stunden lang die Verbindung gehalten wird......sonst bringt ja nämlich die Fulltext Feature nichts, wenn der Server ab einer Leerlaufzeit von 5 Minuten immer 0,7 Sekunden benötigt, um ne neue Verbindung herzustellen....

:eek:

*g* na hab ich's mir doch gedacht, dass das kein einfaches Problem ist. In der Newsgroup blieb die Frage unbeantwortet...
Ich denke mir nur, die ganze Volltextsuche verfehlt ja so ihren Zweck, denn es geht bei dem ganzen ja um Geschwindigkeit und genau die geht dabei verloren...

Bei den TCP-Verbindungseinstellungen (die ich finden konnte *g* - wer weiß wieviel's da noch gibt *g*) hatte ich bereits geschaut und kein Time-out finden können...

Hilfe, ich muss spenden! me denkt sich: "immer sind diese Organhändler mir auf der Ferse..." ;o)

@martin...ja es sind 2 Dienste...gehören beide zum Microsoft SQL Server 2000 Developer Edition, beides Systemdienste in Windows - von Caching habe ich zwar 0 Ahnung, aber die müssen nicht erst gestartet werden - die laufen durchgehend ;o)

Interessant find ich's nur, dass sich keine anderen Benutzer beschweren über dieses Problem...oder bin ich der einzige, der MS SQL Server nutzt, auf dieser Welt? Der letzte Mohikaner

Danke für Eure Meinungen ;o)

Prepared Statements? Hm, ich hab schon viel Zeit mit der SQL Hilfe verbracht, aber von denen habe ich noch nie etwas gelesen...procedures gibt es, aber das ist etwas anderes...die werden kompiliert, deshalb schneller...
Ich schau mal, was passiert, wenn ich so ein CONTAINS Zeug als Procedure schreibe...ich schätze nichts wird passieren, das übliche eben, aber einen Versuch ist es wert...

@antifuchs...ich glaube das habe ich schon mal probiert. Wenn diese Query keine Query ist, die den Microsoft Search Service in Anspruch nimmt (d.h. wenn sie keine volltextindizierten Tabellen nach Volltext mit microsoft-spezifsichen Befehlen abfragt), ändert sich nichts am Verhalten, d.h. sobald der MS Search Service in Anspruch genommen wird, dauert's wieder länger. Nur wenn man alle i (<= 5) Minuten eine Query die z.b. ein "CONTAINS" enthält, durchführt (eine die in volltextindizierten Spalten sucht), nur dann kann man dieses Timeout umgehen.
Aber ich versuch's jetzt nochmal mit irgendwelchen blabla-queries...mal sehen...

Edit *g*: wenn man *irgendeine* Query ausführt, die nichts mit MS Search zu tun hat, tritt wieder dieses Delay auf: gerade eben ausprobiert...

Und noch ein Nachtrag: Wenn man das ganze zu einer Procedure macht, wird das Problem auch nicht behoben....0,6 Sekunden nach 5 Minuten Wartezeit - bei Wiederholung der Query innerhalb von 5 Minuten: 0,01 Sekunden lol.

Und noch eine Beochbachtung ;o) --> falls man meinen sollte, das geht nur deshalb so schnell, weil man ja *dieselbe* Query wiederholt - nee nee, auch wenn man die Query abändert geht's *fast* so schnell (minimaler Unterschied). Nur, wenn man dann 5 Minuten wartet, braucht die Query plötzlich um ein vielfaches länger.

...wäre zu unprofessionell

Ich bin weiterhin am analysieren...
Neueste Erkenntnisse:
Es gibt ein "Verbindungs-Pooling" in Windows, wo Verbindungen für eine bestimmte Dauer festgehalten werden können. Allerdings ist der Standard nicht 5 Minuten, sondern 60 Sekunden. Ich habe die Sekundenanzahl hochgeschraubt auf 4 Stunden - mit Neustart - ohne Effekt, außer, dass ich das Gefühl habe, Windows wäre insgesamt schneller geworden, lol.

Bei diesem Verbindungs-Pooling gibt's noch die Option "Warten vor Verbindung" - auch das war auf 60 Sekunden, hab's auch hochgeschraubt...ohne Erfolg.

Beobachtungen: Im SQL Server werden Prozesse schön brav angezeigt. Jede Verbindung = 1 Prozess. Queries, die nicht auf Volltextfeature zugreifen bleiben lange als Prozess erhalten - die Volltextqueries hingegen, also die Volltext-Prozesse verschwinden nach 5 Minuten...

antifuchs: das will ich mal überhört haben, Du Schlingl.
Ich oute mich hier jetzt mal: Ich habe MySQL noch nie zu Gesicht bekommen, und bin sowas von voreingenommen, dass ich vorweg sage: der ärgste **** (fängt nicht mit s an, negativ behaucht), den die Zivilisation je gesehen hat. MySQL ist nichts Professionelles, meiner Meinung nach. Bin generell, gegen Gratis Alternativen zu kommerzieller Software. Einzige Ausnahme, die mir jetzt einfällt: Apache - einfach schwer in Ordnung.

meclens: vielen Dank für den Beitrag...hmm, ich hatte bisher kein Service Pack installiert. Wenn ich Dich richtig verstanden habe, tritt der Fehler erst durch das Service-Pack auf?
Heute habe ich ein package des SP2 installiert (da gibts 3 Packages insgesamt) - ohne Änderung.

P.S.: Es ist ganz ganz ganz sicher (hab unzählige Tests gemacht) nur ein Fehler/eine Einstellung des Microsoft Search Dienstes. Denn das ganze tritt *nur* bei volltextindizierten Spalten auf, die man eben mit Volltext-Methoden abgrast. (z.b mit "contains", aber eben nicht mit "like" (-> nix volltext *g*))

Korrektur vom letzten Posting: Der Prozess verschwindet doch *nicht* aus der Prozess-Auflistung von MSSQL Server. Also wenn man jetzt so ne Volltextquery macht, entsteht ein Prozess...aber der bleibt auch brav...sieht genauso aus wie ein gewöhnlicher Query-Prozess mit dem Unterschied, dass nach 5 Minuten die Query trotzdem saulang braucht. Bei normalen Queries ist das eben nicht so. Die brauchen immer gleich kurz *g*

PPPPPPS.: hab sogar jetzt Named Pipes disabled, selbes Problem *g* (aber an Named Pipes konnte es eh nicht liegen, weil in der Prozessinfo immer eine TCP/IP Verbindung angezeigt wurde...)

*g* Frechdachs.
Meine Wertung (ohne alle Systeme begutachtet zu haben):
Oracle, MS SQL, der Rest, MySQL

;o)