Pull to refresh

Comments 14

Почему не regexp_replace и dbms_utility.compile_schema?
Не REGEXP_REPLACE — потому что я регулярными выражениями пользоваться не умею.
Не dbms_utility.COMPILE_SCHEMA — потому что это имело бы смысл при прямом изменении исходников в таблице SYS.SOURCE$, но мне не по себе от такого вмешательства в лоб.
Но конечно после того как все исходники будут обработаны — будет какое то количество INVALID объектов, поэтому как завершающий этап dbms_utility.COMPILE_SCHEMA — будет верным шагом, можно добавить в конец процедуры P_EXECUTE_CODE_UPDATE.
Можно прояснить пару моментов: 1) при таком подходе, если во время компиляции (шаг 3) к объекту идут обращения, он нормально скомпилится. 2) Как объект будет вести себя при обращениях к нему после замены исходников, но до компиляции (т.е. между 2 и 3 шагами)?
Компиляция только на третьем шаге происходит, непосредственной подмены исходников — изменения записей таблицы SYS.SOURCE$ в алгоритме нет.
Собственно компиляция выполняется через "API" сервера, что бы сервер сам как ему надо все вопросы разрулил, и вообще был в курсе что у него исходники поменялись.
Пока не произошло компиляции ( CREATE OR REPLACE ) объекты себя ведут как всегда :)
После компиляции в некоторых сессиях могут вызываться старые версии объектов, поэтому если у пользователя что то "глючит", то ему просто надо перелогинится.
Oracle не даст скомпилировать код, пока есть хотя бы один сеанс, его выполняющий.
Сессия компиляции в таком случае будет ждать освобождения DDL блокировки, что будет видно в словаре данных: dba_ddl_locks.
Из моего опыта, когда у тебя сваливается вся база, тысяч 15 процедур/пакетов/функций и ты пытаешься всё инвалидное откомпилить, да иногда приходиться убивать пользовательские сессии, а иногда без этого обходиться, да иногда пользователям надо перелогинится, а иногда без этого обходиться.
Мой опыт это год работы на Oracle 10g, за это время мы базу раз 10 роняли, раз на раз не приходиться, почему так — я не вникал.
Не спорю, в моей практике тоже бывает приходится убивать сессию или целую пачку, чтобы скомпилить пакет.
Просто немного не понял фразу про старые версии объектов, которые могут выполняться некоторыми сеансами. Насколько мне известно, в Oracle обеспечивается консистентность выполняемого PL/SQL кода. То есть весь выполняемый код пакета одной и той же версии и Oracle не даст обновить пакет, пока хотя бы один сеанс выполняет код из этого пакета. Я ошибаюсь?
Без понятия :)) считай эту сентенцию "старые версии объектов" авторской выдумкой, ради красного словца.
Может быть это не Oracle что то кэширует в сессии, а клиент ERP системы, и пока ERP клиент работает с устаревшими данными у пользователя происходят ошибки.
По прочтении сразу вопросы:
  1. почему нельзя было использовать dba_source (all_source,user_source) вместо недокументированного sys.source$? И dba_objects вместо sys.obj$ ?
  2. на счет компиляции из-под другого пользователя — есть такая штука alter session set current_schema=
  3. компиляцию также можно выполнить alter <object_type> <object_name> compile. При этом, возможно, исходник возьмется из source ?
вообще, после прочтения таких статей начинаешь понимать, зачем разработчики warpят исходники и считают контрольные суммы :)
В представлении DBA_SOURCE есть типы объектов но у DBMS_METADATA.GET_DDL свои правила написания имён типов, и надо будет делать подмену 'PACKAGE' на 'PACKAGE_SPEC'
"alter session set current_schema=" — прикольно, это наверное и есть тот нюанс о котором знает "TOAD", но которого не знаю я.
"При этом, возможно, исходник возьмется из source ?" — без понятия, для себя я эту задачу решил и дополнительно тратить на неё время пока не хочется.
Охохо. Чего только не учиняют люди, когда оригиналы сохранены "где-то на всякий случай" вместо системы контроля версий.
Как это должно делаться на самом деле: однострочный replace по исходному коду, коммит в репозиторий, деплой на тестовую среду (она у вас есть, кстати?), деплой на продуктовую среду.
И да, я когда-то делал и разработку "по живому" и много чего еще :(
Лучше good practices смолоду прививать.
Кстати, Oracle-based EPR из коробки с 20-летней историей — это Парус или Галактика?
Решение любой задачи подразумевает выделение ресурсов — рабочего времени, были выделены сутки, в сутки я уложился.
В стратегическом плане конечно код будет в SVN / Mercurial храниться, опять же не раньше чем мне кто то выделит недельку на изучение этой темы применительно к СУБД ( PL/SQL Developer типа умеет работать с SVN, dbForge вообще с чем угодно, но что и как пока у нас ни кто не разбирался ).
Конечно у нас есть тестовый сервер, у нас даже есть сервер разработки, схема работы конечно такая: DEV — TEST — PROD.
Про "good practices" ни чего не слышал, мы в своей работе руководствуемся "best practices" :)
Oracle-based EPR из коробки с 20-летней историей — это Парус.
"Экземпляров" Паруса у нас кстати два, один клиент это завод с дискретным производством, другой клиент — продаёт услуги, у каждого своя специфика и за 10+ лет чуть более чем полностью переписанный функционал, так что от Паруса — там только название осталось.
Sign up to leave a comment.

Articles