Tarefas de armazém de dados falhar e é registado o ID de evento 33502

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 3137611
Sintoma
Tarefas de armazém de dados falhar no Gestor do serviço de 2012 do Microsoft System Center. Quando este problema ocorre, é registado o seguinte evento no registo de eventos do Gestor de operações no servidor de armazenamento de dados:

Nome de registo: Gestor de operações
Origem: Armazém de dados
ID do evento: 33502
Nível: Erro
Descrição:
Falha na execução de módulo de ETL:
Tipo de processo ETL: transformar
ID de lote: # # #
Nome do módulo: TransformEntityRelatesToEntityFact
Mensagem: Tempo limite expirou. O tempo limite decorreu antes da conclusão da operação ou o servidor não está a responder.


Além disso, quando executar determinadas cmdlets relacionados com o armazém de dados, youfrequently ver um erro de limite de tempo gravado para o módulo deTransformEntityRelatesToEntityFact semelhante à seguinte:

Transform.common de - nometarefa de GET-SCDWJobModule
. . .
TransformEntityRelatesToEntityFact de 1952 falhou
. . .
Causa
Este problema pode ocorrer se o volume de transformação de dados exceder a quantidade que pode ser processada os módulos de transformação durante o período de tempo limite. Isto ocorre normalmente depois de tarefas de armazém de dados foram desactivadas durante algum tempo porque o volume de dados a ser transformados pode tornar-se backlogged rapidamente. Por predefinição, os trabalhos de transformação do armazém de dados têm um limite de tempo de 60 minutos codificado.
Resolução
Para corrigir este problema, utilize um dos seguintes métodos.

Método 1

Se pensa que se trata de um problema de curto e isolado, processa as tarefas transformadas backlogged para regressar a operação de um Estado de funcionamento. Para fazer isto, aguarde que o estado de todos os projectos de armazém de dados para serem apresentados comoNão iniciado ou falhoue, em seguida, siga estes passos:

  1. No servidor do armazém de data, pare o serviceat de HealthService linha de comandos elevada. Para tal, execute o seguinte comando:

    Net Stop HealthService

    Nota Consoante a versão do Gestor do serviço, este nome de serviço pode ser apresentado comoagente de monitorização da Microsoft ou Gestão de centros de sistema.
  2. Actualize a seguinte consulta de SQL Server para reflectir o valor de NomeMódulodo módulo da tarefa de Transform.Common que está a falhar. Este exemplo utilizaTransformEntityRelatesToEntityFact.

    Nota A forma mais simples para ver o valor de NomeMódulopara o módulo que está a falhar é abrir a consola do Gestor do serviço, clique emArmazém de dados, clique novamente em Armazém de dados , clique em projectos de armazém de dadose, em seguida, clique em Transform.Common. No painel inferior centro, pode ver uma lista de módulos e o estado actual. Depois de efectuar as alterações, execute a consulta.

    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. Reinicie o serviço de HealthService numa linha de comandos elevada. Para tal, execute o seguinte comando:

    Net Start HealthService
Nota Poderá ter de repetir estes passos várias vezes ou em vários módulos.

Método 2

Se estiver a utilizar o Gestor de identificar Forefront (FIM), este problema pode ocorrer devido ao fluxo de dados que chega até ao Gestor do serviço. Para distribuir a carga de trabalho para estes dados, altere a agenda deFIM_ScheduleReportingIncrementalSynchronizationJob do valor predefinido de cada 8 horas a cada 2 horas. Para tal, siga estes passos:

  1. No SQL Server Management Studio, ligar à base de dados de FIM, expanda o SQL Server Agente, em seguida, clique em projectos.
  2. FIM_ScheduleReportingIncrementalSynchronizationJobcom o botão direito, clique em Propriedadese, em seguida, clique em agendas.
  3. Alterar a Occurs cada valor para FIM_UpdateReportingIncrementalSynchronizationJobSchedule_12horas.

Método 3

Para obter uma solução a mais longo prazo, actualize para o Microsoft System Center 2012 R2 serviço Gestor de Update Rollup 4 (UR4) ou uma versão posterior. Início no Update Rollup 4, o Gestor do serviço tem uma definição de limite de tempo ajustáveis. Além disso, o limite de tempo de trabalho de transformação de armazém de dados do predefinido muda de 60 minutos para 180 minutos. Se três horas não for suficiente para o módulo deTransform.Common concluir, pode aumentar o valor alterando o valor de registo seguinte:

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

SqlCommandTimeout = (DWord segundo de 32 bits)

Nota Se estiver a utilizar o Gestor de identidades do Forefront, tem de actualizar para R2 de 2012 do Gestor de identidades da Microsoft para obter suporte para o Gestor do serviço de 2012 R2.

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3137611 - Última Revisão: 03/28/2016 21:56:00 - Revisão: 2.0

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

  • kbexpertiseadvanced kbsurveynew kbtshoot kbmt KB3137611 KbMtpt
Comentários