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

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

truncate table Customers
truncate table Transactions

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

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

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

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

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

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

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

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

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

Младший DBA должен был сделать:

delete from [table] where [condition]

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

delete [table] where [condition]

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

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

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

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

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

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

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

update email set processedTime=null,sentTime=null

в производственной базе данных бюллетеней повторная отправка каждого email в базе данных.

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

update Customers set ModifyUser = 'Terrapin'

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

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

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

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

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

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

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

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

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

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

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

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

Но это было не так.

Урок, полученный в производстве: несмотря на то, что мы любим использовать InnoDB таблицы в MySQL по многим MANY причинам... быть SURE вам не удалось найти одну из немногих таблиц MyISAM, которая не уважает транзакции, и вы не можете откатиться назад. Не доверяйте MySQL ни при каких обстоятельствах, и привычно выдавать "start transaction"-это хорошо. Даже в самом худшем случае (то, что произошло здесь) это ничего не повредило, и это защитило бы меня на столах InnoDB.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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