Échouent des travaux d'entrepôt de données et ID d'événement 33502 est enregistré.

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3137611
Symptôme
Travaux d'entrepôt de données échouent dans Microsoft System Center 2012 Service Manager. Lorsque ce problème se produit, l'événement suivant est enregistré dans le journal des événements sur le serveur Data Warehouse Operations Manager :

Nom du journal : Operations Manager
Source : Entrepôt de données
L'ID d'événement : 33502
Niveau : erreur
Description :
Échec de l'exécution du Module ETL :
Type de processus ETL : transformation
CODE de lot: ###
Nom du module : TransformEntityRelatesToEntityFact
Message : Le délai d'attente a expiré. Le délai d'attente écoulée avant l'achèvement de l'opération ou le serveur ne répond pas.


En outre, lorsque vous exécutez certaines applets de commande d'entrepôt de données, youfrequently voir une erreur de délai d'expiration enregistrée pour le moduleTransformEntityRelatesToEntityFact semblable à la suivante :

Transform.common de NomTâche - de Get-SCDWJobModule
. . .
TransformEntityRelatesToEntityFact 1952 a échoué
. . .
Cause
Ce problème peut se produire si le volume de données de transformation dépasse la quantité pouvant être traités par les modules de transformation dans le délai d'attente. Cela se produit généralement après que les travaux de l'entrepôt de données ont été désactivées pendant un certain temps, car vous pouvez retarder rapidement le volume de données à transformer. Par défaut, les tâches de transformation de Data Warehouse ont un délai de 60 minutes codé en dur.
Résolution
Pour résoudre ce problème, appliquez l'une des méthodes suivantes.

Méthode 1

Si vous pensez qu'il s'agit d'un problème à court terme et isolé, traiter les tâches retardées transformés pour l'opération de retour à un état opérationnel. Pour ce faire, attendez que l'état de tous les travaux d'entrepôt de données à afficher en tant queN'a pas démarré ou a échouéet puis procédez comme suit :

  1. Sur le serveur du magasin de Date, arrêter la serviceat HealthService une invite de commandes avec élévation de privilèges. Pour ce faire, exécutez la commande suivante :

    Net Stop HealthService

    Remarque En fonction de votre version du Gestionnaire de Service, le nom de ce service peut-être s'afficher en tantqu'agent de surveillance de Microsoft ou de Gestion de System Center.
  2. Mise à jour de la requête SQL Server pour refléter la valeur ModuleNamedu module dans le projet Transform.Common qui est défectueux. Cet exemple utiliseTransformEntityRelatesToEntityFact.

    Remarque Pour voir la valeur ModuleNamepour le module défaillant, le plus simple consiste à ouvrir la console de Service Manager, cliquez surData Warehouse, cliquez de nouveau sur Data Warehouse , cliquez sur tâches de Data Warehouse, puis cliquez sur Transform.Common. Dans le volet en bas au centre, vous pouvez voir une liste de modules et de l'état actuel. Après avoir apporté les modifications, exécutez la requête.

    Use DWStagingAndConfig  declare  @mybatchid INT,  @mysourceid INT,  @outXML XML,  @myProcessCategoryName NVARCHAR(100),  @myProcessName NVARCHAR(100),  @myModuleName NVARCHAR(100),  @sqlString NVARCHAR(150),  @paramDef NVARCHAR(100)  set @myProcessCategoryName = N'Transform'  set @myProcessName = N'Transform.Common'  set @myModuleName = N'TransformEntityRelatesToEntityFact'  USE DWStagingAndConfig  create table #MyTempTable (  ProcessCategoryName NVARCHAR(150),  ProcessName NVARCHAR(150),  BatchId INT,  BatchStatus NVARCHAR(150),  WorkItemStatus NVARCHAR(150),  WorkItems INT  )  insert #MyTempTable  exec Infra.GetBatchDetails @ProcessCategoryName=@myProcessCategoryName, @ProcessName=@myProcessName  select @mybatchid = BatchId from #MyTempTable  select @mysourceid = sourceid from etl.source where SourceName='SCDW'  create table #MyTempTable2 (  myWaterMark XML  )  insert #MyTempTable2  exec etl.GetWaterMark @BatchId=@mybatchid, @ModuleName=@myModuleName, @ProcessName=@myProcessCategoryName, @SourceId=@mysourceid  select @outXML = myWaterMark from #MyTempTable2  create table #MyTempTable3 (  myWaterMark XML,  BatchId INT,  UpdatedRowCount INT,  InsertedRowCount INT  )  USE DWRepository  set @paramDef = N'@ioutXML XML'  set @sqlString = 'insert #MyTempTable3 exec ' + @myModuleName + 'Proc @WaterMark=@ioutXML'  exec sp_executesql @sqlString, @paramDef, @ioutXML=@outXML  select @mybatchid = BatchId, @outXML = myWaterMark from #MyTempTable3  USE DWStagingAndConfig  exec etl.SetWaterMark @BatchId=@mybatchid, @ModuleName=@myModuleName, @ProcessName=@myProcessCategoryName, @SourceId=@mysourceid, @WaterMark=@outXML  drop table #MyTempTable  drop table #MyTempTable2  drop table #MyTempTable3
  3. Redémarrez le service HealthService à une invite de commandes avec élévation de privilèges. Pour ce faire, exécutez la commande suivante :

    Net Start HealthService
Remarque Vous devrez peut-être répéter ces étapes plusieurs fois ou dans plusieurs modules.

Méthode 2

Si vous utilisez Forefront identifier Manager (FIM), ce problème peut se reproduire à cause du flux de données qui atteint le Gestionnaire de services. Pour répartir la charge de travail pour ces données, modifier la planification de laFIM_ScheduleReportingIncrementalSynchronizationJob la valeur par défaut de toutes les 8 heures pour toutes les 2 heures. Pour ce faire, procédez comme suit :

  1. Dans SQL Server Management Studio, connectez-vous à la base FIM, développez SQL Server Agent, puis cliquez sur travaux.
  2. Cliquez sur FIM_ScheduleReportingIncrementalSynchronizationJobet cliquez sur Propriétés, puis cliquez sur planifications.
  3. Modifier la se produit chaque valeur de FIM_UpdateReportingIncrementalSynchronizationJobSchedule_1 à 2 heures.

Méthode 3

Pour une solution à plus long terme, mise à niveau vers Microsoft System Center 2012 R2 Service Gestionnaire de correctif cumulatif 4 (UR4) ou une version ultérieure. Au début de la mise à jour de correctif cumulatif 4, le Gestionnaire de Service a un paramètre de délai d'attente réglable. Le délai d'attente de travail de la transformation par défaut Data Warehouse change également, à partir de 60 minutes à 180 minutes. Si trois heures n'est pas suffisamment longue pour le moduleTransform.Common à la fin, vous pouvez augmenter la valeur en modifiant la valeur de Registre suivante :

HKLM\SOFTWARE\Microsoft\System Center\2010\Common\DAL

SqlCommandTimeout = (DWord 32 bits dans la seconde)

Remarque Si vous utilisez Forefront Identity Manager, vous devez mettre à niveau vers Microsoft Identity Manager 2012 R2 pour obtenir la prise en charge de Service Manager 2012 R2.

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3137611 - Dernière mise à jour : 03/28/2016 17:54:00 - Révision : 2.0

Microsoft System Center 2012 Service Manager Service Pack 1, Microsoft System Center 2012 R2 Service Manager

  • kbexpertiseadvanced kbsurveynew kbtshoot kbmt KB3137611 KbMtfr
Commentaires