Версия ОС SLES11-SP1-x86_64
Миграция с Oracle 10.2.0.4.Linux-x86_64 на Oracle 11.2.0.3.Linux-x86_64
Все прошло нормально и ибсо даже работает. Но есть одно "но".
Миграция выполнялась с параметром plsql_optimize_level=0
В результате, после utlirp и utlrp все объекты базы, включая все объекты sys, оказались собранными с отладочной инф-цией.
В TOAD все объекты выглядят изъеденными жуками.
Напрягает не сам факт наличия отладочной инф-ции, а картинка в жабе .
При компиляции объекта с plsql_optimize_level < 2 появляется запись
в sys.idl_char$ i where i.part = 1 and i.obj#=мой объект
/* part: 0 = diana, 1 = portable pcode, 2 = machine-dependent pcode */
Именно по факту наличия такой записи жаба отображает "жука".
При компиляции объекта с plsql_optimize_level > 1 эта запись не создается или удаляется.
Перед миграцией по sys.dba_plsql_object_settings все объекты
собраны с plsql_optimize_level = 0.
В доке сказано:
PL/SQL Control Parameters
The behavior of some of the Oracle parameters which control the behavior of PL/SQL changes in Oracle Database 11g Release 1 (11.1):
• If PL/SQL debug code generation mode is selected by any parameter setup, then native code generation is turned off.
• Debug code generation is on if the PLSQL_OPTIMIZE_LEVEL <= 1.
• PLSQL_DEBUG is deprecated.
You should use PLSQL_OPTIMIZE_LEVEL instead. A deprecation warning is issued if PLSQL_DEBUG is used.
• If PLSQL_OPTIMIZE_LEVEL <= 1, then native code generation is turned off.
• PLSQL_COMPILER_FLAGS is obsolete. It has no effect any longer and draws an error message that an illegal option is being set.
Ну и собственно вопрос: кто что об этом думает?
Может для системы поставить plsql_optimize_level = 2 или даже 3,
а объекты ибсо собирать с настоятельно рекомендуемым plsql_optimize_level=0, установив этот параметр для сессии
Токда хотя бы sys не будет погрызен жуками жабы
P.S. utlirp и utlrp не изменяют опции компиляции объекта, т.е. если у него был plsql_optimize_level = 0, он таким и останется, что влечет пересборку в ora11 с debug.
Миграция с Oracle 10.2.0.4.Linux-x86_64 на Oracle 11.2.0.3.Linux-x86_64
Про установку подсистемы XML DB.
В базе (при миграции на 10g по-умолчанию) уже установлена XML DB. Её компоненты
используют tablespace SYSAUX (рекомендация oracle).
После миграции на 11g она там и остается. В инструкции ЦФТ по миграции сказано установить её в отдельный tablespace xdb.
Ну хорошо. После миграции переустановил xdb (catnoqm.sql и catqm.sql). Теперь думаю, а нужна ли ибсо система XDB, кроме как
для правил ACL? В ora11 у скрипта создания появился 3 параметр:
if YES and compatibility is at least 11.2,
then XDB repository will be stored as secure files;
otherwise, old LOBS are used
Т.е. если ибсо сама не планирует использовать XDB, то пусть она останется после миграции в старом варианте и в SYSAUX? И пересоздание xdb на новый лад - излишняя операция?
Кто что думает?
кто нибудь сталкивался при переходе с ошибкой Ora-01017 , заходим в нвигатор без проблем , пробуем поменять пароль и ORA-01017 : invalid username/password; logon denied
кто нибудь сталкивался при переходе с ошибкой Ora-01017 , заходим в нвигатор без проблем , пробуем поменять пароль и ORA-01017 : invalid username/password; logon denied
- sec_case_sensitive_logon=FALSE , инструкция "Замечания по миграции
продуктов на основе "ЦФТ-Платформа Развития"на Oracle 11g Release 2 "
- пункт 7.12
кто нибудь сталкивался при переходе с ошибкой Ora-01017 , заходим в нвигатор без проблем , пробуем поменять пароль и ORA-01017 : invalid username/password; logon denied
- sec_case_sensitive_logon=FALSE , инструкция "Замечания по миграции
продуктов на основе "ЦФТ-Платформа Развития"на Oracle 11g Release 2 "
- пункт 7.12
А топик оказывается жив. Так может кто откликнется на мои вопросы про PLSQL_OPTIMIZE_LEVEL и XDB при переходе на 11.2
А то скоро предстоит боевую систему курочить , а тут непонятки
Т.е. если ибсо сама не планирует использовать XDB, то пусть она останется после миграции в старом варианте и в SYSAUX? И пересоздание xdb на новый лад - излишняя операция?
Кто что думает?
- у цфт только рекомендации, а что и как - как говорится дерзай, PLSQL_OPTIMIZE_LEVEL=2 - у себя пользую с 10-ки ничего негативного не видел за 2 года( но рекомендовать не могу - т.к. цфт не рекомендуют >1), XDB можно и оставить как есть, а в боевой системе лучше придерживаться официальной рекомендации - как показывает практика , если к ним потом обращаться - первые слова будут, ну вот, мы же советовали так и так, вы сделали по-своему....и т.д. и т.п.
P.S. Иногда лучше проверять чем доверять - четко зная цену проверки.
to Serj спасибо за ответ. Пока сделал строго по рекомендации цфт имеено из-за ну вот, мы же советовали так и так, вы сделали по-своему....
Кстати для получения PLSQL_OPTIMIZE_LEVEL=2 на 11 надо еще на 10 перекомпилить базу с 0 на 2, т.к. после миграции вогнать sys в level=2 будет труднее (по моему опыту ). Аналогично с xdb: если переустанавливать, то прибивать надо на 10-ке до миграции
to Serj спасибо за ответ. Пока сделал строго по рекомендации цфт имеено из-за ну вот, мы же советовали так и так, вы сделали по-своему....
Кстати для получения PLSQL_OPTIMIZE_LEVEL=2 на 11 надо еще на 10 перекомпилить базу с 0 на 2, т.к. после миграции вогнать sys в level=2 будет труднее (по моему опыту ). Аналогично с xdb: если переустанавливать, то прибивать надо на 10-ке до миграции
- смена PLSQL_OPTIMIZE_LEVEL с 0 на 2(вместе с компиляцией всех объектов в 16 потоков) - минут 30 на М4000 4*SPARCVII, с XDB и того меньше, есть общие рекомендации , а так - у каждого додика своя методика
После перехода, необходимо перекомпилить все операции расширения, если такие создавались.
- любопытно узнать, что будет если не перекомпилировать ? - таки сдается мне что это лишняя трата времени.
Это не пустая трата времени, а бесполезная трата нервов, когда пользователи начнут заваливать сведениями об ошибках (идентификатор такой-то не найден...). Поэтому лучше загодя перекомпилировать.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Домен cftclub.ru не связан с ЗАО "Центр Финансовых Технологий" и ни в коей мере не нарушает авторских и иных прав
Владелец может не разделять мнения Участников и не несет ответственности за их публикации
Powered by phpBB
О проекте
Поиск
Отзывы
Регистрация
Вход
.
