Безопасное исправление данных производственной базы данных

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

1. Нам нужно войти, кто выполнил запрос и что они запустили
2. В идеале нам нужно дать человеку доступ только для выполнения запросов к интересующим таблицам и только на короткое время.
3. Что бы ни выполнялось, запросы должны иметь некоторые хитрости, чтобы не допустить запуска долго работающего и блокирующего SQL без явного разрешения.
4. Этот процесс должен быть независимым от БД или, по крайней мере, понимать DB2, Oracle и SQL Server.

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

Никогда не обновляйте производственные базы данных вручную.

Писать скрипты.

Тройно проверяйте их, и пусть это делают несколько человек, а не один человек делает это три раза.

Включите в эти сценарии запросы проверки после изменения.

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

Протестируйте эти сценарии до тошноты по тестовой базе данных.

Сделайте резервную копию перед запуском сценария для производственной базы данных.

Запустите сценарии.

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

В любом случае сделайте визуальную проверку.

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

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

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

Представьте себе следующий случай:

1. В программном продукте есть ошибка, из-за которой он перестает работать, когда обнаруживает несоответствие данных в базе данных.

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

3. В настоящее время компания теряет тысячи долларов в час (скажем, 6 000 долларов, что означает 100 долларов в минуту),

4. Ошибка затрагивает несколько таблиц, одна из которых огромна и касается только самих данных, а не схемы,

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

6. База данных велика, и для создания или восстановления резервной копии потребуется три часа.

7. Последнее полное резервное копирование было сделано три недели назад; Есть также ежедневные инкрементные резервные копии, и последнее ежедневное инкрементное резервное копирование было сделано 14 часов назад,

8. Резервные копии базы данных считаются надежными; они были серьезно проверены, в том числе недавно,

9. Потеря данных за 14 часов недопустима, но потеря данных за один-два часа

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

11. База данных - Microsoft SQL Server 2008 Enterprise.

Чистый способ сделать что-то:

1. Восстановите резервную копию в промежуточной среде,

2. Эксперимент там,

3. Проверьте финальный сценарий дважды,

4. Запустите скрипт на производственном сервере.

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

Вместо этого вы могли бы сделать так:

1. Создать моментальный снимок (Microsoft SQL Server поддерживает это, и требуется несколько секунд, чтобы вернуть (и ничего не создать) моментальный снимок базы данных, резервное копирование которого занимает час; я полагаю, что другие продукты баз данных также поддерживают моментальные снимки),

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

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

Вывод

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

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

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

Это плохая практика и приглашение к решению проблем и проблем с данными. Есть даже фраза, которая описывает этот подход как « быстрый и грязный ».

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

Тем не менее, ошибки будут там и должны быть исправлены. Де-факто промышленный стандартом является применение патчей / (сценариев развертывания) на постановщиках (предварительную версию среды с последней копией базы данных прода) и пусть аналитик данных / QA для проверки исправления. Один и тот же сценарий должен контролироваться версией и применяться к среде Prod, чтобы избежать проблем.

В этом связанном посте упоминается ряд хороших практик

Хороший набор ссылок для просмотра:

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

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

Человек, пишущий сценарий обновления, сделает это в тесте (как и в других ответах) и получит серьезное одобрение от не-техников (тех, кто знает систему, плюс кто-то со старшим авторитетом), что функции кажутся «правильными снова» в дополнение к собственным параноидальным тестам. Сценарии и данные будут независимо проверяться другим техническим специалистом (часто ролью администратора БД, о котором я упоминал) во время тестирования перед запуском в эксплуатацию. Результаты будут сравниваться с ожидаемыми значениями (уникальными для каждого сценария, но часто такими, как количество строк и т. Д.)

В одной компании, в которой я работал, создание резервных копий не было реалистичным вариантом, но все строки, подлежащие обновлению, были записаны в текстовый файл для справки ДО обновления, а затем снова ПОСЛЕ обновления, если кому-либо когда-либо понадобится обратиться к нему. Сценарии и эти данные хранятся в правильно организованном журнале изменений данных.

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

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

Есть моменты, когда вы должны исправить данные на Prod, которые не существуют на других серверах. Это не только из-за ошибок, но и из-за импорта данных из файла, который клиент отправил неверно, или из-за проблемы, вызванной взломом вашей системы. Или из-за проблемы, вызванной неправильным вводом данных. Если ваша база данных велика или критична по времени, у вас может не быть времени, чтобы восстановить последнюю резервную копию и исправить ее на dev.

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

Далее все сценарии для изменения данных о производстве должны включать следующее:

Они должны быть в явных транзакциях и иметь блок TRY Catch.

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

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

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

Наконец, разработчики не должны запускать эти скрипты. Они должны быть запущены dbas или группой управления конфигурацией. Если у вас нет ни одного из них, то только люди, которые являются техническими лидерами или выше, должны иметь права управлять вещами на Prod. Чем меньше людей работают над продуктом, тем легче отследить проблему. Сценарии должны быть написаны так, чтобы они просто выполнялись, без выделения частей и запуска по одному шагу за раз. Это тот материал, который выделяет, который часто доставляет людям неприятности, когда они забывают выделить предложение where.

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

Это также было бы дорого (мы бы посмотрели друг на друга и обсудили 2 или 3, может быть)

И золотое правило: всегда делайте оператор select, чтобы показать, что будет сделано, прежде чем выполнять оператор update / delete / insert

Золотое правило соблюдается двумя другими людьми в команде!

Re: ответ MainMa ...

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

• Откуда ты знаешь, что это «ошибка»? Данные противоречивы в соответствии с правилами, изложенными разработчиком программного продукта.

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

В настоящее время компания теряет тысячи долларов в час (скажем, 6 000 долларов, что означает 100 долларов в минуту),

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

Ошибка затрагивает несколько таблиц, одна из которых огромна и касается только самих данных, а не схемы,

• Все проблемы с базой данных "касаются" схемы. То, как спроектирована схема, определит, как вы решите эту проблему.

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

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

База данных велика, и для создания или восстановления резервной копии потребуется три часа.

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

Последнее полное резервное копирование было сделано три недели назад; Есть также ежедневные инкрементные резервные копии, и последнее ежедневное инкрементное резервное копирование было сделано 14 часов назад,

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

Резервные копии базы данных считаются надежными; они были серьезно проверены, в том числе недавно,

• Превосходно! Тогда вам может не понадобиться восстанавливать базу данных более одного раза.

Потеря данных за 14 часов недопустима, но потеря данных за один-два часа

• По описанному вами сценарию все ставки сняты. Это ситуация «управления информационными катастрофами». Хорошая вещь для руководства, чтобы делать это, документируя затраты, которых можно было бы избежать в будущем с помощью резервного копирования, процедур восстановления и ресурсов.

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

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

База данных - Microsoft SQL Server 2008 Enterprise.

• Труднее сделать все это, но не невозможно. Удачи!