Re: OMS tz

From: Dave Herring <gdherri@xxxxxxxxx>
To: Courtney Llamas <courtney.llamas@xxxxxxxxxx>
Date: Fri, 5 Jan 2018 17:05:46 -0600

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@xxxxxxxxxx>
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>@<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@xxxxxxxxx]
*Sent:* Thursday, January 04, 2018 4:01 PM
*To:* ORACLE-L <oracle-l@xxxxxxxxxxxxx>
*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

Follow-Ups:
- Re: OMS tz
  - From: Tony

References:
- OMS tz
  - From: Dave Herring
- RE: OMS tz
  - From: Courtney Llamas

Re: OMS tz

Other related posts: