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

FrankieКак же в Oracle всё сложно!
"Тяжело в учении - легко в бою".

FrankieMSSQL в этом тут явно выигрывает.
Спорно. На эту тему был большой топик, в котором tygra как отстаиватель преимуществ MSSQL так и не смог нарисовать цельную картину "каким образом я накатываю онлайн патчи так, что все замечательно".

lockyвот ЭТО - точно выигрывает

use tempdb
go
if object_id('test_proc','P') is not null drop procedure test_proc
go
create proc test_proc
Хм. Точно?

Ну ладно. Правда, лично я по-прежнему буду делать


Frankie1 и 2. Никакой перекомпиляции связанных процедур не нужно,
Это не совсем так, но в чем-то. Возможность незаметно положить в базу некорректную процедуру - я бы не считал преимуществом, но вопрос вкусов.

Frankie а про shared pool в MSSQL вообще не слышал.
"Не слышал" - это сильный аргумент. Тем не менее, он там есть.

lockyА глубинный смысл примера: если при последовательном обновлении процедур
на очередной из них произошла ошибка - один rollback вертает взад все
ранее залитые процедуры.
Признаться, этот аспект меня крайне мало беспокоит. Впрочем, если хотите риторики - учитывая отсутствие контроля ошибок, "на очередной из них произошла ошибка" - событие, мягко говоря, не очень вероятное. Реальным исходом будет успешный commit и массовое выпадание ошибок у пользователей.

lockyМеня такой аспект беспокоит, и очень :-)
Частенько необходимо бывает "пакетная" заливка взаимосвязанных процедур
вкупе с изменением схемы.
При этом "частенько" таки приходится выгонять пользователей, работающих с этой частью приложения. Во всяком случае, tygra так и не смог рассказать, за счет чего в нетривиальных случаях можно обойтись и без выгоняния пользователей, и без риска для данных.

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

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

lockyДля контроля ошибок можно вставить set xact_abort on и будет щастие.
Не вижу разницы и щастия соответственно.

lockyА вероятное событие, невероятное - понятие философическое.
Только до тех пор, пока рассуждения идут на "принципиально качественном" уровне. Как только делается хотя бы самая грубая количественная оценка - насколько поможет эта фича - понятие становится сугубо прагматичным.

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

lockyВ идеале ваще не нужны ни rollback, ни транзакции как таковые - приложения (в т.ч.
сервера) должны быть написаны без ошибок и должны работать без ошибок.
Глупость, уж извини. Транзакции защищают вовсе не от "написаны с ошибками".

lockyГлавное преимущество транзакции, как мне кажется - она "или всё, или ничего".
Само по себе это ничего особого не стоит. Грубо говоря, представьте себе многопользовательскую СУБД с поддержкой транзакций и умеющую только грязное чтение. Давайте договоримся, что блокировок в ней нет - чтобы не было соблазна руками эмулировать более высокие уровни изоляции. Ну и представьте себе решение практических задач в такой ситуации.

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

locky> Возможность отката одним rollback-ом - не спорю, удобна. Но чего-то
> принципиального я в ней не вижу. В любом случае по-хорошему нужно делать
> инсталлятор, который берет на себя кучу технических моментов и в том
> числе может делать откат. rollback лишь делает сомнительную практику
> наката патчей голыми скриптами несколько менее сомнительной.
Да, очень удобно перед накатываем патча делать полный бэкап, а затем - в
случае "облома" - выгонять тех, кого не выгнал и тратить N времени на
restore.
Хм. У меня такое впечатление, что Вы попытались проявить иронию.

Желание безусловно хорошее, но не в том случае, когда оно заменяет такие шаги алгоритма как

Прочитать сказанное

Подумать

Применить имеющиеся знания

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

А теперь предлагаю сделать rollback и выполнить таки вышеописанные шаги.

locky
> Не вижу разницы и щастия соответственно.
Разница в том, что при xact_abort on в случае ошибки транзакция
откатится и все изменения внесенные патчем тоже будут откачены,
Для того, чтобы xact_abort откатил транзакцию, нужно, чтобы сервер зафиксировал ошибку. А поскольку сервер ошибку не зафиксирует - xact_abort ни на что не влияет. Процедура спокойно закоммитится, патч завершится, пользователи вернутся в базу - и только тут посыпятся ошибки.

lockyочень прагматично. У меня синхронно с внутренними метаданными системы
регенерируется код обработчиков. И мне не хотелось бы, дабы метаданные с
обработчиками расходились. Хотя - зависит от дизайна системы.
Я понимаю это "не хотелось бы", но в данном случае это выбор между "хорошим" и "нормальным".

lockyОбнаружит, и откатит (см. выше про xact_abort).
Не обнаружит и не откатит.

lockyточнее - ошибку во внутренней логике процедуры - нет, не найдет.
Вот именно что. Скажем, если патч номер 28 по каким-то причинам не накатился - патч номер 29 скорее всего накатится, и проявится только когда пользователи вернутся в базу, выполнят процедуру и получат какой-нибудь table not found.

lockyа вот ошибку при накатывании патча - найдет вполне. И откатится.
А что это за "ошибка при накатывании патча"? Синтаксическая ошибка в скрипте, какой-нибудь там UNSERT вместо INSERT-а?

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

lockyВ случае с неправильно написанным патчем - защищают и от этого тоже.
Это мы обсуждаем выше. Ты выдвинул весьма универсальное утверждение (в идеале - транзакции вообще не будут нужны).

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

Frankie softwarerЯ бы начал с того, что баз должно быть не две, а как минимум три - разработка, тестирование и продакшн.
У нас весь отдел автоматизации - три человека + аналитик! Не те масштабы.
Количество людей тут не при чем. Названное - минимум, который потребуется даже если вообще один человек на все. Смотрите сами:

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

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

Вывод: грамотное тестирование на Development сервере практически невозможно. Код, который работает на development-е запросто может свалиться на production например потому, что опирается на чужую функцию, которая еще не попала в релиз.

Вывод: нужен еще один экземпляр БД, точная копия Production, на котором будут тестироваться как скрипты, так и собственно приложение перед попаданием на боевой.

Вот и все - даже если один человек. Без тестового сервера можно обойтись только в одном случае: если во-первых, постоянно заливать Development с Production-а, во-вторых, выпускать в версию только "все изменения на Development одновременно", при этом тщательно следя за отсутствием хвостов, ну а в-третьих, перед началом тестирования убивать development (перезаливать его с production-а) и накатывать на него все те скрипты, которыми потом будет догоняться боевой. Но это - экстремально неудобный режим, завести еще один экземпляр намного проще и удобнее.

FrankieТестированием у нас занимаются пользователи.
Я понимаю, что случаи бывают разные, но в ответ на эту фразу так и просится картинка с гробом ;-)

Пусть занимаются пользователи. Но это не отменяет необходимости в тестовой базе, на которой можно проверить версию, не рискуя поломать боевые данные. Если, конечно, эти данные важны.

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

FrankieКроме того, на production существуют тестовые объекты - например я могу скопировать боевую процедуру, перенаправить клиента на неё, менять и отлаживать на актуальных данными
Можете, если конечно наплевать на то, что из-за этой процедуры production может встать раком, например, по производительности. Непонятно, правда, зачем так хитрить, но это мелочи.

Frankie(речь идёт естественно о select-процедурах).
Мнение softwarer-а о select-процедурах skipped

FrankieКстати, тестовая база на боевом сервере у нас есть и используется, когда пользователи тестируют какой-то большой новый блок.
Замечательно. Тогда в чем вопрос, почему Вы убеждаете меня, что она не нужна? И зачем вам тогда калечить боевой вышеописанным образом?

FrankieА поддержание двух баз для тестирования
Каких двух? Откуда двух? Разве у меня где-нибудь было сказано про необходимость двух тестовых баз?

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

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

FrankieЧаще всего нужно переписывать только таблицу с константами айдишников.
Ну если это действие поможет убить все левые модификации, которые успели наплодить девелоперы, то этого хватит....