Horário de Verão e Servidores com Horário da Rede

O horário de verão e os servidores com horário de rede afetam o horário atual em uma máquina servidor. Em serviços de deslocamento de dados, os timestamps são usados para determinar quando os servidores fazem a verificação de novos dados e quando eles realizarão o deslocamento de dados. Alterações no relógio do sistema afetam os componentes de serviço de dados e seu desempenho perceptível.

A mudança manual do relógio do sistema também afeta o horário. O comportamento do sistema é afetado da mesma forma, independentemente do método usado para alterar o relógio. Atrasos indesejados nos serviços de deslocamento de dados ocorrem quando o relógio do sistema é atrasado. Atrasos não ocorrem quando o relógio do sistema é adiantado, embora esse procedimento faça com que os componentes dos serviços de deslocamento de dados atinjam os intervalos planejados mais cedo.

Efeito da Alteração de Horários sobre os Componentes

Caso o relógio do sistema seja atrasado, os componentes afetados terão seus timestamps configurados para o futuro, mas o relógio do sistema será configurado para o passado. O relógio do sistema, esses timestamps internos e os parâmetros que indicam intervalos serão todos afetados pela alteração do relógio do sistema.

Caso o relógio do sistema seja adiantado, os componentes afetados terão seus timestamps internos configurados para o passado e o timestamp atual do relógio do sistema será configurado para o futuro. Esse comportamento é similar ao comportamento normal do relógio do sistema; a diferença é que algumas das medições de tempo que incluem a determinação da próxima execução programada ou a determinação do ciclo de vida de um registro do banco de dados serão afetadas. O tempo realmente decorrido será menor do que o tempo decorrido calculado.

Exemplo: Um registro deve permanecer no sistema durante 24 horas após se tornar elegível para exclusão. Assuma que um registro se torna elegível para exclusão às 15h da terça-feira. Nesse ponto, em virtude da política de retenção de 24 horas, o registro pode ser excluído a qualquer momento após às 15h da quarta-feira. Suponha também que às 15h01 da terça-feira o sistema está configurado para às 15h01 da sexta-feira seguinte. Conseqüentemente, mesmo que apenas 1 minuto tenha se passado no tempo decorrido real, o tempo decorrido para o sistema será de 3 dias e 1 minuto e o período de retenção de 24 horas do registro terá sido satisfeito. Isso significa que, em virtude da alteração do horário, o registro pode ser removido mais rapidamente do que se o relógio do sistema não tivesse sido alterado.

Outro exemplo: Um componente ETL específico é executado a cada 24 horas e, imediatamente após sua execução, o relógio do sistema salta 26 horas no futuro. Em vez de esperar pelas 24 horas pré-requisitadas no horário real anterior à sua próxima execução, o Componente de ETL será iniciado novamente o mais rapidamente possível. Isso se deve ao cálculo do sistema de que se passaram pelo menos 26 horas desde a última execução. De fato, adiantar o relógio reduziu o intervalo de execução do ETL neste caso. O Componente de ETL voltará ao normal depois dessa execução, retomando o intervalo definido, desde que nenhuma outra alteração seja feita no relógio do sistema.

As seções a seguir enfocam apenas o atraso do relógio depois que os componentes foram executados antes do relógio ser atrasado.

O componente Capture continua a capturar alterações em qualquer uma das tabelas que esteja rastreando. Um cálculo de tempo é utilizado para determinar quando confirmar essas alterações e disponibilizá-las para o Componente Apply e o componente Source Life Cycle. É mais provável que o componente Capture tenha marcado internamente um timestamp para o futuro. Ele não confirmará a transação até que o relógio interno seja superior ao do timestamp marcado, mais algum parâmetro interno para o intervalo entre as confirmações. Nesse caso, se o relógio do sistema foi atrasado em 1 hora, então o pior resultado é que nenhuma transação ocorrida na nova hora estará disponível até que essa hora passe. Se o relógio foi atrasado em 1 ano, então levará um ano para que o sistema se atualize.
Nota: O componente Capture confirma após um número prescrito de transações; o padrão é 120. É possível que os dados venham a estar disponíveis para os componentes Apply e Source Life Cycle mais cedo do que o definido.

O componente Apply também mantém um timestamp interno que determina quando ele fará a verificação em busca de novos registros. Nesse cenário, esse timestamp interno será superior ao timestamp atual do sistema. O componente Apply espera até que o timestamp do sistema atinja o timestamp interno, mesmo que novos registros estejam disponíveis. Uma vez que o timestamp seja atingido, ele começará a procurar por registros disponíveis para deslocamento de dados.

Os timestamps não determinam quais linhas devem ser replicadas. Isso é determinado por um valor interno que não é afetado pelo relógio do sistema. Os componentes Source e Target Life Cycle também usam timestamps para determinar quando se iniciam e quais registros estão prontos para serem cortados.

O componente Source Life Cycle no serviço de deslocamento de dados de Estado para Tempo de Execução usa apenas timestamps para determinar quando deve será iniciado. Ele não usa timestamps para determinar quais cortar. Esse componente nesse serviço não suporta o recurso da política de retenção que permite que informações elegíveis para corte existam pelo período determinado pela política de retenção. No entanto, esse recurso existe no serviço de deslocamento de dados de Tempo de Execução para Histórico do componente Source Life Cycle. Alguns registros não satisfazem os critérios da política de retenção até que o atual relógio do sistema os alcancem. Os componentes Target Life Cycle em ambos os serviços de deslocamento de dados suportam a definição da política de retenção de forma que qualquer alteração nos horários afeta quando são executados e quando são cortados.

Os Componentes de ETL usam timestamps como parte de seu planejamento interno. Uma vez iniciados, esses componentes esperam que a hora esteja passando. Quando o relógio do sistema é colocado no passado, o planejamento do ETL é afetado, e nenhum ETL é desempenhado até que o sistema seja sincronizado.

Os possíveis cenários do horário do relógio do sistema são:

Recuperação

A recuperação durante uma alteração realizada por um servidor de horário não deve ser necessária porque os diferenciais de horário devem ser muito pequenos -- apenas alguns minutos. O efeito será um pequeno intervalo no qual nada acontece enquanto os componentes são sincronizados. Durante uma alteração no horário, em virtude da alteração para o horário de verão, o atraso no horário faz com que os componentes interrompam a replicação durante uma hora, após a qual os componentes precisarão fazer a sincronização com o sistema. Se isso é um problema, depende do sistema.

Um cenário no qual essa espera poderia ser significativa é quando um engano é cometido e o horário do sistema é adiantado muito tempo no futuro, enquanto os servidores de componentes estão em execução. Então, (independente de se os servidores estão em execução), o horário é restaurado para o horário atual. Nesse caso, os componentes configurariam seus timestamps internos para o futuro, mas estarão em execução no período de tempo atual. Haverá um longo retardo antes que o serviço de deslocamento de dados processe qualquer linha novamente. Esse retardo poderia causar um crescimento no sistema que afetaria o tempo de recuperação. O administrador pode ter que executar uma ação corretiva.

Ação Corretiva

Uma opção é simplesmente forçar os componentes Capture e Apply a iniciarem um atualização completa e, em seguida, atualizar os timestamps internos para os componentes Source Life Cycle, Target Life Cycle e ETL.
  1. Identifique todos os bancos de dados que estão em execução no servidor no qual o horário foi adiantado e, em seguida, atrasado. Há duas possibilidades: Estado e Tempo de Execução ou Tempo de Execução e Histórico.
  2. Pare todos os servidores que suportam os serviços de deslocamento de dados no sistema afetado. Durante esse processo, você estará modificando os parâmetros internos e alguns componentes podem estar fora de sincronização, caso sua execução seja permitida. Para obter informações adicionais, consulte Iniciando e Interrompendo um Serviço de Deslocamento de Dados
  3. Modifique os timestamps internos dos componentes Source Life Cycle e dos componentes Target Life Cycle.
    Nota: Esta ação está sujeita a alterações de release para release.
    1. Atualizando timestamps de corte do Source Life Cycle. Isso modificará as configurações de todos os componentes Source Life Cycle servindo a todos os modelos de medidas de negócios no sistema.
      Verifique as definições atuais:
      connect to <banco_de_dados_de_origem>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL, CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME LIKE 'APP%'
      Nota: Reveja os valores de LAST_PRUNED e PRUNE_INTERVAL e CURRENT TIMESTAMP. Decida se você deseja cortar imediatamente ou no próximo intervalo.
      -- PARA EXECUTAR o mais rápido possível.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME LIKE 'APP%';
      -- PARA EXECUTAR no próximo intervalo.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME LIKE 'APP%';
      connect reset;
    2. Atualizando timestamps de corte do Target Life Cycle.
      CONNECT TO <banco_de_dados_de_destino>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME NOT LIKE 'APP%';
      Nota: Reveja os valores de LAST_PRUNED e PRUNE_INTERVAL e CURRENT TIMESTAMP. Decida se é desejável cortar imediatamente ou no próximo intervalo.
      -- PARA EXECUTAR o mais rápido possível.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME NOT LIKE 'APP%';
      -- PARA EXECUTAR no próximo intervalo.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME NOT LIKE 'APP%';
    3. Atualizando o ETL Schedule.
      Nota: Isso afetará todas as atividades de ETL ao longo de todos os modelos.
      CONNECT TO <DESTINO>
      -- Essa consulta mostra
      SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
      Nota: Os valores ETL_0_MINUTES, NEXTSTARTTIME e LASTUPDATED conforme comparados ao CURRENT TIMESTAMP.
      -- PARA Executar no próximo intervalo.
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP);
      -- Para Executar o mais rápido possível.
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES);
      CONNECT RESET
    4. Force uma atualização completa. A forma mais simples de forçar uma atualização completa dos servidores Capture e Apply de replicação é copiar e modificar os scripts StartCapture para todo modelo de medidas de negócios. Localize todo script de captura de início para todo modelo implementado no sistema (Se você seguiu as instruções localizadas na seção consolidando scripts de início e interrupção, simplesmente localize cada comando asncap), e inclua o parâmetro: STARTMODE=COLD no final da linha de comandos.
      Nota: Uma atualização completa é um caso extremo e pode levar a um baixo desempenho até que a atualização completa seja concluída. Isso se deve ao fato de que uma atualização completa inclui código extra que normalmente não está presente no Data Services Operations. Assim, é importante que a atualização completa seja executada durante o período em que o sistema não se encontra muito usado. O desempenho da Atualização Completa depende muito do tamanho dos dados no banco de dados de origem do Serviço de Deslocamento de Dados.

      Exemplo:

      Antes:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."
      Depois:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLD
      Em seguida, inicie todos os scripts. Essa atualização completa fará com que os componentes Capture e Apply reconfigurem todos os seus timestamps internos, mas não acarretará o custo extra de mover e reprocessar os dados. É importante ter um plano para o caso de queda do desempenho potencial durante a sincronização do sistema.

Direitos Autorais IBM Corporation 2005. Todos os Direitos Reservados.