RE: Oracle Timezone Updates

……how are folks handling “fall back”…….

42 – or “it depends”.

Seriously, anyone who’s been paying attention for more than a year should already KNOW how any application older than a year will behave and so SHOULD be able to make an “intelligent” or at least informed decision about which option to take. I’d also offer the opinion that any time one uses a timestamp or date, the impact of time shifts and/or timezone changes MUST be considered.

Back when the US government moved the date for the “time change” (at least the last time they did so) and I was a practicing DBA, I was somewhat successful in “forcing the issue” by announcing a month in advance that the databases I managed would be shut down for 62 minutes. Of course, the objections were loud and long; and we really DIDN’T shut down ALL the databases; but it did force the research. Several applications that might have been impacted were corrected, a few databases were shut down, and when we DID have a few “failures”, the correct people were engaged to fix the issues, rather than “blamestorming”.

Clay Jackson

From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> On Behalf Of Mark W. Farnham Sent: Monday, October 30, 2023 12:52 PM To: srcdco_at_rit.edu; 'Andy Wattenhofer' <watt0012_at_umn.edu> Cc: oracle-l_at_freelists.org
Subject: RE: Oracle Timezone Updates

CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.

The long standing enhancement to error messages such as ORA-39405 would be to include a link to the required documentation in the error message.

Sigh. Thank goodness for oracle-l and others to help solve such problems (especially since support apparently botches telling you the required database update in addition to the patch).

By the way, how are folks handling “fall back” these days? While I applaud the efforts to do away with twice a year time shifts (and skipping ahead doesn’t really pose as much of a potential problem as falling back, since it cannot create times out of order, just possibly squeeze promised delivery times), we’ll still have them for a while.

Options I’m aware of are:

1. All the databases use unshifting prime meridian time
2. All the database use standard time and ignore daylight savings time
3. Shutting down for 62 minutes surrounding the shift hour, so no time can be duplicated
4. What? Me worry? The database won’t break and a little bit of possible oddity in user data ain’t my problem

There are different downsides to each of these from the user viewpoint.

Does anyone have any significant improvement on these options?

mwf

From: oracle-l-bounce_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Scott Canaan ("srcdco") Sent: Friday, October 27, 2023 3:08 PM
To: Andy Wattenhofer
Cc: oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org> Subject: RE: Oracle Timezone Updates

Thanks, that did it.

Scott Canaan ‘88
Sr Database Administrator
Information & Technology Services
Finance & Administration
Rochester Institute of Technology
o: (585) 475-7886 | f: (585) 475-7520
srcdco_at_rit.edu<mailto:srcdco_at_rit.edu> | c: (585) 339-8659 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

From: Andy Wattenhofer <watt0012_at_umn.edu<mailto:watt0012_at_umn.edu>> Sent: Friday, October 27, 2023 2:56 PM
To: Scott Canaan <srcdco_at_rit.edu<mailto:srcdco_at_rit.edu>> Cc: oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org> Subject: Re: Oracle Timezone Updates

The binary files were installed with the 19.20 RU (35320081), but you still need to update the timezone in the database(s). The procedure for that is in doc id 2940808.1<https://support.oracle.com/epmos/faces/DocContentDisplay?id=2940808.1>.

Andy

On Fri, Oct 27, 2023 at 1:49 PM Scott Canaan <dmarc-noreply_at_freelists.org<mailto:dmarc-noreply_at_freelists.org>> wrote: I am trying to migrate a database from Red Hat 7 to Red Hat 8 both with Oracle 19.20. I’m using impdp over the network. When I invoke impdp, I get the following error:

ORA-39405: Oracle Data Pump does not support importing from a source database with TSTZ version 41 into a target database with TSTZ version 32.

I went to Oracle support to find out how to update the timezone to 41 in the new database. It sent me to patch 35099667. I downloaded the patch and attempted to install it. Opatch told me that the patch was included in patch 35320081, which was installed on July 19. So the timezone is still at 32.

How do I get the timezone upgraded to 41?

Scott Canaan ‘88
Sr Database Administrator
Information & Technology Services
Finance & Administration
Rochester Institute of Technology
o: (585) 475-7886 | f: (585) 475-7520
srcdco_at_rit.edu<mailto:srcdco_at_rit.edu> | c: (585) 339-8659 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

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