2009-06-05 12 views
1

Szenario:T-SQL-Indexdienst SQL Openquery Optimierung

Ich bin mit einer T-SQL gespeicherte Prozedur (SQL Server Management Studio) Suche zurückzukehren Treffer für Textdokumente, den MS-Indexdienst verwenden und diese (vereinfachte query):

SELECT * 
FROM openquery( 
    filesystem2, 
    'SELECT 
    Path, Rank, Filename 
    FROM 
    SCOPE('' "e:\test\documents" '') 
    WHERE 
    CONTAINS('' FORMSOF (INFLECTIONAL, "test") '') 
    ') b 

Diese Abfrage gestoppt vor richtig ein paar Tage arbeiten. Obwohl nicht vollständig bewiesen, scheint es, dass die Interaktion zwischen dem Eigenschaftscache und dem Hauptindex nicht richtig funktioniert, da ich die gewünschten Dokumente entweder durch

1) Entfernen des SCOPE-Parameters (dh nur mit "FROM SCOPE ()“, wie die FROM-Klausel

2) Entfernen der WHERE-Klausel (und hält die SCOPE-Funktion wie)

Also, ich kann‚finden‘die gewünschten Dokumente von nur Inhalt oder nur locale, aber nicht durch beide zusammen verwenden.

Eine Option wäre, den Katalog neu zu indizieren, aber das Neuindizieren ist vorerst nur eine Option des letzten Ausweges.

Davon abgesehen, schrieb ich die Abfrage des angegebenen Bereichs auszuschließen und beinhalten eine zusätzliche WHERE-Klausel:

SELECT * 
FROM openquery( 
    filesystem2, 
    'SELECT 
    Path, Rank, Filename 
    FROM 
    SCOPE() 
    WHERE 
    CONTAINS('' FORMSOF (INFLECTIONAL, "test") '') and 
    Path like ''%e:\test\documents%'' 
    ') b 

Diese Abfrage die richtigen Dokumente zurückgibt, wenn die Suche. Ich war/bin jedoch besorgt über einen möglichen Leistungseinbruch mit dem LIKE-Schlüsselwort. Also untersuchte ich den Ausführungsplan jeder Abfrage, aber sie waren genau gleich ... was mir eins von zwei Dingen sagt:

1) Die Abfragekomponente des Indexdienstes optimiert beide Abfragen so, dass sie erstellt werden gleich.

2) Der Query Analyzer bietet keine genaue Rückmeldung für entfernte Abfragen, wenn keine DB-Tabellen referenziert werden.

Fragen (in keiner bestimmten Reihenfolge). Hat jemand irgendeinen Einblick in die folgenden ?:

1) Was könnte das Verhalten des ursprünglichen Problems zwischen dem Eigenschaftscache und dem Hauptindex, der im obigen Szenario beschrieben wird, verursachen?

2) In Bezug auf den Ausführungsplan,

a) Would the Querying Component process/optimize both queries the same? 

b) Can Sql Server Management Studio provide execution plan feedback for openquery queries that do not reference any DB tables? 

3) Schließlich, die Abfrage ist effizienter/schneller, und warum?

a) i.e. should I use the second one because it solves my problem? 

Vielen Dank!

Antwort

2

null Werte könnten ein Problem sein. Ich bin mir nicht sicher über diesen genauen Fall, aber manchmal einschließlich "where xxx is not null" kann einen wirklichen Unterschied machen.

Eine andere Option ist manchmal, wo Bedingungen auf der Tabelle nach der offenen Abfrage select aaa, bbb from openquery(.....) where aaa = zzz setzen. (Wählen Sie für einen besseren Stil die Spalten aus, die Sie anstelle von * benötigen.

Als effizienter oder schneller, müssen Sie möglicherweise die Abfrage mit einem einfachen Timing-Prozess umschließen und für sich selbst beurteilen, wenn Sie die von den SQL Management-Standardnachrichten bereitgestellten Metriken nicht verwenden können.

Am Ende, solange Ihre Abfrage funktioniert und keine Standards bricht, die Sie für Ihr Projekt festgelegt haben, ja - verwenden Sie es.

+0

Danke für die Einsicht. Ich habe mit den Anfragen ein bisschen mehr gekontert, indem ich Ihre Vorschläge verwendet habe ... und mich entschieden, die Lösung zu verwenden. – dda