Bewährte Methoden zum Verbessern der Suchleistung (Office SharePoint Server 2007)
In diesem Artikel werden einige empfohlene Vorgehensweisen beschrieben, die Sie verwenden können, um in Microsoft Office SharePoint Server 2007 ein fehlerfreies und effizientes Suchsystem aufrecht zu erhalten.
Inhalt dieses Artikels:
Gründe zum Starten eines vollständigen Crawls
Überwachen von Webservern
Überwachen von Datenbankservern
Überwachen von Indexservern
Überwachen von Office SharePoint Server mit dem SharePoint-Diagnosedienst
Verwenden von ULS-Protokollen (Unified Logging Service, vereinheitlichter Protokollierungsdienst) für die Diagnose von Abfrageengpässen
Optimierung von SQL Server für die Suche in Office SharePoint Server 2007
Verwalten und Warten von SQL Server-Datenbanken für die Suche
Vermeiden einer Crawlerüberlastung
Vermeiden von durch Zugriffssteuerungslisten verursachten Engpässen
Problembehandlung fehlender Suchfeld-Webparts
Gründe zum Starten eines vollständigen Crawls
Für das Crawlen und Indizieren großer Mengen an Informationen, Dokumente und Webseiten ist eine große Rechenleistung erforderlich. Durch den Crawlvorgang werden auch Netzwerk- oder andere Ressourcen beansprucht. Sie müssen eine Microsoft Office SharePoint Server 2007-Farm sorgfältig konfigurieren, um sicherzustellen, dass die Crawling- und Indizierungsprozesse die für den Benutzer verfügbaren Dienste nicht gegenseitig beeinträchtigen. So wird Inhalt beispielsweise in Zeiten mit geringer Auslastung gecrawlt und indiziert, d. h. bei einer Unterauslastung der Server, um die Hauptzeitendienste für Benutzer verwalten.
Eine Möglichkeit, um die Auswirkungen des Crawlingvorgangs zu reduzieren, besteht darin, inkrementelle Crawls anstelle vollständiger Crawls zu planen. Bei einem inkrementellen Crawl werden nur geänderte Elemente indiziert, sodass für den Prozess weniger Computerressourcen benötigt werden. Sie können für jede Inhaltsquelle vollständige Crawls und inkrementelle Crawls planen. Sie können beispielsweise an Werktagen um 0:00 Uhr inkrementelle Crawls planen und an Samstagen 0:00 Uhr vollständige Crawls planen.
Hinweis
Weitere Informationen zum Planen von Crawlzeitplänen finden Sie unter Planen des Crawlens von Inhalten (Office SharePoint Server)
Wenn Sie sicherstellen möchten, dass der Index vollständig ist, sollten Sie unter den folgenden Bedingungen manuell einen vollständigen Crawl starten:
Wenn von Administratoren ein Update oder Service Pack auf die Server in der Farm angewendet wurde.
Wenn der Suchkonfiguration von den Administratoren eine neue verwaltete Eigenschaft hinzugefügt wurde.
Wenn von den Administratoren eine Crawlregel hinzugefügt oder geändert wurde.
Wenn Sie ASP.NET-Seiten in Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 oder Search Server 2008-Websites neu indizieren möchten. Es kann vom Crawler nicht festgestellt werden, ob sich solche Webseiten geändert haben. Daher können sie nur mithilfe eines vollständigen Crawls neu indiziert werden.
Wenn Fehler bei aufeinanderfolgenden inkrementellen Crawls aufgetreten sind. Wenn bei einem inkrementellen Crawl nacheinander einhundert Mal an einer bestimmten Stufe im Repository ein Fehler auftritt, wird der betreffende Inhalt vom Indexserver aus dem Index entfernt.
Wenn ein beschädigter Index von Administratoren repariert wurde.
Wenn von einem Administrator eine Servernamenszuordnung erstellt wurde.
Wenn Sie die Berechtigungen für bestimmte Inhalte geändert haben, die Inhalte selbst jedoch nicht geändert wurden und das Hotfixpaket nach Service Pack 1 (KB941442) oder ein höheres Service Pack nicht auf die Server angewendet wird. Ohne dieses Hotfixpaket werden bei den inkrementellen Crawls keine Zugriffssteuerungslisten (Access Control Lists, ACLs) überprüft. Wenn diese nicht überprüft werden, wird einem Benutzer möglicherweise ein Element in den Suchergebnissen angezeigt, obwohl die Berechtigung für dieses Element für den Benutzer beim letzten vollständigen Crawl von einem Administrator entfernt wurde.
Unter den folgenden Bedingungen wird in Microsoft Office SharePoint Server 2007 ein vollständiger Crawl ausgeführt, obwohl ein inkrementeller Crawl geplant oder manuell gestartet wurde:
Wenn ein vorheriger Crawl manuell vom einem Administrator angehalten wurde.
Wenn eine Inhaltsdatenbank von einem Administrator aus einer Sicherung wiederhergestellt wurde.
Hinweis
Wenn Sie das Infrastrukturaktualisierung für Microsoft Office Server installiert haben, können Sie mit den Optionen des Befehlszeilentools "Stsadm" angeben, ob durch einen Wiederherstellungsvorgang ein vollständiger Crawl erfolgt.
Wenn eine Inhaltsdatenbank von einem Administrator getrennt und erneut angefügt wurde.
Wenn von Office SharePoint Server bisher kein vollständiger Crawl des Inhalts ausgeführt wurde.
Wenn im Änderungsprotokoll keine Informationen zu den Adressen im Crawl enthalten sind. Das Änderungsprotokoll wird dazu verwendet, um zu bestimmen, ob ein Element seit dem letzten Crawl geändert wurde. Ohne die Informationen des Änderungsprotokolls können keine inkrementellen Crawls ausgeführt werden.
Wenn sich das Konto, mit dem auf den Inhalt zugegriffen wird, geändert hat. Dieses Konto kann das Standardzugriffskonto oder ein in einer Crawlregel angegebenes Konto sein.
Wenn eine Indexbeschädigung aufgetreten ist.
Sie müssen bei den von Ihnen in einer solchen Situation ausgeführten Aktionen sorgfältig vorgehen. Dies ist darauf zurückzuführen, dass wenn Sie einen Crawl manuell oder mit einem Zeitplan starten, bei einem vollständigen Crawl möglicherweise deutlich mehr Ressourcen benötigt werden als bei einem inkrementellen Crawl. Dies wiederum hat Einfluss auf den Dienst, der den Benutzern zur Verfügung steht.
Überwachen von Webservern
Sie können die Suchleistung in Microsoft Office SharePoint Server 2007 maximieren, indem Sie eine vollständige Analyse des Systems ausführen. Sie sollten eine Grundlinie erstellen, indem Sie eine vollständige Überprüfung der Server ausführen. Sie sollten in regelmäßigen Abständen Leistungstests erneut ausführen, um Änderungen frühzeitig zu erkennen bzw. Probleme rechtzeitig zu diagnostizieren. Bei einer Optimierung können Sie die Grundlinie verwenden, um daraus folgende Verbesserungen zu kennzeichnen. In den folgenden Abschnitten werden Leistungsüberwachungszähler und von anderen Tools verfügbare Daten aufgeführt, die für die Leistung von Microsoft Office SharePoint Server 2007 relevant sind.
Hinweis
Weitere Informationen zur allgemeinen Systemüberwachung finden Sie unter Leistungsüberwachung (https://go.microsoft.com/fwlink/?linkid=105584&clcid=0x407).
In Microsoft Office SharePoint Server 2007 werden alle Websites und Websitesammlungen von Webservern gehostet. Sie erhalten Inhalte, die auf den Datenbankservern gespeichert sind und reagieren auf Benutzeranfragen. Da Webserver Antworten auf Suchabfragen von Benutzer senden, hat ihre Leistung direkte Auswirkungen auf die Suchleistung. Webserver haben auch Einfluss auf die Indizierung, da der Crawler Office SharePoint Server-Inhalte indiziert, indem Anfragen an den Webserver gesendet werden.
Sie können die folgenden Systemmonitor-Leistungsindikatoren verwenden, um die Integrität von Webservern zu überwachen:
Prozessor/Prozessorzeit (%)/_Total
Dieser Leistungsindikator ist die primäre Anzeige für die Prozessoraktivität. Damit wird der Zeitanteil gemessen, den die Prozessoren für die Ausführung nicht im Leerlauf befindlicher Threads benötigen. Wenn dieser Leistungsindikator über einen längeren Zeitraum einen Durchschnittswert von über 80 % aufweist, könnten die Prozessoren möglicherweise einen Engpass darstellen und Sie sollten eine Aktualisierung der Prozessoren in Erwägung ziehen.
Arbeitsspeicher/Verfügbare MB
Mit diesem Leistungsindikator wird der unmittelbar für Prozesse oder das System verfügbare physikalische Speicher gemessen. Fällt der Wert für diesen Leistungsindikator auf einen zu geringen Wert, verlangsamt sich das System, da eine höhere Auslagerung erfolgt. Sie sollten dem Server mehr Arbeitsspeicher hinzufügen.
Webdienst/Aktuelle Verbindungen
Mit diesem Indikator wird die Anzahl der Verbindungen zum WWW-Dienst gemessen. Auf Microsoft Office SharePoint Server 2007-Webservern sind in dieser Anzahl alle gleichzeitigen Benutzer, und während der Indizierung der Crawler, enthalten. Verwenden Sie diesen Leistungsindikator, um Verwendungsmuster zu ermitteln und die Spitzenzeiten zu bestimmen. Es gibt keine Beschränkung für diesen Zähler. Sehr hohe Werte sind ein Hinweis auf hervorragende Leistung.
Hinweis
In einer Office SharePoint Server-Serverfarm mit mehreren Webservern werden mit diesem Leistungsindikator nur Verbindungen auf einem Server gemessen. Informationen zum Überwachen von Benutzeraktivitäten in der gesamten Farm finden Sie unter Überwachen von Office SharePoint Server mit dem SharePoint-Diagnosedienst.
Überwachen von Datenbankservern
In Microsoft Office SharePoint Server 2007 wird Microsoft SQL Server 2005 oder Microsoft SQL Server 2008 zum Speichern von Inhaltsdatenbanken verwendet. Obwohl der Inhaltsindex vom Indexserver im Dateisystem gespeichert wird, nicht in einer Datenbank, werden Dokumentmetadaten und Berechtigungen in der Suchdatenbank gespeichert. Da bei vielen Suchvorgängen Metadaten überprüft werden und alle Suchvorgänge die Einschränkung aus Sicherheitsgründen beinhalten, wirkt sich die Leistung von Datenbankservern direkt auf die Suchleistung aus.
Sie können die folgenden Systemmonitor-Leistungsindikatoren verwenden, um die Integrität von Datenbankservern zu überwachen:
Prozessor/Prozessorzeit (%)/_Total
Dieser Leistungsindikator ist der Hauptindikator für die Prozessoraktivität und ist daher auf Datenbankservern ebenso wichtig wie auf Webservern.
**LogicalDisk/Zeit (%)/**DiskName
Mit diesem Leistungsindikator wird der Anteil der verstrichenen Zeit gemessen, für den der Datenträger mit dem Lesen oder Schreiben von Anforderungen beschäftigt war. Überwachen Sie für die Suche diesen Leistungsindikator für den Datenträger, der die Suchdatenbank enthält. Wenn dieser Leistungsindikator regelmäßig einen Durchschnittswert von über 90 % aufweist, stellt die Festplatte möglicherweise einen Engpass für die Suche dar.
System: Prozessor-Warteschlangenlänge
Dieser Leistungsindikator sollte durchschnittlich weniger als zwei multipliziert mit der Anzahl der CPU-Kerne auf dem Server betragen.
Arbeitsspeicher: Verfügbare MB
Stellen Sie sicher, dass dieser Leistungsindikator durchschnittlich mindestens 20 % des gesamten physikalischen Arbeitsspeichers aufweist.
Arbeitsspeicher: Seiten/s
Dieser Leistungsindikator sollte im Durchschnitt unter 100 liegen.
Logischer Datenträger: Übertragungen/s
Mithilfe dieses Zählers wird der Gesamtdurchsatz für eine Partition gemessen.
Logischer Datenträger: Bytes gelesen/s & Bytes geschrieben/s
Mithilfe dieses Zählers wird die Gesamtbandbreite eines bestimmten Datenträgers gemessen.
Logischer Datenträger: Mittlere Sek./Lesevorgänge
Auch als Lesewartezeit bezeichnet, wird mit diesem Leistungsindikator die Zeit angegeben, die für den Datenträger zum Abrufen von Daten erforderlich ist. Eine niedrige Lesewartezeit ist entscheidend für eine gute Reaktionszeit auf Benutzerabfragen.
Logischer Datenträger: Mittlere Sek./Schreibvorgänge
Auch als Schreibwartezeit bezeichnet, wird mit diesem Leistungsindikator die Zeit angegeben, die für den Datenträger zum Schreiben von Daten erforderlich ist. Eine niedrige Schreibwartezeit trägt zu einer verbesserten Indizierungsleistung bei.
**LogicalDisk/Lesezeit (%)/**DiskName
Mit diesem Leistungsindikator wird der Anteil der verstrichenen Zeit gemessen, für den der Datenträger mit dem Lesen von Anforderungen beschäftigt war. Ein hoher Anteil von Leseanfragen für den Suchdatenbank-Datenträger kann ein Hinweis darauf sein, dass die Benutzer eine große Anzahl von Suchabfragen ausführen.
**LogicalDisk/Schreibzeit (%)/**DiskName
Mit diesem Leistungsindikator wird der Anteil der verstrichenen Zeit gemessen, die das Laufwerk mit dem Bearbeiten von Schreibanforderungen beschäftigt war. Ein hoher Anteil von Schreibanforderungen für den Suchdatenbank-Datenträger wird beim Indizierungsvorgang erwartet.
Hinweis
Wenn möglich, können Sie die Suchleistung optimieren, indem Sie die Suchdatenbank auf einem separaten Datenträger von den anderen Datenbanken getrennt platzieren. Wenn Sie die Suchdatenbank auf diese Weise separieren, sind diese Leistungsindikatoren des logischen Datenträgers eine klare Angabe für die Suchleistung, da dieser Datenträger ausschließlich für die Suche verwendet wird.
SQLServer:Puffer-Manager/Lebenserwartung von Seiten
Mit diesem Leistungsindikator wird die Anzahl der Sekunden gemessen, für die eine Datenbankseite ohne Verweise im Pufferpool verbleibt. Diese Zeitdauer sollte mindestens 300 Sekunden betragen. Werte unter 300 Sekunden sind ein deutlicher Hinweis auf Arbeitsspeicherengpässe. In diesem Fall sollten Sie die Aufrüstung von Speicher für den Server in Betracht ziehen.
Hinweis
Eine vollständige Beschreibung zur allgemeinen Optimierung von SQL Server gehört nicht zum Gegenstand dieses Office SharePoint Server-Artikels. Weitere Informationen erhalten Sie in den folgenden Ressourcen:
-
Top 10 der empfohlenen Vorgehensweisen zur Speicheroptimierung (https://go.microsoft.com/fwlink/?linkid=148543&clcid=0x407)
-
Empfohlene Vorgehensweisen für E/A bei der Vorabbereitstellung von SQL Server (https://go.microsoft.com/fwlink/?linkid=148544&clcid=0x407)
-
RAID-Stufen und SQL Server (https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x407)
-
Weitere Informationen zu Microsoft SQL Server-Leistungsüberwachungszählern und SharePoint-Produkten und -Technologien finden Sie unter Planen und Überwachen des SQL Server-Speichers für SharePoint: Leistungsempfehlungen und bewährte Methoden: Whitepaper (https://go.microsoft.com/fwlink/?linkid=119398&clcid=0x407).
Überwachen von Indexservern
In Microsoft Office SharePoint Server 2007 wird der Inhalt von den Indexservern gecrawlt, und es wird eine Indexdatei erstellt. Nach Abschluss des Crawlvorgangs wird der Index an die Abfrageserver übertragen, die auf die Suchanforderungen der Benutzer reagieren.
Wenn der Indexserver eine schlechte Leistung aufweist, hat dies möglicherweise keine direkten Auswirkungen auf die Benutzer. Der Crawlvorgang verlängert sich jedoch, in Einzelfällen so, dass es nicht möglich ist, das Crawling auf Zeiten mit geringer Auslastung zu beschränken und diesen Vorgang getrennt von anderen Aktivitäten in Zeiten mit geringer Auslastung (z. B. Erstellen von Sicherungen) auszuführen.
Hinweis
Der Indexserver befindet sich, je nach Anzahl der verfügbaren Server, nicht immer auf einem separaten Server.
Sie können während eines Crawls die folgenden Systemmonitor-Leistungsindikatoren verwenden, um die Integrität des Indexservers zu überwachen:
Office Server-Sucharchivierungs-Plug-In/Gesamte Dokumente in erster Warteschlange/Portalinhalt
Mit diesem Zähler wird die Anzahl der Dokumente in der ersten Warteschlange des Archivierungs-Plug-Ins erfasst. Während eines Crawls sollte dieser Wert unter 500 liegen und ansonsten einen sehr geringen Wert aufweisen. Wenn der Wert über 500 liegt, stellt das Suchdatenbanklaufwerk auf dem Datenbankserver möglicherweise einen Engpass dar.
Office Server-Sucharchivierungs-Plug-In/Gesamte Dokumente in zweiter Warteschlange/Portalinhalt
Mit diesem Zähler wird die Anzahl der Dokumente in der zweiten Warteschlange des Archivierungs-Plug-Ins erfasst. Wie auch bei dem anderen Zähler sollte dieser Wert während eines Crawls unter 500 liegen.
Office Server Search-Gatherer/Leerlaufthreads
Mit diesem Zähler wird die Anzahl der Threads im Gathererprozess erfasst, bei dem auf Dokumente gewartet wird. Wenn der Zähler gleich Null (0) ist, sind für den Gatherer nicht genügend Ressourcen verfügbar. Es empfiehlt sich, die Anzahl der gleichzeitig ausgeführten Crawls zu reduzieren.
Office Server Search-Gatherer/Auf das Netzwerk zugreifende Threads
Mit diesem Zähler wird die Anzahl der Threads im Gathererprozess erfasst, von denen Anforderungen an einen fernen Datenspeicher gesendet wurden und auf die Antwort gewartet oder die Antwort bearbeitet wird. Wenn der Zähler dauerhaft einen hohen Wert aufweist, kann die Netzwerkbandbreite eine Engpass darstellen oder der Indexserver ist für die Indizierung des Inhalts möglicherweise mit einem oder mehreren langsamen Hosts verbunden.
Office Server Search-Gatherer/Filterthreads
Mit diesem Zähler wird die Anzahl der Threads angegeben, die Inhalte abgerufen haben und diese filtern. Wenn diese Anzahl sehr hoch liegt, ist das möglicherweise ein Hinweis auf Engpässe bei den Ressourcen auf dem Indexserver.
Office Server Search-Gatherer/Threads in Plug-Ins
Mit diesem Zähler wird die Anzahl der Threads angegeben, die Inhalte abgerufen haben und diese mithilfe von Plug-Ins wie IFilters verarbeiten. Dies ist die Stufe im Crawlprozess, in der der Index und die Suchdatenbank aufgefüllt werden.
Gatherer-Projekte von Office Server Search/Laufende Crawlvorgänge
Mit diesem Zähler wird die Anzahl der aktuell ausgeführten Crawls angegeben. Dieser Wert sollte der Anzahl der Inhaltsquellen mit geplanten Crawls entsprechen, sofern nicht vom Administrator manuell ein Crawlvorgang gestartet wurde.
Überwachen von Office SharePoint Server mit dem SharePoint-Diagnosedienst
Das SharePoint-Diagnosetool v1.0 (auch als SPDiag bezeichnet) ist ein fortschrittliches Tool für die Diagnose und Analyse, mit dem umfassende Informationen zu einem einzelnen Server oder eine Serverfarm bereitgestellt werden, auf denen SharePoint-Produkte und -Technologien ausgeführt werden. Mithilfe des SPDiag können Sie sehr detaillierte Snapshots auf den Server- und Farmkonfigurationen anzeigen. Darüber hinaus können Sie Informationen aus IIS-Protokollen (Internet Information Services, Internetinformationsdienste), ULS-Protokollen (Unified Logging Service, Vereinheitlichter Protokollierungsdienst) und Ereignisprotokollen zusammenführen und anzeigen und Leistungsprobleme, beispielsweise langsame Anforderungen, überprüfen.
Hinweis
SPDiag ist Teil des Microsoft SharePoint Administration Toolkit v3.0 (https://go.microsoft.com/fwlink/?linkid=141504&clcid=0x407).
SPDiag kann für jeden Server in der Farm Diagramme der Leistungsindikatoren darstellen. Darüber hinaus sind verschiedene Indikatoren enthalten, die die farmweiten Daten auf der Grundlage von IIS-Protokollen angeben. Eine solche farmweite Analyse kann bei einer ausschließlichen Verwendung des Systemmonitors nicht ausgeführt werden.
Hinweis
Lesen Sie das SharePoint-Diagnosetool (SPDiag) – Benutzerhandbuch (https://go.microsoft.com/fwlink/?linkid=141204&clcid=0x407), um SPDiag effizient einsetzen zu können.
Verwenden Sie die folgenden farmweiten Zähler, um die Reaktion der Microsoft Office SharePoint Server 2007-Farm zu überprüfen:
SharePointRequests/Anzahl der eindeutigen Client-IPs
Mit diesem Indikator wird die Anzahl eindeutiger Clients angegeben, die innerhalb eines bestimmten Zeitraums Anforderungen gesendet haben. Beachten Sie, dass Clients, von denen über einen Proxyserver auf die Farm zugegriffen wird, als einzelne IP-Adresse angegeben werden.
SharePointRequests/Anzahl der eindeutigen Client-Agents
Mit diesem Indikator wird die Anzahl eindeutiger Client-Agents (Browser) angegeben, die innerhalb eines bestimmten Zeitraums Anforderungen gesendet haben. Bei diesem Zähler wird zwischen Clients unterschieden, die über einen Proxyserver auf eine Farm zugreifen, da der Zähler auf dem Agent basiert, der in der HTTP-Anforderung des Browsers angegeben ist.
Hinweis
Mit den folgenden Zählern wird die Anzahl der Anforderungen angegeben. Diese Anforderungen beinhalten sowohl Suchabfragen als auch Inhaltsabfragen.
SharePointRequests/Anforderungen gesamt
Mit diesem Indikator wird die Gesamtzahl der Anforderungen angegeben, da diese innerhalb eines bestimmten Zeitraums variieren. Sie sollten diesen Indikator zusammen mit den folgenden Indikatoren permanent überwachen, um den Anteil der schnellen bzw. langsamen Anforderungen zu ermitteln.
SharePointRequests/Anzahl der Anforderungen mit einer Dauer von mehr als 1 Sekunde
Mit diesem Indikator wird die Anzahl der Anforderungen angegeben, die innerhalb einer Sekunde erfüllt wurden. In einer leistungsstarken Farm sollte dieser Wert etwa dem Wert unter Anforderungen gesamt entsprechen.
SharePointRequests/Anzahl der Anforderungen mit einer Dauer von 1-5 Sekunden
Mit diesem Indikator wird die Anzahl der Anforderungen angegeben, die innerhalb von 1-5 Sekunden erfüllt wurden. Diese Leistung ist normalerweise akzeptabel für Benutzer; eine zunehmende Anzahl entsprechender Anforderungen ist jedoch möglicherweise ein Hinweis auf einen Engpass in der Entwicklung.
SharePointRequests/Anzahl der Anforderungen mit einer Dauer von 5-10 Sekunden
Mit diesem Indikator wird die Anzahl der Anforderungen angegeben, die innerhalb von 5-10 Sekunden erfüllt wurden. Benutzer haben die Seite möglicherweise bereits verlassen, bevor die Ergebnisse zurückgegeben werden.
SharePointRequests/Anzahl der Anforderungen mit einer Dauer von mehr als 10 Sekunden
Mit diesem Indikator wird die Anzahl der Anforderungen angegeben, die innerhalb von mehr als 10 Sekunden erfüllt wurden. Wenn diese Anforderungen einen entsprechend hohen Anteil der Anforderungen gesamt darstellen, reagiert die Farm nicht auf Anforderungen; Sie sollten die Engpässe überprüfen und eine Aufrüstung der Hardware in Betracht ziehen.
Verwenden von ULS-Protokollen (Unified Logging Service, vereinheitlichter Protokollierungsdienst) für die Diagnose von Abfrageengpässen
Mithilfe der vereinheitlichten Protokollierungsdienste (ULS) können Sie die Leistung des Microsoft Office SharePoint Server 2007-Systems überwachen und optimieren. Sie sollten ULS als eine Möglichkeit zur Optimierung des Systems verwenden. Als weitere Möglichkeiten stehen Ihnen der Systemmonitor sowie Ereignis- oder Webprotokolle zur Verfügung.
In diesem Abschnitt wird die Verwendung der ULS-Protokolle zum Diagnostizieren von Leistungsverzögerungen bei der Suche beschrieben. Mithilfe von ULS-Protokollen können Sie ermitteln, für welche Abschnitte im Suchvorgang die meiste Zeit benötigt wird bzw. die Rückgabe von Ergebnissen an den Benutzer verzögert wird. Mithilfe der ULS-Protokolle können Sie außerdem die Leistungsverbesserungen bewerten, die durch kleine Änderungen an der Konfiguration des Systems erzielt werden.
Hinweis
Verwenden Sie die ULS-Protokollierung nur in begrenztem Maß, um mögliche Auswirkungen auf die Leistung oder die Datenträgerverwendung zu vermeiden. Nach der Diagnose von Leistungsproblemen mit ULS können Sie die Leistung durch Deaktivieren der ULS-Protokollierung maximieren. Die ULS-Protokolle sollten auf einem Datenträger mit ausreichend Speicherplatz gespeichert werden.
Hinweis
Weitere Informationen und Beispiele für Abfragen, die Sie in Log Parser 2.2 verwenden können, finden Sie unter How to: Mine the ULS logs for query latency (https://go.microsoft.com/fwlink/?linkid=148540&clcid=0x407) im Microsoft Enterprise Search-Blog.
Konfigurieren des vereinheitlichten Protokolldiensts
Beginnen Sie damit, den Dienst auf der Website für die Microsoft Office SharePoint Server 2007-Zentraladministration zu konfigurieren.
Wichtig
Sie müssen Mitglied der Gruppe Farmadministratoren sein, um das folgende Verfahren ausführen zu können.
Konfigurieren des vereinheitlichten Protokolldiensts für die Diagnose von Suchleistungsproblemen
Klicken Sie auf Start, Alle Programme, Microsoft Office Server und dann auf SharePoint 3.0-Zentraladministration.
Klicken Sie auf die Registerkarte Vorgänge.
Klicken Sie im Abschnitt Protokollierung und Berichterstellung auf Diagnoseprotokollierung.
Klicken Sie Abschnitt Ereignissteuerung in der Liste Kategorie auswählen auf MS Search - Abfrageprozessor.
Klicken Sie unter Unwichtigstes, im Ablaufverfolgungsprotokoll aufzuzeichnendes Ereignis auf Hoch.
Klicken Sie unten auf der Seite auf OK .
Verwenden des Log Parser-Tools
Ähnlich wie bei IIS-Protokollen (Internet Information Services, Internetinformationsdienste) handelt es sich bei Microsoft Office SharePoint Server 2007-ULS-Protokollen um sehr große Textdateien. Verwenden Sie für die Analyse des Inhalts solcher Dateien ein Protokollanalyseprogramm; damit können Sie sich auf interessante Ablaufverfolgungen konzentrieren und die Daten formatieren. Microsoft Log Parser 2.2 (https://go.microsoft.com/fwlink/?linkid=148542&clcid=0x407) ist ein kostenloses Tool, das ideal dafür geeignet ist.
Beim Log Parser-Tool handelt es sich um ein Befehlszeilenprogramm. Sie müssen die folgenden Parameter verwenden, um anzugeben, dass es sich bei den ULS-Protokollen um tabulatorgetrennte Textdateien in Unicode handelt:
logparser -i:TSV -iCodepage:-1 -fixedSep:ON
Zusätzlich zu diesen Parametern müssen Sie eine Abfrage im Transact-SQL-Stil bereitstellen, mit der von Log Parser ermittelt wird, wie die Protokolldatei zu analysieren ist. Sie können beispielsweise die folgende WHERE-Klausel verwenden, wenn Sie sich auf Zeitgebermeldungen des Abfrageprozessors konzentrieren möchten:
WHERE Category = 'MS Search Query Processor' AND Message LIKE '%Completed query execution with timings:%'
Hinweis
Sie können den SQL-Abfragetext direkt in die Befehlszeile des Log Parser-Tools eingeben. Alternativ können Sie die Abfrage in einer Textdatei speichern und den Parameter ":file" verwenden, um den Speicherort an Log Parser zu übergeben. Dies ist hilfreich bei längeren oder komplexeren Abfragen bzw. für Abfragen, die Sie häufig verwenden möchten.
Durchsuchen von Meldungen in ULS-Protokollen
Wenn der ULS-Dienst wie oben beschrieben konfiguriert ist, werden die folgenden Meldungen in den Protokolldateien angezeigt, wenn Benutzer Abfragen ausführen:
Completed query execution with timings
Diese Meldung gibt an, dass eine Abfrage abgeschlossen wurde und sechs Richtlinienzeiten enthält, in denen die Abfrage in Millisekunden angegeben ist. Diese sechs Richtlinienzeiten lauten wie folgt:
v1. Die Gesamtzeit, die für die Verarbeitung der Abfrage benötigt wird.
v2. Die Wartezeit für die Abfrage, die nach der Duplikaterkennung ermittelt wurde.
v3. Die Wartezeit für die Abfrage, die nach der Einschränkung der Sicherheit ermittelt wurde.
v4. Die Wartezeit für die Abfrage, die nach dem Zusammenfügen der Ergebnisse aus dem Index mit denen aus der Suchdatenbank ermittelt wurde.
v5. Die Zeit, in der auf die Ergebnisse des Indexservers gewartet wurde.
v6. Die Zeit, die für Aufrufe der Datenbank benötigt wurde; ohne das Abrufen von Eigenschaften aus der Suchdatenbank.
Anhand dieser sechs Richtlinienzeiten können Sie die folgenden Informationen ermitteln:
v1 – v2. Die Zeit, die für das Abrufen von Eigenschaften und das Hervorheben von Treffern benötigt wird.
v2 – v3. Die Zeit, die für das Erkennen von Duplikaten erforderlich ist.
v3 – v4. Die Zeit, die für das Einschränken der Sicherheit erforderlich ist.
v4 – v5. Die Zeit, die für das Zusammenführen der Index- und Suchdatenbankergebnisse erforderlich ist.
Wiederholung der Zusammenführung
Mit dieser Meldung wird angegeben, dass ein erneuter Versuch erfolgt ist, da die von der Suchdatenbank zurückgegebenen Ergebnisse nicht mit denen aus dem Volltextindex übereingestimmt haben und daher auch nicht zusammengeführt werden konnten.
Wiederholung der Einschränkung aus Sicherheitsgründen
Mit dieser Meldung wird angegeben, dass von einem Benutzer eine Abfrage ausgeführt wurde, für die Ergebnisse zurückgegeben wurden, für die der Benutzer keine Berechtigung zum Lesen hat. Eine solche Abfrage wird erneut ausgeführt, wobei eine größere Ergebnisanzahl angefordert wird, bis genügend Ergebnisse zurückgeliefert werden.
Wiederholung der Duplikatentfernung ähnlicher Elemente
Mit dieser Meldung wird angegeben, dass viele praktisch identische Dokumente aus den Ergebnissen eingeschränkt wurden und nicht genügend Ergebnisse für die Anzeige im Abfrageprozessor verfügbar waren. Eine solche Abfrage wird erneut ausgeführt, wobei eine größere Ergebnisanzahl angefordert wird, bis genügend Ergebnisse zurückgeliefert werden.
Analysieren der Abfragerichtlinienzeiten
Von den zuvor in diesem Abschnitt beschriebenen Meldungen ist die Meldung Completed query execution with timings am wichtigsten für die Diagnose von Verzögerungen bei der Abfrageverarbeitung. Wenn beispielsweise die Einschränkung aus Sicherheitsgründen langsam erfolgt, wird der Wert aus der v3 – v4-Berechnung einen Großteil der Gesamtverarbeitungszeit v1 ausmachen.
Sie können die Richtlinienzeiten analysieren, indem Sie die folgende SQL-Abfrage an das Log Parser-Tool übergeben. Es wird vom Tool eine kommagetrennte Datei erstellt, in der die Richtlinienzeiten v1 bis v6 und ihre Unterschiede enthalten sind.
Select Timestamp,
TO_INT(Extract_token(Message,7, ' ')) as TotalQPTime,
TO_INT(Extract_token(Message,8, ' ')) as v2,
TO_INT(Extract_token(Message,9, ' ')) as v3,
TO_INT(Extract_token(Message,10, ' ')) as v4,
TO_INT(Extract_token(Message,11, ' ')) as TimeSpentInIndex,
TO_INT(Extract_token(Message,12, ' ')) as v6,
SUB(v4, TimeSpentInIndex) as JoinTime,
SUB(v3, v4) as SecurityTrimmingTime,
CASE v2
WHEN 0 THEN 0
ELSE SUB(v2, v3)
End as DuplicateDetectionTime,
SUB(TotalQPTime, v2) as FetchTime
INTO QTiming
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Completed query execution with timings:%'
Sie können die erstellte CSV-Datei in Microsoft Office Excel oder in ein anderes Analyseprogramm importieren, um Diagramme und Berichte zu erstellen. Beachten Sie, dass in einem stark ausgelasteten System viele Anfragen erfolgen und Sie möglicherweise Durchschnittswerte für die vielen Ergebnisse verwenden müssen, um sinnvolle Analysen zu erstellen.
Analysieren der Wiederholungsversuche
Die Richtlinienzeitendaten, die in der Meldung Completed query execution with timings bereitgestellt werden, enthalten keine Informationen über Wiederholungsversuche, beispielsweise Wiederholungsversuche, die durch die Einschränkung der Sicherheit verursacht wurden. Wenn Sie analysieren möchten, wie viel Zeit vom Abfrageprozessor für Wiederholungsversuche benötigt wurde, müssen Sie die Gesamtzahl der Abfragen mit der Anzahl der unterschiedlichen Wiederholungsversuche vergleichen.
Mithilfe der folgenden Abfrage wird die Gesamtzahl der ausgeführten Abfragen ermittelt:
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Completed query execution%'
Mithilfe der folgenden Abfrage wird die Gesamtzahl der Wiederholungsversuche ermittelt, die durch die Einschränkung der Sicherheit verursacht wurden:
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Security trimming retry%'
Mithilfe der folgenden Abfrage wird die Gesamtzahl der Wiederholungsversuche ermittelt, die durch die Entfernung von Duplikaten verursacht wurden:
SELECT count (Message)
FROM 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\LOGS\MOSSServer1*.log'
WHERE Category = 'MS Search Query Processor'
AND Message LIKE '%Near duplicate removal retry%'
Verwenden Sie diese Abfragen, um zu ermitteln, wie die Abfrageergebnisse durch die Wiederholungsversuche verzögert werden. Wenn die Anzahl der Wiederholungsversuche einen großen Anteil in Bezug auf die Gesamtanzahl der Abfragen darstellt, empfiehlt sich möglicherweise eine Überarbeitung der Konfiguration. Wenn beispielsweise nur wenige Benutzer auf die Dokumente in einer der Inhaltsquellen zugreifen können, wird damit möglicherweise die Anzahl der Wiederholungsversuche erhöht, die durch die Einschränkung der Sicherheit verursacht wurden. In diesem Fall empfiehlt sich möglicherweise die Entfernung dieser Quelle aus dem Index.
Optimieren von SQL Server für die Suche in Office SharePoint Server 2007
In Microsoft Office SharePoint Server 2007 wird Microsoft SQL Server zum Speichern von Inhalt, Konfigurationsinformationen und Eigenschaften des indizierten Inhalts verwendet. Sie müssen SQL Server optimieren, um eine optimale Leistung für Office SharePoint Server sicherzustellen.
Hinweis
Für Microsoft Office SharePoint Server 2007 können in SQL Server 2008 oder SQL Server 2005 gespeicherte Datenbanken verwendet werden.
Allgemeine Optimierung von SQL Server
Mithilfe einiger Optimierungen kann die Leistung von SQL Server unabhängig vom Verwendungszweck des Servers optimiert werden. Sie sollten sicherstellen, dass diese Optimierungen für eine Office SharePoint Server-Datenbank erfolgt sind.
Die folgenden Empfehlungen sollten für die Planung und Bereitstellung des Datenbankservers berücksichtigt werden:
Führen Sie SQL Server wenn möglich auf einem dedizierten Server oder einer dedizierten Serverfarm aus.
Führen Sie eine dezentrale Skalierung auf mehrere Datenbankserver in einer Serverfarm aus. Im Allgemeinen sollte ein Datenbankserver für jeweils vier Webserver installiert werden, die mit der vollen Kapazität ausgeführt werden.
Verwenden Sie eine 64-Bit-Version von SQL Server auf den Computern in Kombination mit einem 64-Bit-Betriebssystem.
Verwenden Sie so viele physikalische Datenträgerspindeln, wie Ihr Hardwarebudget zulässt.
Verwenden Sie Hochgeschwindigkeitsdatenträger.
Verwenden Sie für die Datenbanken RAID 1+0- oder RAID 1-Datenträgerarrays.
Speichern Sie die Protokolldateien separat auf einem physikalischen Datenträger, auf dem keine primären und sekundären Datendateien gespeichert werden.
Hinweis
Eine vollständige Beschreibung zur allgemeinen Optimierung von SQL Server gehört nicht zum Gegenstand dieses Office SharePoint Server-Artikels. Weitere Informationen erhalten Sie in den folgenden Ressourcen:
-
Top 10 der empfohlenen Vorgehensweisen zur Speicheroptimierung (https://go.microsoft.com/fwlink/?linkid=148543&clcid=0x407)
-
SQL Server-Best Practices (https://go.microsoft.com/fwlink/?linkid=148544&clcid=0x407)
-
RAID-Stufen und SQL Server (https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x407)
Optimieren von SQL Server für die Suchabfragen und die Indizierung
Für viele Microsoft Office SharePoint Server 2007-Administratoren hat die Optimierung der Crawling-, Indizierungs- und Abfragevorgänge besonders hohe Priorität. Der Office SharePoint Server-Inhaltsindex wird in einem Dateisystem außerhalb einer SQL Server-Datenbank gespeichert. Von der Suchdatenbank werden jedoch Metadaten aus den indizierten Dateien und Zugriffssteuerungslisten gespeichert. Dies führt dazu, dass sich die Leistung von SQL Server direkt auf die folgenden beiden Suchvorgänge auswirkt:
Indizierung, wenn von Office SharePoint Server Metadaten und Zugriffssteuerungslisten gespeichert werden.
Abfragen. Alle Office SharePoint Server-Abfragen beinhalten die Einschränkung aus Sicherheitsgründen, bei der von Office SharePoint Server die Zugriffssteuerungslisten in der Suchdatenbank überprüft und die Ergebnisse entfernt werden, für deren Anzeige der Benutzer keine Berechtigung aufweist. Falls vom Benutzer eine Eigenschaftensuche ausgeführt wurde, müssen darüber hinaus Metadaten von der Suchdatenbank abgerufen werden.
Sie sollten zuerst die allgemeinen Empfehlungen zur Optimierung von SQL Server weiter oben im Artikel befolgen. Zusätzlich tragen die in den folgenden Abschnitten aufgeführten Informationen zur Optimierung der Indizierung und Abfrage bei.
Optimieren Sie die Leistung der Datenbank tempdb.
Jede Benutzerabfrage erfordert Aktivitäten in der SQL Server-Datenbank tempdb. Die Konfiguration dieser Datenbank wirkt sich also direkt darauf aus, wie schnell die Abfrageantworten für die Benutzer angezeigt werden.
Führen Sie die folgenden Schritte aus, um tempdb zu optimieren:
Legen Sie das Wiederherstellungsmodell auf
SIMPLEfest.Lassen Sie die tempdb-Dateien automatisch auf die erforderliche Größe wachsen.
Legen Sie das Inkrement für den Dateizuwachs auf einen sinnvollen Wert fest. Dieser Wert sollte idealerweise etwa 10 % der tempdb-Dateigröße entsprechen.
Ordnen Sie vorab Speicherplatz für die tempdb-Dateien zu, indem Sie die Dateigröße auf einen Wert festlegen, mit dem alle Aktivitäten während Crawls oder Abfragen abgedeckt sind.
Verwenden Sie mehrere Datendateien, um die Datenträgerbandbreite zu maximieren. Idealerweise sollte eine Datendatei pro CPU-Kern des Computers, auf dem SQL Server ausgeführt wird, verwendet werden.
Alle Datendateien sollten dieselbe Größe aufweisen.
Speichern Sie die Datenbank tempdb auf einem physikalischen Datenträger separat von den Datenträgern mit den Inhaltsdatenbanken bzw. der Konfigurations- und Suchdatenbank.
Hinweis
Weitere Informationen zur Optimierung von tempdb finden Sie unter Optimieren der Leistung von 'tempdb' (https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x407).
Verwenden Sie Dateigruppen, um die Leistung zur verbessern.
Beim Microsoft Office SharePoint Server 2007-Crawling- und Indizierungsvorgang wird die Eingabe/Ausgabe sehr stark beansprucht, und es werden große Datenvolumen in die Suchdatenbank geschrieben. Wenn im System Zeiten mit Zeiten mit geringer Auslastung auftreten, sollten Sie die Ausführung der Indizierung für diese Zeit planen, um sicherzustellen, dass kein Ressourcenkonflikt zwischen Indizierung und Benutzerabfragen auftritt. In einigen Organisationen, die weltweit oder rund um die Uhr tätig sind, gibt es solche geringen Bedarfszeiten nicht. Wenn sich der Datenbankserver, auf dem die Suchdatenbank gehostet wird, nah an seiner E/A-Kapazitätsgrenze befindet, sollten Sie andere Möglichkeiten in Betracht ziehen, um E/A-Vorgänge zur Indizierung von Vorgängen, die mit Benutzerabfragen zusammenhängen, zu trennen.
Die Suchdatenbank kann in Tabellen unterteilt werden, die für die Indizierung verwendet werden, und solche, die für Benutzerabfragen verwendet werden. Wenn Sie diese Gruppen von Tabellen auf zwei physikalische Datenträger verteilen können, wird sichergestellt, dass die Indizierung nur minimale Auswirkungen auf die Abfrageleistung hat. Obwohl sich die Tabellen für die Indizierung und die Abfrage in einer Datenbank befinden, können Sie mithilfe des Microsoft SQL Server-Dateigruppenfeatures eine solche Trennung erzielen.
Erstellen Sie dazu eine Benutzerdateigruppe mit einer sekundären Datendatei. Diese Datendatei muss sich auf einem dedizierten physikalischen Datenträger befinden, um eine Leistungsverbesserung zu erzielen. Verschieben Sie anschließend mithilfe des folgenden Verfahrens die Tabellen, die für die Indizierung verwendet werden, in diese Dateigruppe. Dieses Verfahren kann abhängig von der Größe der Suchdatenbank einen langen Zeitraum beanspruchen. Es empfiehlt sich daher, dieses Verfahren bei einer geringen Auslastung des Systems auszuführen.
Hinweis
Weitere Informationen zur Verwendung von Dateigruppen für die Suchdatenbank, einschließlich Transact-SQL-Skripts zum Verschieben von Tabellen, finden Sie unter SQL File groups and Search (https://go.microsoft.com/fwlink/?linkid=132066&clcid=0x407).
Trennen von Indizierungstabellen in einzelne dedizierte Dateigruppen
Klicken Sie in SQL Server Management Studio mit der rechten Maustaste auf die Suchdatenbank und anschließend auf Eigenschaften.
Klicken Sie in der Liste Seite auswählen auf Dateigruppen.
Klicken Sie auf Hinzufügen, und benennen Sie die neue Dateigruppe "CrawlFileGroup".
Klicken Sie in der Liste Seite auswählen auf Dateien.
Klicken Sie auf Hinzufügen, und benennen Sie die neue Datei.
Wählen Sie in der Zelle Dateigruppe den Eintrag CrawlFileGroup aus.
Wählen Sie in der Zelle Pfad einen Pfad auf einem separaten physikalischen Datenträger aus der PRIMÄREN Dateigruppe aus.
Klicken Sie auf OK.
Klicken Sie in SQL Server Management Studio auf Neue Abfrage.
Kopieren Sie die folgende Abfrage in das Abfragefenster, und klicken Sie dann auf Ausführen. Mit diesem Transact-SQL-Code wird eine neue gespeicherte Prozedur erstellt, mit der Tabellen in die neue Dateigruppe verschoben werden.
IF EXISTS (SELECT * FROM sysobjects WHERE type = 'P' AND name = 'proc_MoveTableToFileGroup') BEGIN DROP Procedure dbo.proc_MoveTableToFileGroup END GO CREATE PROCEDURE [dbo].[proc_MoveTableToFileGroup] ( @fileGroup sysname, @tableName sysname ) as begin declare @data_space_id int declare @object_id int declare @index_id int declare @index_name sysname declare @object_name sysname declare @fileGroupName sysname declare @index_cols nvarchar(4000) declare @sql nvarchar(4000) declare @key_ordinal int set @index_id = 0 set @key_ordinal = 0 select @data_space_id = data_space_id, @fileGroupName = name from sys.filegroups where name = @fileGroup if @data_space_id is null begin raiserror ('The specified filegroup does not exist.', 16, 1) return end while 1=1 begin select top 1 @object_id = i.object_id, @index_id = i.index_id, @index_name = i.name, @object_name = o.name from sys.indexes AS i inner join sys.objects AS o ON i.object_id = o.object_id where i.index_id > 0 and o.type = 'U' and o.name = @tableName and i.index_id > @index_id and i.data_space_id <> @data_space_id order by i.index_id if @@rowcount = 0 begin if @index_id = 0 print 'There are no indexes to move to filegroup ' + @fileGroupName + ' for table ' + @tableName break end set @index_cols = null set @key_ordinal = 0 while 1=1 begin select top 1 @index_cols = case when @index_cols is null then '[' + c.name + ']' else @index_cols + ', [' + c.name + ']' end + case when i.is_descending_key = 0 then ' asc' else 'desc' end, @key_ordinal = i.key_ordinal from sys.index_columns i inner join sys.columns as c on i.object_id = c.object_id and i.column_id = c.column_id where i.object_id = @object_id and i.index_id = @index_id and i.key_ordinal > @key_ordinal order by i.key_ordinal if @@rowcount = 0 break end select @sql = case when i.is_primary_key = 1 then N'begin try ' + N'begin tran ' + N'alter table [' + @object_name + '] drop constraint [' + i.name + '] ' + N'alter table [' + @object_name + '] add constraint [' + i.name + '] ' + 'primary key ' + case when i.type = 1 then 'clustered ' else 'nonclustered ' end + ' (' + @index_cols + ') ' + 'with (' + 'IGNORE_DUP_KEY = ' + case when i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end + ', PAD_INDEX = ' + case when i.is_padded = 1 then 'ON ' else 'OFF ' end + case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ') ' + 'ON [' + @fileGroupName + ']' + N' commit ' + N'end try ' + N'begin catch ' + N'rollback ' + N'end catch ' else N'create ' + case when i.is_unique = 1 then 'unique ' else '' end + case when i.type = 1 then 'clustered ' else 'nonclustered ' end + 'index [' + i.name + '] on [' + @object_name + '] (' + @index_cols + ') ' + 'with (' + 'IGNORE_DUP_KEY = ' + case when i.ignore_dup_key = 1 then 'ON ' else 'OFF ' end + ', PAD_INDEX = ' + case when i.is_padded = 1 then 'ON ' else 'OFF ' end + case when i.fill_factor = 0 then '' else ', FILLFACTOR = ' + CONVERT(nvarchar(10),i.fill_factor) end + ', DROP_EXISTING = ON ) ' + 'ON [' + @fileGroupName + ']' end from sys.indexes AS i where i.object_id = @object_id and i.index_id = @index_id print 'Moving index ' + @index_name + ' to filegroup ' + @fileGroupName print @sql print '' exec sp_executesql @sql end endKlicken Sie in SQL Server Management Studio auf Neue Abfrage.
Kopieren Sie die folgende Abfrage in das Abfragefenster, und klicken Sie dann auf Ausführen. Mit diesem Transact-SQL-Code wird eine neue gespeicherte Prozedur für jede Indizierungstabelle ausgeführt.
declare @fileGroup sysname set @fileGroup = 'CrawlFileGroup' if not exists (select 1 from sys.filegroups where name = @fileGroup) begin raiserror ('The specified filegroup does not exist.', 16, 1) return end exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorChangeLog' exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorPendingChangeLog' exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorText' exec proc_MoveTableToFileGroup @fileGroup, 'MSSAnchorTransactions' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedSourceDocs' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlChangedTargetDocs' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlContent' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedErrorList' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlDeletedURL' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlErrorList' begin try begin tran IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_MSSCrawlContent_MSSCrawlHistory]') AND parent_object_id = OBJECT_ID(N'[dbo].[MSSCrawlContent]')) ALTER TABLE [dbo].[MSSCrawlContent] DROP CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHistory' ALTER TABLE [dbo].[MSSCrawlContent] WITH CHECK ADD CONSTRAINT [FK_MSSCrawlContent_MSSCrawlHistory] FOREIGN KEY([CrawlID]) REFERENCES [dbo].[MSSCrawlHistory] ([CrawlID]) commit end try begin catch rollback end catch exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlHostList' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlQueue' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURL' exec proc_MoveTableToFileGroup @fileGroup, 'MSSCrawlURLLog' exec proc_MoveTableToFileGroup @fileGroup, 'MSSTranTempTable0'
Verwalten und Warten von SQL Server-Datenbanken für die Suche
Wie bei jedem anderen komplexen System erfordern auch SQL Server-Datenbanken eine regelmäßige Wartung, um das höchstmögliche Leistungsniveau zu erzielen. In diesem Abschnitt werden einige empfohlene Vorgehensweisen zum Beibehalten der maximalen Leistung beschrieben.
Mithilfe der folgenden Datenträgerwartungsmethoden kann die Leistung der Datenbankserver möglicherweise verbessert werden:
Es sollte mindestens 25 % freier Datenträgerspeicherplatz bewahrt werden, damit die Datenbanken "wachsen" können. Überwachen Sie die Datenträgergröße, und stellen Sie regelmäßig freien Speicherplatz bereit, um sicherzustellen, dass sich der Prozentwert nicht weiter verringert. Die Größe der Suchdatenbank kann sich deutlich und sehr kurzfristig erhöhen, wenn Administratoren neue Inhaltsquellen hinzufügen.
Wenn vom Festplattencontroller Datenträgerschreibungscache verwendet wird, muss sichergestellt sein, dass für diesen ein Sicherungsakku verfügbar ist, sodass im Fall eines Stromausfalls keine Dienstunterbrechung auftritt.
Mithilfe der folgenden SQL Server-Wartungsmethoden kann die Leistung der Datenbankserver möglicherweise verbessert werden:
Führen Sie regelmäßig die
DBCC CHECKDB-Transact-SQL-Routine für alle Office SharePoint Server-Datenbanken aus. Diese Routine führt zu einer starken Auslastung auf dem Computer, auf dem SQL Server ausgeführt wird, und wirkt sich möglicherweise auf die Reaktionszeiten aus. Verwenden Sie daher diePHYSICAL_ONLY-Option, und planen SieDBCC CHECKDBfür Zeiten mit geringer Auslastung. Diese Routine sollte nicht während eines Office SharePoint Server-Crawls ausgeführt werden.Führen Sie auf den Produktionsservern, auf denen SQL Server ausgeführt wird, keine nicht unterstützten Vorgänge aus. Sie sollten beispielsweise nicht die Datenbanksortierung ändern oder einer Office SharePoint Server-Datenbanktabelle Spalten hinzufügen. Weitere Informationen zu nicht unterstützten Vorgängen finden Sie im Microsoft Knowledge Base-Artikel 841057: Unterstützung für Änderungen an den Datenbanken, die durch Office-Serverprodukte und Windows SharePoint Services verwendet werden (https://go.microsoft.com/fwlink/?linkid=105589&clcid=0x407).
Nach und nach kann durch die Fragmentierung in den SQL Server-Indizes, von denen die Suchdatenbank unterstützt wird, die Indizierungs- und Abfrageleistung beeinträchtigt werden. Im Microsoft Knowledge Base-Artikel KB943345 ist ein Transact-SQL-Skript enthalten, mit dem die gespeicherte Prozedur proc_DefragmentIndices erstellt wird. Sie können proc_DefragmentIndices verwenden, um sowohl die Such- als auch die Inhaltsdatenbanken in der Office SharePoint Server-Farm zu defragmentieren. Diese gespeicherte Prozedur "kostet" jedoch viele Serverressourcen. Aus diesem Grund sollte sie nur nach sorgfältiger Überlegung verwendet werden, um eine reduzierte Leistung in Bezug auf die Abfragereaktionsfähigkeit zu vermeiden.
Hinweis
Weitere Informationen zum proc_DefragmentIndices-Skript und zu seiner Verwendung finden Sie unter Defragmentieren von Windows SharePoint Services 3.0- und SharePoint Server 2007-Datenbanken (https://go.microsoft.com/fwlink/?linkid=105588&clcid=0x407).
Darüber hinaus ist die gespeicherte Defragmentierungsprozedur proc_DefragSearchIndexes verfügbar, die speziell für Office SharePoint Server-Suchdatenbanken konzipiert ist. Mit dieser Prozedur werden nur die Indizes defragmentiert, die zu einer maximalen Leistung beitragen, beispielsweise IX_MSSDocProps und IX_MSSDocSdids. Dadurch kann der Bedarf an Datenbankserverressourcen gering gehalten werden. Es wird empfohlen, die gespeicherte Prozedur für Zeiten mit geringer Auslastung zu planen und die Auswirkungen auf die Benutzer sorgfältig zu überwachen.
Hinweis
Weitere Informationen zum proc_DefragSearchIndexes-Skript und zu seiner Verwendung finden Sie unter SQL Index defrag and maintenance tasks for Search (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=158799&clcid=0x407) im Microsoft Enterprise Search-Blog.
Wenn Sie auf einem Datenbankserver in der Farm einen Datenträger- oder RAID-Engpass diagnostizieren, können die Auswirkungen des Problems durch die folgenden Aktionen möglicherweise reduziert werden:
Verschieben Sie Datendateien und Transaktionsprotokolle auf separate Datenträger oder RAID-Arrays. Die Leistung kann durch die Verwendung von Dateigruppen maximiert werden, wie weiter oben im Artikel beschrieben.
Fügen Sie dem RAID-Array Datenträger hinzu.
Tauschen Sie langsame Datenträger durch schnellere aus.
Vermeiden einer Crawlerüberlastung
In einer großen oder komplexen Organisation stellt die Konfiguration des Microsoft Office SharePoint Server 2007-Indizierungssystems eine große Herausforderung dar. Möglicherweise haben Sie viele verschiedenartige Inhaltsquellen mit einem umfangreichen Inhaltskorpus, für den das Crawling viel Zeit in Anspruch nimmt. Sie sollten aus Gründen der Aktualität der Einträge im Index außerdem über sorgfältig geplante Ziele verfügen, um sicherzustellen, dass in den Ergebnissen aktuelle Inhalte wiedergegeben werden. Sie können die Aktualität der Ziele nur erreichen, indem Sie die Indiziererleistung optimieren, damit alle Inhalte in regelmäßigen Abständen gecrawlt werden können.
Ein schwerwiegendes Problem in Bezug auf die Indizierungsgeschwindigkeit stellt die Blockierung im Crawler dar. Der Crawler befindet sich in einem blockierten Zustand, wenn kein neuer Thread zugeordnet werden kann, um das nächste Dokument in der Warteschlange abzurufen. Die Blockierung kann auf folgende Ursachen zurückzuführen sein:
Ressourcenkonflikte auf Datenbankservern, auf denen die Suchdatenbank gehostet wird
Zu viele am Crawl beteiligte Hosts
Ein Thread wird von den Hosts nicht schnell freigegeben. (in diesem Artikel werden diese auch als "ressourcenhungrige" Hosts bezeichnet.)
Parallel mit dem Crawl ausgeführte Sicherungen
Ein Thread wird von ressourcenhungrigen Hosts blockiert, und ein Wechsel zum nächsten Dokument wird verhindert. Diese Blockierung kann in folgenden Situationen auftreten:
Wenn der Host aufgrund ungenügender CPU-, Arbeitsspeicher- oder anderer Ressourcen langsam ist.
Wenn der Host zusätzliche Vorgänge für inkrementelle Crawls ausführen muss. Wenn die Quelle beispielsweise ein Microsoft SharePoint Portal Server 2003:-Server ist, muss ein vollständiges Dokument vom Crawler erneut verarbeitet werden, falls sich die Berechtigungen geändert haben.
Hosts oder Dokumente mit einer größeren Anzahl von Eigenschaften. Wenn für jedes Dokument viele Eigenschaften verfügbar sind, bedeutet dies einen höheren Arbeitsaufwand für den Datenbankserver, auf dem die Suchdatenbank gehostet wird. Geschäftsdatenkatalog-Inhaltsquellen und Meine Website sind typische Beispiele für eine große Anzahl von Eigenschaften.
Die effizientesten Crawls treten gewöhnlich bei folgenden Hosttypen auf:
Microsoft Office SharePoint Server 2007-Server. Diese Server verwenden ein Änderungsprotokoll, das vom Crawler verwendet werden kann.
Dateifreigaben. Es können vom Crawler Überprüfungen auf Änderungen auf der Ordnerebene erfolgen; es muss nicht jedes Dokument einzeln überprüft werden.
Öffentliche Exchange-Ordner. Es können vom Crawler Überprüfungen auf Änderungen auf der Ordnerebene erfolgen; es muss nicht jede Bereitstellung einzeln überprüft werden.
Richtlinien zur Vermeidung einer Blockierung
Sie können die Crawlerblockierung mithilfe der folgenden empfohlenen Vorgehensweise minimieren:
Minimieren Sie die Anzahl der Inhaltsquellen. Sie können die Effizienz steigern, indem Sie Hosts ähnlicher Größe bzw. ähnlichen Typs jeweils in einzelnen Inhaltsquellen gruppieren.
Führen Sie zuerst Crawlvorgänge für große Microsoft Office SharePoint Server 2007-Hosts aus, bevor Sie andere Hosttypen hinzufügen. Diese Hosts können sehr effizient gecrawlt werden, und bei inkrementellen Crawls werden Threads sehr schnell freigegeben.
Planen Sie keine Crawls für mehrere ressourcenhungrige Hosts gleichzeitig.
Planen Sie als Ausgangspunkt vier parallele Crawls. Möglicherweise können Sie diese Anzahl für einige Indexserver erhöhen. Weitere Informationen finden Sie im folgenden Abschnitt in diesem Artikel.
Wenn der Crawler wegen unzureichender Ressourcen blockiert wird, halten Sie den Crawl für die ressourcenhungrigen Hosts an, um Threads freizugeben.
Diagnostizieren einer Blockierung
Wenn Sie ein neues Microsoft Office SharePoint Server 2007-Suchsystem installieren, erstellen Sie die Crawlerkonfiguration, indem Sie über mehrere Tage oder Wochen hinweg neue Inhaltsquellen hinzufügen. Überwachen Sie die Systemleistung beim Hinzufügen der einzelnen Inhaltsquellen, um eine Blockierung zu vermeiden und die Problembehandlung zu vereinfachen. Auf diese Weise können Sie das Verhalten des Systems während der Crawls verstehen lernen.
Die Anzahl der vom Crawler verwendeten Threads wird durch die Einstellung Indexerstellungsleistung festgelegt. Sie können diese Einstellung ändern, indem Sie in der Zentralverwaltung auf die Registerkarte Vorgänge, dann auf Dienste auf dem Server und dann auf Office SharePoint Server-Suche klicken. In der folgenden Tabelle wird veranschaulicht, wie die Crawlthreads mithilfe der Einstellung Indexerstellungsleistung gesteuert werden.
| Einstellung "Indexerstellungsleistung" | Gesamtzahl der Threads | Max. Anzahl der Threads für den jeweiligen Host |
|---|---|---|
Reduziert |
Anzahl der Prozessoren |
Anzahl der Prozessoren |
Teilweise reduziert |
4-fache Anzahl der Prozessoren |
Anzahl der Prozessoren + 4 |
Maximum |
16-fache Anzahl der Prozessoren |
Anzahl der Prozessoren + 4 |
In Microsoft Office SharePoint Server 2007 darf die Anzahl der Crawlthreads nie höher als 64 sein.
Der häufigste Grund für eine Blockierung ist ein Ressourcenkonflikt auf dem Datenbankserver. Sie können dies durch die Überwachung des Archivierungs-Plug-Ins erkennen. Verwenden Sie im Systemmonitor das Objekt Office Server-Sucharchivierungs-Plug-In und die Zähler Gesamte Dokumente in erster Warteschlange sowie Gesamte Dokumente in zweiter Warteschlange. Wenn diese Zähler beide Werte von 500 für die Instanz Portalinhalt oder 50 für die Instanz ProfileImport aufweisen, wird der Crawler blockiert. Es empfiehlt sich möglicherweise, eine Feinabstimmung des Datenbankservers, wie unter Optimieren von SQL Server für die Suche in Office SharePoint Server 2007 weiter oben in diesem Artikel beschrieben, auszuführen.
Blockierungszustände, die nicht durch das Archivierungs-Plug-In verursacht wurden, können mithilfe des Objekts Office Server Search-Gatherer im Systemmonitor diagnostiziert werden. Beschränken Sie sich auf die Zähler Leerlaufthreads, Auf das Netzwerk zugreifende Threads und Threads in Plug-Ins, und vergleichen Sie diese mit der Gesamtthreadzahl des Systems. Eine ausführliche Beschreibung dieser Zähler finden Sie unter Überwachen von Indexservern weiter oben in diesem Artikel.
Vermeiden von durch Zugriffssteuerungslisten verursachten Engpässen
Wenn eine Inhaltsquelle von Microsoft Office SharePoint Server 2007 gecrawlt und indiziert wird, werden Zugriffssteuerungslisten (Access Control Lists, ACLs) überprüft und in der Suchdatenbank gespeichert. Wenn Benutzer den Index durchsuchen, wird jedes Ergebnis in der Suchdatenbank überprüft, um sicherzustellen, dass der Benutzer berechtigt ist, auf dieses Ergebnis zuzugreifen. Dieser Vorgang wird auch als Einschränkung aus Sicherheitsgründen bezeichnet. Große Zugriffssteuerungslisten mit vielen Verschachtelungsebenen können sich daher negativ auf die Leistung des Crawlvorgangs sowie auf die Suchvorgänge in Office SharePoint Server auswirken. In diesem Abschnitt wird beschrieben, wie Sie eine derartige Leistungsherabsetzung minimieren können.
Mit Active Directory werden die folgenden Sicherheitsprinzipaltypen bereitgestellt, mit denen Sie Office SharePoint Server-Websites und indizierten Inhalt sichern können:
Benutzerkonten
Globale Gruppen
Lokale Domänengruppen
Universelle Gruppen
In Microsoft Office SharePoint Server 2007 stehen Ihnen auch SharePoint-Gruppen zur Verfügung. Dieses System ist äußerst flexibel und kann verschiedene Verschachtelungsebenen enthalten. Die Suchleistung von Office SharePoint Server kann durch die Sicherheitsprinzipale jedoch negativ beeinflusst werden.
Sie können eine maximale Leistung des Crawlers und der Suchen in Microsoft Office SharePoint Server 2007 erzielen, indem Sie die folgenden Regeln bei der Verwendung von Active Directory-Sicherheitsprinzipalen und SharePoint-Gruppen beachten:
Stellen Sie Benutzerkonten in globalen Gruppen und globale Gruppe in lokalen Domänengruppen zusammen. Dies ist die empfohlene Vorgehensweise für die Verwendung von Sicherheitsprinzipalen in Active Directory. Damit wird sichergestellt, dass vom Domänencontroller Gruppenmitgliedschaften schnell nachgeschlagen werden können und Benutzer über eine Struktur auf Ressourcen zugreifen können.
Falls universelle Gruppen erforderlich sind, können Sie dasselbe System verwenden, globale Gruppen jedoch in universellen Gruppen und universelle Gruppen in lokalen Domänengruppen zusammenstellen.
Fügen Sie lokale Domänengruppen in SharePoint-Gruppen ein, um Berechtigungen für SharePoint-Websites und andere Ressourcen zuzuordnen.
Beschränken Sie die Anzahl der in der Gruppenmitgliedschaft verwendeten Verschachtelungsebenen.
Die folgenden spezifischen Situationen beeinträchtigen die Leistung von Microsoft Office SharePoint Server 2007-Suchen und sollten vermieden werden:
Ordnen Sie einzelnen Benutzern keine Office SharePoint Server-Websiteberechtigungen zu.
Die Leistung der Office SharePoint Server-Websites wird verlangsamt, wenn mehr als 2.000 Sicherheitsprinzipale in der freigegebenen Zugriffssteuerungsliste (Discretionary Access Control List, DACL) einer Website aufgelistet sind. Eine Active Directory- oder SharePoint-Gruppe stellt jedoch ein einzelnes Sicherheitsprinzipal dar, unabhängig von der Anzahl der darin enthaltenen Benutzer. Sie sollten daher SharePoint-Gruppen verwenden, um Websiteberechtigungen zuzuordnen und Benutzer oder Active Directory-Gruppen in SharePoint-Gruppen einzufügen.
Verwenden Sie keine stark verschachtelten Active Directory-Sicherheitsgruppen.
Wenn ein Benutzer versucht, auf eine Office SharePoint Server-Website zuzugreifen, müssen vom Server die Gruppenmitgliedschaften bewertet werden, um den Benutzer zu autorisieren. Bei stark verschachtelten Gruppen sind viele Abfragen an die Domänencontroller erforderlich. Darüber hinaus sind möglicherweise Abfragen an ferne Domänen in der Struktur erforderlich. Der Benutzer erhält erst nach Abschluss dieser Abfragen Zugriff.
Verwenden Sie keine Verteilungslisten oder Sicherheitsgruppen, in denen Kontakte enthalten sind.
Kontakte in Active Directory können Gruppen hinzugefügt werden, um beispielweise E-Mails zu verteilen. Kontakte sind jedoch keine Sicherheitsprinzipale und können nicht in die Autorisierung einbezogen werden. Wenn Sie einer Gruppe, in der Kontakte enthalten sind, Berechtigungen zuweisen, kann dies zu Leistungseinbußen führen.
In Microsoft Office SharePoint Server 2007 kann der Websitebesitzer den einzelnen Websites Benutzer hinzufügen und der Website-DACL Gruppen hinzufügen. Es ist sehr wichtig, dass Websitebesitzer Kenntnisse zur sorgfältigen Verwendung von Gruppenmitgliedschaften haben, um so möglicherweise entstehende Engpässe zu vermeiden.
Problembehandlung fehlender Suchfeld-Webparts
In den folgenden Situationen wird das Suchfeld-Webpart nicht im Suchcenter oder anderen Positionen auf der Microsoft Office SharePoint Server 2007-Benutzeroberfläche angezeigt:
Die Suchcenter-Inhaltsseite oder die Masterseite der Website wurde von einem Entwickler geändert, um das Suchfeld-Webpart auszublenden oder zu entfernen.
Das Suchfeld-Webpart wurde von einem Benutzer mit Berechtigungen für den Vollzugriff oder der Berechtigungsstufe Entwerfen ausgeblendet oder entfernt.
Der Suchdienst ist in der Office SharePoint Server-Farm nicht verfügbar; entweder aufgrund einer Dienstunterbrechung oder weil er von Administratoren offline geschaltet wurde.
Hinweis
Weitere Informationen zum Suchfeld-Webpart finden Sie unter Konfigurieren von Eigenschaften für das Suchfeld-Webpart (Office SharePoint Server 2007).
Siehe auch
Konzepte
Problembehandlung für Office SharePoint Server 2007
Bewährte Methoden für den Suchdienst in Office SharePoint Server