Что произошло в прошлый раз, когда произошел простой SQL Server или потеря данных?

Other that the classic "I forgot to include the WHERE clause and I wasn't inside a transaction" update/delete statement?

Kept getting the databases on one server going offline in our lab environment. The drive the MDB files lived on would just disappear, SQL would hiccup, and I'd need to manually bring the databases back online when the drive re-appeared (usually a few minutes later) Spent the better part of a week with the ops guys to try and determine why the drive was going away. It was a LUN on the SAN, with redundant paths to the switch.

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

В результате человеческой ошибки база данных MS-SQL объемом 2 терабайта была сброшена. Они заметили довольно быстро и решили перестроить индексы. К сожалению, этот процесс занял 48 часов. Оглядываясь назад, было бы легче (и вызвало бы намного меньше времени простоя) восстановить с ленты.

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

У нас была односторонняя репликация транзакций из SQL 2K (SP3) в SQL 2K (SP3), и во время развертываний репликацию следует отключать и перестраивать как политику компании, если в репликации задействованы таблицы. В какой-то момент было принято решение перейти на SP4, и изменения были перенесены на все серверы Prod, но репликация не была восстановлена ​​после обновления.

Пару недель спустя мой проект (я был разработчиком базы данных и подрядчиком) должен был быть развернут, и я нахожусь в центре обработки данных, поддерживающем развертывание (обычно развертывания выполняются в полночь). Репликация была прервана, развертывание проекта прошло успешно, а при восстановлении репликации произошел сбой через 2 часа. Сотрудник SCM перезапустил его, не прочитав полное сообщение об ошибке в 3 часа ночи, и через 2 часа снова произошел сбой, и мы почти приближаемся к SLA. Я знал, что должен был позвонить своему менеджеру в 5 часов утра, и было сделано много звонков, чтобы распространить проблему на все уровни / группы.

Группа DBA взяла на себя проблему в 6 часов утра, и я был в неведении относительно шагов по устранению неполадок, и мой менеджер попросил меня 3 раза за 2 часа проверить, не отвечаю ли я за то, что мои скрипты отвечают за провал. Моя голова была на линии. 4 менеджера Prod DBA и 2 менеджера были в восторге от этой проблемы, и с MSFT был поднят билет, и даже после 3 часов дня проблема НЕ была решена, пока я не выяснил, что на самом деле произошло. В одной статье (таблице) у нас был уникальный индекс по столбцу, но качество данных было плохим. У нас было '' и нулевое значение, а оставшиеся миллионы записей были допустимыми значениями, хотя некоторые устаревшие данные были сомнительными. После обновления SP4 SQL Server пытался преобразовать '' и нулевые значения в нулевое на стороне подписчика, и это не удалось из-за нарушения уникального ключа / индекса. Неверные данные были удалены после получения разрешений высокого уровня от бизнес-группы, и я смог сохранить свою работу еще на один год.

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

В небольшой компании, в которой я был, мы только что отключили базовый сайт Sharepoint Services. Мы были маленькими, но наши работники были по всему миру, поэтому веб-доступ и интеграция MS Office для Sharepoint были удивительными (все остальное отстой, но это уже другая история) Поскольку у нас не было много денег, и мы были маленькими, мы сохранили это простым, один SQL сервер с RAID и один веб-сервер также с RAID. Около 1 недели и 5 гигабайтов данных проекта в него произошел сбой блока питания в блоке SQL. У нас был день простоя в ожидании доставки нового. Мы могли бы перенести резервные копии на другой сервер, но, поскольку мы все еще были новичками в распределении ресурсов, план аварийного восстановления все еще находился в процессе разработки, и мы решили, что потребуется время, чтобы все это выяснить, так же как и ожидание поступления блока питания и так как мы знаем, как только у нас будет новый источник питания, мы будем в сети и не должны откатываться, мы просто решили подождать и не рискнуть испортить sharepoint.