Какая худшая авария с базой данных произошла с вами на производстве? [закрыто]

Например: Обновление всех строк таблицы клиентов, потому что вы забыли добавить предложение where.

  1. Каково это, осознавать это и сообщать об этом своим коллегам или клиентам?
  2. Какие уроки были извлечены?
15.08.2008 11:13:53
18 ОТВЕТОВ

Я уронил живую базу данных и удалил ее.

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

0
9.11.2008 17:24:30
удалялись и удалялись одновременно .. но почему вы так сильно отреагировали на плохую производственную базу данных ;-)
Chris 21.03.2011 11:46:33

Младший администратор базы данных хотел сделать:

delete from [table] where [condition]

Вместо этого они напечатали:

delete [table] where [condition]

Который является допустимым T-Sql, но в основном полностью игнорирует бит where [condition] (по крайней мере, это было тогда на MSSQL 2000/97 - я забыл, какой) и стирает всю таблицу.

Это было весело :-/

4
15.08.2008 11:37:54
Конечно, не на SQL Server 2000. Там нет SQL Server 97 - предшественник был SQL Server 7.
splattne 9.11.2008 17:22:01

Я обнаружил, что не понимаю файлы журналов повторов Oracle (терминология? Это было давно) и потерял данные о торговле за неделю, которые пришлось вручную набирать с бумажных билетов.

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

0
15.08.2008 11:22:33

Я думаю, что моя худшая ошибка была

truncate table Customers
truncate table Transactions

Я не видел, к какому серверу MSSQL я подключился, я хотел очистить свою локальную копию ... Знакомый «OH s ** t», когда удаление заняло значительно больше полсекунды, мой начальник заметил, что я пошел видимо белый, и спросил, что я только что сделал. Примерно через полминуты монитор нашего сайта сошел с ума и начал писать нам по электронной почте о том, что сайт не работает.

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

Только до 4 утра восстановление данных из резервных копий тоже! Мой начальник пожалел меня и купил мне ужин ...

11
15.08.2008 11:38:00
да, я почти сделал это раньше. Определенно всегда тесная связь, чтобы жить, как только вы можете.
alexmac 23.11.2008 21:57:45
Первое, что я сделал, когда прочитал это, было закрытие моего открытого SSMS-соединения с живым сервером базы данных ...
Moo 28.05.2010 14:17:57

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

@ Кит в T-SQL, не является ли ключевое слово FROM необязательным для DELETE? Оба эти утверждения делают одно и то же ...

0
23.05.2017 12:19:33

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

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

update facilities set address1 = '123 Fake Street'
    where facilityid in (1, 2, 3)

Что-то подобное. Запустил его в тесте, 3 строки обновлены. Скопировал его в буфер обмена, вставил в службы терминалов на нашем производственном sql box, запустил его, с ужасом наблюдал, как потребовалось 5 секунд, чтобы выполнить и обновил 100000 строк. Каким-то образом я скопировал первую строку, а не вторую, и не обращал внимания на то, как я CTRL+ V, CTRL+ E'd.

Мой DBA, пожилой греческий джентльмен, наверное, самый сварливый человек, которого я встречал, не был в восторге. К счастью, у нас была резервная копия, и она не разбивала какие-либо страницы, к счастью, это поле предназначено только для отображения (и для выставления счетов / доставки).

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

5
20.08.2015 22:23:22

Худшее, что случилось со мной, было то, что производственный сервер занимал все пространство на HD. Я использовал SQL Server, поэтому я вижу файлы базы данных и вижу, что размер журнала составляет около 10 ГБ, поэтому я решаю делать то, что делаю всегда, когда хочу обрезать файл журнала. Я сделал Отключить удаление файла журнала, а затем снова прикрепить. Ну, я понимаю, что, если файл журнала не закрывается должным образом, эта процедура не работает. так что в итоге я получаю файл mdf, а не файл журнала. К счастью, я зашел на сайт Microsoft и получил способ восстановить базу данных как восстановление и перейти на другую базу данных.

0
15.08.2008 13:23:23
update Customers set ModifyUser = 'Terrapin'

Я забыл предложение where - довольно невинно, но на столе с 5000+ клиентами мое имя будет на каждой записи какое-то время ...

Извлеченный урок: используйте фиксацию транзакции и откат!

2
15.08.2008 14:20:12

Однажды мне удалось написать обновляющий курсор, который никогда не выходил. На 2М + таблице строк. Блокировки только увеличивались и увеличивались до тех пор, пока этот 16-ядерный 8 ГБ ОЗУ (в 2002 году!) Фактически не остановился (из-за синего экрана).

3
15.08.2008 14:39:26

Около 7 лет назад я создавал скрипт изменения для клиентской БД после поздней работы. Я только изменил хранимые процедуры, но когда я генерировал SQL, я проверял «объекты, зависящие от сценария». Я запустил его на своей локальной машине, и все, казалось, работало хорошо. Я запустил его на сервере клиента, и сценарий был выполнен успешно.

Затем я загрузил сайт, и сайт был пуст. К моему ужасу, настройка «объекты, зависящие от сценария» выполнялась DROP TABLEдля каждой таблицы, к которой прикасались мои хранимые процедуры.

Я немедленно позвонил ведущему разработчику и боссу, чтобы они знали, что произошло, и спросил, где может быть расположена последняя резервная копия БД. Были проведены конференции с двумя другими разработчиками, и мы пришли к выводу, что не было никакой резервной системы и данные не могли быть восстановлены. Клиент потерял весь контент своего веб-сайта, и я был основной причиной. В результате наш клиент получил кредит в размере 5000 долларов .

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

4
15.08.2008 15:46:59

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

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

1
15.08.2008 16:00:13

Мы пытались исправить неисправный узел в кластере Oracle.

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

Хм, оказывается, кнопка деинсталляции применена ко всему кластеру, поэтому он с радостью удалил модуль управления хранилищем из всех узлов системы.

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

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

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

2
15.08.2008 18:02:40

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

Именно это я и сделал: | , Я обновил столбец пароля для всех пользователей в виде строки, набранной на консоли. Хуже всего было то, что я получал доступ к производственному серверу и проверял некоторые запросы, когда делал это. Моим пожилым людям пришлось вернуть старую резервную копию и отправить несколько звонков от действительно недовольных клиентов. Конечно, в другой раз я использовал оператор delete, о котором даже не хочу говорить ;-)

0
22.08.2008 05:23:10

Усеченная таблица T_DAT_STORE

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

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

0
23.02.2018 00:41:11

Я не помню всех операторов sql, которые вышли из-под контроля, но я усвоил один урок - сделайте это в транзакции, если можете (остерегайтесь больших лог-файлов!).

В производстве, если можете, действуйте по старинке:

  1. Используйте окно обслуживания
  2. Резервное копирование
  3. Выполните ваши изменения
  4. проверить
  5. восстановить, если что-то пошло не так

Довольно не круто, но в целом работает и даже возможно дать эту процедуру кому-то еще, чтобы она выполнялась во время их ночной смены, пока вы хорошо засыпаете :-)

1
24.09.2008 16:58:55

Это не случилось со мной, просто клиент нашего, чей беспорядок мне пришлось убирать.

У них был SQL-сервер, работающий на дисковом массиве RAID5 - отличные горячие диски с подсветкой индикаторов состояния диска. Зеленый = Хорошо, Красный = Плохо.

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

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

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

Мораль этой истории включает в себя ... всегда начинать новую транзакцию, прежде чем менять НИЧЕГО, проверять результаты, как вы ожидаете, а затем и только потом совершать транзакцию.

Как общее замечание, многие классы ошибок rm -rf / type можно предотвратить, правильно определив ограничения внешнего ключа в вашей схеме и держась подальше от любой команды, помеченной как «CASCADE».

0
23.11.2008 20:48:57

Я сделал именно то, что вы предложили. Я обновил все строки в таблице, которая содержала документы клиентов, потому что я забыл добавить «где ID = 5» в конце. Это была ошибка.

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

Не было

Урок, полученный на производстве: несмотря на то, что нам нравится использовать таблицы InnoDB в MySQL по многим МНОГИМ причинам ... УБЕДИТЕСЬ, что вам не удалось найти одну из немногих таблиц MyISAM, которая не учитывает транзакции, и вы не можете откатить обратно на. Не доверяйте MySQL ни при каких обстоятельствах, и обычно выдается «стартовая транзакция». Даже в худшем случае (что здесь произошло) это ничего не повредило, и это защитило бы меня за столами InnoDB.

Мне пришлось восстановить таблицу из резервной копии. К счастью, у нас есть ночные резервные копии, данные почти никогда не меняются, и таблица состоит из нескольких десятков строк, поэтому она была почти мгновенной. Для справки, никто не знал, что у нас все еще были таблицы, не относящиеся к InnoDB, мы думали, что преобразовали их все давно. Никто не сказал мне, чтобы высматривать эту ошибку, никто не знал, что это было там. Мой босс сделал бы то же самое (если бы он слишком рано нажал клавишу ввода, прежде чем набрать предложение where).

1
23.11.2008 21:59:26

Что-то с эффектом:

update email set processedTime=null,sentTime=null

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

4
23.11.2008 22:20:58