Leitfaden zur Indexer-Problembehandlung bei Azure KI-Suche

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 Optionen nicht die gleiche Zuverlässigkeit oder vorübergehende Fehlerwiederherstellung bieten.

Indexer bieten eine optimale Indizierung im Laufe der Zeit.

• Integrierte Indizierer verarbeiten Dokumente ohne dauerhafte Fehler und wiederholen die geplanten Ausführungsläufe. Sie bieten eine bequeme, low-code- oder no-code-Methode zum Indizieren von Daten für gängige Szenarien und ermöglichen eine schnellere Entwicklung und einfachere Wartung. Wenn ein Indexer ein Skillset ausführt, verfügt jede Ausführung über ein festes Ausführungszeitlimit. Indexer, die in der Mehrinstanzenausführungsumgebung ausgeführt werden, verfügen über eine zweistündige maximale Laufzeit. Dieser Grenzwert ist der häufigste Fall, der verwendet wird, wenn Skillsets keine freigegebenen privaten Links erfordern. Indexer, die für die Nutzung von gemeinsam genutzten privaten Links konfiguriert sind, werden in einer privaten Ausführungsumgebung mit einer maximalen Laufzeit von 24 Stunden ausgeführt. Die vollständige Tabelle finden Sie unter "Indexergrenzwerte". Wenn die Skillsetverarbeitung pro Dokument verhindert, dass der Indexer vor Ablauf des Zeitlimits fertiggestellt wird, wird er angehalten, und die verbleibenden Dokumente bleiben unverarbeitet. Die vollständige Verarbeitung kann nicht garantiert werden, wenn das Dokumentvolumen, die Dateigröße, die Komplexität des Skillsets oder die Ausführungsumgebung verhindern, dass der Indexer innerhalb seiner maximalen Laufzeit abschließen kann. Die Partitionierung Ihrer Datenquelle kann dieses Risiko verringern, beseitigt es jedoch nicht, insbesondere, wenn Sie später große Mengen von Dateien zu einer Partition hinzufügen. Dieses Verhalten wird erwartet. Informationen zu Strategien für die Verwaltung großer Datensätze und zur Unterstützung der inkrementellen Wiederherstellung finden Sie unter Große Datensätze indizieren und Indexer planen. Wenn Ihre Lösung strenge Kontrolle darüber erfordert, wann der Indexer Dokumente verarbeitet, verwenden Sie die Push-API-Alternative in diesem Artikel.
• 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 diese Bedingung 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 Der Fehlercode 403 mit der folgenden Meldung angezeigt wird, liegt möglicherweise ein Problem mit der Angabe des Ressourcenendpunkts in einem Skillset vor:

• "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 KI-Suche befindet, verwenden Sie eine schlüssellose Verbindung , um die Ressource anzufügen.

Fehler bei verwendung eines freigegebenen privaten Links

Wenn der Fehlercode 403 mit der folgenden Meldung angezeigt wird, stellt der Indexer möglicherweise über den öffentlichen Endpunkt eine Verbindung her statt über eine genehmigte freigegebene private Verbindung:

Unexpected error validating provided resource. {"error":{"code":"403","message":"Public access is disabled. Please configure private endpoint."}}

Dieser Fehler kann auftreten, wenn der Indexer nicht für die Verwendung der privaten Ausführungsumgebung konfiguriert ist. Vergewissern Sie sich, dass die freigegebene private Verbindung genehmigt ist, setzen Sie das executionEnvironment des Indexers auf private, und stellen Sie sicher, dass die Verbindung den richtigen Ressourcenendpunkt und die Gruppen-ID verwendet.

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

Verwenden Sie eine der folgenden Optionen, um Indexern den 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. Ausführliche Informationen zum Konfigurieren von IP-Adressbereichseinschränkungen für jeden Datenquellentyp 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 der folgenden Fehler erhalten:

• Stellen Sie sicher, dass Sie auf Ihre Quelle zugreifen können, indem Sie versuchen, direkt und nicht über den Suchdienst eine Verbindung damit herzustellen.
• Überprüfen Sie Ihre Ressource im Azure-Portal auf aktuelle Fehler oder Ausfälle.
• Suchen Sie nach Netzwerkausfällen im Azure Status.
• Überprüfen Sie, ob Sie ein öffentliches DNS für die Namensauflösung und keine Azure Privates DNS verwenden.

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 wird, setzt die erste Anmeldung von Ihrem Suchdienst die Datenbank automatisch fort, gibt jedoch einen Fehler zurück, der angibt, dass die Datenbank nicht verfügbar ist, was den Fehlercode 40613 angibt. 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. Wenn Sie eine Meldung erhalten, die besagt"Your sign-in was successful but your admin requires the device requesting access to be managed", blockiert wahrscheinlich eine Richtlinie für den bedingten Zugriff den Indexer aus der SharePoint-Dokumentbibliothek.

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 blockieren kann, enthält das Benutzerkonto, das Sie während des Indexerstellungsschritts im Abschnitt "Benutzer und Gruppen " authentifiziert 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
   • Legen Sie den Gerätestatus auf "Ja" fest.

4. Nachdem Sie bestätigt haben, welche Richtlinie den Indexer blockiert, nehmen Sie eine Ausnahme für den Indexer vor. 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 150.0.0.1 Sie einer eingehenden Regel in der Azure Storage Firewall hinzu. Es kann bis zu 15 Minuten dauern, bis die Firewalleinstellungen für den Suchdienstindexer aktualisiert wurden, um auf das Azure Storage Konto zuzugreifen.

   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.

   Sie können die IP-Adressbereiche für das AzureCognitiveSearch Diensttag über die Ermittlungs-API oder die herunterladbare JSON-Datei abrufen.

   Für diese Übung wird vorausgesetzt, dass der Suchdienst die Azure Public Cloud ist, die Azure öffentliche JSON-Datei herunterladen.

   

   In der JSON-Datei ist – unter der Annahme, dass sich der Suchdienst in „West Central US“ befindet – die Liste der IP-Adressen für die Ausführungsumgebung des mandantenfähigen Indexers 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=2026-04-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 der Suchdienst indiziert. Gelegentlich kann ein Dokument, das in der Datenquelle vorhanden ist, nicht in einem Suchindex angezeigt werden. Dieses unerwartete Ergebnis kann aus folgenden Gründen auftreten:

• Sie haben das Dokument aktualisiert, nachdem der Indexer ausgeführt wurde. 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 geändert und seine Artikulation im Suchindex unterscheidet sich von dem, was Sie erwarten.
• Änderungsnachverfolgungs-Werte sind fehlerhaft oder Voraussetzungen fehlen. Wenn ihr Wert für hohe Wasserzeichen ein Datum ist, das auf eine zukünftige Uhrzeit festgelegt ist, überspringt der Indexer alle Dokumente mit einem früheren Datum. Sie können den Änderungsnachverfolgungsstatus des Indexers mithilfe der initialTrackingState Felder finalTrackingState im Indexerstatus ermitteln. 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 müssen Sie den BLOB-Indexer so konfigurieren, dass sowohl Inhalt als auch Metadaten extrahiert werden:

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2026-04-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 KI-Suche ist implizit von der Azure Cosmos DB-Indizierung abhängig. Wenn Sie die automatische Indizierung in Azure Cosmos DB deaktivieren, gibt Azure KI-Suche 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. Diese Bedingung gilt für Datenquellen, die das Konzept von Spalten haben, z. B. Azure Cosmos DB.
• Wenn die Datenquellendefinition eine andere Abfrage aufweist als die, die Sie verwenden, um die Anzahl der Datensätze zu schätzen. Beispielsweise fragen Sie in Ihrer Datenbank die Anzahl der Datenbankdatensätze ab, während Sie in der Datenquellendefinitionsabfrage nur eine Teilmenge der zu indizierenden Datensätze auswählen.
• Die Anzahl wird in unterschiedlichen 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, was dazu führt, dass ein Indexer ein Dokument zwei oder mehr Mal indiziert. Daher ist die Anzahl der verarbeiteten Dokumente mehr als die tatsächliche Anzahl von Dokumenten in der Datenquelle. Dieses Verhalten wirkt sich nicht auf die im Index gespeicherten Daten aus, z. B. das Duplizieren von Dokumenten, nur, dass es länger dauern kann, um eine spätere Konsistenz zu erreichen. Diese Bedingung tritt besonders häufig auf, wenn eines der folgenden Kriterien zutrifft:

• On-Demand-Indexeranforderungen werden in schneller Folge ausgegeben.
• Die Topologie der Datenquelle enthält mehrere Replikate und Partitionen, z. B. die topologie, die in Konsistenzstufen in Azure Cosmos DB beschrieben wird.
• 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. Bei der On-Demand-Verarbeitung sollten Sie Ihre Anfragen in Abständen von mindestens fünf Minuten senden und den Indexer nach einem Zeitplan ausführen.

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

In der folgenden Zeitachse werden die Bedingungen erläutert, unter denen ein Dokument zweimal verarbeitet wird. Sie verzeichnet jede Aktion und Gegenaktion. Die folgende Zeitachse veranschaulicht das Problem:

In der Praxis tritt dieses Szenario nur auf, wenn Sie für bestimmte Datenquellen Indexer bei Bedarf manuell im Abstand von nur wenigen Minuten aufrufen. 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, geben einige Indexer in der Regel eine Warteschlange ein und warten vor dem Start auf verfügbare Ressourcen. Mehrere Faktoren bestimmen, wie viele Indexer gleichzeitig ausgeführt werden können. Wenn die Indexer keine Verknüpfung mit Skillsets herstellen, bestimmt die Anzahl der Replikate und Partitionen im AI-Suchdienst, wie viele Indexer parallel ausgeführt werden können.

Wenn Sie einen Indexer einem Skillset zuordnen, wird er innerhalb der internen AI Search-Cluster ausgeführt. Die Komplexität des Skillsets und die gleichzeitige Ausführung anderer Skillsets bestimmen, wie viele Indexer gleichzeitig ausgeführt werden können. Integrierte Indexer extrahieren zuverlässig Daten aus der Quelle, sodass keine Daten fehlen, wenn sie in einem Zeitplan ausgeführt werden. Die Indexerprozesse für die Parallelisierung und Skalierung benötigen jedoch einige Zeit, bis sie abgeschlossen sind.

Indizieren von Dokumenten mit Vertraulichkeitsbezeichnungen

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

Verwandte Inhalte

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