Базы данных

Никогда не работал программистом, но чтобы облегчить себе жизнь, всегда что-то ваял — по специальности я инженер-автомобилист.

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

Я всегда с трепетом относился к финансовым программам, но тут Остапа понесло. Слил копию БД (благо с безопасностью было всё очень криво), за две недели написал новый фронт-энд — на русском, естественно. Функции нужные сделал так, как мне удобно. Неделю назад запустил — всё работает.

Местный админ и так был в шоке от того, что я не дёргаю его по вопросам CMS, но когда увидел, в чём я работаю...

Работаю переводчиком с китайского языка в консалтинговой компании, хотя в неразумном отрочестве увлекался HTML, PHP и MySQL. В числе моих обязанностей — перевод названий компаний с китайского языка, которые добавляются в базу через специальную форму сотрудниками этих самых компаний. Всё было более-менее терпимо, пока какой-то умник не добавил порядка 50 записей одной и той же компании. Естественно, набивать перевод каждый раз, тем более что это бессмысленно, мне не хотелось, поэтому я обратился к программисту с просьбой что-нибудь с этим сделать.

— Извини, — говорит он, — но функции группового удаления нету, так что придётся потерпеть.
— А давай сделаем запрос в базу. У этой компании название уникальное; я тебе дам пару иероглифов, и ты удалишь все записи, где они встречаются.

Сказано — сделано. Когда я пересылал программисту нужные иероглифы, почувствовал себя, будто обращаюсь к колдуну или знахарю, дабы навести порчу. В качестве отвара — консоль MySQL, в качестве волос жертвы — парочка иероглифов, в качестве жертвы — невинные записи.

Есть у меня несколько серверов, в задачу которых входит сбор и обработка статистики от нескольких сервисов. Вся статистика хранится в базах MySQL. И вот однажды сервер, на котором крутилась база, начал тормозить. Это было вполне предсказуемо: объём поступающих данных постоянно рос, и требовалось всё большее время на его обработку. Так как оптимизация работы базы уже не помогала, а оптимизация скриптов уже была проведена до этого, было принято решение о переносе базы на более мощный сервер. Сказано — сделано. Железо настроено, установлена CentOS 5, MySQL, подобраны оптимальные настройки базы и написан скрипт для автоматического переноса данных.

В пятницу утром запускаю тестовый прогон, который должен был воссоздать структуру таблиц. Результат успешен. Запускаю основной скрипт и наблюдаю, как начинают передаваться данные. К шести вечера скрипт всё ещё работает, хотя должен был закончить часам к трём, и рапортует о том, что успешно передаёт в среднем по 70 записей в секунду, Стоп! Как так? До этого шло по три-четыре тысячи в секунду, а сейчас 70? Начинаю проверять всё, что пришло в голову: интернет-канал в норме, нагрузка на обоих серверах в норме, зависших запросов в базе тоже нет, генерацию отчётов отключил...

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

Невнимательность — враг системного администратора. В следующий раз я напишу план работ и буду расставлять в нём галочки, чтобы не пропустить что-либо ненароком, чего и вам советую!

Несколько лет назад, по молодости и глупости возомнив себя крутым хакером, решил я получить доступ к админской панели сайта одного товарища. Способ добраться до своей цели нашёлся очень быстро — «угон» дампа базы данных.
Не буду рассказывать о том, какими ухищрениями мне удалось этого добиться, но в скором времени заветный файлик был у меня. Ага! Вот она, таблица users. Находим нужные поля, копируем их значения. Имя пользователя: «admin», пароль... Ах ты засранец! Ну и пароль у тебя!

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

Лишь через некоторое время, всерьёз взявшись за изучение веб-технологий, я узнал волшебные слова «хеш» и «MD5».

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

Недавно ковырял «жёлтый глюк» и с ужасом пришел к выводу, что творение моих рук от этого ушло недалеко. Припомнил и случай, когда мне довелось услышать пятиэтажный мат одного из местных админов.

Руки сами набрали rm -rf ~/web_project/buh_prj.

Есть в нашем маленьком городке одна конторка на девять угрюмых человек. Делаю я в этой конторке не только свою прямую работу, но и по мере возможности обслуживаю электронное барахло, которого за многие годы скопилось приличное количество, в пределах «собери, установи, настрой, денег не проси». У Самого Мощного Компьютера, как несложно догадаться, целых девять пользователей, из которых семь путают правую и левую кнопки мыши, а на любой объект на мониторе кликают дважды, после чего удивляются результатам.

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

Две недели спустя нахожу на столе конвертик с двумя дисками и пояснительной запиской: «Уважаемый Пользователь! Приносим извинения за допущенные технические неполадки, вызванные некорректной записью компакт-дисков с обновлениями ЭБД, и просим провести обновление с повторно полученных дисков». Интересно, если в следующий раз пришлют апдейт на грампластинках, я всё равно заставлю базу обновиться?

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

1. Не существует отношений «один к одному». Все такие отношения вырождаются в «один ко многим». Проявляются после написания полного и подробного ТЗ.

2. Не существует отношений «один ко многим» — все они вырождаются в «многие ко многим». Появляются после слов заказчика: «Может быть только так и никак иначе».

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

4. Не существует направленных графов. Есть просто графы. Появляются после описания всех возможных и невозможных связей.

5. Не существует графов. Есть хаос.

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

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

s2i_loader: Неожиданный конец файла среди информационных полей.

Задумался о жизни.

Позвали меня как-то в одну контору перенести оракловый сервер на новое железо, так как старое начало подавать признаки скорой кончины. Задача знакомая: инсталлирую сервисы, настраиваю основные параметры, заливаю базу через импорт-экспорт. Запускаю для проверки пользовательское приложение, написанное кем-то неизвестным на коленке — ошибка, причём дурацкая: «Параметр не является датой». На старом сервере то же самое приложение запускается без проблем. Настройки сервера в порядке. Сравниваю содержимое таблиц — байт в байт. Серверы одинаковые, но на первом прога работает, а на втором — нет.

Воевал с ошибкой до утра. Под конец уже думал, что умом тронулся, ибо в природе такое просто невозможно... В конце концов, конечно, нашёл. Оказалось, что приложение было написано с ошибкой в тексте запроса, вследствие чего в оператор TO_DATE() мог попасть текст, действительно не являющийся датой. Проблема же эта нивелировалась другой ошибкой, но уже на стороне сервера: на нём с рождения ни разу не собирали статистику. В результате то самое кривое значение не попадало в оператор из-за кривого плана выполнения запроса. Настраивая же новый сервер, я машинально поставил сбор статистики на таймер — для Оракла это правильно. Умный оптимизатор сразу же поменял план запроса, и две ошибки перестали компенсировать друг друга.

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