Обновление time zone при помощи DBMS_DST
Tol2000
Дата: 28.03.2011 18:31:45
Доброго времени суток!
Тестил апгрейд БД с 11.1 на 11.2 при помощи DBUA.
ОС: 2003 виндовый сервер.
Все прошло успешно. Собственно, я, кроме запуска ассистанта, вообще ничего не делал, он все сделал сам.
Меня пока смущает, что он предупредил о необходимости обновления тайм зоны при помощи пакета dbms_dst.
Полез в доку, нашел, что в моей БД версия файла 4 (SELECT version FROM v$timezone_file).
Теперь смотрю DBMS_DST.BEGIN_PREPARE (new_version IN BINARY_INTEGER) и вижу там параметр new_version.
Вопрос: где мне взять этот самый new_version и связан ли он с version из v$timezone_file?
В той БД, что сразу ставилась на 2й релиз (11.2), select version FROM v$timezone_file возвращает 11.
Но откуда брать этот самый new_version, имея на руках только инсталляцию СУБД 11.2?
Или, может, я что-то не так понимаю... или вообще не стоит заморачиваться с этим апдейтом? Хотя, вон Россия собирается отменить переход на зимнее-летнее время, и такой апдейт может понадобиться...
Вячеслав Любомудров
Дата: 29.03.2011 02:48:26
Файл таймзоны (да и DBTIMEZONE сама по себе) влияет только на данные в столбцах TIMESTAMP
WITH LOCAL TIME ZONE
Если планируется их использовать, то рекомендуется выставлять фиксированную таймзону (а лучше вообще с нулевым смещением) без всяких переходов летнее/зимнее
Рекомендация, к сожалению, появилась позже, чем сама фича
В результате, отжиги нашего Властелина Времени оказывают удручающее действие
Tol2000
Дата: 29.03.2011 10:51:43
Вячеслав Любомудров,
Спасибо! Я вообще думаю, что какое время сервер, так сказать, проставил изначально, такое оно и должно быть :)
Мы такой тип данных нигде не используем, более того, не используем даже просто timestamp.
Единственное, почему я за это спросил и заволновался... я подумал, что такие типы данных могут быть где-то, скажем, в репозитории того же апекса, dbconsole или системного словаря...
А вообще, если у меня на свежесозданной БД пишет, что версия 11, то может проапгрейдю до 11й... для того, чтобы не муляло :) Или лучше вообще не трогать? ))
Tol2000
Дата: 29.03.2011 17:37:33
Вячеслав Любомудров
Дата: 30.03.2011 02:03:20
В связи с нашими инициативами (по поводу неспособности настроить в iPhone зимнее время), в течении полугода придется очередной патч ставить
И, кстати, почему файл таймзоны 11 версии? Я полгода назад интересовался -- была 14. Сейчас, возможно, и новее
stil
Дата: 24.11.2011 15:45:13
Ссылка к сожалению уже не работает ((( Пойду погуглю
Tol2000
Дата: 01.12.2011 21:47:44
Вячеслав Любомудров,
Таки 14я ) По кр. мере, в патче 11.2.0.2. А так, отдельно, кажется и попозже есть уже.
Но вот у нас не используются поля timestamp with local timezone, и оно к лучшему конечно!) Собственно, делал апгрейд методом аут-оф-плейс, очень даже все цивильно и хорошо.
1. Ставишь Оракул в новый дом как только ПО.
2. Выполняешь всякие преапгрейд чеки скриптовые, там чет по мелочам
3. Запускаешь DBUA и наслаждаешься, пока она тебе там все пропатчит, в том числе и таймзону до 14 пропатчила мне. Да, если есть поля timestamp with local timezone, то там надо, насколько я понял, просто скорректировать в них данные, исходя, скажем, из того, что по новому закону вон именно в тот месяц уже, скажем, был отменен переход на летнее время, а в тех данных он еще записан с его учетом... что ли... Наверное, где-то так... Хорошо, что мы это не используем (тьфу три раза)))
4. Ну там, по мелочам после апгрейда. Но в общем я очень доволен, что наконец-то Оракл стал выпускать патчи как самостоятельные инсталляции. Хотя... я просто ленив наверное )))
Кстати, вопрос назрел один по поводу апгрейда методом аут-оф-плейс... но задам его лучше отдельной темой )