Problema
As aplicações conectando no banco de dados, quando executam “SELECT SYSDATE FROM DUAL” recebem um horário 3h adiantado.
O horário no servidor (comando date no Linux) estava correto.
O resultado da consulta “SELECT SYSDATE FROM DUAL” conecando diretamente na instância com “sqlplus / as sysdba” retornava o horário correto.
O timezone do servidor estava correto (comando timedatectl), estava com “America/Sao_Paulo (-03, -0300)”.
Conexão via sqlplus através do servidor, mas passando pelo Listener (comando sqlplus usuario@banco) retornava o horário incorreto.
O problema ocorria somente quando a instância era iniciada via srvctl, se iniciada diretamente via sqlplus. o horário sempre retornava correto.
As aplicações conectando no banco de dados, quando executam “SELECT SYSDATE FROM DUAL” recebem um horário 3h adiantado.
O horário no servidor (comando date no Linux) estava correto.
O resultado da consulta “SELECT SYSDATE FROM DUAL” conecando diretamente na instância com “sqlplus / as sysdba” retornava o horário correto.
O timezone do servidor estava correto (comando timedatectl), estava com “America/Sao_Paulo (-03, -0300)”.
Conexão via sqlplus através do servidor, mas passando pelo Listener (comando sqlplus usuario@banco) retornava o horário incorreto.
O problema ocorria somente quando a instância era iniciada via srvctl, se iniciada diretamente via sqlplus. o horário sempre retornava correto.
Não havia variável de ambiente no profile do banco (srvctl getenv database).
Não havia variável de ambiente no profle do listener (srvctl getenv listener).
Causa
O Grid Infrastructure foi instalado quando o servidor tinha o Time Zone UTC, depois o Time Zone do sistema operacional (Linux) foi alterado para “America/Sao_Paulo”. O Grid tem um arquivo de variaveis de ambiente que é definido durante a instalação dos binários e precisaria ser ajustado manualmente quando alterasse o Time Zone do SO.
O arquivo fica em: $GI_HOME/crs/install/s_crsconfig_<hostname>_env.txt
$ cat $GI_HOME/crs/install/s_crsconfig_<hostname>_env.txt
TZ=Etc/GMT
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
CRS_LIMIT_STACK=2048
CRS_LIMIT_OPENFILE=65536
CRS_LIMIT_NPROC=65536
TNS_ADMIN=
Solução
Alterar o arquivo GI_HOME/crs/install/s_crsconfig_<hostname>_env.txt com Time Zone correto e reiniciar o CRS.
Para o meu caso ficou da seguinte forma:
TZ=America/Sao_Paulo
Após essa alteração no arquivo é preciso reiniciar o CRS com o usuário GRID
[grid@ ~]$ crsctl stop has
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ''
CRS-2673: Attempting to stop 'ora.evmd' on ''
CRS-2673: Attempting to stop 'ora.orcl.db' on ''
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on ''
CRS-2677: Stop of 'ora.LISTENER.lsnr' on '' succeeded
CRS-2677: Stop of 'ora.evmd' on '' succeeded
CRS-2677: Stop of 'ora.orcl.db' on '' succeeded
CRS-2673: Attempting to stop 'ora.RECO.dg' on ''
CRS-2677: Stop of 'ora.RECO.dg' on '' succeeded
CRS-2673: Attempting to stop 'ora.asm' on ''
CRS-2677: Stop of 'ora.asm' on '' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on ''
CRS-2677: Stop of 'ora.cssd' on '' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on '' has completed
CRS-4133: Oracle High Availability Services has been stopped.
[grid@ ~]$ crsctl start has
CRS-4123: Oracle High Availability Services has been started.
O comando de start retorna quase imediamente, mas os serviços são inicializados na sequência e pode levar alguns minutos até que a instância de banco de dados fique online novamente, mas ela será iniciada de forma automática.