Что делать с базами данных для перехода на зимнее время в 2014 году
Непростое решение: что делать с базами данных для корректного перехода на зимнее время в 2014 году. Особенно если у тебя 150 баз в промышленной эксплуатации. Как ни странно, лучшее решение: ничего не делать :)Сначала обратимся к первоисточникам:
в России с 2 часов 00 минут 26 октября 2014 года 11 часовых зон. Москвы во 2-й зоне:" 2-я часовая зона (МСК, московское время, UTC+3): Республика Адыгея, Республика Дагестан, Республика Ингушетия,
Кабардино-Балкарская Республика, Республика Калмыкия, Карачаево-Черкесская Республика, Республика Карелия, Республика Коми,
Республика Крым, Республика Марий Эл, Республика Мордовия, Республика Северная Осетия — Алания, Республика Татарстан, Чеченская Республика,
Чувашская Республика — Чувашия, Краснодарский край, Ставропольский край, Архангельская область, Астраханская область, Белгородская область,
Брянская область, Владимирская область, Волгоградская область, Вологодская область, Воронежская область, Ивановская область,
Калужская область, Кировская область, Костромская область, Курская область, Ленинградская область, Липецкая область, Московская область,
Мурманская область, Нижегородская область, Новгородская область, Орловская область, Пензенская область, Псковская область, Ростовская область,
Рязанская область, Саратовская область, Смоленская область, Тамбовская область, Тверская область, Тульская область, Ульяновская область,
Ярославская область, города федерального значения Москва, Санкт-Петербург, Севастополь и Ненецкий автономный округ;"
Документация техподдержки Oracle
Есть подробное описание влияния этого перехода в документе: The Russian Government re-introduces DST in 2014 - Impact on Oracle RDBMS (Doc ID 1907147.1)Если кратко, то:
есть некая база (база Олсона), хранящая часовые пояса и смещения времени для разных часовых поясов начиная с 1970 г (начало эпохи Unix). Эти данные также хранятся (и обновляются патчем) в базе данных Оракл. Когда происходит изменение смещения (например как в случае с предстоящим изменением на зимнее время в России), эти данные вендор СУБД обновляет из базы Олсона и выпускает в виде патча для БД (в нашем случае Oracle). Если этот патч не применить, то работа с датами и временем содержащим смещения DST приведет к неверным результатам для тех часовых поясов, смещения в которых поменялись.
Если приложения работают исключительно с локальным временем без указания таймзон, то патч на базу можно не ставить, достаточно только патча для ОС.
The "Date" datatype has no timezone information stored, "sysdate" (and "systimestamp") do not use any Oracle provided timezone information. None of these are using in any way Oracle DST patches or Oracle provided DST information. "Sysdate" is purely dependent on the operating system clock, hence it IS depending on the timezone information of this operating system and/or the operating system "TZ" variable settings when the database and listener where started (!!!).
Т.е. если используются для хранения дат и времени типы без таймзоны, то они никак не используют оракловый патч с таймзонами и DST.
Зато если в базе используется TimeStamp with Time Zone то придется ставить патч и тестировать. Вот этот патч: «Patch 19396455: DST-23: DST UPDATE SEPTEMBER 2014 - TZDATA2014F» К сожалению этот патч выпустили не на все версии Oracle, например для 11.2.0.2 уже нет патча.
В шедулере базы Oracle, к сожалению, используется TimeStamp with Time Zone, поэтому щедулер возможно собъёться на один час 26 октября, поэтому разработчикам нужно будет проверить свои задания и выставить нужное смещение (а не именованную тайм зону). Надо это не забыть сделать 26 октября.
Также желательно обновить Java на все серверах, применить TZupdater tool с tzdata2014f
Текущее состояние
Смотрим как у нас Oracle работает с московской зоной на продуктовых серверах:
select from_tz(timestamp '2013-10-01 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
union all
select from_tz(timestamp '2013-11-26 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
union all
select from_tz(timestamp '2014-10-25 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
union all
select from_tz(timestamp '2014-10-26 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
union all
select from_tz(timestamp '2015-07-26 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
union all
select from_tz(timestamp '2015-10-29 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual;
-----------------------------------
TZ
01/10/2013 5:00:00.000000000 +04:00
26/11/2013 4:00:00.000000000 +03:00
25/10/2014 5:00:00.000000000 +04:00
26/10/2014 4:00:00.000000000 +03:00
26/07/2015 5:00:00.000000000 +04:00
29/10/2015 4:00:00.000000000 +03:00
-----------------------------------
Вот и первый сюрприз: база в 2013, 2014, 2015 годах переводит время на зимнее и на летнее время. То есть она не знает, что в 2011 году мы в России отменили переход на зимнее время. Как же так ? Проверяем версию тайм-зоны:
SELECT version FROM v$timezone_file;
-----------------------------------
14
-----------------------------------
Так и есть, во всех установленных базах Oracle, версий 10, 11, 12 стоит версия таймзон (база Олсона) от 2010 года! У нас никто не ставил патч 7695070 от 2011 года. А Oracle не включил в свои дистрибутивы новую версию базы Олсона, как ни странно, весь остальной мир не меняет свои часовые пояса раз в 3 года, скучно живут.
Получается что у нас Oracle неправильно работал с часовыми поясами в полях типа "*with Time Zone" последние 3 года, никто об этом не догадался, или никто такие поля не использует.
Поэтому лучший вариант для нас: ничего не трогать. 26 октября базы сами перейдут на зимнее время, ничего менять не нужно, все будет работать правильно. К тому же большинство разработчиков использует простые типы полей, баз тайм зон, для них вообще ничего не меняется, в их случае база берет дату из операционной системы. То есть достаточно на OS установить патч.
Но следующей весной базы опять сами сменят даты на летнее время (смещение 4 часа от UTC), это может вызвать проблемы для тех кто использует время с тайм зонами!
Вообще летнее и зимнее время - это вопрос философский, важно смещение от UTC. С 26 октября мы в России должны получать смещение 3 часа от UTC навечно (или пока правительству не надоест). Следующей весной непропатченные базы Oracle автоматом сменят смещение на 4 часа от UTC, что неправильно.
4) Если мы все таки решили исправить такое поведение баз Oracle. Краткая инструкция что нужно делать:
- Обновляем OPatch
- Обновляем базу минимум до версии 11.2.0.3
- Ставим патч 19396455: DST-23 (остановка базы не требуется)
- Обновляем базу данных, выполняем скрипт: Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12cR1 database . (Doc ID 1585343.1) Эти скрипты автоматически перегрузят базу данных 2 раза!
- Проверяем:
SELECT version FROM v$timezone_file;
----------
23
----------
Видно что тайм зона теперь 23 версии.
SQL> select from_tz(timestamp '2013-10-01 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
2 union all
3 select from_tz(timestamp '2013-11-26 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
4 union all
5 select from_tz(timestamp '2014-10-25 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
6 union all
7 select from_tz(timestamp '2014-10-26 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
8 union all
9 select from_tz(timestamp '2015-07-26 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual
10 union all
11 select from_tz(timestamp '2015-10-29 1:00:00','UTC') at time zone 'Europe/Moscow' tz from dual;
TZ
---------------------------------------------------------------------------
01-OCT-13 05.00.00.000000000 AM EUROPE/MOSCOW
26-NOV-13 05.00.00.000000000 AM EUROPE/MOSCOW
25-OCT-14 05.00.00.000000000 AM EUROPE/MOSCOW
26-OCT-14 04.00.00.000000000 AM EUROPE/MOSCOW
26-JUL-15 04.00.00.000000000 AM EUROPE/MOSCOW
29-OCT-15 04.00.00.000000000 AM EUROPE/MOSCOW
Видно что смещение от UTC теперь 3 часа с 26 октября 2014 года постоянно.
5) Обновление JAVA машин. На серверах приложений с Weblogic, BI, Cloud Control обязательно.
Краткая инструкция по обновлению java :
- cd /u01/distr/tzupdater
- unzip tzupdater-1_4_8-2014h.zip
- cd tzupdater-1.4.8-2014h/
- /u01/app/oracle/product/11203/dbhome_1/jdk/bin/java -jar tzupdater.jar -u
- /u01/app/oracle/product/11203/dbhome_1/jdk/jre/bin/java -jar tzupdater.jar -u
- Проверка:
/u01/app/oracle/product/11203/dbhome_1/jdk/bin/java -jar tzupdater.jar -V
/u01/app/oracle/product/11203/dbhome_1/jdk/jre/bin/java -jar tzupdater.jar -V
- Результат обеих команд должен содержать строку:
tzupdater version 1.4.8-b01
JRE time zone data version: tzdata2014h
Embedded time zone data version: tzdata2014h
Комментариев нет:
Отправить комментарий