Re: OMS tz

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_at_tpg.com.au> 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_at_gmail.com> 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_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.proper
>>> ties
>>> 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
>>>
>>
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

-- 
Dave

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