Базы данных

Сопровождаем медицинскую БД в крупной больнице. Письмо от наших частых собеседников — отдела медицинской статистики.

Посмотрите, пожалуйста, сводку за ##.##. Ну не может человек умереть за один день дважды! А если глянуть сводку по хирургии, этот же пациент ещё и выписан. Хотя я вообще не понимаю, что он мог делать в хирургии, если он числится за отделением неврологии и никуда оттуда не переводился. А умер он вообще в реанимации…

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

Ищем мы пользователей, и в гриде среди большого числа всяких Mr. TestName01 LastName01 красным флагом в капсе виднеется пользователь со словом PORN во всех полях. А юзеров по политике удалять нельзя… Пришлось быстро выдумывать историю, что тестили валидацию полей и решили прикрутить словарь запрещённых слов. Идею одобрили, а с тем юзером историю замяли — пусть висит как напоминание.

Работаю в техподдержке софтовой фирмы. Придя на смену, получаю задание с пометкой к исполнению «ещё вчера». Сегодня суббота, и за выходные надо всё сделать.

Суть задания: обновить софт на сервере и перенести часть БД на второй сервак. Дело не самое сложное, но может потребовать времени. Копирую нужные файлы на флешку, запускаю программу обновления и понимаю, что база лежит.
Вскрытие показывает, что повреждены блоки в файлах БД, а это значит, что база полностью неработоспособна. Бэкапов нет, Oracle настолько древний, что никаких RMAN ещё нет и в помине.

Поднял БД с помощью хекс-редактора и такой-то матери. Читаю логи и нахожу дату, когда эта ошибка всплыла впервые: 24 декабря 2008 года.

MSSQL выдал ошибку:

«Определите причину и исправьте ошибку операционной системы, и ещё раз попытайтесь выполнить операцию».

И на том спасибо! Хорошо, что не так:

«Ошибка ОС. Сделайте что-нибудь, если получится — расскажите нам».

В серверных логах СУБД Progress (если они на русском велись) при отвале клиентского процесса иногда наблюдалось чудное сообщение: «Клиент такой-то плохо кончил».

Один раз клиентская часть того же Прогресса выдала просто шедевральный месседжбокс с текстом «Не могу» и кнопкой «OK». Даже пожалеть захотелось.

Вам случалось иметь таблицу с такой кучей записей, что довольно трудно понимать, что в ней происходит? Если да, то вы поймёте, почему в одном из проектов по ходу необходимого рефакторинга было решено разделить эту таблицу на четыре более мелких. Рефакторинг, как ни странно, прошёл на ура: бранч примёрджился без конфликтов, скрипт для миграции базы тоже вполне неплохо отрабатывал на кошках, то есть на копиях рабочей базы, тесты работали как ни в чём не бывало.

Что ж, сайт закрыт, база обновилась, прошёл скрипт миграции. Сайт запущен и пашет вроде бы даже стабильно. Через день началось. Пользователи перестали регистрироваться, регистрация падала с ошибкой внешнего ключа в одной из получившейся при разделении таблиц. Заказчик в бешенстве, рвёт и мечет, дёргает всех, начиная с разработчика (он прикреплён к поддержке и развитию проекта) и заканчивая директором компании. Директор добавляет своей суеты. Тестировщик на песочнице с рабочей базой повторить баг не может — у него всё пашет на ура.

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

Человек, который разделял таблицу, создал две другие по образу и подобию первой: он поставил в них автоинкремент на первичный ключ. При регистрации пользователя создавалась основная запись, значение автоинкремента увеличивалось, проходили дальнейшие операции. По дороге что-то не срасталось, и транзакция откатывалась, но значение автоинкремента в основной таблице оставалось увеличенным. При следующей попытке регистрация уже не могла пройти никак. Пока «упряжка автоинкрементов» таблиц шла вровень, всё работало. Как только произошла одна ошибка при регистрации, главная таблица вырвалась вперёд.

А мораль такова: как бы вы ни были загружены, обязательно проверяйте миграционные скрипты своих сотрудников!

Презабавнейший случай произошёл только что у меня на работе. Позвонила мне девушка из одного из офисов, которые подключаются к главному веб-серверу. У неё внезапно вывалилась ошибка MySQL: «Access denied». Короче, оказалось, что работа парализована во всех офисах. Я полез на сервер, перезапустил MySQL, сбросил рутовый пароль — результат тот же.

Начал думать. Вспомнил, что этот сервер поднимали когда-то парни из Тулы, и у них есть доступ по SSH, поэтому решил проверить логи. Так точно: в девять утра заходил парень с тульским айпишником. Пятиминутный поиск по свежим следам показал, что в одном из перловых скриптов были изменены параметры доступа к MySQL: в строчке с паролем вместо буквы «i» стояла единица.

В общем, схема была такая: парень поменял символ для того, чтобы мы не смогли войти в базу, перепугались, позвонили ему, а он бы всё нам починил и взял за это щедрую пригоршню долларов. Такой вот бесчестный корыстный редиска! Я ему в аську потом написал, чтобы он хоть следы после себя заметал.

— Господа, вы как-то невнимательно читаете. Вопрос не в том, знаю я или нет, как это победить. Я понимаю, что искушение показать себя умным и дать очередную порцию рекомендаций велико, но всё-таки: вопрос в том, что установка %SQLServer% с умолчательными параметрами даёт возможность положить сервер под Виндой. Чтобы этого избежать, всего-то нужно отказаться от умолчательного пароля под виндой, как это уже сделано под многими линуксами. Но все обсуждения стартуют одинаково: «Настрой конфигурационный файл, права доступа…»

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

Великая смена логинов для реализации контекстов безопасности — кто сталкивался с со сменой руководства в крупных компаниях, поймёт. Я, админ БД, и наш сисадмин (парень очень умный и учёный — только список его MS-сертификатов длиннее всего моего резюме за семь лет) выставляем новые логины. Попытки сделать это по виндостандарту заняли уже больше часа, а служба MSSQLServer всё продолжает сообщать нам, что мы отчаянно неправы. В какой-то момент времени до меня доходит идея сделать всё образом, не предусмотренным инструкциями.

— Есть предложение сделать невиндовую аутентификацию, перезавести логин на обоих серверах, дать права db_owner на рабочих базах и право securityadmin.
— Странно… По всем правилам и так должно работать.
— Почему странно? Всё через жопу, так что правильность решения сомнений не вызывает!

Через несколько минут:

— Заработало!

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