Это не вопрос о том, как справиться с простоями или потерей данных или ограничить их, я все об этом знаю. Я составляю раздел «Истории» для своего выступления по завершении конференции PASS по аварийному восстановлению, и я хотел бы иметь возможность поделиться некоторыми более свежими и впечатляющими историями, чем те, что у меня были из дней в Microsoft, хотя, если вы Я слышал, как я представлял свою колоду коррупции в любое время за последние 3 года, вы помните, что все они были бездельниками.
Так что подумайте, что это своего рода исповедь (хотя я не могу дать отпущение грехов :-) и, конечно же, все рассказанные здесь истории произошли с другом или коллегой, или в предыдущей компании, если вы не смелы и не хотите признайся. Я не буду осуждать или высмеивать какие-либо ответы, а предоставлю информацию только по запросу.
На самом деле идея состоит в том, чтобы каждый учился на ошибках и просчетах. В качестве примера рассказа, который я слышал, см. Печальная история ошибок и коррупции.
Не уверен, сработает это на этом форуме или нет, но попробовать стоит.
Спасибо!
PS Если вы не видели мою сессию коррупции и не слышали рассказы, это была сессия №2 на TechEd IT Pro в прошлом году, и они записали ее на видео: см. TechEd: 80-минутное видео презентации методов выживания в коррупции. Сообщение в блоге содержит ссылки на кучу поврежденных баз данных и демо-скриптов, которые вы также можете скачать и поиграть (без рекламы или чего-то подобного на нашем сайте, просто информация).
Другое, что классический оператор обновления / удаления «Я забыл включить предложение WHERE, и я не был внутри транзакции»?
Продолжал отключать базы данных на одном сервере в нашей лабораторной среде. Диск, на котором находились файлы MDB, просто исчезнет, SQL заканчивал, и мне нужно было вручную вернуть базы данных в оперативный режим, когда диск снова появился (обычно через несколько минут). Провел большую часть недели с оператором. ребята, чтобы попытаться определить, почему уходит диск. Это был LUN в сети SAN с избыточными путями к коммутатору.
Короче говоря, оказалось, что оптоволоконные кабели не были полностью вставлены в порты коммутатора, а кабели сместились во время недавнего технического обслуживания. Теперь они находились в полости между дверцей стойки и нишей, в которую она закрывается. Когда дверь закрылась, она потянула за кабели ровно настолько, чтобы заглушки вылетели и оборвали соединение. Дверь не была заперта, она просто свободно раскачивалась, и когда дверь в лабораторию открывалась / закрывалась, движение воздуха заставляло дверцу стойки раскачиваться вперед и назад.
Из-за человеческой ошибки все индексы базы данных MS-SQL размером 2 терабайта упали. Они заметили это довольно быстро и решили перестроить индексы. К сожалению, этот процесс занял более 48 часов. Оглядываясь назад, было бы легче (и вызвало бы гораздо меньше простоев) восстановление с ленты.
В небольшой компании, в которой я работал, мы только что исключили базовый сайт Sharepoint Services. Мы были маленькими, но наши сотрудники были по всему миру, поэтому веб-доступ и интеграция MS Office для Sharepoint были потрясающими (все остальное - отстой, но это уже другая история). Поскольку у нас не было много денег и мы были маленькими, мы сохраняли простоту, один SQL сервер с RAID и один веб-сервер также с RAID. Примерно 1 неделя и 5 гигов проектных данных в ней отказал блок питания в ящике SQL. У нас был день простоя в ожидании доставки нового. Мы могли бы перенести резервные копии на другой сервер, но, поскольку мы все еще были новичками в sharepoint, план аварийного восстановления все еще находился в разработке, и мы посчитали, что на то, чтобы разобраться во всем этом, потребуется столько же времени, как и просто дождаться прибытия источника питания , и поскольку мы знаем, что как только у нас появится новый блок питания, мы будем в сети и не будем отказываться от него, мы просто решили подождать и не рисковать испортить sharepoint.
Несколько лет назад, работая в автомобильной финансовой компании, я отключил один сервер базы данных во время развертывания. Это одна из главных ошибок, которые я совершил в своей профессиональной жизни, хотя из этой проблемы я вышел совершенно чистым.
У нас была односторонняя репликация транзакций из SQL 2K (SP3) в SQL 2K (SP3), и во время развертывания репликация должна быть отключена и перестроена как политика компании, если она включает в себя таблицы (таблицы) в репликации. В какой-то момент было принято решение об обновлении до SP4, и изменения были перенесены на все prod-серверы, но репликация не была восстановлена после обновления.
Пару недель спустя мой проект (я был разработчиком базы данных и подрядчиком) должен был быть развернут, и я нахожусь в центре обработки данных, поддерживающем развертывание (обычно развертывание выполняется в полночь). Репликация была остановлена, развертывание проекта прошло успешно, а при восстановлении репликация завершилась неудачно через 2 часа. Специалист по SCM перезапустил его, не прочитав всего сообщения об ошибке, в 3 часа ночи, и через 2 часа он снова отказал, и мы почти приближаемся к SLA. Я знал, что должен позвонить своему менеджеру в 5 часов утра, и было сделано много звонков, чтобы передать проблему на все уровни / группы.
Группа администраторов баз данных взяла на себя эту проблему в 6 часов утра, и меня держали в неведении от действий по устранению неполадок, и мой менеджер трижды за 2 часа просил меня проверить, несут ли мои скрипты ответственность за провал. Моя голова была на кону. 4 администратора базы данных Prod и 2 менеджера горячо высказались по этому поводу, и в MSFT был поднят запрос, и даже после 15:00 проблема НЕ была решена, пока я не выяснил, что произошло на самом деле. В одной статье (таблице) у нас был уникальный индекс для столбца, но качество данных было плохим. У нас было '' и нулевое значение, а оставшиеся миллионы записей были допустимыми значениями, хотя некоторые устаревшие данные были сомнительными. После обновления SP4 SQL Server пытался преобразовать значения '' и NULL в NULL на стороне подписчика, и это не удалось из-за нарушения уникального ключа / индекса. Плохие данные были удалены после получения разрешений высокого уровня от бизнес-группы, и я остался на работе еще на год.
Извлеченный урок: тестируйте, тестируйте и тестируйте каждую имеющуюся у вас программу, прежде чем переходить с обновлением.