Например: Обновление всех строк таблицы клиентов, поскольку вы забыли добавить предложение where.Какая худшая авария в базе данных, которая произошла с вами в производстве?
Я сбросил базу данных и удалил ее.
Изученный урок: убедитесь, что вы знаете свой SQL - и убедитесь, что вы создали резервную копию, прежде чем прикасаться к материалу.
Младший DBA намеревался сделать:
delete from [table] where [condition]
Вместо этого они набрали:
delete [table] where [condition]
Который действует T-Sql, но в основном игнорирует где [условие] укусил полностью (по крайней мере, он сделал тогда на MSSQL 2000/97 - я забыл, что) и вытирает всю таблицу.
Это было весело: -/
Конечно, на SQL Server 2000 нет. SQL Server 97 - предшественник SQL Server 7. – splattne 2008-11-09 17:22:01
я обнаружил, что я не понимаю, Oracle журнальных файлов (? Терминологию это было очень давно) и потерял данные о торговле недели, которые должны были быть повторно вручную с помощью бумажных билетов.
Там был серебряной подкладкой - в выходные дни, когда я проводил ввод, я много узнал о возможности использования экрана ввода торговли, который значительно улучшился после этого.
Я думаю, что моя самая большая ошибка была
truncate table Customers
truncate table Transactions
я не увидел, что MSSQL сервер я вошел в, я хотел, чтобы очистить мою локальную копию из ... Знакомый «ОН s ** т», когда его был значительно длиннее, чем примерно половина секунды, чтобы удалить, мой босс заметил, что я побледнел, и спросил, что я только что сделал. Примерно через полчаса наш монитор сайта пошатнулся и начал посылать нам по электронной почте сообщение о том, что сайт не работает.
Урок? Никогда не держите соединение открытым, чтобы жить DB дольше, чем это абсолютно необходимо.
Только до 4 часов восстановления данных из резервных копий тоже! Мой босс пожалел меня и купил мне обед ...
yep i почти сделали это раньше. Определенно всегда закрывайте связь, чтобы жить, как только сможете. – alexmac 2008-11-23 21:57:45
Худший сценарий для большинства людей - потеря производственных данных, но если они не запускают ночные резервные копии или реплицируют данные на сайт DR, то они заслуживают всего они получают!
@Keith в T-SQL, не является ли ключевым словом FROM для DELETE? Оба эти заявления делают то же самое ...
Я работаю для небольшой электронной коммерции, есть 2 разработчиков и DBA, я один из разработчиков. Обычно у меня нет привычки обновлять производственные данные «на лету», если у нас есть хранимые процедуры, которые мы изменили, мы передаем их через контроль источника и установили стандартную процедуру развертывания.
Ну, в любом случае, пользователь пришел ко мне, чтобы обновить нашу базу данных контактов, чтобы обновить кучу объектов. Поэтому я написал запрос в нашей тестовой среде, что-то вроде
update facilities set address1 = '123 Fake Street'
where facilityid in (1, 2, 3)
Что-то в этом роде. Запустил его в тесте, обновил 3 строки. Скопировал его в буфер обмена, вставил его в терминальные службы на нашей производственной sql-панели, запустил, просмотрел в ужасе, так как потребовалось 5 секунд для выполнения и обновления 100000 строк. Каким-то образом я скопировал первую линию, а не второй, а не обращая внимания, как я CTRL +V, CTRL +E «д.
Мой администратор базы данных, старший греческий джентльмен, вероятно, самый суровый человек, которого я встречал, не был взволнован. К счастью, у нас была резервная копия, и она не сломала никаких страниц, к счастью, это поле действительно для отображения (и выставления счетов/доставки).
Выученный урок обращал внимание на то, что вы копируете и вставляете, возможно, некоторые другие.
Худшее, что случилось со мной, было то, что производственный сервер потребляет все пространство в HD. Я использовал SQL Server, поэтому я вижу файлы базы данных и вижу, что журнал был около 10 Гб, поэтому я решил делать то, что я всегда делаю, когда хочу обрезать файл журнала. Я удалил файл журнала и снова подключился. Хорошо, я понимаю, что если файл журнала не работает должным образом, эта процедура не работает. поэтому я получаю файл mdf и файл журнала. К счастью, я пошел на сайт Microsoft, и мне удалось восстановить базу данных в качестве восстановления и перейти в другую базу данных.
update Customers set ModifyUser = 'Terrapin'
Я забыл, где положение - довольно невинное, но на столе с 5000+ клиентов, мое имя будет на каждой записи на некоторое время ...
Урок: Использование транзакции и отката !
Однажды мне удалось написать курсор обновления, который никогда не выходил. На таблице строк 2M +. Блокировки просто эскалировались и эскалировались до тех пор, пока этот 16-ядерный ящик объемом 8 ГБ (в 2002 году!) Фактически не остановился (из разновидности синего экрана).
Около 7 лет назад я создавал сценарий изменений для базы данных клиента после работы. Я только изменил хранимые процедуры, но когда я сгенерировал SQL, у меня были «зависимые от скрипта объекты». Я запустил его на своей локальной машине, и все оказалось хорошо работать. Я запустил его на сервере клиента, и сценарий преуспел.
Затем я загрузил веб-сайт, и сайт был пуст. К моему ужасу, настройка «зависимые от сценария» делала DROP TABLE для каждой таблицы, к которой коснулись мои хранимые процедуры.
Я сразу же позвонил ведущему разработчику и начальнику, чтобы сообщить им, что произошло, и спросить, где можно найти последнюю резервную копию БД. 2 другим разработчикам были связаны, и мы пришли к выводу, что резервная система не была даже на месте, и никакие данные не могли быть восстановлены. Клиент потерял весь контент своего сайта, и я был основной причиной. Результатом стал кредит $ 5000, предоставленный нашему клиенту.
Для меня это был отличный урок, и теперь я очень осторожен в работе над любыми сценариями изменений и резервным копированием БД. Я по-прежнему с той же компанией сегодня, и всякий раз, когда шутки приходят о резервных копиях или сценариях базы данных, кто-то всегда вызывает знаменитый инцидент «DROP TABLE».
Я думал, что работал в тестовой БД (это было не так), поэтому, когда я закончил «тестирование», я запустил сценарий, чтобы сбросить все данные обратно к стандартным тестовым данным, которые мы используем. Ой!
К счастью, это произошло в базе данных с резервными копиями на месте, поэтому, выяснив, что я сделал что-то неправильно, мы могли легко вернуть исходную базу данных.
Однако этот инцидент действительно учил компании, с которой я работал до realy, независимо от производственной и тестовой среды.
Мы пытались исправить разбитый узел в кластере Oracle.
У модуля управления памятью возникли проблемы, поэтому мы нажали кнопку un-install с целью переустановки и копирования конфигурации с другого узла.
Хм, оказывается, что кнопка un-install применяется ко всему кластеру, поэтому он с радостью удалил модуль управления хранилищем со всех узлов в системе.
Устранение всех узлов в кластере производства. И поскольку ни один из узлов не имел менеджера хранилища, они не появлялись!
Вот интересный факт о резервном копировании ... самые старые резервные копии заставляют заходить за пределы сайта, и вы знаете, какие ваши самые старые файлы в базе данных? Конфигурационные файлы, которые были настроены при установке системы.
Таким образом, мы должны были отправить людей-экспедиторов с этой лентой, и через пару часов у нас было все переустановлено и запущено. Теперь мы сохраняем локальные копии файлов установки и настройки!
Обновление всех строк таблицы клиентов, поскольку вы забыли добавить предложение where.
Это было именно то, что я сделал: | , Я обновил столбец паролей для всех пользователей на строку с образцом, которую я набрал на консоль. Хуже всего то, что я обращался к серверу производства, и я проверял некоторые запросы, когда я это делал. Затем моим старшим пришлось отменить старую резервную копию и пришлось нанести некоторые вызовы от некоторых действительно недовольных клиентов. Конечно есть еще один момент, когда я действительно использовал ВЕЬЕТЕ, что я даже не хочу говорить о ;-)
усечение таблицы T_DAT_STORE
T_DAT_STORE был тот факт, таблица отдела I работа. Я думаю, что я был связан с базой данных разработки. К счастью, у нас есть ежедневная резервная копия, которая не использовалась до этого дня, и данные были восстановлены через шесть часов.
С тех пор я пересмотреть все до усечения, и периодически я прошу резервного восстановления мелких таблиц только для проверки резервного копирования делает хорошо (резервное копирование не производится моим отделом)
Я не помните все заявления sql, которые вышли из-под контроля, но у меня есть один урок, который выучили - сделайте это в транзакции, если сможете (остерегайтесь больших лог-файлов!).
В производстве, если вы можете, действуйте по старинке:
Довольно нераскрытый, но, как правило, работающий и даже способный дать эту процедуру кому-то еще, чтобы запустить ее во время ночной смены, пока вы получаете свой заслуженный сон :-)
Это не случилось со мной, клиент нашего хаоса, который мне пришлось убирать.
У них был сервер SQL, работающий на RAID-массиве RAID5 - хорошие диски с горячей заменой в комплекте с индикаторами состояния освещенного диска. Зеленый = Хорошо, Красный = Плохо.
Один из их приводов превратился из зеленого в красный, а гений, которому было приказано вытащить и заменить (красный) плохой диск, вместо этого получил (зеленый) хороший. Ну, это не совсем удавалось полностью сбить набор рейдов - в течение нескольких минут выбирая несколько читаемый (красный) и неизменный (зеленый). После осознания ошибки и замены дисков назад все блоки данных, которые были написаны во время этого время становилось jyberish по мере того, как была потеряна синхронизация диска) ... 24 часа подряд записывали метапрограммы для восстановления читаемых данных и восстанавливали схему среднего размера, в которой они выполняли резервное копирование и запуск.
Мораль этой истории включает в себя ... Никогда не используйте RAID5, всегда поддерживайте резервные копии, заботясь о том, кого вы нанимаете.
Однажды я совершил серьезную ошибку в системе производства клиентов, к счастью, задаваясь вопросом, почему команда так долго выполняла, чтобы реализовать, что я сделал, и отменил ее до того, как мир подошел к концу.
Мораль этой истории включает в себя ... всегда начинайте новую транзакцию, прежде чем изменять НИЧЕГО, проверьте результаты, которые вы ожидаете, а затем и только затем совершите транзакцию.
В качестве общего наблюдения многих классов ошибок -rf/типа ет может быть предотвращены путем надлежащего определения ограничений внешних ключа на вашу схему и оставаться далеко от любой команды помечены «КАСКАД»
я сделал именно то, что вы предложили , Я обновил все строки таблицы, в которой хранятся документы клиента, потому что я забыл добавить «где ID = 5» в конце. Это была ошибка.
Но я был умным и параноидальным. Я знал, что однажды испортил бы. Я опубликовал «стартовую транзакцию». Я выпустил откат, а затем проверил, что таблица в порядке.
Не было.
Урок, полученный в процессе производства: несмотря на то, что нам нравится использовать таблицы InnoDB в MySQL для многих МНОГИХ причин ... быть уверенным, что вам не удалось найти одну из немногих таблиц MyISAM, которая не учитывает транзакции и вы не можете вернуться назад. Не доверяйте MySQL ни при каких обстоятельствах, и обычная выдача «стартовой транзакции» - это хорошо. Даже в худшем случае (что здесь произошло) это ничего не повредило, и это защитило бы меня на столах InnoDB.
Мне пришлось восстановить таблицу из резервной копии. К счастью, у нас есть ночные резервные копии, данные почти никогда не меняются, а таблица - несколько десятков строк, поэтому она была почти мгновенной. Для справки никто не знал, что у нас все еще есть таблицы, отличные от InnoDB, мы думали, что мы их давно переделали. Никто не велел мне следить за этой добычей, никто не знал, что это было. Мой босс сделал бы то же самое (если бы он набрал слишком рано, прежде чем набирать предложение where).
Что-то эффект:
update email set processedTime=null,sentTime=null
на базе производства бюллетеня, повторная отправка каждое письмо в базе данных.
одновременно удалено и удалено .. но почему вы так сильно отреагировали на плохую производственную базу данных ;-) – Chris 2011-03-21 11:46:33