Sim, é verdade que o TZ de GMT-2 reportado estaria correto se o seu Estado
adotou o horário de verão - esse meu exemplo que mostra isso foi tirado duma
máquina Windows com o relógio acertado pelo serviço de hora default do Windows
(time.windows.com), setada para o TZ de Brasília GMT-3 E com a opção de usar
Horário de Verão tickada.... EM TESE, falando propriamente, Não deveria ser
necessário se alterar esse TZ, que está correto, mas na prática a gente vê
muita "programação criativa" pelaí, muita monstruosidade, pode até ser que como
uma enorme gambi vc acabe tendo que alterar manualmente o tz (que está correto)
do servidor ...
Antes disso, porém :
1. confirme com eles que REALMENTE essa data/hora que está atrasada está
mesmo vindo do banco de dados : NADA impede que na verdade isso esteja sendo
extraído dalgum servidor de aplicação, por exemplo...
2. SE realmente tá vindo do database, mostre para eles o meu exemplo que
demonstra a TZ de banco, de sessão E de SO (e repita-o no seu database), e
QUESTIONE qual eles estão usando : PODE ser que seja só um caso de ajustar o
ambiente (via variáveis de ambiente, arquivo de config, ou o que for) - isso
faz bastante sentido, já que quando vc (ou o próprio Windows) ajusta a TZ do
servidor as configs de sessão (principalmente se forem em variáveis de
ambiente) não são automaticamente alteradas, de repente esse é o seu problema :
a SYSTIMESTAMP tá vindo correta porque vêm do SO que está ajustado mas na
verdade eles usam a CURRENT_TIMESTAMP, que está setada via config de ambiente
defasada....
Uma vez confirmado que eles usam a TZ do SO refletida no SYSTIMESTAMP (ou
então se eles usam TZ de sessão não souberem indicar onde/como alterar o
ambiente de TZ na tool deles, o que não é impossível) aí OK, vc vai ter que
altera a TZ no SO ...
Só relembro que, como já foi dito algumas vezes nas últimas threads
recentes, antes de alterar data/hora/tz do Sistema Operacional tenha em mente
que o RDBMS em si é INDIFERENTE a isso, mas MUITOS componentes auxiliares (como
CLUSTERWARE, DBMS SCHEDULER JOBS, e mais alguns) e atividades de administração
(como RECOVER por tempo, retenções no RMAN, arquivos de log e assemelhados que
estejam com o nome composto por data/hora, entre outras) usam/podem usar
internamente o componente date/time/tz do Sistema Operacional e podem ter
registrado a informação de antes da mudança - se vc está INSEGURO se o seu
database usa itens do tipo, o mais Seguro (se vc tiver janela para tal) seria
fazer um shutdown (de banco, aplicação, listener, tudo) antes da troca e um
startup depois ....
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, André Luiz Silva <mennuciano@...> escreveu
>
> Fábio e Chiappa muito obrigado pelo retorno,
>
> A solicitação para alterar o TZ do SO partiu da fabricante do software que
> roda neste DB, hoje o TZ do SO do servidor está em GMT 02:00 já que
> estamos em sp e no horário de verão o que está correto na minha opinião.
>
> Más o horário que aparece nas telas e relatórios da aplicação estão com uma
> hora em atraso e eles alegam que a solução é alterar o fuso do SO para
> 03:00 já que segundo eles este é o TZ do Brasil
>
> Abs e obrigado novamente.
>
> Ps.já alterei o TZ do DB para 03:00 e não surtiu o efeito esperado.
> Em 24/10/2013 15:28, "J. Laurindo Chiappa" <jlchiappa@...>
> escreveu:
>
> > **
> >
> >
> > Sim, a função SYSTIMESTAMP retorna ** todas ** as suas informações a
> > partir do clock e do calendário ativos no servidor que hospeda o RDBMS, sim
> > - o manual apropriado "Oracle® Database SQL Language Reference 11g Release
> > 2" na entrada sobre ela textualmente diz (ênfase com *s minha)
> >
> > "
> > Purpose
> >
> > SYSTIMESTAMP returns the system date, including fractional seconds *** and
> > time zone ** , of the system ** on which the database resides **.
> > "
> >
> > ok ? NOTAR, porém, que EXISTE sim a propriedade de TIMEZONE no database
> > (ela é uma das propriedades que vc informa na criação do database, veja no
> > CREATE DATABASE a opção de SET TIMEZONE) , E além disso existe também a
> > timezone-default para a sessão, que pode ser alterada via environment como
> > Qualquer Outra propriedade de uma sessão... Então a pergunta é, QUAL desses
> > timezones vc quer alterar ??? O timezone do ambiente/SO vc altera no SO (e,
> > DA MESMA MANEIRA que uma alteração de data/hora, em princípio NÂO DEMANDA
> > um restart do database, já que o database é INDIFERENTE ao clock do
> > servidor, ele se controla via SCN), o timezone do DB vc pode alterar com
> > ALTER DATABASE SET TIME_ZONE='valorsesejado', e o da sessão vc altera via
> > variável de ambiente ( ou ALTER SESSION, iirc) .... Um exemplo :
> >
> > SQL> select systimestamp from dual ;
> >
> > SYSTIMESTAMP
> > ----------------------------------------------------------
> > 24/10/13 14:26:06,871000 -02:00
> >
> > SQL> SELECT DBTIMEZONE FROM DUAL;
> >
> > DBTIME
> > ------
> > +00:00
> >
> > SQL> select current_timestamp from dual;
> >
> > CURRENT_TIMESTAMP
> > ----------------------------------------------------------
> > 24/10/13 14:36:17,603000 -02:00
> >
> > => ok, na falta de especificação o current timestamp assumiu o do servidor
> > E a sessão (o CURRENT_TIMESTAMP no mesmo manual acima citado tá documentado
> > que registra a TZ da sessão) seguiu... Vou alterar o timezone da sessão :
> >
> > SQL> exit
> >
> > C:\Windows\system32>set ORA_SDTZ=+05:00
> >
> > C:\Windows\system32>echo %ORA_SDTZ%
> > +05:00
> >
> > C:\Windows\system32>sqlplus system/oracle
> >
> > .....
> >
> > SQL> select current_timestamp from dual;
> >
> > CURRENT_TIMESTAMP
> > ----------------------------------------------------------
> > 24/10/13 21:42:52,673000 +05:00
> >
> > SQL> SELECT DBTIMEZONE FROM DUAL;
> >
> > DBTIME
> > ------
> > +00:00
> >
> > SQL> select systimestamp from dual ;
> >
> > SYSTIMESTAMP
> > ----------------------------------------------------------
> > 24/10/13 14:43:05,546000 -02:00
> >
> > SQL>exit
> >
> > => okdoc ? não alterei a tz do database, E não alterei a do ambiente/SO
> > (então AMBAS permaneceram a mesma, E a systimestamp como documentado
> > derivou do SO/servidor), ** MAS ** o tz da sessão foi SIM alterado... Agora
> > vou mudar no SO para GMT-1 (Açores) , e veja (SEM nenhum reboot do servidor
> > nem restart do banco) :
> >
> > C:\Windows\system32>sqlplus system/oracle
> >
> > ...
> >
> > SQL> select systimestamp from dual ;
> >
> > SYSTIMESTAMP
> > ----------------------------------------------------------
> > 24/10/13 16:07:36,060000 -01:00
> >
> > SQL> SELECT DBTIMEZONE FROM DUAL;
> >
> > DBTIME
> > ------
> > +00:00
> >
> > SQL> select current_timestamp from dual;
> >
> > CURRENT_TIMESTAMP
> > ----------------------------------------------------------
> > 24/10/13 22:07:48,270000 +05:00
> >
> > SQL> exit
> >
> > ==> Tá jóia ???
> >
> > E aí vem a SEGUNDA pergunta, POR QUE/PARA QUE vc quer mudar a TZ reportada
> > pelo SYSTIMESTAMP ??? Pergunto isso porque se for para mudar TZ de
> > SCHEDULER JOBs, vc muda esse atributo diretamente com as built-ins de JOBs,
> > por exemplo.... Dia aí o que vc quer/precisa que talvez a gente possa
> > palpitar melhor...
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br, André Luiz Silva <mennuciano@>
> > escreveu
> > >
> > > Pessoal bom dia, tudo bem?
> > >
> > > O timezone retornado na consulta select systimestamp from dual pertence
> > ao
> > > DB ou ao SO? Pelo que andei pesquisando este é o timezone do SO onde o
> > > RDBMS está instalado correto? Se sim alguém já teve que alterar? Quais
> > são
> > > os steps? É necessário stop/start da instance?
> > >
> > > DB: ora 11g
> > > SO: windows 2003
> > >
> > > Atenciosamente
> > > André
> > >
> >
> >
> >
>
