AmKadавторну т.е. можно конечно тратить время на то, чтоб пытаться делать патчи реентерабельными да еще и суперуниверсальными, типа, с любой версии на любую, но этой херней занимаются только конченные чудаки.Представь себе, по трудоемкости и сложности это не сильно отличается от последовательного добавления sql-статементов в .sql-файлы.

это только в теории. в теории можно рассказать про то, что миграции должны делаться только автономными файлами и не иметь внешних зависимостей

команда даже примет это громогласным ура!

но в один прекрасный день в файл миграции или зависимость на юзерский пакет вкомиттят, или под DECLARE поселят пару мегабайт глючной копипасты.

а реентерабельность - очень прикольно звучит в случае рефакторинга вида "разделение структуры таблицы на две отдельные таблицы", или даже простейшего "партицирование таблицы".

хотя да, реентерабельно индексы строить или констрейны прикручивать, ту да, это как два пальца - пищем PL/SQL обертки и вперед.

svn_oradbpatch,
Вы какие инструменты используете/советуете?
как я говорил выше - единственно правильным является Oracle XDF/ODF фреймфорк.
подход ликвибейза - он настолько неудобен, что пользовать им могут разве идейные мазохисты.

а по факту рабочим вариантом является следующее:

реентерабильные .SQL файлы, в т.е. CREATE PROCEDURE, VIEW, PACKAGE и прочее хранится просто как именованыне .SQL файлы, где именем файла является имя объекта, без нумераций. несколько объектов в один файл не допустимо, ну кроме случая PACKAGE и его BODY.

эти файлы генерятся прямо из базы данных специальной PL/SQL процедурой, программисту не нужно копипастить.

отдельно эти все файлы разбиты по каталогам, по подсистемам, так искать проще (не всегда в имени объекта префиксом зашито имя подсистемы/модуля).

это все делается чтоб воспринимать код базы данных как любой иной (Java, C++, PHP) код и пользоваться blame, merge привычным способом

CREATE TABLE и CREATE INDEX, ALTER TABLE - в настоящее время делаются через специальные PL/SQL вызовы, суть которых в том, чтоб проверить - если есть индекс, и его структура как в вызове - то ничего не делать, иначе перестроить и т.п.
эти вызовы сидят в .sql файле с именем таблицы, т.е. хранится только последнее актуальное состояние таблицы (реентерабельность -же!). эти файлы тоже генерятся.

т.е. цель - обеспечить реентерабельность патча (логика или пересоздать, или скипнуть) прошита изначально.

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

если скрипты миграции не реентерабельны, или требуют строго специфической версии базы данных на которую они накатываются - то они из патча выносятся в отдельно выполняемые вручную файлы, которые подшивают в release notes/steps (бывают pre и post разновидности)

типо если вот хотите обновиться - берете эти файлы и выполняете вручную (если упали - то разбор полетов отдельно, вплоть до flashbask restore)

слава богу, что примерно 99% всех миграций - они тривиальны и реентерабельны, особенно в случае пострелизных быстрых багфиксов.

со статичным справочниками тот-же подход - их наполнение прошивается в специальные PL/SQL вызовы, кладется в .SQL файлы и работает по принципу - или добавь, или обнови, или ничего не делай, если запись уже на месте.
файлы, естественно, тоже генерятся из базы, а вот PL/SQL код наполнения лежит, естественно, в отдельных .SQL файлах, они гарантированно выполняются первыми (есть еще понятие стадий и проходов, это отдельная тема)

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

или же накатываются только те файлы, которые изменились от последнего релиза, если схема не пустая - хотя можно и все целиком накатить (реэнтерабельно же все), но когда у тебя объектов более 1000, то процедура накатки всех файлов в которых реально и не было изменений начинает занимать порой десятки минут, это неудобно.

тулы все самописные (bash и sqlplus), готовых нормальных не нашлось

AmKaddbpatchэто только в теории. в теории можно рассказать про то, что миграции должны делаться только автономными файлами и не иметь внешних зависимостей
Не знаю, что ты понимаешь под внешними зависимостями.

господи, ты стоишь на .SQL файле, в нем некий код. этот код или вызывает некий иной PL/SQL код, который лежит в других .SQL файлах этого же патча (внешняя зависимость по отношению к текущему файлу), или нет - он полностью автономен, и вызвает только то, что в Oracle изначально доступно.


на остальные твои "флаг" в руки отвечать лениво и бессмысленно, ты просто не в теме.

AmKaddbpatchCREATE TABLE и CREATE INDEX, ALTER TABLE - в настоящее время делаются через специальные PL/SQL вызовы, суть которых в том, чтоб проверить - если есть индекс, и его структура как в вызове - то ничего не делать, иначе перестроить и т.п.
эти вызовы сидят в .sql файле с именем таблицы, т.е. хранится только последнее актуальное состояние таблицы (реентерабельность -же!). эти файлы тоже генерятся.
Попытался представить себе сигнатуру и тело pl/sql обертки для создания индекса. Ты проверяешь только набор и порядок полей? Уникальность/неуникальность? Или еще такие параметры tablespace, pctfree, next и т.д.?

А при добавлении поля. Проверяешь размерность, null/not null, lob store as, storage in row ... и т.д.?

Или еще лучше - добавление check-constraint-а? Проверяешь там текст?

параметры аж три штуки

имя таблицы,
имя индекса
column expression (там могут быть FBI, DESC и прочее).

уникальность не уникальность - это имя процедуры - .idx() или .uk(), .pk()

тонкости вида чем отличается UNIQUE INDEX от UNIQUE CONSTRAINT в рамках проекта задавили, чтоб не смущать сильно сумлевающихся - всем ходить в констрейн.

локальность или не локальность индекса определяется автоматом из набора колонок.

глобально партицированные индексы ни разу не понадобились, было решено что это все от лукавого.

параметры сториджа берутся по дефолту от тейблспейса, а сам тейблспейс от юзера.
практически никому не нужны эти тонкие материи, а кому сильно надо - тот сам потом руками сделает MOVE/REBUILD, как считает нужным.

единственное место, где есть деление тейблспейсов - это партицирование по периодам (годам), с целью пометки оных тейблспейсов как R/O.

но это делается отдельным фреймворком datalifecycle management, патч с ним перпендикулярен - в случае новой таблицы патч создает только изначальную партицию, остальные по датам добавляет уже другой пакет/набор джоб.


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

какое-то время с этим мучались, но недостатки превысили бенефиты - при ресторе ребилд
индексов занял неприемлимое по SLA время, а пару раз вообще не прошел, потому что TEMP
не хватило, потому вкинувшего идею хранить индексы отдельно и не бекапить/ресторить - публично перед строем сильно поругали.

на этом эпопея отдельного тейблспейса для индексов была выкинута - в современных SAN и SSD условиях это полная бессмыслица даже для перфоманса.

Lary Denisdbpatch, сложилось ощущение, что AmKad работал с ликвибейзом и понимает, о чем пишет. Твои доводы ПРОТИВ, не совсем понятны.
нет, ты просто не можешь понять, как можно иначе. вот AmKad что-то уже начал понимать, видно у него не полный ликвибейз головного мозга (или он просто не совсем его понимает, это мы уже выяснили ранее).

Lary Denis Ты скорее философ. А спорить с философом, себе дороже. Вы живете в своем мире.

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

А если ты что-то не осознал из сказанного мной выше - ну... ок, просто твой взгляд на мир ограничен теми рамками, в которых ты эффективен и выход за оные, переход на следующий уровень - тебя пугает, это нормально для 95% популяции людей, вне зависимости от их специализации.

В средние века вон таких как я "философов" за подобные откровения на кострах жгли, ибо зачем думать-то, проще не думать и сразу объявить ересью :)

dbpatchА при добавлении поля. Проверяешь размерность, null/not null, lob store as, storage in row ... и т.д.?

Размерность, тип (если колонка пуста, то тип меняется автоматом), null/not null - да, еще DEFAULT значение.
Все параметры сториджа не проверяются - см. выше про сториджи, не патча это дело ковыряться с физикой, кому надо - сам потом поправит после патча.
Даже параметры партицирования не прописываются - проще отдельными PL/SQL вызовами сделать отдельную миграцию пустой таблицы в партицированную, если сильно нужно.

Смысл патча не только в реентерабельности, но и в гарантированном времени выполнения - это важно для пострелизных фиксов, которые выполняются по SLA не в выходные, а по требованию, т.е. должны занимать минуты, а не часы, т.е. не делать никаких неожиданных массированных миграций и ребилдов (делать только руками, если явно попросят).

dbpatchИли еще лучше - добавление check-constraint-а? Проверяешь там текст?
да, просто проверяется текст. если trim()-ed версии не совпадают - то пересоздается.


отдельно - в настоящее время не шатко валко прорабатывается вопрос вообще избавиться от PL/SQL вызовов, и хранить только plain text вида

CREATE TABLE, ALTER TABLE, CREATE INDEX

уже отдельно по BNF его парсить и выдавать нужные ALTER TABLE ADD/MODIFY COLUMN, но, как говорится, "это тема моей будущей докторской диссертации".

да и через bash/sqlplus такой парсинг уже не сделать, нужно применять более тяжелые вещества средства

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

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

Lary DenisСталкиваясь с Liquibase в своей практике, не испытал дискомфорта.
А скорее, как педант, остался очень им доволен.

Это явление не ново. Вот тут описано: https://ru.wikipedia.org/wiki/Луддиты
И гордиться подобным я бы не стал.

Lary DenisА вот раз у тебя (Вас) такое негативное мнение о нем, быть может ты (Вы) его не понял (ли)?
Я описал явно выше, почему он не приемлем.

В нем практически невозможно делать blame (вернее ОЧЕНЬ затруднено) и совсем невозможно делать backmerge/merge - эти процедуры занимают часы, иногда дни, особенно для больших проектов, при этом качество результата практически всегда низкое и негарантированное.

Но если для тебя слова backmerge и blame пустой звук (это нормально для большинства проектов, которые делаются для одного заказчика и актуальна только самая последняя версия), то подход с 0000123412.sql очень даже работоспособен, тут даже спорить не нужно.

Яб конечно еще спросил, как вы делаете rollback.sql-ы, но думаю не стоит, ибо столько иронии в ответ ты, пожалуй, можешь и не выдержать :)

Нахлобучdbpatchт.е. цель - обеспечить реентерабельность патча (логика или пересоздать, или скипнуть)
Не реентерабельность, а идемпотентность.

да да, потентность.

результаты не всегда неизменны, смысл реентерабельности патча в схеме "накатывали патч, упали, руками подчинили, накатили еще раз".
причем руками починили часто не только базу, но и сам патч, потому про идемпотенцию :) я бы не стал говорить, это сильно сильное слово.

Нахлобучdbpatchсмысл реентерабельности патча в схеме "накатывали патч, упали, руками подчинили, накатили еще раз".И даже это поведение -- ни разу не про реентерабельность.

Ты прав, термин неудачный и в данном топике был вброшен не мной.
Я сам называю это свойство способностью к перезапуску (restartable), перезапускаемость.

реентерабельность это ЕМНИП скорее из мира POSIX, способность функции к повторому запуску при прерывании на обработку сигнала

Нахлобучdbpatchпричем руками починили часто не только базу, но и сам патч, потому про идемпотенцию :) я бы не стал говорить, это сильно сильное слово.Всё тлен. Патчи должны быть оттестированы и накатываться без правок и "починок" базы. Я, конечно, понимаю, что Oracle не умеет транзакционный DDL, но это не повод.

причины бывают разные. наиболее типовая - это просто закончилось место (в датафайлах, в TEMP или в UNDO). или патч занимает внезапно неожиданно большое время на миграциях.

или падучая на констрейнах.

протестировать на полной копии продукционных данных не всегда получается, в виду объема оных.

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

envЭкономить на индексах в бакапе при выпячивании X@# (*xdf) своего OEBSа, как-то странновато выглядит.
нет никакого OEBS, я его привел как пример грамотно реализованной системы патчей (и генерации и деплоя).

envМеханизм проверки хешей предыдущих изменений в системах наката патчей очень неплохо позволяет избежать вынужденного backmerge при накате велосипедистами только имеющихся на руках изменений на некую старую версию о которой известен только номер.
Про каких велосепедистов ты говоришь? О своем, о наболевшем?

и да, ты походу путаешь backmerge и rollback. backmerge - это когда некая фича или багфикс, реализованная в версии 3.2 срочным порядком добавляется в предыдущую версию, к примеру, 2.9, с учетом того, что между ними полгода-год изменений и много рефакторингов уже прошло.

разрешение конфликтов, 3-way merge, и прочий подобный .... гарантирован.

a rollback это банальный откат на предыдующую версию.

envз.ы. использовал liquibase на проекте с кучей зависимостей, изменением структуры и датафиксами. Проблем при накате с древней версии на свежую было минимум. В основном, не связанных с liquibase как таковым.
никто и не утверждает, что liquibase создает проблемы при деплое. если говорить с позиции наиболее обобщенного решения - то для деплоя лучше и не придумаешь.

у него проблемы с merge/blame/backmerge - собственно работе с системой контроля версий исходных кодов.
он с любой VCS просто идеологически несовместим, ибо перпендикулярен ей, реализуя собственное понимание версий исходного кода: вместо package.sql ревизий 1, 322, 2251 он предлагает иметь sql000001.sql, sql000322.sql и sql002251.sql - и никакой тебе
черепашки, прыгай сам по этим файлам как хочешь, пытаясь выяснить, кто, почему и когда изменил/внес вот эту строку.

неужели это не очевидно?

AmKadНу и зачем такой недовелосипед (не знаю как назвать по-другому) с попыткой учесть множество ньюансов?

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

AmKaddbpatchон с любой VCS просто идеологически несовместим, ибо перпендикулярен ей, реализуя собственное понимание версий исходного кода: вместо package.sql ревизий 1, 322, 2251 он предлагает иметь sql000001.sql, sql000322.sql и sql002251.sql - и никакой тебе
черепашки, прыгай сам по этим файлам как хочешь, пытаясь выяснить, кто, почему и когда изменил/внес вот эту строку.

неужели это не очевидно?Ты не прав. Кто внушил тебе такой бред?

ну и в чем именно я не прав? попробуй развернуть свою ээээ.... мысль, а то все телепаты ушли в отпуск, и догадаться что ты там подразумеваешь в виде отличий "такой бред" от "не такой бред", "бред, но не такой" никак не есть возможно.