Ошибки в скриптах миграции баз данных

Question

Следующие базы данных существуют для каждого приложения, разрабатываемого внутри компании и независимо от него (на основе веб-интерфейса или клиент-сервер):

• Разработка (D1 и D2)
• Интеграция
• 1008 * Балетмейстер *
• Тестирование
• Производство

Производственная среда распределяется между приложениями.

Для миграции приложений требуется:

• Запустить скрипт, который изменяет производственную базу данных для новой версии приложения
• Развертывание новой версии программного приложения

Мои вопросы:

1. Допустимо ли в скрипте обновления производственной базы данных ОШИБКИ?
2. Почему или почему нет?

Answer 1

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

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

Answer 2

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

Что касается ожидаемых ошибок, это вопрос вкуса. Некоторые сценарии DDL выглядят так:

create table t23 
    (id number not null
     , description not null varchar2(30)
     , constraint t23_pk primary key (id))
/

prompt patch for ticket #42

alter table t23 
    add active_flag char(1) default 'N' not null
/

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

1012 * редактировать *

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

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