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

Question

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

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

Answer 1

BEGIN TRANSACTION;

Таким образом, вы можете откатиться после ошибки.

Answer 2

Три вещи, которым я научился на протяжении многих лет ...

Сначала, если вы обновляете или удаляете живые данные, сначала напишите запрос SELECT с предложением WHERE, которое вы будете использовать. Убедитесь, что это работает. Убедитесь, что это правильно. Затем добавьте оператор UPDATE / DELETE к известному рабочему предложению WHERE.

Вы никогда не хотите иметь

DELETE FROM Customers

сидит в вашем анализаторе запросов и ждет, пока вы напишете предложение WHERE ... случайно нажал "выполнить", и вы только что убили свою таблицу клиентов. К сожалению.

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

SELECT *
INTO CustomerBackup200810032034
FROM Customer

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

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

Answer 3

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

РЕДАКТИРОВАТЬ : учитывая то, что сказали другие, убедитесь, что в ваших ОБНОВЛЕНИЯХ есть соответствующие предложения WHERE.

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

Answer 4

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

Answer 5

Часто перед тем, как сделать ОБНОВЛЕНИЕ или УДАЛЕНИЕ, я пишу эквивалентный SELECT.

Answer 6

НИКОГДА не делайте обновления, если вы не находитесь в НАЧАЛЕ ПЕРЕВОЗКИ t1 - ни в базе данных разработчиков, ни в рабочей среде, ни где-либо еще. НИКОГДА не запускайте COMMIT TRAN t1 вне комментария - всегда вводите

--COMMIT TRAN t1

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

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

begin tran t1
update 
set 
where 
rollback tran t1
--commit tran t1

Answer 7

Чтобы ответить на мой вопрос:

При написании заявления об обновлении запишите его не по порядку.

1. Запись UPDATE [table-name]
2. Запись WHERE [conditions]
3. Вернитесь назад и напишите SET [columns-and-values]

Выбор строк, которые вы хотите обновить, прежде чем сказать, какие значения вы хотите изменить, гораздо безопаснее, чем делать это в другом порядке. update person set email = 'bob@bob.com' не может находиться в окне вашего запроса, готовый к запуску неуместным нажатием клавиши, готовый испортить все строки в таблице.

Редактировать: Как уже говорили другие, напишите предложение WHERE для ваших удалений, прежде чем писать DELETE.

Answer 8

Всегда проверяйте, чтобы ваши ОБНОВЛЕНИЯ и УДАЛЕНИЯ содержали правильное предложение WHERE.

Answer 9

Мой # 1 способ быть осторожным с живой базой данных? Не трогай это. :)

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

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

Answer 10

В качестве примера я создаю SQL как этот

--Update P Set
--Select ID, Name as OldName, 
    Name='Jones'
From Person P
Where ID = 1000

Я выделяю текст от конца до Select и запускаю этот SQL. Убедившись, что он извлекает запись, которую я хочу обновить, я нажимаю клавишу shift, чтобы выделить оператор Update и запустить его.

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

Если я делаю это в сочетании с транзакциями и откатом / фиксацией, я действительно, действительно в безопасности.