Re: Timezone setting on Exadata - daylight savings time

From: Stefan Knecht <knecht.stefan_at_gmail.com>
Date: Thu, 5 Oct 2017 20:30:34 +0700
Message-ID: <CAP50yQ9pCAmZcExpB096LqafZrOQku285VD9NCFNSJ5LtADFqQ_at_mail.gmail.com>





One needs to be mindful of the potential data corruptions when doing this, though. It's very easy to get any kind of batch job or other connection that doesn't go through that listener and then end up using different data.

Just a thought...

Stefan

On Thu, Oct 5, 2017 at 7:43 PM, Matt Adams <MAdams_at_equian.com> wrote:

> Just as any FYI, in case it meets your needs in the future
>
>
>
> You could set the time zone in the environmental variable for the
> listener..
>
>
>
>
>
> SID_LIST_LISTENER4 =
>
> (SID_LIST =
>
> (SID_DESC =
>
> (SID_NAME = DB01)
>
> (ORACLE_HOME = /u00/app/oracle/product/11.2.0.4)
>
> (ENVS='TZ=CST6CDT')
>
> )
>
> )
>
>
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_
> freelists.org] *On Behalf Of *De DBA
> *Sent:* Thursday, October 05, 2017 7:40 AM
> *To:* oracle-l_at_freelists.org
> *Subject:* Re: Timezone setting on Exadata - daylight savings time
>
>
>
> Thanks to all who responded.
>
> We never explicitly configured any time zones per database, so the
> timezone was "only" configured in 3 levels. In the end I had to do the
> following to change the timezone for a node:
>
> 1. Change the OS timezone by editing the file /etc/sysconfig/clock and
> create a soft link from the file /usr/share/zoneinfo/Australia/Brisbane
> to /etc/localtimezone (also works for other RedHat based distributions -
> Doc ID 1931729.1)
> 2. Remove the TZ variable from the .bash_profile of both the grid and
> the oracle users - they are apparently put in there by the initial install
> scripts, and force a user-specific timezone. Not needed unless you want the
> TZ to differ from the system timezone.
> 3. Edit the file $GRID_HOME/crs/install/s_crsconfig_<nodename>_env.txt
> which in spite of the .txt extension is actually a configuration file. The
> setting in this file overrides the user-level and system-level settings. In
> the same directory is also a file called crsconfig_params, but that file is
> not important and can be left as is ( Doc ID 1209444.1 - this also contains
> Linux OS instructions, but they are no longer valid)
>
> After changing the above, the node needs to be restarted. Or perhaps not,
> Oracle support was not entirely clear on that point. Rebooting does not
> hurt though, as the cluster ware does need to be restarted to make the
> change in step 3 take hold.
>
> According to Support, one is not allowed to change _anything_ on a storage
> cell and that includes the timezone and password policy (another point of
> contention). The compute nodes can run a different timezone than the
> storage cells.
>
> Cheers,
> Tony
>
> On 02/10/17 03:26, John Chacho wrote:
>
> Check out these docs if you haven't already.
>
>
>
> The first suggests "You can change the time zone that Oracle Clusterware
> uses for a database by running the command srvctl setenv database -env
> 'TZ=*time zone*'"
>
>
>
> Real Application Clusters Installation Guide
>
> 6.3 Understanding Time Zone Settings on Cluster Nodes
>
> https://docs.oracle.com/database/122/RILIN/understanding-time-zone-
> settings-on-cluster-nodes.htm#RILIN1083
>
>
>
>
>
> Grid Infrastructure Installation and Upgrade Guide
>
> 3.14 Setting Network Time Protocol for Cluster Time Synchronization
>
> https://docs.oracle.com/database/122/CWAIX/setting-
> network-time-protocol-for-cluster-time-synchronization.
> htm#CWAIX-GUID-9A4CE718-6742-4F58-A8B0-2CCB6151E26F
>
>
>
>
>
> Exadata Database Machine Maintenance Guide
>
> 4.11 Changing the Time Zone Settings
>
> http://docs.oracle.com/cd/E80920_01/DBMMN/maintaining-
> exadata-components.htm#DBMMN22942
>
>
>
> Regards,
>
> John
>
>
>
> On Sun, Oct 1, 2017 at 4:18 AM, De DBA <dedba_at_tpg.com.au> wrote:
>
> Update:
>
> After shuttling the SR between RDBMS and NLS groups, Oracle allowed us to
> change the time zone settings on just the compute nodes. They were not very
> clear on whether a reboot was necessary and advised us that "...*for os
> level changing timezone you might need to reboot server to effect the value*.
> *please* * check with Unix admins once on that*... " That was the NLS
> group, who were apparently oblivious to the fact that the SR was raised as
> a Hardware/OS SR. By the UNIX admin... :/
>
> Oracle Support is not what it used to be...
>
> So we rebooted both nodes. All good & dandy, except the database still did
> swap to DST after all that. Turns out that the bash profiles for both the
> oracle and grid home owners had the TZ variable set to the original value,
> but removing that still made no difference.
>
> Checking the environment of the running clusterware processes, all of them
> including the databases started with the clusterware tool srvctl, have yet
> another setting for TZ. This is now the situation:
>
> - system timezone = Australia/Brisbane
> - oracle/grid TZ - reset (was Australia/Sydney)
> - ocw timezone = Australia/Canberra
>
> Where does the ocw get it's timezone setting from? The TZ it uses is not
> expected or documented..
>
> Cheers,
> Tony
>
>
>
> On 29/09/17 20:45, De DBA wrote:
>
> Hi Franky,
>
>
>
> Thanks, I did find that doc but it doesn't go into detail - especially
> whether it is OK to have one or two components run with another timezone
> than the rest of the stack. Also, I cannot find whether I need to reboot
> Linux after changing the /etc/localtime file to make the OS notice the
> change..
>
>
>
> Cheers,
>
> Tony
>
>
>
> On 29/09/17 19:41, Franky Weber Faust wrote:
>
> Hi Tony,
>
>
>
> You can follow this doc 1931729.1
>
> Since Exadata runs Linux it should work for you.
>
>
>
> Regards,
>
>
>
> Franky
>
>
>
> On Fri, 29 Sep 2017 at 00:55 De DBA <dedba_at_tpg.com.au> wrote:
>
> G'day.
>
>
> A BI collegue just realised that this weekend part of Eastern Australia
> will change over to Daylight Savings time. Our exadata is in that part, and
> set up with the local timezone, but the business itself is not. As a result
> the database will likely change to AEDT with the rest of the datacentre,
> throwing all kind of schedules in disarray as batch jobs running in
> Queensland will continue to run at their normal time (relative to UTC).
>
>
> I can't seem to find any information on how to disable daylight savings
> time safely for the entire exadata. Any ideas?
>
>
> Cheers,
>
> Tony
>
> --
> http://www.freelists.org/webpage/oracle-l
>
> --
>
> *Kind regards / Cordialmente / Saludos cordiales / Sincères amitiés / Mit
> freundlichen Grüßen / Cordiali saluti,*
>
>
>
> Franky Weber Faust
>
> Oracle DBA
>
> Skype: franky.faust
>
> [image: Image removed by sender.][image: Image removed by sender.][image:
> Image removed by sender.][image: Image removed by sender.]
>
>
>
>
>
>
>
>
>
> **** This communication may contain privileged and/or confidential
> information. If you are not the intended recipient, you are hereby notified
> that disclosing, copying, or distributing of the contents is strictly
> prohibited. If you have received this message in error, please contact the
> sender immediately and destroy any copies of this document. ****
>

-- 
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat |
_at_zztat_oracle









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

image001.jpg
(image/jpeg attachment: image001.jpg)

image004.jpg
(image/jpeg attachment: image004.jpg)

image002.jpg
(image/jpeg attachment: image002.jpg)

image003.jpg
(image/jpeg attachment: image003.jpg)

Received on Thu Oct 05 2017 - 15:30:34 CEST

Original text of this message