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

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

truncate table Customers
truncate table Transactions

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

Урок извлечен? Никогда не сохраняйте соединение открытым для проживания DB дольше, чем необходимый absolutly.

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

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

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

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

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

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

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

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

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

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

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

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

Как общее наблюдение много классов комнаты-rf / ошибки типа могут быть предотвращены путем надлежащего определения ограничений внешнего ключа на схему и пребывания далеко от любой команды labled 'КАСКАДА'

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

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

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

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

@Keith в T-SQL, не ОТ ключевого слова, дополнительного для УДАЛЕНИЯ? Оба из тех операторов делают точно то же самое...

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

Был луч надежды - в течение выходных, я потратил ввод, я узнал много о useability моего торгового входного экрана, который улучшился существенно после этого.

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

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

Это не было.

Урок извлечен в производстве: несмотря на факт нам нравится использовать таблицы InnoDB в MySQL для многих МНОГО причин... быть УВЕРЕННЫМИ, что Вам не удалось найти одну из нескольких таблиц MyISAM, которая не уважает транзакции, и Вы не можете откатывать на. Не доверяйте MySQL ни при каких обстоятельствах, и обычно издание "запускается, транзакция" является хорошей вещью. Даже в худшем варианте развития событий (что произошло здесь) это ничего не повредило, и это защитит меня на таблицах InnoDB.

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

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

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

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

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

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

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

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

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

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

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

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

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

update Customers set ModifyUser = 'Terrapin'

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

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

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

Что-то к эффекту:

update email set processedTime=null,sentTime=null

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

Приблизительно 7 лет назад я генерировал сценарий изменения для DB клиента после работы поздно. Я только изменил хранимые процедуры, но когда я генерировал SQL, у меня были "зависимые объекты сценария", проверенные. Я выполнил его на своей локальной машине, и все, казалось, работали хорошо. Я выполнил его на сервере клиента и сценарии, за которым следуют.

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

Я сразу назвал вывод dev и босса, сообщающего им, что произошло и выяснение, где последнее резервное копирование DB могло быть расположено. 2 других devs были conferenced в и заключением, в которое мы приехали, был то, что никакая система резервного копирования не была даже на месте, и никакие данные не могли быть восстановлены. Клиент потерял содержание их всего веб-сайта, и я был первопричиной. Результатом был кредит в размере 5 000$, данный нашему клиенту.

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

Младший DBA означал делать:

delete from [table] where [condition]

Вместо этого они ввели:

delete [table] where [condition]

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

Это было забавой :-/

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

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

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

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

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

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