Лучшие практики для управления изменениями с индексами

Question

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

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

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

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

Когда мы сталкиваемся с индексами, которые, по нашему мнению, должны быть сделаны, как мы лучше справляемся с управлением изменениями в отношении них как для наших собственных баз данных, так и для любых поставщиков?

Что вы делаете в своем магазине? Я меньше беспокоюсь об инструментах, чем о процессе.

РЕДАКТИРОВАТЬ: До сих пор я ценю отзывы, комментарии и ответы на этот вопрос. Я заметил, что некоторые ответы немного специфичны для инструмента. Я ищу больше «агностических» практик, если это можно было иметь.

Однако, если агностик невозможна, то для наборов инструментов мы используем IBM DB2 Luw (и это на самом деле на AIX) в основном. У нас есть немного DB2 в Windows и DB2 для I (IBM I5/OS), но мы в основном AIX DB2. Мы используем управление источником, в частности, подрывная деятельность.

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

РЕДАКТИРОВАТЬ: Текущее решение: Мы намерены отслеживать наши рассуждения, а также наши изменения. Таким образом, мы собираемся открыть проблему в нашем программном обеспечении для отслеживания проблем (которое в нашем случае является JIRA). Теперь мы можем добавить документацию относительно того, какой приоритет имеет изменение, данные, которые подтверждают, какими должны быть изменения, изменения и результаты изменения из другой среды, в которой было проверено изменение.

Затем мы также намерены отслеживать наши изменения в сценариях в SVN (очень похоже на предложение ниже). Таким образом, мы можем отслеживать, какая версия того, что существует, где. Это может быть записано в нашей проблеме JIRA (и в любом другом программном обеспечении, которое мы используем, т.е. вставленные ссылки). Мы можем с уверенностью знать, какое изменение произошло в какую среду и почему. Затем мы можем также отслеживать, если индекс был чем -то, что мы добавили за пределы реализации поставщиков или перед их реализацией и т. Д.)

Answer 1

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

Чтобы получить объекты в управление источником, есть ряд инструментов, которые вы можете использовать. У Microsoft есть инструмент, который является прозвищем Data Dude. Он работает с Visual Studio. Они также готовятся выпустить новый инструмент под названием SQL Server Database Tools (SSDT), опять же, работа с Visual Studio. Моя компания, программное обеспечение Red Gate, создает инструмент, который работает с SSMS под названием SQL Source Control.

С точки зрения процесса, я написал несколько глав для книги Руководство по развитию команды Red Gate. Анкет Он доступен в виде бесплатной загрузки (или, если вы хотите убить дерево, вы можете перенести один из Amazon). Я занимаюсь гораздо более подробной информацией о работе с базами данных в командах разработчиков.

Answer 2

1. Мы поддерживаем сценарии базы данных как часть нашей кодовой базы приложений, которая поддерживается под управлением версий. Однако мы используем разные «процессы» для разработки и производственного кода

2. Развитие мы поддерживаем следующие сценарии:

   • base.sql - создает таблицы схемы и образцы данных
   • StagingChanges.sql - вносит изменения в base.sql для постановки среды, в основном адреса электронной почты, пути и другие активы, которые могут изменить
   • prodchanges.sql - вносит изменения в base.sql для развертывания производства. Для новых проектов мы обычно протестируем их в реальных производственных средах

3. Обслуживание

   • base.sql - продефицированная версия производственной базы данных
   • StagingChanges.sql и Prodchanges.sql - как указано выше
   • Changerequest.sql (обычно имеет идентификатор запроса на изменение), который применяет любые изменения схемы для текущего запроса на изменение, над которым мы работаем
   • Changerequest -rollback.sql - меняет изменения, внесенные для запроса на изменение, и сбрасывает базу данных обратно в производство
   • Архив (папка) для предыдущих сценариев запроса на изменение

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

Answer 3

Находиться в пространстве контроля версий базы данных в течение 5 лет (как директор по управлению продуктами в DBMAESTRO) и работая в качестве DBA в течение более двух десятилетий, я могу сказать вам простой факт, что вы не можете относиться к объектам базы данных, когда вы относитесь к своей Java, C# или другими файлами.

Есть много причин, и я назову несколько:

• Файлы хранятся локально на ПК разработчика и изменения/он
  не влияет на других разработчиков. Аналогичным образом, разработчик не влияет изменения, внесенные ее коллегой. В базе данных это
  (обычно) не так, и разработчики имеют одну и ту же базу данных
  Окружающая среда, поэтому любые изменения, которые были привержены базе данных, влияют на других.
• Изменения кода публикации осуществляются с использованием регистрации / отправки изменений / и т. Д. (В зависимости от того, какой инструмент управления источником вы используете). В этот момент вставлен код из локального каталога разработчика
  в хранилище управления источником. Разработчик, который хочет получить
  Последний код должен запросить его из инструмента управления источником. В
  База данных изменение уже существует и влияет на другие данные, даже если оно не было зарегистрировано в репозитории.
• Во время регистрации файла инструмент управления источником выполняет проверку конфликта, чтобы увидеть, был ли тот же файл изменен и зарегистрирован другим разработчиком в течение времени, когда вы изменили локальную копию. Опять же, в базе данных нет проверки. Если вы измените процедуру с локального ПК и в то же время я изменяю одну и ту же процедуру с помощью кода с моим локальным ПК, мы переопределяем изменения друг друга.
• Процесс сборки кода выполняется путем получения метки / последней версии кода в пустой каталог, а затем выполнить сборку - компиляция. Вывод - двоичные файлы, в которых мы копируем и заменяем существующее. Нам все равно, что было раньше. В базе данных мы не можем воссоздать базу данных, поскольку нам нужно сохранить данные! Также развертывание выполняет сценарии SQL, которые были сгенерированы в процессе сборки.
• При выполнении сценариев SQL (с командами DDL, DCL, DML (для статического содержания) вы предполагаете, что текущая структура среды соответствует структуре при создании сценариев. Если нет, то ваши сценарии могут потерпеть неудачу, поскольку вы пытаетесь добавить новый столбец, который уже существует.
• Обработка сценариев SQL как кода и их генерация вручную вызовет ошибки синтаксиса, ошибки зависимостей в базе данных, сценарии, которые не используются повторно, что усложняет задачу разработки, поддержания, тестирование этих сценариев. Кроме того, эти сценарии могут работать в среде, которая отличается от той, которую вы будете работать.
• Иногда скрипт в репозитории управления версией не соответствует структуре тестируемого объекта, а затем ошибки будут происходить в производстве!

Есть еще много, но я думаю, что вы получили картинку.

Я нашел, что работает, это следующее:

1. Используйте принудительную систему управления версиями, которая обеспечивает выполнение операций по вырезом/регистрации в объектах базы данных. Это убедится, что репозиторий управления версией соответствует коду, который был зарегистрирован, когда он читает метаданные объекта в операции регистрации, а не как отдельный шаг вручную
2. Используйте анализ воздействия, который использует базовые линии в рамках сравнения для определения конфликтов и определения того, является ли изменение (при сравнении структуры объекта между хранилищем управления источником и базой данных) реальным изменением, которое происхождение от разработки или изменение, которое было происхождением из Другой путь, а затем его следует пропустить, например, различная ветвь или аварийное исправление.

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