Базы данных

На работе прислали новую версию программы. Старая версия была ужасна — новую я уже «люблю» за вот такой пассаж из прилагаемой инструкции:

Пользователи версии 2.01 могли заметить ошибку при автоматической нумерации выдаваемых справок. Данная ошибка возникает из-за неравномерности записи данных в базу. Эта неравномерность вызвана неправильной эксплуатацией вашего компьютера, а именно возникает от частой записи и удаления файлов (или программ) больших объёмов. Чтобы устранить эту неравномерность, необходимо регулярно проводить дефрагментацию логических дисков вашего компьютера.

Зацените, как надо делать — валить глюки своей проги на фрагментирование диска! Это ж додуматься надо.

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

Решили мы тут озаботится вопросом, не расширить ли парк серверов баз данных — ресурсы есть, но нужно ли? Стали собирать статистику. Самым большим по количеству (75%) и объёму (90%) запросов оказался сайт Самого Важного Клиента, который занимал чуть ли не половину дискового пространства всего хранилища и отвечал за 60% всего трафика. Решили посмотреть, что они такое туда пишут.

Оказалось, разработчики этого чуда решили оптимизировать SQL-запросы и использовали какую-то чудо-библиотеку, которая на лету оптимизировала обращения к MySQL-кластеру. Результат оптимизации выглядел следующим образом: сначала происходит обращение на сервер с целью создания физического плана запроса, ждёт подтверждения, затем в него подсовываются входные параметры, забирается результат, но тут происходит самое страшное — физический план запроса удаляется. То есть при каждом однотипном запросе физический план создаётся заново. Но и это не самое страшное. Половина всех запросов выглядела так:

INSERT INTO `statistic_logs` VALUES ...

В результате простейший запрос, занимающий одну строку и являющийся элементарной операцией MySQL-сервера, после «оптимизации» занимал восемь строк и выполнялся в полтора раза медленнее.

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

История произошла по причине моего увлечения опенсорсом. Как не крути, а GNU/Linux от известных мейнтейнеров работает на старом железе гораздо надёжнее и стабильнее, нежели «популярная» ОС. Всё началось с малых экспериментов над одной программой для оборудования с ЧПУ. Поставил Дебиан и Вайн, первый же блин вышел комом — нет связи по COM-порту, точнее, есть, но очень нестабильная. Погуглив, нашёл патч для драйвера, исправлявший этот недостаток. Накладывать пришлось, конечно же, напильником, благо С я немного знал.

Всё прекрасно работало в течение нескольких месяцев, пока не пришло обновление. Оно-то тоже работало, да вот только базы данных в этот раз должны были быть в клиент-серверном варианте, да ещё и через сторонний драйвер. Из-за некоторых ограничений Вайн не мог такие костыли поддерживать, но я немного покопался и нашёл-таки способ использовать локальные базы.

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

Это уже была серьёзная проблема, которую пришлось «выпилить» банальным hex-редактором, благо сама же программа выдавала окна с указанием ошибок в синтаксисе запросов. Так-то, лучший саппорт — голова на плечах.

Третьего дня свёл знакомство с одной проблемой. Наши одиночества встретились весьма прозаичным способом: я жил и писал странные команды в консоли, а она родилась хоть и тихо, но зато сразу всех обрадовала — точнее, сначала заказчиков. Потом они вместе пришли и всем своим видом показали: «А вот и мы!» Бага была из разряда пренеприятнейших — пряталась умело, возникала внезапно и при возникновении сразу знала, куда наносить удар. Именно в то место, где сходятся интересы всех без исключения — в финансовые расчёты.

В процессе ловли ошибки я много времени провёл наедине с базой данных. Нужно упомянуть, что я работаю в области строительства цифрового телевидения. Так вот, обнаружилось странное — приличное количество абонентов по непонятной причине подписывает и отписывает один и тот же сервис по несколько раз за день, да и еще с завидным упорством повторяет эти действия на протяжении месяцев! Причину такого странного поведения понять стало даже интереснее, чем ловить багу, про которую уже все забыли. Так как в базе все сущности связаны хитросплетением ID, «констрейнтов» и прочих «форейнкеев», на первый взгляд кажется, что люди просто любят мелькание менюшек на телевизоре.

Всё обрело смысл, как только я выцепил человеческое имя этого сервиса. Им оказался пакет каналов «Досуг». Да-да, набор каналов с замечательными девушками и их хирургическими достижениями. Изучение результатов выполнения запросов показало, что для удовлетворения среднестатистическому пользователю нужно от двух до пятнадцати минут. Как правило, люди склонны к изучению своего внутреннего мира с утра и после работы. И самое главное — все склонны скрывать свою страсть к подобного рода времяпрепровождению, так как отключают сервис сразу после выполнения задуманного.

Закончив интересный анонимный соцопрос, я подумал: «Как же хорошо быть айтишником!»

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

Недавно мне на глаза попались исходники одного скрипта регистрации на сайте; среди прочих была и графа «пол» — пара радиокнопок. Не знаю, сколько раз человек, писавший этот скрипт, сталкивался с бесконечно меняющимися требованиями заказчиков, но этот перл, по-моему, является верхом перестраховочной паранойи.

Среди прочих таблиц в базе данных была таблица «sexes»: идентификатор и название, две строки. В профиле у каждого пользователя хранился идентификатор нужной строки. Интересно, предусмотрел ли что-нибудь автор на тот случай, если на ключ этой таблицы перестанет хватать четырёх байт?

Довелось мне работать в местном интернет-провайдере. Помимо предоставления телекоммуникационных услуг, фирма зарабатывала на создании различных тематических сайтов. Одним из них был сервис по отсылке SMS-сообщений, которые клиенты нашей сети могли отправлять бесплатно.

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

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

update users set password='newpass' where id - 1234;

...и жму Enter. Вместо знака равенства нажалась клавиша «минус». В результате база данных, вычислив разность между номерами клиентов и заданным числом, поменяла пароли всем, кроме этого клиента.

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

Проверяйте запросы перед выполнением!

Служба поддержки клиентских серверов неоднократно упомянутого датацентра.

Один из серверов был сильно перегружен клиентскими сайтами и в конце концов перестал отдавать контент: пошел в своп, а load average зашкаливал за полсотни. Начинаем вместе с клиентом выяснять, чем же его так. В выводе top налицо активно лопающий память MySQL-сервер, каковым фактом мы радуем клиента и рекомендуем оптимизировать запросы. Клиент отвечает: «Сайт не использует базу данных этого сервера, а работает с удалённой базой».

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

— Ммм, а сколько сайтов находится на нашем сервере, и каких именно?

Несколько лет назад наша контора внедряла большую ERP-систему в большой конторе. Всё было настроено, отлажено, проверено, данные загружены. Наступило замечательное время, которое у консультантов называется UAT. Восхищённые/раздражённые юзеры полезли грязными руками тыкать в кнопочки. Одним из юзеров был важный дядя (не Сам, но почти).

Итак, модуль по работе с кадрами. Дядя, не мудрствуя лукаво, запрашивает свои собственные данные и выпадает в осадок. Мало того, что он отображается в системе как женщина, так он (она?) ещё и беременный! Так как кодят систему в основном индусы, огрехи всплывают часто. Как оказалось, забеременеть можно не только по естественным причинам, но и в результате неправильного использования nvl и decode.

Ведь обещали миллион условных енотов первому мужчине, который родит. Можно сказать, дядя шел к успеху, но не подфартило. Исправленный код выпустили через неделю. А какая была мечта!

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

Вот уже не осталось носителей знаний, и даже некому было поставить клиент Navision Axapta. Каково же было моё изумление, когда хрупкая девушка попросила меня подойти к ней! На экране — удалённая оснастка, вход в локальную базу и какой-то мелкий вопрос, как правильно делать бэкап. Оказалось, что многие годы эта героическая девушка из бухгалтерии по инструкции еженедельно делала бэкап самой важной базы, как ей и заповедовал один из основоположников всей этой системы.