Leitfaden zur Indexer-Problembehandlung bei Azure AI Search

Gelegentlich gibt es mit Indexern Probleme, die keine Fehler verursachen oder die bei anderen Azure-Diensten auftreten, z. B. während der Authentifizierung oder beim Herstellen einer Verbindung. Dieser Artikel konzentriert sich auf die Behandlung von Indexerproblemen, wenn keine Meldungen zur Unterstützung vorhanden sind. Er bietet auch die Problembehandlung für Fehler, die aus Nicht-Suchressourcen stammen, die während der Indizierung verwendet werden.

Bewährte Methoden

Dies sind einige bewährte Methoden und Empfehlungen beim Arbeiten mit Indexern:

Indexer sind dafür konzipiert, nach einem Zeitplan zu laufen.

• Konfigurieren Sie Für eine zuverlässige Indizierung Ihre Indexer so, dass sie regelmäßig ausgeführt werden. Geplante Ausführungen erfassen automatisch alle Dokumente, die in früheren Ausführungen aufgrund transiente Fehler, Netzwerkunterbrechungen oder vorübergehende Dienstprobleme übersehen wurden. Dieser Ansatz trägt dazu bei, die Datenkonsistenz aufrechtzuerhalten und die Notwendigkeit eines manuellen Eingriffs zu minimieren.
• Bei großen Datenquellen kann die anfängliche Aufzählung und Indizierung Stunden oder sogar Tage dauern. Wenn Sie den Indexer in einem Zeitplan ausführen, wird der Fortschritt fortgesetzt, und Fehler werden automatisch wiederholt. Verlassen Sie sich nicht ausschließlich auf manuelle oder On-Demand-Indexerausführungen, da diese nicht die gleiche Zuverlässigkeit oder vorübergehende Fehlerwiederherstellung bieten.

Indexer bieten eine optimale Indizierung im Laufe der Zeit.

• Integrierte Indexer sind so konzipiert, dass alle Dokumente ohne permanente Fehler im Laufe der Zeit verarbeitet werden, wenn nicht in der aktuellen Ausführung, dann in nachfolgenden geplanten Ausführungen. Sie bieten eine bequeme, low/no-code-Methode zum Indizieren von Daten für gängige Szenarien und ermöglichen eine schnellere Entwicklung und einfachere Wartung. Wenn sie jedoch über KI-Anreicherungsfunktionen verfügen, sind sie nicht für sehr große Workloads optimiert. Eine Anleitung zum Behandeln großer Datasets finden Sie in der Indizierung großer Datasets.
• Wenn Ihre Lösung strenge Kontrolle über die Indizierungszeitleisten erfordert, verwenden Sie stattdessen die Push-APIs, z. B. die REST-API für Dokumente oder die IndexDocuments-Methode (Azure SDK für .NET). Diese Optionen bieten Ihnen die vollständige Kontrolle über die Indizierungspipeline.
• Indexer können gelegentlich aus dem Zeitplan geraten. Obwohl dies ungewöhnlich ist und mechanismen für die automatische Wiederherstellung vorhanden sind, kann die Wiederherstellung zeitaufwendigen. Dieses Verhalten wird erwartet.

Problembehandlung bei Verbindungen mit eingeschränkten Ressourcen

Bei Datenquellen unter Azure-Netzwerksicherheit ist die Art und Weise eingeschränkt, wie Indexer die Verbindung herstellen. Derzeit können Indexer mit einer freigegebenen privaten Verbindung über einen privaten Endpunkt auf eingeschränkte Datenquellen hinter einer IP-Firewall oder in einem virtuellen Netzwerk zugreifen.

Fehler beim Herstellen einer Verbindung mit einer Microsoft Foundry-Ressource in einer privaten Verbindung

Wenn Sie den Fehlercode 403 mit der folgenden Meldung erhalten, besteht möglicherweise ein Problem mit der Angabe des Ressourcenendpunkts in einem Skillset:

• "A Virtual Network is configured for this resource. Please use the correct endpoint for making requests. Check https://aka.ms/cogsvc-vnet for more details."

Dieser Fehler tritt auf, wenn Sie einen freigegebenen privaten Link für Verbindungen mit einer Azure Foundry-Ressource konfiguriert haben und der Endpunkt eine benutzerdefinierte Unterdomäne fehlt. Eine benutzerdefinierte Unterdomäne ist der erste Teil des Endpunkts (z. B. http://my-custom-subdomain.services.ai.azure.com). Möglicherweise fehlt eine benutzerdefinierte Domäne, wenn Sie die Ressource im Foundry-Portal anstelle des Azure-Portals erstellt haben.

Wenn sich die Foundry-Ressource nicht in derselben Region wie Azure AI Search befindet, verwenden Sie eine schlüssellose Verbindung , um die Ressource anzufügen.

Firewallregeln

Azure Storage, Azure Cosmos DB und Azure SQL bieten eine konfigurierbare Firewall. Sie erhalten keine spezifische Fehlermeldung, wenn die Firewall die Anforderung blockiert. Normalerweise sind Firewall-Fehler allgemeiner Natur. Häufige Fehler sind z. B. folgende:

• The remote server returned an error: (403) Forbidden
• This request is not authorized to perform this operation
• Credentials provided in the connection string are invalid or have expired

Es gibt zwei Möglichkeiten, Indexern in einem solchen Fall Zugriff auf diese Ressourcen zu ermöglichen:

• Konfigurieren Sie eine eingehende Regel für die IP-Adresse des Suchdiensts und den IP-Adressbereich des AzureCognitiveSearch-Diensttags. Details zum Konfigurieren der Einschränkungen des IP-Adressbereichs für die einzelnen Datenquellentypen finden Sie unter den folgenden Links:

  • Azure Storage (in englischer Sprache)
  • Azure Cosmos DB
  • Azure SQL

• Deaktivieren Sie als letzte Möglichkeit oder als temporäre Maßnahme die Firewall, indem Sie den Zugriff für Alle Netzwerke zulassen.

Einschränkung: Einschränkungen des IP-Adressbereichs funktionieren nur, wenn Sich Ihr Suchdienst und Ihr Speicherkonto in verschiedenen Regionen befinden.

Zusätzlich zum Datenabruf senden Indexer auch ausgehende Anforderungen über Skillsets und benutzerdefinierte Fähigkeiten. Beachten Sie bei benutzerdefinierten Fähigkeiten, die auf einer Azure-Funktion basieren, dass Azure-Funktionen auch IP-Adresseinschränkungen unterliegen. Die Liste der IP-Adressen, die für die Ausführung von benutzerdefinierten Fähigkeiten zulässig sind, umfasst die IP-Adresse des Suchdiensts und den IP-Adressbereich des AzureCognitiveSearch-Diensttags.

Regeln für die Netzwerksicherheitsgruppe (Network Security Group, NSG)

Wenn ein Indexer auf Daten in einer SQL-verwalteten Instanz zugreift oder wenn eine Azure-VM als Webdienst-URI für eine benutzerdefinierte Fähigkeit verwendet wird, bestimmt die Netzwerksicherheitsgruppe, ob Anforderungen zulässig sind.

Konfigurieren Sie für externe Ressourcen, die sich in einem virtuellen Netzwerk befinden, eingehende NSG-Regeln für das AzureCognitiveSearch-Diensttag.

Weitere Informationen zum Herstellen einer Verbindung mit einem virtuellen Computer finden Sie unter Konfigurieren einer Verbindung eines Indexers der kognitiven Azure-Suche mit SQL Server auf einer Azure-VM.

Netzwerkfehler

Normalerweise sind Netzwerkfehler allgemeiner Natur. Häufige Fehler sind z. B. folgende:

• A network-related or instance-specific error occurred while establishing a connection to the server
• The server was not found or was not accessible
• Verify that the instance name is correct and that the source is configured to allow remote connections

Wenn Sie eine dieser Fehler erhalten:

• Stellen Sie sicher, dass Ihre Quelle zugänglich ist, indem Sie versuchen, sich direkt mit ihr zu verbinden und nicht über den Suchdienst
• Überprüfen Sie Ihre Ressource im Azure-Portal auf aktuelle Fehler oder Ausfälle
• Suchen Sie nach Netzwerkausfällen im Azure-Status
• Stellen Sie sicher, dass Sie einen öffentlichen DNS für die Namensauflösung verwenden und nicht einen Azure Private DNS

Azure SQL-Datenbank – serverlos: Indizierung (Fehlercode 40613)

Wenn sich Ihre SQL-Datenbank auf einer serverlosen Computeebene befindet, müssen Sie sicherstellen, dass die Datenbank ausgeführt wird (und nicht angehalten wurde), wenn der Indexer eine Verbindung mit ihr herstellt.

Wenn die Datenbank angehalten wurde, sollte sie bei der ersten Anmeldung Ihres Suchdiensts automatisch fortgesetzt werden. Darüber hinaus wird jedoch ein Fehler mit dem Fehlercode 40613 und dem Hinweis zurückgegeben, dass die Datenbank nicht verfügbar sei. Wenn die Datenbank ausgeführt wird, wiederholen Sie den Anmeldeversuch, um eine Verbindung herzustellen.

Richtlinien für Microsoft Entra Conditional Access

Wenn Sie einen SharePoint-Indexer erstellen, müssen Sie sich nach der Bereitstellung eines Gerätecodes bei Ihrer Microsoft Entra-App anmelden. Möglicherweise erhalten Sie die Meldung "Your sign-in was successful but your admin requires the device requesting access to be managed". In diesem Fall wird der Indexer wahrscheinlich durch eine Richtlinie für bedingten Zugriff daran gehindert, auf die SharePoint-Dokumentbibliothek zuzugreifen.

So aktualisieren Sie die Richtlinie und erlauben den Indexerzugriff auf die Dokumentbibliothek:

1. Öffnen Sie das Azure-Portal, und suchen Sie nach „Bedingter Microsoft Entra-Zugriff“.

2. Wählen Sie im Menü links Richtlinien aus. Wenn Sie keinen Zugriff zur Anzeige dieser Seite haben, bitten Sie entweder einen Benutzer mit entsprechendem Zugriff, die Seite zu öffnen, oder fordern Sie Zugriff auf die Seite an.

3. Ermitteln Sie, welche Richtlinie den Zugriff auf die Dokumentbibliothek durch den SharePoint-Indexer blockiert. Die Richtlinie, die den Indexer möglicherweise blockiert, enthält das Benutzerkonto, das Sie während des Schritts zur Indexererstellung im Abschnitt Benutzer und Gruppe für die Authentifizierung verwendet haben. Die Richtlinie umfasst darüber hinaus möglicherweise Bedingungen, für die Folgendes gilt:

   • Einschränkung von Windows-Plattformen
   • Einschränkung von Mobile Apps und Desktopclients
   • Gerätestatus auf Ja festgelegt

4. Nachdem Sie bestätigt haben, welche Richtlinie den Indexer blockiert, erstellen Sie eine Ausnahme für den Indexer. Rufen Sie zunächst die IP-Adresse des Suchdiensts ab.

   Rufen Sie als erstes den vollqualifizierten Domänennamen (FQDN) Ihres Suchdiensts ab. Der FQDN sieht wie <your-search-service-name>.search.windows.net aus. Sie können im Azure-Portal nach dem FQDN suchen.

   

   Nachdem Sie nun den FQDN haben, rufen Sie die IP-Adresse des Suchdienstes ab, indem Sie einen nslookup (oder ping) des FQDN durchführen. Im folgenden Beispiel fügen Sie einer eingehenden Regel in der Azure Storage-Firewall „150.0.0.1“ hinzu. Es kann bis zu 15 Minuten nach dem Aktualisieren der Firewalleinstellungen dauern, bis der Suchdienstindexer auf das Azure Storage-Konto zugreifen kann.

   nslookup contoso.search.windows.net
   Server:  server.example.org
   Address:  10.50.10.50
   
   Non-authoritative answer:
   Name:    <name>
   Address:  150.0.0.1
   Aliases:  contoso.search.windows.net
   

5. Rufen Sie die IP-Adressbereiche für die Indexerausführungsumgebung für Ihre Region ab.

   Zusätzliche IP-Adressen werden für Anforderungen verwendet, die aus der mehrinstanzenfähigen Ausführungsumgebung des Indexers stammen. Sie können diesen IP-Adressbereich aus dem Diensttag abrufen.

   Die IP-Adressbereiche für das Diensttag AzureCognitiveSearch können entweder über die Ermittlungs-API oder die herunterladbare JSON-Datei abgerufen werden.

   Für diese Übung sollte unter der Annahme, dass der Suchdienst der öffentliche Azure-Clouddienst ist, die öffentliche Azure-JSON-Datei heruntergeladen werden.

   

   Aus der JSON-Datei sind unter der Annahme, dass sich der Suchdienst in „USA, Westen-Mitte“ befindet, die IP-Adressen für die Ausführungsumgebung des Indexers für mehrere Mandanten nachfolgend aufgeführt.

       {
         "name": "AzureCognitiveSearch.WestCentralUS",
         "id": "AzureCognitiveSearch.WestCentralUS",
         "properties": {
           "changeNumber": 1,
           "region": "westcentralus",
           "platform": "Azure",
           "systemService": "AzureCognitiveSearch",
           "addressPrefixes": [
             "52.150.139.0/26",
             "52.253.133.74/32"
           ]
         }
       }
   

6. Wählen Sie im Azure-Portal zurück auf der Seite „Bedingter Zugriff“ im Menü links die Option Benannte Standorte und anschließend + IP-Adressbereiche (Standort) aus. Geben Sie dem neuen benannten Standort einen Namen, und fügen Sie die IP-Adressbereiche für Ihre Suchdienst- und Indexerausführungsumgebungen hinzu, die Sie in den letzten beiden Schritten erfasst haben. 1

   • Für die IP-Adresse Ihres Suchdiensts müssen Sie möglicherweise am Ende der IP-Adresse „/32“ hinzufügen, da nur gültige IP-Adressbereiche akzeptiert werden.
   • Denken Sie daran, dass Sie für die Indexerausführungsumgebung nur die IP-Adressbereiche der Region hinzufügen müssen, in der sich Ihr Suchdienst befindet.

7. Schließen Sie den neuen benannten Speicherort aus der Richtlinie aus:

   1. Wählen Sie im Menü links Richtlinien aus.
   2. Wählen Sie die Richtlinie aus, die den Indexer blockiert.
   3. Klicken Sie auf Bedingungen.
   4. Wählen Sie Standorte aus.
   5. Klicken Sie auf Ausschließen, und fügen Sie dann den neuen benannten Speicherort hinzu.
   6. Speichern Sie die Änderungen.

8. Warten Sie einige Minuten, bis die Richtlinie aktualisiert wurde, und erzwingen Sie die neuen Richtlinienregeln.

9. Versuchen Sie erneut, den Indexer zu erstellen:

   1. Senden Sie eine Aktualisierungsanforderung für das Datenquellenobjekt, das Sie erstellt haben.
   2. Senden Sie die Anforderung zum Erstellen des Indexers erneut. Verwenden Sie den neuen Code für die Anmeldung, und senden Sie eine weitere Anforderung zur Indexererstellung.

Indizieren nicht unterstützter Dokumenttypen

Wenn Sie Inhalte aus Azure Blob Storage indizieren und der Container Blobs eines nicht unterstützten Inhaltstyps enthält, überspringt der Indexer dieses Dokument. In anderen Fällen können Probleme mit einzelnen Dokumenten auftreten.

In diesem Fall können Sie Konfigurationsoptionen festlegen, damit die Indexerverarbeitung bei Problemen mit einzelnen Dokumenten fortgesetzt werden kann.

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2025-09-01
Content-Type: application/json
api-key: [admin key]

{
  ... other parts of indexer definition
  "parameters" : { "configuration" : { "failOnUnsupportedContentType" : false, "failOnUnprocessableDocument" : false } }
}

Fehlende Dokumente

Indexer extrahieren Dokumente oder Zeilen aus einer externen Datenquelle und erstellen Suchdokumente, die dann vom Suchdienst indiziert werden. Gelegentlich wird ein Dokument, das in der Datenquelle vorhanden ist, nicht in einem Suchindex angezeigt. Dieses unerwartete Ergebnis kann aus folgenden Gründen auftreten:

• Das Dokument wurde nach der Ausführung des Indexers aktualisiert. Wenn Sie für Ihren Indexer einen Zeitplan festgelegt haben, wird er das Dokument schließlich erneut ausführen und abrufen.
• Für den Indexer wurde vor der Erfassung des Dokuments ein Timeout ausgelöst. Es gibt Grenzwerte für die maximale Bearbeitungszeit, nach deren Ablauf keine Dokumente mehr bearbeitet werden können. Sie können den Indexerstatus im Azure-Portal oder durch Aufrufen von Get Indexer Status (REST API) überprüfen.
• Feldzuordnungen oder KI-Anreicherung haben das Dokument verändert, und seine Formulierung im Suchindex ist anders, als Sie es erwarten.
• Änderungsnachverfolgungs-Werte sind fehlerhaft oder Voraussetzungen fehlen. Wenn der hohe Grenzwert ein Datum ist, das auf einen späteren Zeitpunkt festgelegt ist, werden alle Dokumente mit einem früheren Datum vom Indexer übersprungen. Sie können den Zustand der Änderungsnachverfolgung des Indexers mithilfe der Felder „initialTrackingState“ und „finalTrackingState“ im Indexerstatus bestimmen. Indexer für Azure SQL und MySQL müssen über einen Index für die Hochwassermarken-Spalte in der Quelltabelle verfügen. Andernfalls kann bei Abfragen des Indexers ein Timeout auftreten.

Fehlender Inhalt aus Blob Storage

Der Blobindexer findet und extrahiert Text aus Blobs in einem Container. Beim Extrahieren von Text können u.a. diese Probleme auftreten:

• Das Dokument enthält nur gescannte Bilder. PDF-Blobs mit Nichttextinhalten wie gescannten Bildern (JPGs) erzeugen keine Ergebnisse in einer Standard-Blobindizierungspipeline. Wenn Sie Bildinhalte mit Textelementen haben, können Sie mithilfe der optischen Zeichenerkennung (OCR) oder Bildanalyse Text suchen und extrahieren.

• Der Blobindexer ist so konfiguriert, dass er nur Metadaten indiziert. Zum Extrahieren von Inhalten muss der Blobindexer so konfiguriert sein, dass er sowohl Inhalte als auch Metadaten extrahiert:

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2025-09-01
Content-Type: application/json
api-key: [admin key]

{
  ... other parts of indexer definition
  "parameters" : { "configuration" : { "dataToExtract" : "contentAndMetadata" } }
}

Fehlender Inhalt von Azure Cosmos DB

Azure AI Search ist implizit von der Azure Cosmos DB-Indizierung abhängig. Wenn Sie die automatische Indizierung in Azure Cosmos DB deaktivieren, gibt Azure AI Search zwar einen erfolgreichen Status zurück, indiziert aber keine Containerinhalte. Anweisungen zum Überprüfen der Einstellungen und zum Aktivieren der Indizierung finden Sie unter Verwalten der Indizierung in Azure Cosmos DB.

Abweichung der Dokumentanzahl zwischen der Datenquelle und dem Index

Ein Indexer kann eine andere Dokumentanzahl als von der Datenquelle, dem Index selbst oder der Anzahl in Ihrem Code angezeigen. Hier sind einige mögliche Gründe, warum dieses Verhalten auftreten kann:

• Der Index kann die tatsächliche Dokumentanzahl verzögert anzeigen, insbesondere im Azure-Portal.
• Eine Dokumentrichtlinie im Indexer wurde gelöscht. Die gelöschten Dokumente werden vom Indexer gezählt, wenn die Dokumente indiziert werden, bevor sie gelöscht werden.
• Wenn die ID-Spalte in der Datenquelle nicht eindeutig ist. Dies gilt für Datenquellen mit Spaltenkonzept wie Azure Cosmos DB.
• Wenn die Datenquellendefinition eine andere Abfrage aufweist als die, die Sie verwenden, um die Anzahl der Datensätze zu schätzen. In Ihrer Datenbank können Sie beispielsweise die Datensätze abfragen, während Sie in der Datenquellen-Definitionsabfrage nur eine Teilmenge von Datensätzen auswählen, die indiziert werden sollen.
• Die Anzahl wird in verschiedenen Intervallen für jede Komponente der Pipeline überprüft: Datenquelle, Indexer und Index.
• Die Datenquelle verfügt über eine Datei, die vielen Dokumenten zugeordnet ist. Diese Bedingung kann auftreten, wenn BLOBs indiziert werden und wenn „parsingMode“ auf jsonArray und jsonLines festgelegt ist.

Mehrfach verarbeitete Dokumente

Indexer nutzen eine konservative Pufferstrategie, um sicherzustellen, dass jedes neue und geänderte Dokument in der Datenquelle während der Indizierung aufgenommen wird. In bestimmten Situationen können sich diese Puffer überlappen, wodurch ein Indexer ein Dokument doppelt oder mehrfach indiziert, was dazu führt, dass die Anzahl der verarbeiteten Dokumente größer als die tatsächliche Anzahl von Dokumenten in der Datenquelle ist. Dieses Verhalten wirkt sich nicht auf die im Index gespeicherten Daten aus, es werden z. B. keine Dokumente dupliziert, sondern hat lediglich zur Folge, dass es länger dauern kann, bis die letztliche Konsistenz erreicht ist. Diese Bedingung tritt besonders häufig auf, wenn eines der folgenden Kriterien zutrifft:

• Bedarfsbasierte Indexeranforderungen werden in schneller Folge ausgegeben.
• Die Topologie der Datenquelle umfasst mehrere Replikate und Partitionen (ein solches Beispiel wird hier erläutert).
• Die Datenquelle ist eine Azure SQL-Datenbank-Instanz, die als „Obergrenze“ ausgewählte Spalte hat den Typ datetime2.

Indexer sollen nicht mehrmals in schneller Folge aufgerufen werden. Wenn Sie schnell Updates benötigen, besteht der unterstützte Ansatz im Pushen von Updates an den Index, während gleichzeitig die Datenquelle aktualisiert wird. Für die bedarfsbasierte Verarbeitung wird empfohlen, dass Sie Ihre Anforderungen in Intervallen von fünf Minuten oder mehr senden und den Indexer nach einem Zeitplan ausführen.

Beispiel für die doppelte Verarbeitung Dokumente mit einem Puffer von 30 Sekunden

Bedingungen, unter denen ein Dokument zweimal verarbeitet wird, werden im Folgenden in einer Zeitachse mit den einzelnen Aktionen und Gegenaktionen beschrieben. Die folgende Zeitachse veranschaulicht das Problem:

In der Praxis tritt dieses Szenario nur auf, wenn bedarfsbasierte Indexer für bestimmte Datenquellen innerhalb weniger Minuten manuell aufgerufen werden. Dies kann zu abweichenden Zahlen führen (z. B. dass der Indexer gemäß den Indexerausführungsstatistiken insgesamt 345 Dokumente verarbeitet hat, in der Datenquelle und im Index aber nur 340 Dokumente enthalten sind) oder eine potenziell erhöhte Abrechnung verursachen, wenn Sie die gleichen Skills für dasselbe Dokument mehrmals ausführen. Empfehlung: Die Ausführung eines Indexers unter Verwendung eines Zeitplans ist die bevorzugte Vorgehensweise.

Parallele Indizierung

Wenn mehrere Indexer gleichzeitig ausgeführt werden, ist es normal, dass einige von ihnen sich in eine Warteschlange einreihen und auf verfügbare Ressourcen warten, um mit der Ausführung zu beginnen. Die Anzahl der Indexer, die gleichzeitig ausgeführt werden können, hängt von mehreren Faktoren ab. Wenn die Indexer nicht mit Skillsets verknüpft sind, hängt die Kapazität zur parallelen Ausführung von der Anzahl der Replikate und Partitionen ab, die in Azure KI-Suche eingerichtet wurden.

Wenn ein Indexer dagegen einem Skillset zugeordnet ist, wird er innerhalb der internen Cluster der KI-Suche ausgeführt. Die Fähigkeit, in diesem Fall gleichzeitig zu laufen, hängt von der Komplexität des Skillsets und davon, ob andere Skillsets gleichzeitig ausgeführt werden, ab. Integrierte Indexer sind so konzipiert, dass Daten zuverlässig aus der Quelle extrahiert werden, sodass keine Daten fehlen, wenn sie in einem Zeitplan ausgeführt werden. Es ist jedoch davon auszugehen, dass die Indexerprozesse für Parallelisierung und Hochskalierung einige Zeit in Anspruch nehmen.

Indizieren von Dokumenten mit Vertraulichkeitsbezeichnungen

Wenn Sie Vertraulichkeitsbezeichnungen für Dokumente festgelegt haben, können Sie sie möglicherweise nicht indizieren. Wenn Sie Fehler erhalten, entfernen Sie die Bezeichnungen vor der Indizierung.

Weitere Informationen

• Problembehandlung bei häufigen Indexerfehlern und -warnungen
• Überwachen der indexerbasierten Indizierung
• Indizieren großer Datasets