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 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.
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
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%'
-- 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;
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%';
-- 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%';
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;
-- 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
Exemplo:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."Depois:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLDEm 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.