blog.atwork.at

news and know-how about microsoft, technology, cloud and more.

SQL Server und MSIDXS: Abfrage ist nicht gleich Abfrage

Letzte Woche hatte ich ein größeres "Häh???" (Kurzform von: Wie bitte?) - Erlebnis mit SQL Server in Verbindung mit Index-Service. Eine Abfrage funktioniert mit manchen Suchbegriffen, mit anderen jedoch nicht; es folgt neuerdings eine Fehlermeldung. Und das, nachdem diese Abfrage bereits seit Jahren einwandfrei funktioniert!

Zugegeben, die Suchbegriffe, die ich verwende sind sehr komplex: Die Suche nach "arzt" funktioniert. Die Suche nach "pflege" funktioniert jedoch nicht...

Aber schön der Reihe nach, ich hole mal etwas aus um das Problem zu beschreiben:

Schon seit den "seligen" Windows NT-Zeiten ist der Microsoft Index Service mit an Board. Damit ist es mit Betriebssystem-Mitteln möglich das Filesystem zu durchsuchen. Dies ist einerseits sehr praktisch (Windows Desktop-Search) und andererseits natürlich auch möglich, die Kataloge selbst in eigenen Lösungen anzuzapfen und zu verwenden.

Die Kataloge können in der Computerverwaltung definiert werden, der Index-Dienst kümmert sich dann um das Befüllen und Aktualisieren. Dies ist standardmäßig für Text-Dokumente und Office-Dokumente möglich. Für weitere Dokument-Typen stehen eine Reihe von IFilter (PDF, Office2007, etc.) zur Verfügung.

indexservice

Der Index-Dienst kann auch vom SQL Server verwendet werden - als Linked Server (eben auch von einer Remote-Maschine).

indexservice_sql

Damit kann dann per T-SQL das Filesystem durchsucht werden. Nach der Katalog-Definition und Verlinkung geht´s dann gleich los; hier das (neue) Problem, welches bei mir entstanden ist:

SELECT Q.FileName, Q.vPath FROM OPENQUERY(webserver_intern, 'SELECT FileName, vPath FROM "webserver-IIS".intern..SCOPE('' "\" '') WHERE CONTAINS( '' arzt '' )') AS Q

Liefert alle Dokumente, wo im Filenamen oder im Inhalt "arzt" vorkommt. Schön.

indexservice_sql_suche

Nun dasselbe Query mit dem Suchbegriff "pflege":

SELECT Q.FileName, Q.vPath FROM OPENQUERY(webserver_intern, 'SELECT FileName, vPath FROM "webserver-IIS".intern..SCOPE('' "\" '') WHERE CONTAINS( '' pflege '' )') AS Q

indexservice_sql_error

OLE DB provider "MSIDXS" for linked server "webserver_intern" returned message "Das Zeilenhandle ist ungültig.".
Msg 7330, Level 16, State 2, Line 1
Cannot fetch a row from OLE DB provider "MSIDXS" for linked server "webserver_intern".

Häh??? Was ist denn hier los? Die Suche nach "arzt" funktioniert und die Suche nach "pflege" funktioniert nicht (mehr)? Wie kann denn das sein?

Man befragt also die Suchmaschine seiner Wahl nach der Fehlermeldung. Und erhält: Fast nichts. Nach vielen Suchbegriff-Varianten finde ich nur einen Forumsbeitrag, wo sinngemäß steht. "Ich habe dieses Problem. Wenn ich die Spalte "vPath" entferne und nur "Filename" verwende, klappt die Suche aber wieder."

Ich probiere es also aus und ... es stimmt! Die Suche ohne Spalte vPath funktioniert wieder (auch für mein Suchwort "pflege").

Wie ich schon bemerkt habe, ist dieses Problem in meinem Fall erst vor kurzem aufgetreten: die Lösung hat jahrelang anstandslos funktioniert. Was ist also die Ursache?

Also schnell einen Case bei Microsoft eröffnen und nachfragen. Unser sehr engagierter Partner Technical Consultant (PTC) recherchiert und stellt eine seltsame Frage:

"Wurde kürzlich ein SQL Server von 32 bit nach 64 bit upgegraded?"

Bingo! Genau das ist in meinem Szenario erfolgt: Die Datenbankmaschine wurde erneuert und läuft nun mit 64bit System statt zuvor mit 32bit System, während der Webserver (mit dem Index-Service) nach wie vor ein 32bit System ist. Die Suche hat dazu tatsächlich einen Eintrag ans Licht gefördert:

Indexing Service: Querying 64b SQL linked server to a 32b Indexing Service

ISSUE: When performing queries in certain architectures, the query terminates with an "invalid handle" error after returning 1 row when there are more than 50 records to return. When there are less than 50 rows to return, the query executes successfully.

From To: 32-bit 64-bit
32-bit works works
64-bit fails works

...Issue does NOT occur when the path field is removed from the select statement.

Da haben wir also die Ursache. Zumindest die Erklärung, dass es sich um ein bekanntes Problem handelt: KB940061, welcher jedoch noch nicht veröffentlicht ist. Anscheinend steht dafür ein private Hotfix zur Verfügung. Dieser Hotfix kann angefordert werden; im Windows SP3 wird dieser Hotfix enthalten sein.

In meiner HOT-Applikation benötige ich die vPath-Spalte zum Glück nicht (da ich ein eigenes virtuelles Web als Katalogpfad verwende), in meiner COLD-Applikation (virtuelles Verzeichnis, wo ich datenbankseitig den Dokumentpfad benötige) muss ich bis zum Hotfix oder SP3 ohne vPath leben.

Wahrscheinlich gibt es nicht so viele Szenarien, wo dieser spezielle Fall auftritt. Für mich war´s aber ein ziemlicher Aufwand und arbeitsintensiv, hier draufzukommen, dass eine SQL Server-Umstellung von 32 auf 64bit solche Phänomene auslösen kann, vor allem, weil dieses Problem meist erst viel später bemerkt wird und kein Zusammenhang zwischen der Umstellung und dem Auftreten des Problems hergestellt werden kann - bei mir ist die DB-Umstellung schon fast ein Jahr her und erst jetzt sind die Probleme bekannt geworden.

Mögen Suchmaschinen diesen Artikel brav indizieren und anderen Anwendern diese Informationen zur SQL-Server-Index-Service 64bit Umstellung zu tragen! ;-)

Beitrag von Toni Pohl

Loading