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

Question

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

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

Answer 1

Go купить Apex SQL Log . Если вы понимаете, что действительно облажались, или даже если это был кто-то другой, вы можете использовать журнал, чтобы отменить изменения.

Answer 2

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

2 - При написании оператора обновления ВСЕГДА сначала пишите предложение WHERE, затем верните курсор в начало строки и запишите часть обновления поля.

3 - оператор where для # 2 должен быть проверен с помощью оператора select.

Answer 3

если вы используете оракул 10 / 11g ... Flashback

http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm

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

Answer 4

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

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

Answer 5

Если вы используете SQL Server 2005+ Management Studio, вы можете включить неявные транзакции.

Answer 6

Всякий раз, когда я открываю соединение с PROD или переключаюсь в контекст данных PROD, первое, что я всегда делаю, это добавляю этот комментарий до и после моего активного блока рабочего кода:

-- PROD -- PROD -- PROD -- PROD -- PROD -- PROD --

Были случаи, когда я замечал это, когда мой большой палец был на клавише Alt, а мой средний палец был на полпути к клавише «X». Уф!

Answer 7

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

select *
  into MyBackupDb..PeterTableName2008_09_28BeforeABigUpdate

Это значительно ускоряет восстановление после ошибок (когда полное восстановление нецелесообразно).

Answer 8

Убедитесь, что в вашем запросе указан WHERE параметр

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

В результате теперь, когда я работаю с живыми БД, я структурирую свои запросы следующим образом:

UPDATE my_table WHERE condition = true;

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

Answer 9

Если вы используете Microsoft SQL Server Management Studio 2008 , вы можете указать, какой цвет будет использоваться в информационном окне при выполнении запросов (в нижней части редактора запросов SQL)

В окне подключения выберите «Параметры»> «Использовать пользовательский цвет» и выберите «КРАСНЫЙ» для производства.

Answer 10

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