After a bit more poking around I've realized that the metadata has a
modifier, DISPLAY_TZ, and this column's value is applied to the stored date
for display in the console, causing the "raw" date to display differently.
Dave
On Fri, Jan 5, 2018 at 5:52 PM, Tony <dedba@xxxxxxxxxx> wrote:
I don't understand why Oracle seems to think that TZ should be set. It
usually isn't. You can better check the locality by using the "locale"
command.
Cheers
Tony
On 6 January 2018 9:05:46 am AEST, Dave Herring <gdherri@xxxxxxxxx> wrote:
--
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.proper
ties
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
Sent from my Android device with K-9 Mail. Please excuse my brevity.
