Les tâches d’entrepôt de données échouent et l’ID d’événement 33502 est journalisé

Cet article vous aide à résoudre un problème dans lequel les tâches de Data Warehouse échouent dans le gestionnaire de services de Microsoft System Center 2012 et l’ID d’événement 33502 est journalisé.

Version du produit d’origine :   Microsoft System Center 2012 Service Manager, System Center 2012 R2 Service Manager
Numéro de la base de connaissances initiale :   3137611

Symptôme

Les tâches d’entrepôt de données échouent dans le gestionnaire de services de Microsoft System Center 2012. Lorsque ce problème se produit, l’événement suivant est enregistré dans le journal des événements Operations Manager sur le serveur du Data Warehouse :

Nom du journal : gestionnaire des opérations
Source : Data Warehouse
ID d’événement : 33502
Level : erreur
Description :
Échec de l’exécution du module ETL :
Type de processus ETL : Transform
ID de lot : <Batch ID>
Nom du module : TransformEntityRelatesToEntityFact
Message : ErrorNumber = "50000" message = "Impossible d’acquérir applock-une autre instance du module doit déjà être en cours d’exécution." Gravité = "18" État = "1" NomProcédure = "InitializeTransform" LineNumber = "52" Task = "(null)"

De plus, lorsque vous exécutez certaines applets de commande liées à Data Warehouse, vous voyez fréquemment une erreur de délai d’attente enregistrée pour le TransformEntityRelatesToEntityFact module qui ressemble à ce qui suit :

Get-SCDWJobModule-JobName Transform. Common
...
1952 TransformEntityRelatesToEntityFact échec
...

Cause

Ce problème peut se produire si le volume des données de transformation dépasse la quantité pouvant être traitée par les modules de transformation dans le délai d’attente imparti. Cela se produit généralement après la désactivation des tâches de l’entrepôt de données pendant un certain temps, car le volume de données à transformer peut être rapidement journalisé en tant que journal. Par défaut, les travaux de transformation de l’entrepôt de données ont un délai d’attente de 60 minutes codé en dur.

Résolution 1

Si vous êtes actuellement en état d’échec, utilisez la résolution 1 pour traiter la file d’attente et renvoyer l’opération à un état de fonctionnement. Les deux autres méthodes permettent d’éviter que le problème ne se reproduise. Pour ce faire, attendez que l’état de tous les travaux du Data Warehouse s’affiche comme non démarré ou échec, puis procédez comme suit :

  1. Sur le serveur de Data Warehouse, arrêtez le service santéintégrité à partir d’une invite de commandes avec élévation de privilèges. Pour ce faire, exécutez la commande suivante :

    Net Stop HealthService
    

    Notes

    En fonction de votre version du gestionnaire de service, ce nom de service peut être affiché sous la forme agent de surveillance Microsoft ou gestion System Center.

  2. Mettez à jour la requête SQL suivante pour refléter la ModuleName   valeur du module dans le Transform.Common travail qui échoue. Cet exemple utilise TransformEntityRelatesToEntityFact .

    Notes

    La façon la plus simple de voir la ModuleName valeur du module qui ne fonctionne pas est d’ouvrir la console du gestionnaire de services, de sélectionner DataWarehouse, de sélectionner de nouveau Data Warehouse, de sélectionner les travaux de l' entrepôt de données, puis de sélectionner Transform.Common . Dans le volet inférieur du centre, vous pouvez voir la liste des modules et l’état actuel. Une fois les modifications effectuées, 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  
    update infra.workitem set statusid = 6 where batchid = @mybatchid
    update infra.batch set statusid = 6 where batchid = @mybatchid
    exec infra.CreateBatch N'Transform.Common'
    drop table #MyTempTable  
    drop table #MyTempTable2  
    drop table #MyTempTable3
    
  3. Si le script ci-dessus affiche le message suivant :

    « Impossible d’acquérir applock-une autre instance du module doit déjà être en cours d’exécution »

    Exécutez la requête suivante à partir de SQL Server Management Studio, puis réexécutez la requête SQL à l’étape 2 :

    insert #MyTempTable
    exec Infra.GetBatchDetails @ProcessCategoryName='Transform', @ProcessName='Transform.Common'
    GO
    Update infra.workitem set statusid = 6 where batchid IN (SELECT myBatchID FROM #MyTempTable)
    GO
    Update infra.batch set statusid = 6 where processid = (SELECT ProcessId from infra.process where processname = 'Transform.Common')
    GO
    EXEC infra.CreateBatch 'Transform.Common'
    DROP TABLE #MyTempTable
    
  4. Redémarrez le service santéintégrité à partir d’une invite de commandes avec élévation de privilèges. Pour ce faire, exécutez la commande suivante :

    Net Start HealthService
    

Notes

  • Vous devrez peut-être exécuter la requête SQL plusieurs fois jusqu’à ce qu’elle se termine rapidement.
  • Ne déconnectez pas lorsque vous exécutez la requête.
  • Exécutez la requête aussi rapidement que possible, car les nouvelles données capturées dans le gestionnaire de services s’apporteront à l’entrepôt de données lors du redémarrage du service.  
  • S’il vous faut un long moment pour exécuter la requête plusieurs fois, il se peut que vous rencontriez une autre augmentation de données.
  • Utilisez la résolution 3 comme solution à long terme.

Résolution 2

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

  1. Dans SQL Server Management Studio, connectez-vous à la base de données FIM, développez agent SQL Server, puis sélectionnez travaux.
  2. Cliquez avec le bouton droit FIM_ScheduleReportingIncrementalSynchronizationJob , sélectionnez Propriétés, puis planifications.
  3. Modifiez le a lieu toutes les FIM_UpdateReportingIncrementalSynchronizationJobSchedule_1 sur 2 heures.

Résolution 3

Pour une solution plus à long terme, effectuez la mise à niveau vers le correctif cumulatif 4 (UR4) ou une version ultérieure de Microsoft System Center 2012 R2 Service Manager. À partir du correctif cumulatif 4, le gestionnaire de services a un paramètre de délai d’expiration réglable. Par ailleurs, le délai d’attente de transformation de l’entrepôt de données par défaut passe de 60 minutes à 180 minutes. Si trois heures ne sont pas suffisamment longues pour que le Transform.Common module se termine, vous pouvez augmenter la valeur en modifiant la valeur de Registre suivante :

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

  • SqlCommandTimeout = (DWord 32-bit en seconde)

Notes

Si vous utilisez Forefront Identity Manager, vous devez effectuer une mise à niveau vers Microsoft Identity Manager 2012 R2 pour obtenir la prise en charge de service Manager 2012 R2.

Informations supplémentaires

Pour plus d’informations, consultez la rubrique How to change the default Timeout period for Data Warehouse Transform Jobs.