After a recent upgrade to Enterprise Manager 12c 188.8.131.52, we noticed that the few Oracle Databases in release 10g were no more connectable:
The problem is due to the time zone table on the target database that doesn’t contain the timezone requested by the client. But who’s the client? In our case, all the target agents were correctly set to Europe/Zurich, but the timezone table of the target database contained it:
SQL> select version from v$timezone_file; VERSION ---------- 4 SQL> SELECT TZname, TzAbbrev FROM V$TIMEZONE_NAMES where TZname like 'Europe/Zurich'; TZNAME TZABBREV ------------------ --------------------- Europe/Zurich LMT Europe/Zurich BMT Europe/Zurich CET Europe/Zurich CEST
So what was causing the problem?
The upgrade process of the OMSes from 184.108.40.206 to 220.127.116.11, without the presence of a specific TZ environment variable, set the OMS timezone to Europe/Vaduz. I figured it out after searching deep and large, inside the WLS product properties:
$ pwd /u01/app/oracle/Middleware_12105/wlserver_10.3 $ cat .product.properties ... USER_TIMEZONE=Europe/Vaduz ...
Indeed, that timezone was not present in the timezone table version 4:
SQL> sELECT TZname, TzAbbrev FROM V$TIMEZONE_NAMES where TZname like 'Europe/Vaduz'; no rows selected SQL> alter session set time_zone='Europe/Zurich'; Session altered. SQL> alter session set time_zone='Europe/Vaduz'; ERROR: ORA-01882: timezone region not found
After setting explicitly the TZ to Europe/Zurich on the OMS servers and restarting the OMSes, everything was fine again.