Menu de navegação

[airoospParticipant]

Boa tarde,

Ao utilizar a v$session_longops para ver o tempo de execução de um comando, percebi que o tempo apresentado na coluna “start_time” esta 1 hora a mais em relação ao horário atual.

Ao executar “select sysdate from dual”, o retorno é data/hora correta.

Outro teste que fiz foi, “alter system switch logfile” e verifiquei no “alert” que data/hora estão corretas.

A data/hora do servidor também estão corretas.

Pesquisando mais sobre a v$session_longops, vi que as informações da mesma vem da gv$session_longops, que por sua vez vem da “x$ksulop” (kernel service, user long operation).

Ambiente:

Windows Server 2012 R2, banco 11g R2 (11.2.0.4) STD One.

Alguém já viu isso acontecer?

 

Obrigado

Airton

[José Laurindo ChiappaModerator]

Blz ? Então, eu nunca vi isso não, MAS quando alguém aqui no Brasil fala de horário adiantando uma hora recentemente, a PRIMEIRA coisa em que penso é que a pessoa não está com as definições de TIME ZONE corretas para o Brasil em 2019( sejam os arquivos com definições de TZ usadas no banco, sejam as definições no Sistema Operacional), já que o horário de verão foi cancelado em 2019 meio que na última hora, com o ano já começado – em princípio as colunas da V$SESSION são DATE e não timestamp with time zone então DEVERIAM ser imunes à TZ erradas, mas vai saber se alguma API interna do seu sistema operacional usa essa informação de TZ e aí na hora de converter em DATETIME pra uso da V$SESSION_LONGOPS aí dá essa diferença…. Numa busca Rápida e Superficial no site de Suporte da Oracle não achei uma referência direta pra isso mas Não é Impossível….
Então a minha PRIMEIRA PERGUNTA é : vc já disse que a DATA/HORA em si estão OK, ** MAS ** e a informação de TIME ZONE, principalmente à referente a Horário de verão, está ?? Se não estiver (o que é Provável) , faça uma pesquisa Melhor no site de Suporte da Oracle E abra um chamado pra confirmar, mas isso é bem possível de estar acontecendo, aí a solução é vc aplicar o patch de DST/DaylightSavingTime (ie, horário de verão) cfrme mostrado nas notas do Suporte Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches (Doc ID 412160.1) e Brazil Daylight Saving Time End Period (Doc ID 2506909.1), BEM COMO aplicar os patches referentes à isso no Sistema Operacional….

[]s

Chiappa

[José Laurindo ChiappaModerator]

Só pra te mostrar que É POSSÍVEL, veja o exemplo abaixo num servidor de teste meu, com Windows :

==> o servidor está setado para usar Brasil/São Paulo como timezone default, e está com o Windows Update correto, que alterou a informação de TZ pro horário de verão 2019 que foi cancelado :

C:\Users\jlchi_000>echo 24/10/2019 14:00:34,75 E. South America Standard Time
24/10/2019 14:00:34,75 E. South America Standard Time

C:\Users\jlchi_000>

==> perfeito, a hora tá certinha… Aí, no banco Oracle que reside nesse servidor, a DATA/HORA e o TIMESTAMP estão OK :

container=ORCL12C:SYSTEM@ORCL12C>select sysdate, systimestamp from dual;

SYSDATE SYSTIMESTAMP

24/10/2019 14:04:55 24/10/19 14:04:55,788000 -03:00

1 linha selecionada.

container=ORCL12C:SYSTEM@ORCL12C>

==> MAS veja que a data/hora NA TIMEZONE não está ok :

container=ORCL12C:SYSTEM@ORCL12C> select systimestamp at time zone 'America/Sao_Paulo' from dual;
SYSTIMESTAMPATTIMEZONE'AMERICA/SAO_PAULO'
24/10/19 15:06:15,213000 AMERICA/SAO_PAULO

1 linha selecionada.

container=ORCL12C:SYSTEM@ORCL12C>

==> Tá vendo a hora ADIANTADA, apesar do TIME ZONE estar ok E os dados de timezone estarem ok no Sistema Operacional ?? Isso é porque eu NÂO ESTOU com a versão mais recente do arquivo de timezone nesse banco :

container=ORCL12C:SYSTEM@ORCL12C> select * from v$timezone_file;

FILENAME VERSION CON_ID

timezlrg_26.dat 26 0

1 linha selecionada.

container=ORCL12C:SYSTEM@ORCL12C>

==> CONFORME A NOTA “Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches” (Doc ID 412160.1) deveria ser versão 34…

Como eu disse antes, Não deveria estar acontecendo isso na V$SESSION_LONGOPS pois a coluna START da V$SESSION_LONGOPS where é do datatype DATE apenas e não TIMESTAMP WITH TIME ZONE, mas vale a pena Checar com o Suporte Oracle se por algum bug imprevisto essa view interna tá usando alguma API que leve em consideração TZ, ou ecoisa do tipo – SE ISSO FOR CONFIRMADO, é só aplicar o patch que aplica o arquivo de TZ versão 34 no seu database, pra banco 12c rodando em Windows 64 bits é o Patch 29997937: RDBMS – DSTV34 UPDATE – TZDATA2019B… Após Confirmada a necessidade com o Suporte Oracle, baixe e aplique esse patch, certinho ??

[]s

Chiappa

[José Laurindo ChiappaModerator]

Nesse meu database de teste, depois de aplicar o patch DST indicado E fazer o upgrade interno (no caso eu optei por fazer via DBMS_ST cfrme a nota “Updating the RDBMS DST version in 12c Release 1 (12.1.0.1 and up) using DBMS_DST” com Doc ID 1509653.1, PODERIA ter optado pelos scripts cfrme a nota “Scripts to update the RDBMS DST (timezone) version in an 11gR2 or 12c database” com Doc ID 1585343.1), VEJA que a conversão no TZ Brasil passou a ficar correta :

container=ORCL12C:SYS@ORCL12C> select sysdate, systimestamp from dual;

SYSDATE SYSTIMESTAMP

---

2019/10/24 24/10/19 17:27:41,270000 -03:00

1 linha selecionada.

container=ORCL12C:SYS@ORCL12C> select systimestamp at time zone ‘America/Sao_Paulo’ from dual;

SYSTIMESTAMPATTIMEZONE’AMERICA/SAO_PAULO’

24/10/19 17:28:00,630000 AMERICA/SAO_PAULO

1 linha selecionada.

container=ORCL12C:SYS@ORCL12C>

==> SE o teu database e/ou teu servidor estejam usando o TZ do Brasil de um local onde não deveria ter sido acionado o Horário de verão E a consulta ao Suporte Oracle indicar possibilidade disso estar influenciando no seu problema com a coluna START da V$SESSION_LONGOPS, experimenta (depois da Aprovação do Suporte Oracle) aplicar o patch de DSTv34 que nem eu fiz acima, veja lá se isso resolve o teu problema….

[]s

Chiappa

[Author]

Posts