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

Question

Вы знаете тот, о котором я говорю.

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

Конечно, теперь вы можете смеяться над этим, верно, так что продолжайте и поделитесь своими неудачами с SQL Server с нами.

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

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

Это было в мои первые годы в качестве младшего гуру SQL Server. Я мчался вокруг Enterprise Manager, выполняя несколько обязанностей администратора. Вы знаете, как это, проверив несколько журналов, убедившись, что резервные копии работают нормально, немного ведя базу данных, в значительной степени занимаясь бизнесом на автопилоте и нажимая клавишу ввода в обычных всплывающих подсказках.

Ой, подождите, было ли сообщение «Вы уверены, что хотите удалить эту таблицу»? Слишком поздно!

Просто для подтверждения любых начинающих администраторов баз данных удаление производственной таблицы - очень и очень плохая вещь!

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

Answer 1

Полагаю, что в какой-то момент все пропустили предложение WHERE из DELETE или UPDATE ...

Answer 2

Я изменил все цены до нуля на крупномасштабном, производственном сайте электронной коммерции. Мне пришлось закрыть сайт и восстановить БД из резервной копии. ОЧЕНЬ УЖАСНО.

К счастью, это было ОЧЕНЬ давно.

Answer 3

Моя самая большая ошибка SQL Server заключалась в том, что он был так же эффективен, как Oracle, когда дело дошло до параллелизма.

Позвольте мне объяснить.

Когда речь идет об уровне изоляции транзакций в SQL Server, у вас есть два варианта:

1. Грязные чтения: транзакции могут видеть незафиксированные данные (из других транзакций); или
2. Выбирает блокировку неподтвержденных обновлений.

Я полагаю, что они получены из ANSI SQL.

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

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

Достаточно сказать, что это был опыт обучения.

А ты знаешь что? Даже MySQL имеет MVCC.

Answer 4

Внесено 5 миллионов тестируемых в производственную базу данных. Самая большая ошибка, на мой взгляд, состояла в том, что я позволил мне иметь доступ для записи к производственной базе данных. : P Bad dba!

Answer 5

Я работал над платежной системой в крупном онлайн-бизнесе. Многомиллионный бизнес.

• Получите скрипт от коллеги с несколькими небольшими обновлениями.
• Запустите его на производстве.
• Получите сообщение об ошибке через 30 минут от службы поддержки, жалуясь на отсутствие покупок за последние 30 минут.
• Обнаружение того, что все соединения ожидают освобождения блокировки таблицы
• Обнаружьте, что сценарий моего коллеги начался с явного НАЧАЛА СДЕЛКИ и ожидал, что я в конце наберу команду COMMIT TRANSACTION.
• Объясните боссу, почему были потеряны 30 минут продаж.
• Виноват себя в том, что я не прочитал документацию сценария должным образом.

Answer 6

забывая выделить предложение WHERE при обновлении или удалении

создание сценариев и проверка в первую очередь отбрасываемых зависимых объектов и запуск их на производстве

Answer 7

Запуск восстановления с прошлой недели на производственном экземпляре вместо экземпляра разработки. Не доброе утро.

Answer 8

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

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

Answer 9

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

Answer 10

Я видел множество других людей, которые пропускают предложение WHERE.

Сам я всегда сначала набираю предложение WHERE, а затем возвращаюсь к началу строки и набираю оставшуюся часть запроса:)