Goofy122Version Control для pl/sqlЧто значит "для pl/sql"?Goofy122При чтобы не обновять вручную.Что значит "обновять вручную"?

Формализуй требования.

Кроик Семён,

А как накатываешь изменения на уже работающую бд?

Кроик СемёнAmKadКроик Семён,
А как накатываешь изменения на уже работающую бд?


проектирую на девелоперской базе

все CREATE TABLE / ALTER TABLE / INSERT / UPDATE / RENAMEs записываю в Update-скрипт

внизу этого скрипта еще TODO-список из указаний, какие процедуры/функции/пакеты создать. Они лежат и разрабатываются в виде отдельных файлов и не имеет смысла их полностю раскрывать в Update-скрипте
Бывает так, что забыл добавить в update-скрипт или вызвать перекомпиляцию измененной ХП, и в результате, получил состояние прода, отличающее неполнотой по отношению к дев-у? Если да, то сколько времени уходит на то, чтобы понять, какое из изменений было пропущено?

sharkerrлибо liquibase http://www.liquibase.org/, но нужно допиливать плагин для Oracle (ограниченный он какой-то)А можно поподробнее?

sharkerr, orac_listGitora http://www.gitora.com/ Посмотрел презентацию и документацию, касающуюся Managed Schema. Позволю себе попридираться.

0) Презентация содержит только примеры управление пакетами. Продемонстрирована только двусторонняя синхронизация между активной веткой репозитория и БД - только на примере пакетов, это не очень интересно. Гораздо интереснее было бы взглянуть на управление hard objects (выражение взято из их документации), как таблицы, индексы, констраинты. Идем дальше.
1) Смотрим документацию . Из того, что я понял, на dev-схему вешается некий listener ddl-команд (вероятно ddl-триггер). И прокатив список команд (цитирую из той же доки)



в результате на каком-то из последующих этапов (видимо, при коммите) получаем пакет наката на последующие контура:

Из того, что мне сразу бросилось в глаза - никакого логирования в перманентные таблицы об ходе выполнения. Собственно, читаем доку дальше.

http://blog.gitora.com/tag/documentation/ Errors during its execution does not prevent the doModel function from executing remaning DDL statements.Да, по коду это видно. Сомнительная фича.

http://blog.gitora.com/tag/documentation/ The function captures these errors and returns them as a CLOB value.Та-а-к. Запустил я процедуру DoModel. А за месячный релиз у меня там столько alter-ов собралось - по пальцам рук и ног десяти сотрудников не сосчитаешь. И тут в какой-то момент у меня теряется связь с сервером (причину выберем самую абсурдную - я ногой случайно пилот выключил) - не получил я ответный clob в общем. Включаю снова комп, переподключаюсь к БД. А как теперь понять, какие alter-ы прошли, а какие упали? У тут я понимаю, что в обещанный мною моему начальнику получасовой простой системы я не укладываюсь, а тот, в свою очередь, премию урежет, и пиво лишний раз на радостях попить не сходишь. Эх нога, нога, лучше б я тебя к стулу привязал.

Ну да ладно, допустим, ногой я не дрыгал и ответный clob все-таки получил. Анализирую. Блин, да там чуть ли не каждый двадцатый-тридцатый alter упал. Почему ж так много-то? А, ну правильно, некоторые последующие завязаны на результаты предыдущих. Причины падения первых могут быть разные - отсутствие привилегий (а ведь наш dba клялся и божился, что тестовое окружение соответствует продовому), нехватка места, квот (на тесте данных было мало, а необходимый объем табличного пространства для индекса на проде мы оценить забыли). Ну ладно, привилегий додали, места добавили/квоты повысили. Конечно, gitora здесь не виноват, здесь виноваты мы, не досмотрели. Но давайте посмотрим, как мы будем выходить из этой ситуации. Что делать дальше?
http://blog.gitora.com/tag/documentation/ This way, the same GITORA_MODEL package can be executed many times even if contains DDL statements that are previously executed in the target database (because these statements will silently fail)Вот те на. 5 баллов! Как мне в результате повторного наката определить: упал alter по той же причине, по которой упал в первый раз, или упал потому, что уже выполнился в первый раз? А-а-а, уже знаю что вы скажете: в log-е есть SQLErrm и dbms_utility.format_error_backtrace - анализируй. Хорошо, пойду писать нетривиальный реглярус, чтобы выдернуть только нужные. Не то что в полчаса, и в час-два времени простоя могу не уложиться.

Вторая сторона абсурдности повторного запуска пакета - вот дернул меня черт добавить в релиз пересоздание индекса с дополнительной колонкой - имя индекса менять не хотелось - много где хинтами прибито. А это два удачно выполнившихся на предыдущем шаге изменения - drop и create. Ну, надеюсь, drop отработает быстро. А create - мне опять сортировку по полному объему таблицы ждать?

Напрашивается выход - аккуратненько из кода пакета после каждого наката выпиливать удачно выполнившиеся изменения (согласно логу) - только бы не ошибиться, с продом ведь работаю, во время простоя не укладываюсь, тороплюсь, нервничаю. Даже боюсь представить, что будет, если ошибусь.

Не раскрыта тема DML-обновлений. Кейс - я хочу добавить поле, заполнить его чем-то (DML: merge или update), а потом сделать его notnull-ным и уникальным. Мне руками вставлять DML в автосгенеренный пакет при каждом коммите?

Резюме : в общем, если у тебя все удачно накатилось с первого раза - считай повезло. Если вылазят ошибки - то с этим инструментом я тебе не завидую.

P.S. По поводу того, что падение применения изменений не останавливает, а продолжает накат - я на вскидку не смог придумать сценария, когда удачное выполнение какого-то DDL после неудачного предыдущего DDL приводит к коллизиям.
С DML-ем все понятно, при падении одного DML все последующие DML запускать нельзя, потому что они могут быть завязаны на результаты первого и выполниться "удачно" (либо запускать только те, что не имеют зависимостей с упавшим).

А вот с DDL: поясню, что имею в виду.
Пусть у нас есть два последовательных изменения, которые согласно скрипту наката должны довести систему до состояния STATE1.
STATE0 -> DDL1 -> DDL2 -> STATE1
Но в результате первого запуска первый упал, но удачно выполнился второй. Мы устранили причину падения первого и перенакатили. В результате имеем:
STATE0 -> DDL2 -> DDL1 -> STATE1'.
Задумался, есть ли такие DDL1 и DDL2, при которых STATE1 != STATE1'? Что-то не могу придумать, если кто знает, поделитесь идеей.

AmKadЗадумался, есть ли такие DDL1 и DDL2, при которых STATE1 != STATE1'? Что-то не могу придумать, если кто знает, поделитесь идеей.Есть сценарий, при разных исходных состояниях теста и прода: на тесте индекс был, а на проде не было (хотя это само по себе уже косяк), состояние теста = STATE0, а состояние прода = STATE0'.

Drop/create index. На тесте все прошло по хронологи: дропнули, создали. А на проде drop упал, прошел create как DDL2, а потом drop как DDL1. Случай вырожденный, немного не соответствует поставлененому мною вопросу, но все равно неприятный.

dmdmdmcreate role/table/view
grant на это делоЭто не соответствует постановке моего вопроса - в данном случае второй ddl не пройдет, если не прошел первый.

ElicВсё ещё веришь в золотую пулю?
Конкурентный контроль версий в многопользовательской БД - это фикция.В золотую пулю конечно нет.
Меня интересует не столько вопрос ведения версий БД в СКВ в плане хранения PL/SQL кода, сколько вопрос согласованного наката изменений схемы на Dev-Test-Prod контура. Именно поэтому я акцентировал внимание на методе применения alter-ов, предлагаемом в gitora. Допускаю, что у разных подходов могут быть свои плюсы и минусы, но хуже чем этот не придумаешь. Хотя, если продукт развивается, вполне возможно, что когда-нибудь он станет более юзабельным.