Exécuter ou réinitialiser des indexeurs, des compétences ou des documents

Dans Recherche Azure AI, vous pouvez exécuter un indexeur de plusieurs façons :

• Exécutez immédiatement lors de la création de l’indexeur. Cette option est la valeur par défaut, sauf si vous créez l’indexeur dans un état désactivé.
• Fonctionner selon un calendrier pour déclencher l’exécution à intervalles réguliers. Si un indexeur planifié cesse de déclencher, consultez la FAQ sur le comportement de planification pour connaître les étapes de récupération.
• Exécutez à la demande, avec ou sans réinitialisation.

Cet article explique comment exécuter des indexeurs à la demande, avec et sans réinitialisation. Il décrit également l’exécution, la durée et la concurrence de l’indexeur.

Comment les indexeurs se connectent à des ressources Azure

Les indexeurs sont l'un des rares sous-systèmes qui effectuent des appels sortants ouverts vers d'autres ressources Azure. Selon la source de données externe, vous pouvez utiliser des clés ou des rôles pour authentifier la connexion.

En termes de rôles Azure, les indexeurs n'ont pas d'identités distinctes : une connexion du moteur de recherche à une autre ressource Azure utilise l'identité managée affectée par le système ou l'utilisateur d'un service de recherche, ainsi qu'une attribution de rôle sur la ressource Azure cible. Si l’indexeur se connecte à une ressource Azure sur un réseau virtuel, vous devez créer une liaison privée shared pour cette connexion.

Exécution de l’indexeur

Un service de recherche exécute un travail d’indexeur par unité de recherche. Chaque service de recherche commence par une unité de recherche, mais chaque nouvelle partition ou réplica augmente les unités de recherche de votre service. Vous pouvez vérifier le nombre d'unités de recherche dans la section Essential du portail Azure de la page Overview. Si vous avez besoin d’un traitement simultané, assurez-vous que vos unités de recherche incluent des réplicas suffisants. Les indexeurs ne s’exécutent pas en arrière-plan. Vous pouvez donc rencontrer plus de limitation des requêtes que d’habitude si le service est sous pression.

La capture d’écran suivante montre le nombre d’unités de recherche, qui détermine le nombre d’indexeurs pouvant s’exécuter simultanément.

Une fois l’exécution de l’indexeur démarrée, vous ne pouvez pas la suspendre ou l’arrêter. L’exécution de l’indexeur s’arrête lorsqu’il n’y a plus de documents à charger ou à actualiser, ou lorsque la limite maximale d’exécution est atteinte.

Vous pouvez exécuter plusieurs indexeurs à la fois en supposant une capacité suffisante, mais chaque indexeur lui-même est une seule instance. Le démarrage d’une nouvelle instance pendant que l’indexeur est déjà en cours d’exécution génère cette erreur : "Failed to run indexer "<indexer name>" error: "Another indexer invocation is currently in progress; concurrent invocations are not allowed."

Environnement d’exécution de l’indexeur

Un travail d’indexeur s’exécute dans un environnement d’exécution managé. Actuellement, il existe deux environnements :

• Un environnement d’exécution privée s’exécute sur des clusters de recherche spécifiques à votre service de recherche.

• Un environnement multilocataire dispose de processeurs de contenu qui Microsoft gère et sécurise sans frais supplémentaires. Cet environnement décharge le traitement nécessitant beaucoup de ressources de calcul, de sorte que les ressources spécifiques au service restent disponibles pour les opérations de routine. Dans la mesure du possible, la plupart des compétences s’exécutent dans l’environnement mutualisé. Cet environnement est la valeur par défaut.

  Le traitement nécessitant beaucoup de ressources fait référence à des ensembles de compétences s’exécutant sur des processeurs de contenu et des travaux d’indexeur qui traitent un volume élevé de documents ou de documents d’une grande taille. Les heuristiques et les informations système déterminent le traitement hors jeu de compétences sur les processeurs de contenu mutualisés, et celui-ci n’est pas contrôlé par le client.

Vous pouvez empêcher l’utilisation de l’environnement mutualisé sur les services Standard2 ou supérieurs en épinglant un indexeur et un traitement d’ensemble de compétences exclusivement à vos clusters de recherche. Définissez le executionEnvironment paramètre dans la définition de l’indexeur pour qu’il exécute toujours un indexeur dans l’environnement d’exécution privée.

Les pare-feu IP bloquent l’environnement multilocataire. Par conséquent, si vous disposez d’un pare-feu, créez une règle qui autorise les connexions de processeur multilocataire.

Les limites d’indexeur varient pour chaque environnement :

¹ Les unités de recherche peuvent être des combinaisons flexibles de partitions et de réplicas, mais les travaux d’indexation ne sont pas liés les uns aux autres. En d’autres termes, si vous avez 12 unités, vous pouvez avoir 12 travaux d’indexeur s’exécutant simultanément dans l’exécution privée, quelle que soit la façon dont les unités de recherche sont déployées.

² Si plus de deux heures sont nécessaires pour traiter toutes les données, activez la détection des modifications et planifiez l’exécution de l’indexeur à intervalles de 5 minutes pour reprendre l’indexation rapidement si elle s’arrête en raison d’un délai d’expiration. Pour plus de stratégies, consultez Indexation d’un jeu de données volumineux .

³ « Indéterminé » signifie que la limite n’est pas quantifiée par le nombre d’emplois. Certaines charges de travail, telles que le traitement des ensembles de compétences, peuvent s’exécuter en parallèle, ce qui peut entraîner de nombreux travaux même si un seul indexeur est impliqué. Bien que l’environnement n’impose pas de contraintes, les limites d’indexeur pour votre service de recherche s’appliquent toujours.

Exécuter sans réinitialisation

Une opération Run Indexer détecte et traite uniquement ce qu’il doit synchroniser l’index de recherche avec les modifications apportées à la source de données sous-jacente. L’indexation incrémentielle commence par localiser un repère interne de niveau haut afin de trouver le dernier document de recherche mis à jour. Ce document devient le point de départ de l’exécution de l’indexeur sur les documents nouveaux et mis à jour dans la source de données.

La détection des modifications est essentielle pour déterminer les nouveautés ou mises à jour dans la source de données. Les indexeurs utilisent les fonctionnalités de détection des modifications de la source de données sous-jacente pour déterminer les nouveautés ou mises à jour dans la source de données.

• stockage Azure a une détection de modification intégrée par le biais de sa propriété LastModified.

• D’autres sources de données, telles que Azure SQL ou Azure Cosmos DB, nécessitent une configuration pour la détection des modifications avant que l’indexeur puisse lire les lignes nouvelles et mises à jour.

Si le contenu sous-jacent n’est pas modifié, une opération d’exécution n’a aucun effet. Dans ce cas, l’historique d’exécution de l’indexeur indique les 0\0 documents traités.

Pour retraiter tous les documents, vous devez réinitialiser l’indexeur.

Réinitialiser les indexeurs

Après l’exécution initiale, un indexeur effectue le suivi des documents de recherche indexés via un marqueur de niveau élevé interne. Le marqueur n’est pas exposé, mais en interne, l’indexeur sait où il s’est arrêté pour la dernière fois.

Pour reconstruire tout ou partie d’un index, utilisez les API Reset disponibles à des niveaux décroissants dans la hiérarchie d’objets :

• Réinitialiser les indexeurs efface le point de repère supérieur et effectue une réindexation complète de tous les documents.
• Resynchroniser les indexeurs (aperçu) effectue une réindexation partielle efficace de tous les documents.
• Réinitialiser les documents (préversion) réindexe un document ou une liste spécifique de documents.
• Réinitialiser les compétences (préversion) appelle le traitement des compétences pour une compétence spécifique.

Après la réinitialisation, suivez une commande Run pour retraiter les documents nouveaux et existants. Vous ne pouvez pas supprimer les documents de recherche orphelins sans correspondance dans la source de données en réinitialisant puis en exécutant. Pour supprimer des documents spécifiques, consultez Supprimer des documents dans un index de recherche ou des documents - Index.

Comment réinitialiser et exécuter des indexeurs

Réinitialiser efface le seuil maximal. Tous les documents de l’index de recherche sont marqués pour un remplacement complet, sans mises à jour inline ni fusion dans du contenu existant. Pour les indexeurs dotés d’un ensemble de compétences et d’une mise en cache de l’enrichissement (version préliminaire), la réinitialisation de l’index réinitialise implicitement l’ensemble de compétences.

Le travail réel se produit lorsque vous suivez une réinitialisation avec une commande Exécuter :

• Tous les nouveaux documents trouvés dans la source sous-jacente sont ajoutés à l’index de recherche.
• Tous les documents qui existent dans la source de données et l’index de recherche sont remplacés dans l’index de recherche.
• Tout contenu enrichi créé à partir d’ensembles de compétences est reconstruit. Le cache d’enrichissement, s’il est activé, est actualisé.

Comme indiqué précédemment, la réinitialisation est une opération passive : vous devez suivre cela d’une requête d'exécution pour reconstruire l’index.

Les opérations de réinitialisation/exécution s’appliquent à un index de recherche ou à une base de connaissances, à des documents ou projections spécifiques et aux enrichissements mis en cache si une réinitialisation inclut explicitement ou implicitement des compétences.

La réinitialisation s’applique également aux opérations de création et de mise à jour. Il ne déclenche pas de suppression ni de nettoyage des documents orphelins dans l’index de recherche. Pour plus d’informations sur la suppression de documents, consultez Documents - Index.

Vous ne pouvez pas annuler une opération de réinitialisation.

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);
}

Comment réinitialiser les aptitudes (aperçu)

La requête Réinitialiser les compétences traite de manière sélective une ou plusieurs compétences lors de l’exécution de l’indexeur suivant. Pour les indexeurs disposant de jeux de compétences, vous pouvez réinitialiser des compétences individuelles afin de forcer le retraitement uniquement de cette compétence et de toutes les compétences en aval qui dépendent de sa sortie. Si vous avez activé le cache d’enrichissement, la requête l’actualise également.

Pour les indexeurs qui ont activé la mise en cache, vous pouvez demander explicitement le traitement des mises à jour des compétences que l’indexeur ne peut pas détecter. Par exemple, si vous apportez des modifications externes, telles que des révisions à une compétence personnalisée, utilisez cette API pour réexécuter la compétence. Le processus actualise les sorties, telles qu’une base de connaissances ou un index de recherche, à l’aide de données réutilisables du cache et du nouveau contenu conformément à la compétence mise à jour.

Utilisez la dernière API en préversion.

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

Vous pouvez spécifier des compétences individuelles, comme indiqué dans l’exemple précédent, mais si l’une de ces compétences nécessite une sortie des compétences non répertoriées (#2 à #4), le processus exécute des compétences non répertoriées, sauf si le cache peut fournir les informations nécessaires. Pour que cette condition soit vraie, les enrichissements mis en cache pour les compétences #2 à #4 ne doivent pas dépendre de #1 (répertoriés pour la réinitialisation).

Si vous ne spécifiez aucune compétence, le processus exécute l’ensemble de compétences et, si la mise en cache est activée, actualise également le cache.

N’oubliez pas d’exécuter Run Indexer pour démarrer le traitement réel.

Comment réinitialiser les documents (aperçu)

L’API Indexers - Reset Docs (préversion) accepte une liste de clés de document afin de pouvoir actualiser des documents spécifiques. Si vous spécifiez les paramètres de réinitialisation, ils déterminent uniquement ce qui est traité, quelles que soient les autres modifications apportées aux données sous-jacentes. Par exemple, si 20 objets blob ont été ajoutés ou mis à jour depuis la dernière exécution de l’indexeur, mais que vous réinitialisez un seul document, l’indexeur traite uniquement ce document.

Par document, l’indexeur actualise tous les champs du document de recherche avec des valeurs et des métadonnées à partir de la source de données. Vous ne pouvez pas sélectionner les champs à mettre à jour.

Si la source de données est Azure Data Lake Storage (ADLS) Gen2 et que les objets blob sont associés aux métadonnées d’autorisation, l’indexeur ingère à nouveau ces autorisations dans l’index de recherche si les autorisations changent dans les données sous-jacentes. Pour plus d’informations, consultez Réindexation de l’ACL et de l’étendue RBAC avec les indexeurs ADLS Gen2.

Si vous enrichissez le document par le biais d’un ensemble de compétences et qu’il a mis en cache des données, l’indexeur appelle l’ensemble de compétences uniquement pour les documents spécifiés et met à jour le cache pour les documents reprocessés.

Lorsque vous testez cette API pour la première fois, les API suivantes peuvent vous aider à valider et tester les comportements. Utilisez la dernière API en préversion.

1. Appeler Indexeurs - Obtenir le statut avec une version préliminaire de l’API pour vérifier le statut de réinitialisation et d’exécution. Vous pouvez trouver des informations sur la demande de réinitialisation à la fin de la réponse d’état.

2. Appelez Indexers - Réinitialiser les Documents avec une version préliminaire de l'API pour spécifier les documents à traiter.

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

   • L’API accepte deux types d’identificateurs de document comme entrée : les clés de document qui identifient de manière unique les documents dans un index de recherche et les identificateurs de documents de source de données qui identifient de manière unique les documents dans une source de données. Le corps doit contenir une liste de clés de document ou une liste d’identificateurs de document source de données que l’indexeur recherche dans la source de données. L’appel à l’API ajoute aux métadonnées de l’indexeur les clés de document ou les identifiants de document de la source de données à réinitialiser. Lors de l’exécution planifiée ou à la demande suivante de l’indexeur, l’indexeur traite uniquement les documents de réinitialisation.

   • Si vous utilisez des clés de document pour réinitialiser des documents et que vos clés de document sont référencées dans un mappage de champs d’indexeur, l’indexeur utilise le mappage de champs pour localiser le champ approprié dans la source de données sous-jacente.

   • Les clés de document que vous fournissez dans la requête sont des valeurs de l’index de recherche, qui peuvent être différentes des champs correspondants dans la source de données. Si vous n’êtes pas sûr de la valeur de clé, envoyez une requête pour retourner la valeur. Vous pouvez utiliser select pour renvoyer uniquement le champ clé du document.

   • Pour les blobs que l’indexeur analyse en plusieurs documents de recherche (où parsingMode est défini sur jsonLines ou jsonArrays, ou delimitedText), l’indexeur génère la clé du document, et il se peut que vous ne la connaissiez pas. Dans ce scénario, une requête pour la clé de document afin de retourner la valeur correcte.

   • Si vous souhaitez que l’indexeur cesse d’essayer de traiter les documents réinitialisés, définissez "documentKeys" ou "datasourceDocumentIds" sur une liste vide []. Cette action permet à l’indexeur de reprendre une indexation normale à partir du repère de progression élevé. Les clés de document non valides ou les clés de document qui n’existent pas sont ignorées.

3. Appelez Run Indexer (toute version d’API) pour traiter les documents que vous avez spécifiés. L’indexeur indexe uniquement ces documents spécifiques.

4. Appelez Run Indexer une deuxième fois pour traiter depuis le dernier point de référence élevé.

5. Appelez les documents de recherche pour rechercher des valeurs mises à jour et pour retourner des clés de document si vous n’êtes pas sûr de la valeur. Utilisez "select": "<field names>" si vous souhaitez limiter les champs qui apparaissent dans la réponse.

Remplacer la liste des clés de document

Si vous appelez l’API Réinitialiser les documents plusieurs fois avec différentes clés, les nouvelles clés sont ajoutées à la liste des clés de document réinitialisées. Si vous appelez l’API avec le overwrite paramètre défini sur true, la liste actuelle est remplacée par la nouvelle :

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

Comment resynchroniser les indexeurs (préversion)

Resync Indexers est une API REST en préversion qui effectue une réindexation partielle de tous les documents. Un indexeur est considéré comme synchronisé avec sa source de données lorsque des champs spécifiques de tous les documents de l’index cible sont cohérents avec les données de la source de données. En règle générale, un indexeur obtient la synchronisation après une exécution initiale réussie. Si vous supprimez un document de la source de données, l’indexeur reste synchronisé conformément à cette définition. Toutefois, lors de l’exécution suivante de l’indexeur, le document correspondant dans l’index cible est supprimé si le suivi de suppression est activé.

Si vous modifiez un document dans la source de données, l’indexeur devient non synchronisé. En règle générale, les mécanismes de suivi des modifications resynchronisent l’indexeur lors de l’exécution suivante. Par exemple, dans stockage Azure, la modification d’un blob met à jour sa date et heure de dernière modification, afin que l’indexeur puisse le réindexer lors de l’exécution suivante, car la date et heure mise à jour dépasse le repère de limite supérieure défini par l’exécution précédente.

En revanche, pour certaines sources de données comme ADLS Gen2, la modification des listes de contrôle d’accès (ACL) d’un objet blob ne modifie pas son heure de dernière modification. Par conséquent, le suivi des modifications est inefficace si les listes de contrôle d’accès doivent être ingérées. Par conséquent, le blob modifié n’est pas réindexé lors de l’exécution suivante, car seuls les documents modifiés après le dernier seuil de progression sont traités.

Bien que l’utilisation de « réinitialiser » ou de « réinitialiser les documents » puisse résoudre ce problème, « réinitialiser » peut prendre du temps et s’avérer inefficace pour les jeux de données volumineux, et « réinitialiser les documents » nécessite d’identifier la clé du document de l’objet blob que vous souhaitez mettre à jour.

Les indexeurs de resynchronisation offrent une alternative efficace et pratique. Vous placez simplement l’indexeur en mode resync et spécifiez le contenu à resynchroniser en appelant l’API d’indexeurs resync. Dans la prochaine exécution, l’indexeur inspecte uniquement la partie pertinente des données dans la source et évite tout traitement inutile qui n’est pas lié aux données spécifiées. Il interroge également les documents existants dans l’index cible et met uniquement à jour les documents qui présentent des différences entre la source de données et l’index cible. Une fois l’exécution resynchronisée terminée, l’indexeur est synchronisé et revient au mode d’exécution standard de l’indexeur pour les exécutions suivantes.

Comment resynchroniser et exécuter des indexeurs

1. Indexeurs d’appels : resynchronisation avec une version d’API en préversion pour spécifier le contenu à resynchroniser.

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

   • Le options champ est obligatoire. Actuellement, la seule option prise en charge est permissions. Autrement dit, seuls les champs de filtre d’autorisation dans l’index cible sont mis à jour.

2. Appelez Run Indexer (n’importe quelle version d’API) pour resynchroniser l’indexeur.

3. Appelez Run Indexer une deuxième fois pour traiter depuis le dernier point de référence élevé.

Vérifier l’état de réinitialisation « currentState »

Pour vérifier l’état de réinitialisation et voir quelles clés de document sont mises en file d’attente pour le traitement, procédez comme suit :

1. Appelez Obtenir l’état de l’indexeur à l’aide d’une API en préversion.

   L’API d’aperçu retourne la currentState section, trouvée à la fin de la réponse.

   "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. Vérifiez le « mode » :

   Pour réinitialiser les compétences, définissez « mode » sur indexingAllDocs parce que potentiellement tous les documents sont affectés, en ce qui concerne les champs renseignés par l’enrichissement par IA.

   Pour les indexeurs resync, définissez « mode » sur indexingResync. L’indexeur vérifie tous les documents et se concentre sur les données intéressées dans la source de données et les champs intéressés dans l’index cible.

   Pour réinitialiser les documents, définissez « mode » sur indexingResetDocs. L’indexeur reste dans cet état jusqu’à ce qu’il traite toutes les clés de documents fournies dans l’appel de réinitialisation des documents. Pendant ce temps, aucune autre tâche d’indexation ne s’exécute tant que l’opération est en cours. Pour trouver tous les documents figurant dans la liste des clés de documents, il faut analyser chaque document afin d’y localiser la clé et d’en vérifier la correspondance. Ce processus peut prendre un certain temps si le jeu de données est volumineux. Si un conteneur d’objets blob contient des centaines d’objets blob et que les documents que vous souhaitez réinitialiser sont à la fin, l’indexeur ne trouve pas les objets blob correspondants tant qu’il n’a pas vérifié tous les autres.

3. Une fois que l’indexeur a retraité les documents, exécutez à nouveau Get Indexer Status. L’indexeur retourne au indexingAllDocs mode et traite tous les documents nouveaux ou mis à jour lors de l’exécution suivante.

Vérifier le quota d’exécution de l’indexeur pour les services de recherche S3 HD et Serverless

Cette section s’applique aux services de recherche Standard 3 Haute densité (S3 HD) et Serverless. Pour plus d’informations sur le comportement des quotas cumulés et les recommandations en matière de planification, consultez Exécution de l’indexeur sur Serverless et S3 HD (préversion).

Chaque exécution d’indexation est limitée à deux heures maximum. Séparément, tous les indexeurs partagent 24 heures de runtime cumulé par service dans chaque fenêtre UTC de 24 heures.

Pour vous aider à surveiller les heures d’exécution de l’indexeur par rapport à la fenêtre de 24 heures, obtenir des statistiques de service et obtenir l’état de l’indexeur retournent désormais plus d’informations dans la réponse.

Suivre le quota de temps d’exécution cumulé

Suivez l’utilisation du runtime de l’indexeur cumulé d’un service de recherche et déterminez la quantité de quota d’exécution restant dans la fenêtre actuelle de 24 heures.

Envoyez une requête GET au point de terminaison du service de recherche. Pour obtenir de l’aide sur la configuration d’un client REST et l’obtention d’un jeton d’accès, consultez Se connecter à un service de recherche.

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

Les réponses incluent les propriétés qui affichent indexersRuntime les heures de début et de fin de la fenêtre, les secondes cumulatives utilisées par tous les indexeurs et les secondes restantes pour le service.

Suivre le quota d’exécution de l’indexeur

Retourne les mêmes informations pour un indexeur unique.

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

Les réponses incluent les runtime propriétés qui affichent les heures de début et de fin de la fenêtre, les secondes utilisées par l’indexeur et les secondes restantes pour tous les indexeurs du service.

Étapes suivantes

Les API de réinitialisation sont utilisées pour définir l’étendue de la prochaine exécution de l’indexeur. Pour le traitement proprement dit, vous devrez invoquer une exécution d’indexeur à la demande ou autoriser un travail planifié pour terminer le travail. Une fois l’exécution terminée, l’indexeur reprend le traitement normal, qu’il soit planifié ou à la demande.

Après avoir réinitialisé et réexécuté les travaux d’indexeur, vous pouvez surveiller l’état du service de recherche ou obtenir des informations détaillées via la journalisation des ressources.

• Surveiller l’état de l’indexeur de recherche
• Collecter et analyser des données de journal
• Planifier un indexeur