Ausführen oder Zurücksetzen von Indexern, Qualifikationen oder Dokumenten

In Azure KI-Suche können Sie einen Indexer auf verschiedene Arten ausführen:

• Direkt bei der Indexerstellung ausführen. Diese Option ist die Standardeinstellung, es sei denn, Sie erstellen den Indexer in einem deaktivierten Zustand.
• Führen Sie einen Zeitplan aus, um die Ausführung in regelmäßigen Abständen aufzurufen. Wenn ein geplanter Indexer nicht mehr ausgelöst wird, finden Sie unter FAQ zum Planungsverhalten Schritte zur Wiederherstellung.
• Bei Bedarf mit oder ohne Reset ausführen.

Dieser Artikel erläutert das Ausführen von Indexern bei Bedarf, mit und ohne Zurücksetzen. Außerdem werden die Ausführung des Indexierers, die Dauer und die Parallelität beschrieben.

Herstellen einer Verbindung zwischen Indexern und Azure Ressourcen

Indexer sind eines der wenigen Subsysteme, die ausgehende Anrufe an andere Azure Ressourcen tätigen. Abhängig von der externen Datenquelle können Sie Schlüssel oder Rollen verwenden, um die Verbindung zu authentifizieren.

In Bezug auf Azure Rollen verfügen Indexer nicht über separate Identitäten: Eine Verbindung von der Suchmaschine zu einer anderen Azure Ressource verwendet das System oder die vom Benutzer zugewiesene verwaltete Identität eines Suchdiensts sowie eine Rollenzuweisung für das Ziel Azure Ressource. Wenn der Indexer eine Verbindung mit einer Azure-Ressource in einem virtuellen Netzwerk herstellt, sollten Sie für diese Verbindung eine gemeinsame private Verbindung erstellen.

Ausführung des Indexers

Ein Suchdienst führt einen Indexerauftrag pro Sucheinheit aus. Jeder Suchdienst beginnt mit einer Sucheinheit, aber jede neue Partition oder jedes Replikat erhöht die Sucheinheiten Ihres Diensts. Sie können die Anzahl der Sucheinheiten im Abschnitt "Essential" des Azure Portals auf der Seite Overview überprüfen. Wenn Sie gleichzeitige Verarbeitung benötigen, stellen Sie sicher, dass Ihre Sucheinheiten ausreichende Replikate enthalten. Indexer werden nicht im Hintergrund ausgeführt, sodass sie möglicherweise mehr Abfrageeinschränkung erleben als üblich, wenn der Dienst unter Druck steht.

Der folgende Screenshot zeigt die Anzahl der Sucheinheiten, die bestimmt, wie viele Indexer gleichzeitig ausgeführt werden können.

Nachdem die Indizierungsausführung gestartet wurde, können Sie sie nicht anhalten oder beenden. Die Indizierungsausführung wird beendet, wenn keine Dokumente geladen oder aktualisiert werden müssen, oder wenn die maximale Laufzeitgrenze erreicht ist.

Sie können mehrere Indexer gleichzeitig ausführen, wobei ausreichend Kapazität vorausgesetzt wird, aber jeder Indexer selbst ist eine Einzelinstanz. Das Starten einer neuen Instanz, während der Indexer bereits ausgeführt wird, führt zu diesem Fehler: "Failed to run indexer "<indexer name>" error: "Another indexer invocation is currently in progress; concurrent invocations are not allowed."

Indexerausführungsumgebung

Ein Indexerauftrag wird in einer verwalteten Ausführungsumgebung ausgeführt. Derzeit gibt es zwei Umgebungen:

• Eine private Ausführungsumgebung wird auf Suchclustern ausgeführt, die für Ihren Suchdienst spezifisch sind.

• Eine mehrinstanzenfähige Umgebung verfügt über Inhaltsprozessoren, die Microsoft ohne zusätzliche Kosten verwalten und sichern. In dieser Umgebung werden rechenintensive Verarbeitungen ausgelagert, sodass dienstspezifische Ressourcen für Routinevorgänge verfügbar bleiben. Die meisten Skillsets werden nach Möglichkeit in der Mehrinstanzenumgebung ausgeführt. Diese Umgebung ist die Standardeinstellung.

  Rechenintensive Verarbeitung bezieht sich auf Skillsets, die auf Inhaltsprozessoren und Indexeraufträgen ausgeführt werden, die eine große Menge von Dokumenten oder Dokumenten einer großen Größe verarbeiten. Heuristiken und Systeminformationen bestimmen die Verarbeitung ohne spezifische Fähigkeiten auf den mehrmandantenfähigen Inhaltsverarbeitern, was nicht der Kontrolle des Kunden unterliegt.

Sie können die Verwendung der Mehrinstanzenumgebung für Standard2 oder höhere Dienste verhindern, indem Sie die Indexer- und Skillset-Verarbeitung ausschließlich Ihren Suchclustern zuordnen. Legen Sie den executionEnvironment Parameter in der Indexerdefinition fest, um immer einen Indexer in der privaten Ausführungsumgebung auszuführen.

IP-Firewalls blockieren die Mehrinstanzenumgebung . Wenn Sie also über eine Firewall verfügen, erstellen Sie eine Regel , die Multitenantprozessorverbindungen zulässt.

Die Indizierungsgrenzwerte variieren für jede Umgebung:

¹ Sucheinheiten können flexible Kombinationen von Partitionen und Replikaten sein, aber Indexeraufträge sind nicht an einen oder den anderen gebunden. Anders ausgedrückt: Wenn Sie über 12 Einheiten verfügen, können Sie 12 Indexeraufträge gleichzeitig in privater Ausführung ausführen, unabhängig davon, wie die Sucheinheiten bereitgestellt werden.

² Wenn mehr als zwei Stunden erforderlich sind, um alle Daten zu verarbeiten, aktivieren Sie die Änderungserkennung , und planen Sie die Ausführung des Indexers in 5-Minuten-Intervallen, um die Indizierung schnell fortzusetzen, wenn sie aufgrund eines Timeouts beendet wird. Weitere Strategien finden Sie unter "Indizieren eines großen Datasets ".

³ "Unbestimmt" bedeutet, dass der Grenzwert nicht durch die Anzahl der Arbeitsplätze quantifiziert wird. Einige Workloads, z. B. die Verarbeitung von Skillset, können parallel ausgeführt werden, was zu vielen Aufträgen führen kann, obwohl nur ein Indexer beteiligt ist. Obwohl in der Umgebung keine Einschränkungen festgelegt werden, gelten die Indizierungsgrenzwerte für Ihren Suchdienst weiterhin.

Ausführen ohne Zurücksetzen

Ein Run Indexer-Vorgang erkennt und verarbeitet nur das, was er zum Synchronisieren des Suchindex mit Änderungen in der zugrunde liegenden Datenquelle benötigt. Die inkrementelle Indizierung beginnt damit, eine interne High-Water-Marke zu ermitteln, um das zuletzt aktualisierte Suchdokument zu finden. Dieses Dokument wird zum Ausgangspunkt für die Ausführung des Indexers für neue und aktualisierte Dokumente in der Datenquelle.

Die Änderungserkennung ist wichtig, um zu bestimmen, was in der Datenquelle neu ist oder aktualisiert wird. Indexer verwenden die Änderungserkennungsfunktionen der zugrunde liegenden Datenquelle, um zu bestimmen, was in der Datenquelle neu oder aktualisiert wird.

• Azure Storage verfügt über die integrierte Änderungserkennung über die LastModified-Eigenschaft.

• Andere Datenquellen, z. B. Azure SQL oder Azure Cosmos DB, erfordern eine Konfiguration für die Änderungserkennung, bevor der Indexer neue und aktualisierte Zeilen lesen kann.

Wenn der zugrunde liegende Inhalt unverändert ist, hat ein Ausführungsvorgang keine Auswirkung. In diesem Fall gibt der Indexerausführungsverlauf dokumente 0\0 an, die verarbeitet wurden.

Um alle Dokumente erneut zu verarbeiten, müssen Sie den Indexer zurücksetzen.

Zurücksetzen von Indexern

Nach der ersten Ausführung verfolgt ein Indexer, welche Suchdokumente über einen internen Schwellenwert indiziert werden. Die Markierung ist nicht zugänglich, aber intern weiß der Indexer, wo er zuletzt aufgehört hat.

Um den gesamten oder einen Teil eines Indexes neu zu erstellen, verwenden Sie reset-APIs, die auf niedrigeren Ebenen in der Objekthierarchie verfügbar sind:

• Das Zurücksetzen von Indizierern löscht die obere Grenze und führt eine vollständige Neuindizierung aller Dokumente durch
• Resync Indexers (Vorschau) führt eine effiziente teilweise Neuindizierung aller Dokumente durch.
• Das Zurücksetzen von Dokumenten (Vorschau) indiziert ein bestimmtes Dokument oder eine Liste von Dokumenten neu.
• Das Zurücksetzen von Skills (Vorschauversion) ruft die Skillverarbeitung für einen bestimmten Skill auf.

Folgen Sie nach dem Zurücksetzen dem Befehl "Ausführen", um neue und vorhandene Dokumente erneut zu verarbeiten. Sie können verwaiste Suchdokumente, die kein Gegenstück in der Datenquelle haben, nicht durch Zurücksetzen und erneutes Ausführen entfernen. Informationen zum Löschen bestimmter Dokumente finden Sie unter "Löschen von Dokumenten in einem Suchindex " oder " Dokumente – Index".

Wie man Indexer zurücksetzt und ausführt

Zurücksetzen löscht den Höchstwert. Alle Dokumente im Suchindex werden zur vollständigen Überschreibung gekennzeichnet, ohne Inline-Aktualisierungen oder Zusammenführung in vorhandene Inhalte. Bei Indexern mit einem Skillset und einer Anreicherungszwischenspeicherung (Vorschau) wird durch das Zurücksetzen des Index auch das Skillset implizit zurückgesetzt.

Die eigentliche Arbeit beginnt erst, wenn Sie nach dem Zurücksetzen einen Ausführungsbefehl ausführen:

• Alle neuen Dokumente, die die zugrunde liegende Quelle gefunden haben, werden dem Suchindex hinzugefügt.
• Alle Dokumente, die sowohl in der Datenquelle als auch im Suchindex vorhanden sind, werden im Suchindex überschrieben.
• Alle aus Skillsets erstellten erweiterten Inhalte werden neu erstellt. Der Anreicherungscache( sofern aktiviert) wird aktualisiert.

Wie bereits erwähnt, ist das Zurücksetzen ein passiver Vorgang: Sie müssen einer Run-Anforderung folgen, um den Index neu zu erstellen.

Zurücksetzungs-/Ausführungsvorgänge gelten für einen Suchindex oder einen Wissensspeicher, für bestimmte Dokumente oder Projektionen und für zwischengespeicherte Anreicherungen, wenn eine Zurücksetzung explizit oder implizit Skills enthält.

Das Zurücksetzen gilt auch für Erstellungs- und Aktualisierungsvorgänge. Das Löschen oder Bereinigen verwaister Dokumente im Suchindex wird nicht ausgelöst. Weitere Informationen zum Löschen von Dokumenten finden Sie unter "Dokumente – Index".

Das Zurücksetzen kann nicht rückgängig gemacht werden.

POST /indexers/[indexer name]/reset?api-version=[api-version]

POST /indexers/[indexer name]/run?api-version=[api-version]

GET /indexers/[indexer name]/status?api-version=[api-version]

// Reset the indexer if it already exists
try
{
    await indexerClient.GetIndexerAsync(blobIndexer.Name);
    //Rest the indexer if it exsits.
    await indexerClient.ResetIndexerAsync(blobIndexer.Name);
}
catch (RequestFailedException ex) when (ex.Status == 404) { }

await indexerClient.CreateOrUpdateIndexerAsync(blobIndexer);

// Run indexer
Console.WriteLine("Running Blob Storage indexer...\n");

try
{
    await indexerClient.RunIndexerAsync(blobIndexer.Name);
}
catch (RequestFailedException ex) when (ex.Status == 429)
{
    Console.WriteLine("Failed to run indexer: {0}", ex.Message);
}

So setzen Sie Kompetenzen zurück (Vorschau)

Die Anforderung zum Zurücksetzen von Skills bewirkt, dass beim nächsten Indexerdurchlauf gezielt ein oder mehrere Skills verarbeitet werden. Für Indexer, die über Skillsets verfügen, können Sie individuelle Skills zurücksetzen, um die Verarbeitung dieses und aller nachgelagerten Skills zu erzwingen, die von der Ausgabe abhängen. Wenn Sie den Anreicherungscache aktiviert haben, wird er durch die Anfrage ebenfalls aktualisiert.

Für Indexer, die das Zwischenspeichern aktiviert haben, können Sie explizit die Verarbeitung für Qualifikationsupdates anfordern, die der Indexer nicht erkennen kann. Wenn Sie beispielsweise externe Änderungen vornehmen, z. B. Überarbeitungen an einer benutzerdefinierten Fähigkeit, verwenden Sie diese API, um die Fähigkeit erneut auszuführen. Der Prozess aktualisiert Ausgaben, z. B. einen Wissensspeicher oder Suchindex, indem wiederverwendbare Daten aus dem Cache und neue Inhalte pro aktualisierter Fähigkeit verwendet werden.

Verwenden Sie die neueste Vorschau-API.

POST /skillsets/[skillset name]/resetskills?api-version=2026-08-01-preview
{
    "skillNames" : [
        "#1",
        "#5",
        "#6"
    ]
}

Sie können einzelne Fähigkeiten angeben, wie im vorherigen Beispiel gezeigt, aber wenn eines dieser Fähigkeiten ausgaben von nicht aufgelisteten Fähigkeiten (#2 bis #4) erfordert, führt der Prozess nicht aufgelistete Fähigkeiten aus, es sei denn, der Cache kann die erforderlichen Informationen bereitstellen. Damit diese Bedingung erfüllt ist, dürfen zwischengespeicherte Anreicherungen für Skills #2 bis #4 nicht von #1 abhängen (zum Zurücksetzen aufgeführt).

Wenn Sie keine Fähigkeiten angeben, führt der Prozess das gesamte Skillset aus und aktualisiert, wenn die Zwischenspeicherung aktiviert ist, auch den Cache.

Denken Sie daran, die Nachverfolgung mit Run Indexer durchzuführen, um die tatsächliche Verarbeitung aufzurufen.

Dokumente zurücksetzen (Vorschau)

Die Indexer - Reset Docs (Preview) -API akzeptiert eine Liste von Dokumentschlüsseln, damit Sie bestimmte Dokumente aktualisieren können. Wenn Sie die Zurücksetzungsparameter angeben, bestimmen sie nur, was verarbeitet wird, unabhängig von anderen Änderungen in den zugrunde liegenden Daten. Wenn beispielsweise 20 Blobs seit der letzten Indizierungsausführung hinzugefügt oder aktualisiert wurden, Sie jedoch nur ein Dokument zurücksetzen, verarbeitet der Indexer nur dieses Dokument.

Auf Dokumentbasis aktualisiert der Indexer alle Felder im Suchdokument mit Werten und Metadaten aus der Datenquelle. Sie können nicht auswählen, welche Felder aktualisiert werden sollen.

Wenn die Datenquelle Azure Data Lake Storage (ADLS) Gen2 ist und die Blobs Berechtigungsmetadaten zugeordnet sind, erfasst der Indexer diese Berechtigungen im Suchindex erneut, wenn sich Berechtigungen in den zugrunde liegenden Daten ändern. Weitere Informationen finden Sie unter Erneutes Indizieren von ACL- und RBAC-Bereich mit ADLS Gen2-Indexern.

Wenn Sie das Dokument durch ein Skillset erweitern und über zwischengespeicherte Daten verfügen, ruft der Indexer das Skillset für nur die angegebenen Dokumente auf und aktualisiert den Cache für die neu verarbeiteten Dokumente.

Wenn Sie diese API zum ersten Mal testen, können Sie die folgenden APIs beim Überprüfen und Testen der Verhaltensweisen unterstützen. Verwenden Sie die neueste Vorschau-API.

1. Rufen Sie Indexer – Status abrufen mit einer Vorschau-API-Version auf, um den Reset-Status und den Ausführungsstatus zu überprüfen. Informationen zur Zurücksetzungsanforderung finden Sie am Ende der Statusantwort.

2. Rufen Sie Indexers - Docs zurücksetzen mit einer Vorschau-API-Version auf, um die zu verarbeitenden Dokumente festzulegen.

   POST https://[service name].search.windows.net/indexers/[indexer name]/resetdocs?api-version=2026-08-01-preview
   {
       "documentKeys" : [
           "1001",
           "4452"
       ]
   }
   

   • Die API akzeptiert zwei Arten von Dokumentbezeichnern als Eingabe: Dokumentschlüssel, die Dokumente in einem Suchindex eindeutig identifizieren, sowie Dokumentbezeichner für Datenquellen, die Dokumente in einer Datenquelle eindeutig identifizieren. Der Textkörper sollte entweder eine Liste von Dokumentschlüsseln oder eine Liste von Datenquellendokumentbezeichnern enthalten, nach denen der Indexer in der Datenquelle sucht. Durch Aufrufen der API werden die Dokumentschlüssel oder Datenquellendokumentbezeichner hinzugefügt, um sie auf die Indizierermetadaten zurückzusetzen. Bei der nächsten geplanten oder bei Bedarf erfolgenden Ausführung des Indexers verarbeitet der Indexer nur noch die zurückgesetzten Dokumente.

   • Wenn Sie Dokumentschlüssel zum Zurücksetzen von Dokumenten verwenden und auf Ihre Dokumentschlüssel in einer Indexerfeldzuordnung verwiesen wird, verwendet der Indexer die Feldzuordnung, um das entsprechende Feld in der zugrunde liegenden Datenquelle zu finden.

   • Die dokumentschlüssel, die Sie in der Anforderung angeben, sind Werte aus dem Suchindex, die sich von den entsprechenden Feldern in der Datenquelle unterscheiden können. Wenn Sie sich nicht sicher sind, ob der Schlüsselwert vorhanden ist, senden Sie eine Abfrage , um den Wert zurückzugeben. Sie können select verwenden, um nur das Dokumentschlüsselfeld zurückzugeben.

   • Für Blobs, die der Indizierer in mehrere Suchdokumente parst (wobei parsingMode auf jsonLines oder jsonArrays oder delimitedText festgelegt ist), generiert der Indizierer den Dokumentschlüssel, und dieser ist Ihnen möglicherweise nicht bekannt. In diesem Szenario gibt eine Abfrage für den Dokumentschlüssel den richtigen Wert zurück.

   • Wenn der Indexer nicht mehr versuchen soll, Reset-Dokumente zu verarbeiten, setzen Sie "documentKeys" oder "datasourceDocumentIds" auf eine leere Liste []. Diese Aktion führt dazu, dass der Indexer die reguläre Indizierung basierend auf dem Wasserzeichen fortsetzen kann. Ungültige Dokumentschlüssel oder Dokumentschlüssel, die nicht vorhanden sind, werden ignoriert.

3. Rufen Sie "Run Indexer " (beliebige API-Version) auf, um die von Ihnen angegebenen Dokumente zu verarbeiten. Der Indexer indiziert nur die spezifischen Dokumente.

4. Rufen Sie "Run Indexer" ein zweites Mal auf, um die Verarbeitung ab dem letzten Stand fortzusetzen.

5. Rufen Sie "Dokumente durchsuchen" auf, um nach aktualisierten Werten zu suchen und um Dokumentschlüssel zurückzugeben, wenn Sie sich nicht sicher über den Wert sind. Verwenden Sie "select": "<field names>", um einzuschränken, welche Felder in der Antwort angezeigt werden.

Überschreiben Sie die Liste der Dokumentschlüssel

Wenn Sie die API zum Zurücksetzen von Dokumenten mehrmals mit unterschiedlichen Schlüsseln aufrufen, werden die neuen Schlüssel zur Liste der Zurücksetzungsschlüssel hinzugefügt. Wenn Sie die API aufrufen, wobei der overwrite Parameter auf "true" festgelegt ist, wird die aktuelle Liste durch das neue ersetzt:

POST https://[service name].search.windows.net/indexers/[indexer name]/resetdocs?api-version=2026-08-01-preview
{
    "documentKeys" : [
        "200",
        "630"
    ],
    "overwrite": true
}

So wird's: Erneutes Synchronisieren von Indexern (Vorschau)

Resync Indexers ist eine Vorschau-REST-API, die eine teilweise Neuindizierung aller Dokumente durchführt. Ein Indexer wird als mit seiner Datenquelle synchronisiert, wenn bestimmte Felder aller Dokumente im Zielindex mit den Daten in der Datenquelle konsistent sind. In der Regel erreicht ein Indexer die Synchronisierung nach einer erfolgreichen ersten Ausführung. Wenn Sie ein Dokument aus der Datenquelle löschen, bleibt der Indexer gemäß dieser Definition synchronisiert. Während der nächsten Indizierung wird das entsprechende Dokument im Zielindex jedoch entfernt, wenn die Löschnachverfolgung aktiviert ist.

Wenn Sie ein Dokument in der Datenquelle ändern, wird der Indexer nicht synchronisiert. Im Allgemeinen synchronisieren Änderungsverfolgungsmechanismen den Indexer bei der nächsten Ausführung neu. In Azure Storage wird beispielsweise beim Ändern eines Blobs dessen letzte Änderungszeit aktualisiert, sodass der Indexer es beim nächsten Indexerlauf neu indizieren kann, weil die aktualisierte Zeit die von der vorherigen Ausführung festgelegte Höchstmarke überschreitet.

Im Gegensatz dazu führt bei bestimmten Datenquellen wie ADLS Gen2 das Ändern der Zugriffssteuerungslisten (ACLs) eines Blobs nicht dazu, dass sich der Zeitpunkt der letzten Änderung ändert, sodass die Änderungsnachverfolgung unwirksam ist, wenn ACLs erfasst werden sollen. Folglich wird der geänderte Blob nicht erneut in der nachfolgenden Ausführung indiziert, da nur Dokumente bearbeitet werden, die nach der letzten Höchstmarke geändert wurden.

Während die Verwendung von "Reset" oder "Reset docs" dieses Problem beheben kann, kann "Reset" zeitaufwändig und ineffizient für große Datasets sein, und "Dokumente zurücksetzen" erfordert, dass der Dokumentschlüssel des Blobs identifiziert wird, das Sie aktualisieren möchten.

Resync Indexers bietet eine effiziente und bequeme Alternative. Sie platzieren den Indexer einfach im Resync-Modus und geben den Inhalt an, der neu synchronisiert werden soll, indem Sie die API für resynchrone Indexer aufrufen. Im nächsten Ausführen prüft der Indexer nur den relevanten Teil der Daten in der Quelle und vermeidet unnötige Verarbeitung, die nicht mit den angegebenen Daten verknüpft ist. Es fragt auch die vorhandenen Dokumente im Zielindex ab und aktualisiert nur die Dokumente, die Abweichungen zwischen der Datenquelle und dem Zielindex anzeigen. Nach der resync-Ausführung wird der Indexer synchronisiert und wird für nachfolgende Ausführungen in den regulären Ausführungsmodus des Indexers zurückgesetzt.

Erneute Synchronisierung und Ausführen von Indexern

1. Rufen Sie Indexers - Resync mit einer Vorschau-API-Version auf, um anzugeben, welche Inhalte erneut synchronisiert werden sollen.

   POST https://[service name].search.windows.net/indexers/[indexer name]/resync?api-version=2026-08-01-preview
   {
       "options" : [
           "permissions"
       ]
   }
   

   • Das options Feld ist erforderlich. Derzeit ist permissionsdie einzige unterstützte Option . Das heißt, nur Berechtigungsfilterfelder im Zielindex werden aktualisiert.

2. Rufen Sie "Run Indexer " (beliebige API-Version) auf, um den Indexer erneut zu synchronisieren.

3. Rufen Sie "Run Indexer" ein zweites Mal auf, um die Verarbeitung ab dem letzten Stand fortzusetzen.

Überprüfen des Zurücksetzungsstatus „currentState“

Führen Sie die folgenden Schritte aus, um den Zurücksetzungsstatus zu überprüfen und zu sehen, welche Dokumentschlüssel zur Verarbeitung in der Warteschlange stehen:

1. Rufen Sie Get Indexer Status mithilfe einer Vorschau-API auf.

   Die Vorschau-API gibt den currentState Abschnitt zurück, der am Ende der Antwort gefunden wurde.

   "currentState": {
       "mode": "indexingResetDocs",
       "allDocsInitialTrackingState": "{\"LastFullEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"LastAttemptedEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"NameHighWaterMark\":null}",
       "allDocsFinalTrackingState": "{\"LastFullEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"LastAttemptedEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"NameHighWaterMark\":null}",
       "resetDocsInitialTrackingState": null,
       "resetDocsFinalTrackingState": null,
       "resyncInitialTrackingState": null,
       "resyncFinalTrackingState": null,
       "resetDocumentKeys": [
           "200",
           "630"
       ]
   }
   

2. Überprüfen Sie den "Modus":

   Legen Sie für Reset Skills „mode“ auf indexingAllDocs fest, da potenziell alle Dokumente betroffen sind, hinsichtlich der Felder, die durch die KI-Anreicherung aufgefüllt werden.

   Legen Sie für Resync Indexers "mode" auf indexingResync. Der Indexer überprüft alle Dokumente und konzentriert sich auf interessierte Daten in der Datenquelle und interessierte Felder im Zielindex.

   Setzen Sie für „Reset Documents“ „mode“ auf indexingResetDocs. Der Indexer behält diesen Status bei, bis er alle Dokumentschlüssel verarbeitet hat, die im Aufruf von „reset documents“ angegeben wurden. Während dieser Zeit werden keine anderen Indizierungseinzelvorgänge ausgeführt, solange der Vorgang läuft. Zum Auffinden aller Dokumente in der Liste der Dokumentschlüssel ist es erforderlich, jedes Dokument zu knacken, um nach dem Schlüssel zu suchen und abzugleichen. Dieser Vorgang kann eine Weile dauern, wenn der Datensatz groß ist. Wenn ein Blobcontainer Hunderte von Blobs enthält und die Dokumente, die Sie zurücksetzen möchten, am Ende liegen, findet der Indexer die übereinstimmenden Blobs erst, wenn alle anderen zuerst überprüft werden.

3. Nachdem der Indexer die Dokumente erneut verarbeitet hat, führen Sie „Get Indexer Status“ erneut aus. Der Indexer kehrt in den indexingAllDocs Modus zurück und verarbeitet alle neuen oder aktualisierten Dokumente bei der nächsten Ausführung.

Überprüfen des Indexerlaufzeitkontingents für S3 HD- und Serverlose Suchdienste

Dieser Abschnitt bezieht sich auf Standard 3 High Density (S3 HD) und Serverless Search Services. Aggregiertes Kontingentverhalten und Planungsleitfaden finden Sie unter Indexerausführung auf Serverless und S3 HD (Vorschau).

Jede Indexerstellungsausführung hat ein Maximum von zwei Stunden. Separat teilen alle Indexer 24 Stunden kumulierte Laufzeit pro Dienst in jedem 24-Stunden-UTC-Fenster.

Damit Sie die Laufzeiten des Indexers im Verhältnis zum 24-Stunden-Fenster überwachen können, stellen Get Service Statistics und Get Indexer Status nun mehr Informationen als Rückmeldung bereit.

Kumuliertes Laufzeitkontingent nachverfolgen

Verfolgen Sie die kumulative Indexerlaufzeit eines Suchdiensts und bestimmen Sie, wie viel Laufzeitkontingent im aktuellen 24-Stunden-Fenster übrig bleibt.

Senden Sie eine GET-Anforderung an den Suchdienstendpunkt. Hilfe zum Einrichten eines REST-Clients und zum Abrufen eines Zugriffstokens finden Sie unter Herstellen einer Verbindung mit einem Suchdienst.

GET {{search-endpoint}}/servicestats?api-version=2026-08-01-preview
  Content-Type: application/json
  Authorization: Bearer {{accessToken}}

Antworten umfassen indexersRuntime Eigenschaften, die die Start- und Endzeiten des Fensters anzeigen, kumulative Sekunden, die von allen Indexern verwendet werden, und Sekunden, die für den Dienst verbleiben.

Laufzeitkontingent des Indexers überwachen

Gibt dieselben Informationen für einen einzelnen Indexer zurück.

GET {{search-endpoint}}/indexers/hotels-sample-indexer/search.status?api-version=2026-08-01-preview
  Content-Type: application/json
  Authorization: Bearer {{accessToken}}

Zu den Antworten gehören runtime Eigenschaften, die die Start- und Endzeiten des Fensters anzeigen, Sekunden, die vom Indexer verwendet werden, und Sekunden, die für alle Indexer im Dienst verbleiben.

Nächste Schritte

Reset-APIs werden verwendet, um den Umfang der nächsten Indexerausführung festzulegen. Zur eigentlichen Verarbeitung müssen Sie eine bedarfsgesteuerte Indiziererausführung aufrufen oder einen geplanten Einzelvorgang zum Abschließen der Arbeit zulassen. Nach Abschluss des Durchlaufs kehrt der Indexer zur normalen Verarbeitung zurück, sei es zeitgesteuerte oder bedarfsorientierte Verarbeitung.

Nachdem Sie Indexeraufträge zurückgesetzt und erneut ausgeführt haben, können Sie den Status des Suchdiensts überwachen oder detaillierte Informationen über die Ressourcenprotokollierung abrufen.

• Überwachen des Suchindexerstatus
• Sammeln und Analysieren von Protokolldaten
• Einen Indexer planen