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. Допускаю, что у разных подходов могут быть свои плюсы и минусы, но хуже чем этот не придумаешь. Хотя, если продукт развивается, вполне возможно, что когда-нибудь он станет более юзабельным.

AmKadМеня интересует не столько вопрос ведения версий БД в СКВ в плане хранения PL/SQL кода, сколько вопрос согласованного наката изменений схемы на Dev-Test-Prod контура.Набросал пример использования liquibase для наката sample-схемы HR. Любой желающий может скачать его и поиграться. Вот ссылки на репозиторий и пояснительную записку . Для того, чтобы понять пример, нужно хотя бы бегло ознакомиться описанием продукта .

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

Хотя пример не такой критичный, так как на бизнес-логику и приложение повлиять не должен.

dbms_photoshop,

Как собрать изменения в целостный пакет - это вопрос, к которому можно подойти с разных сторон. Можно, как ты предлагаешь, делать diff перед релизом и пилить его руками, а можно сразу класть изменения в нужном формате. Второй подход мне ближе.

Но после этого, их еще надо накатить. Тут тоже разные подходы.

dbms_photoshopНе совсем понятно зачем дополнительные приблуды в дополнение к системе контроля версий.Если б ты посмотрел мой пример, и те вопросы, которые я поднимал в отношении gitora, то наверное можно было бы говорить предметно.

dbms_photoshop,

Ты смотрел мой пример с liquibase? Понял, чем он отличается от простого логгирования, whenever sqlerror, spool и как там решается вопрос re-runnable?

dbms_photoshopAmKad,

Если бы мне было интересно получить фидбек по интересующему вопросу - я бы несколько иначе разговаривал.Была тема СУБД. История изменений , где мы в дискутивной форме обсуждали этот вопрос. Правда она длинная, не уверен, станешь ли ты ее читать.
dbms_photoshopБольше не лезу. Хорошего дня. :))Спасибо, и тебе успехов.

Все последующие изменения схемы данных проносятся как отдельные chageset-ы. На изменение суммы LB ругается, чтобы никто задним числом после наката их не менял.

run09Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы?Снимай метаданные с БД после наката. Либо веди модель в CASE-инструменте.

run09Эти метаданные ведь все равно должны лежать отдельно от LB.Да.

run09Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы?Посмотри на DBDoc , может это то, что тебе нужно. Там и пример какой-то есть. Сам я пока не разбирался.

run09Спасибо. Пока решил административно разделить установку и миграции. Изменения вносить вездеБез регулярной сверки метаданных "установка" и "миграции" гарантированно разъедутся. Инфа 146%. На мой скромный вкус вносить руками изменения в два места - это лишняя работа.

run09Я так понимаю, в случае только с одной "миграцией", мне нужно будет последовательно накатывать все изменения...Это не так страшно, как может показаться на первый взгляд. Для тестирования времени наката с нуля я извратился следующим образом: снял метаданные с работающей БД в полторы сотни таблиц и сгенерил xml-файлы наката, в которых каждая таблица создается с одним полем. А далее все отдельные составляющие, такие как остальные поля (alter-ы), индексы + констраинты, комменты, засунул в отдельные changeset-ы. На каждый changeset один SQL-оператор и только один. Плюс recreatable-объекты: вьюхи, пакеты-процедуры и т.д.
Полный накат с нуля на чистую схему составил чуть более 1 минуты. Повторный перезапуск выполнился за несколько секунд - при совпадении хешей changeset повторно не выполняется.