Какой ваш # 1 способ быть осторожным с живой базой данных?

Question

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

Что вы # 1 делаете, чтобы быть осторожным при работе с живыми данными?

Answer 1

Опасность запуска непреднамеренного удаления (или вставки, или обновления) всегда на моей голове.

Я всегда добавляю «где 1 = 2» после них, пока не буду готов нажать на курок.

Answer 2

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

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

Answer 3

Я добавлю к рекомендациям по выполнению BEGIN TRAN до вашего ОБНОВЛЕНИЯ, просто не забудьте на самом деле выполнить COMMIT; Вы можете нанести такой же ущерб, если оставите незафиксированную транзакцию открытой. Не отвлекайтесь на телефоны, коллег, обед и т. Д., Когда вы будете в середине обновлений, или вы обнаружите, что все остальные заперты, пока вы не нажмете COMMIT или ROLLBACK.

Answer 4

Мне часто приходится вставлять, обновлять или удалять данные на производственном сайте (как аналитик данных, это, вероятно, 40% моей работы). В большинстве случаев это происходит через автоматизированные пакеты DTS или SSIS. Тем не менее, мы также люди, которые должны исправлять записи о проблемах или обновлять производство, когда происходит серьезное изменение на основе клиента (например, реорганизация отдела продаж). Иногда проблемы возникают из-за ошибок в коде, но, как правило, они являются результатом странных вещей, которые клиент сделал со своим файлом, или того, что пользователям удалось испортить, чтобы сэкономить время на устранение проблемы, или потому, что они хотели обойти только для этого быстрого и простого изменения! (Примечание для пользователей - Пожалуйста, не пытайтесь исправить вещи вручную, что обычно делается с помощью автоматизированного процесса, вы не знаете, что еще может делать этот процесс !!!!!) иногда мы не можем позволить себе роскошь сначала протестировать скрипт на dev, так как то, что нужно исправить, не на dev.

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

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

Я пишу оператор удаления следующим образом:

начать транс

удалить

- выберите (перечислите важные поля для просмотра здесь)

из таблицы1 a, где field1 = 'x'

- откат тран

- совершить транс

Обратите внимание на несколько вещей об этом. Во-первых, используя псевдоним, я не могу случайно удалить всю таблицу, выделив только одну строку и выполнив код. Запуская предложение where в той же строке, что и таблица, я гораздо реже пропускаю его выделение. Если бы у меня были объединения, я бы удостоверился, что каждая строка заканчивается в месте, где код не будет работать, если он не перейдет к следующей строке. Опять же, это гарантирует, что вы получите ошибку вместо oopsie. Всегда сначала выполняйте команду select и запишите количество затронутых записей (и посмотрите на данные, чтобы убедиться, что они выглядят как правильные записи!). Затем не выполняйте фиксацию, если количество записей не является правильным при запуске фактического удаления. Да, лучше начинать where на отдельной строке, безопаснее заканчивать каждую строку удаления, чтобы она не выполнялась, если не выделен весь запрос.

Обновления следуют симлиарным правилам.

Answer 5

При обновлении / удалении только одной записи mysql позволяет поставить «LIMIT 1» в конце, чтобы повреждена только одна запись, даже если предложение WHEN неверно.

Answer 6

Если вы используете SQL Server 2005 и выше, вы можете создать снимок базы данных, который позволит вам откатить любые изменения, внесенные в момент моментального снимка.

Answer 7

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

удалить из клиентов, где id = 5 limit 1;

«id» может быть уникальным индексом, и я знаю, что есть только строка, которая будет соответствовать моему предложению where, но ограничение - это дополнительный уровень защиты от случайного сброса неправильных данных. Я привык печатать эту часть первым в надежде на дальнейшую защиту от случайных нажатий клавиш. Я начинаю с "удалить предел 1", затем возвращаюсь и добавляю другие вещи.

Answer 8

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

Мы делаем это для всех обычных исправлений данных SQL, даже простых - единственное исключение - когда что-то требуется для решения серьезной проблемы с производством ПРЯМО СЕЙЧАС (например, блокирование входа всех клиентов) - в этом случае мы гарантируем на работе столько пар глаз, сколько возможно (обычно 3-4 человека на одной рабочей станции, каждый из которых может наложить вето на любое действие).

Answer 9

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

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

3. Если вам когда-нибудь придется что-то делать с работающей БД. Запишите это и добавьте исправление в качестве закодированной функции, доступной администраторам. Таким образом, у вас есть еще одно оправдание, чтобы указать инструмент запроса на вашу базу данных.

Answer 10

Чтобы позволить администраторам работать. Исходя из опыта разработки, я не хочу / не должен / должен иметь доступ к чьей-либо живой базе данных. Для меня это равносильно тому, что администратор БД решает проблему кодирования в DAL только потому, что в заголовке есть «база данных». : -)