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

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

  1. Каково это было - осознать это и сообщить об этом своим коллегам или клиентам?
  2. Какие уроки были извлечены?

Ответов (18)

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

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

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

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

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

truncate table Customers
truncate table Transactions

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

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

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

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

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

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

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

delete from [table] where [condition]

Вместо этого они набрали:

delete [table] where [condition]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы пытались исправить вышедший из строя узел в кластере Oracle.

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

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

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

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

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

update Customers set ModifyUser = 'Terrapin'

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

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

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

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

Обрезать таблицу T_DAT_STORE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это было не так.

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

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

Что-то вроде:

update email set processedTime=null,sentTime=null

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