Re: OMS tz

Thx for the reply Courtney! Our OEM envs are rather simplistic in that all components for each install are on the same server.

$TZ is not defined on the server.

% grep TZ $AGENT_INSTANCE_HOME/sysman/config/emd.properties agentTZRegion=US/Eastern

Checking all non-repository, non-ASM processes, none of them show $TZ being defined. This was done using:

for PID in `ps -u oracle -o pid,cmd --noheader | grep -vE '(grep|ora_...._<Oracle SID>|oracle<Oracle SID>|oracle\+ASM|asm_...._\+ASM)' | awk '{print $1}'` do

   PID_TZ=`cat /proc/${PID}/environ 2>&1 | xargs -n 1 -0 | grep -E '(Permission|TZ)'`

   echo "$PID ${PID_TZ:-TZ not set} `ps -p $PID -o cmd --noheader`" done

On Fri, Jan 5, 2018 at 8:27 AM, Courtney Llamas <courtney.llamas_at_oracle.com> wrote:

> I don’t know what the particular fix is here, but I would suggest logging
> an SR w/ support, here’s some ideas to get you started… It’s important to
> find whether it’s from the OMS (where you run ./omsctl) or from the DB
> host, where you run the db. This could be the same server, but generally
> is not in most installations.
>
>
>
>
>
> The timezone is set in the emd.properties file of the agent, so start with
> collecting the value from there, and
>
> 1. Check server (Target, OEM Repo and OMS)
> echo $TZ
>
> 2. Check agent (a target agent, and the agents on OEM Repo and OMS
> server)
> $grep TZ /u01/app/oracle/agent12c/agent_inst/sysman/config/emd.properties
> agentTZRegion=US/Eastern
>
> 3. Check DB (a target DB , and the OEM repository DB )
> *$sqlplus sys/<password>_at_<tns_alias> as sysdba*
>
> SQL*Plus: Release 12.1.0.2.0 Production on Mon Nov 6 12:44:45 2017
>
> Copyright (c) 1982, 2014, Oracle. All rights reserved.
>
> Connected to:
> Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit
> Production
> With the Partitioning, Automatic Storage Management, OLAP, Advanced
> Analytics
> and Real Application Testing options
>
> SQL>ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
>
> Session altered.
>
> SQL>select sysdate from dual;
>
> SYSDATE
> --------------------------
> *06-NOV-2017 06:47:15*
>
> SQL>
>
>
>
> --
> - Courtney
>
> [image: Oracle] <http://www.oracle.com/>
> Courtney Llamas | Consulting Member of Technical Staff
> Phone: +2814108258 | Mobile: +8324720596
> Oracle Strategic Customer Program
>
> Oracle
>
> [image: Green Oracle] <http://www.oracle.com/commitment>
>
> Oracle is committed to developing practices and products that help protect
> the environment
>
>
>
> *From:* Dave Herring [mailto:gdherri_at_gmail.com]
> *Sent:* Thursday, January 04, 2018 4:01 PM
> *To:* ORACLE-L <oracle-l_at_freelists.org>
> *Subject:* OMS tz
>
>
>
> Folks, I recently noticed that dates displayed in OEM appear to be 5 TZ
> off from expected and I'm wondering how to correct this. The environment
> is 12.1.0.4 running on RHEL 6.6. My comparison is from the following:
>
> Whether SQL Developer (client) or OMS server sqlplus, I check the
> LAST_UPDATED_DATE of a given Incident from EM_INCIDENTS. From my sample
> check I get "04-JAN-18 02:01:05". I check the same Incident in the Console
> under "Enterprise -> Monitoring -> Incident Manager" and get "Jan 3, 2018
> 9:01:05 PM EST". Yet based on the dates displayed on the server they match
> up with EST. So somehow both the server and OMS running on the server
> think they're in EST yet the OMS is 5 hours earlier.
>
> Anyone have any ideas where the mixup is and how to fix it? Everything
> else in OEM seems to be running in the *correct* EST, as in all our Jobs.
>
>
> --
>
> Dave
>

-- 
Dave









--
http://www.freelists.org/webpage/oracle-l






(image/gif attachment: image002.gif)




(image/gif attachment: image001.gif)