Black SQL down - не эпическое завершение. История третья
Вот и настало время для, пока что, заключительного рассказа о моих кривых руках и взаимоотношениях с SQLкой. Последняя история будет короткой и в целом даже не кирпичной, потому что стена выстроенная в прошлый раз оказалось достаточно прочной для такой проблемы.
Был обычный день, сижу, копаюсь в интернете, раздается звонок. Привычный ко всему, кроме чесночной клизмы, я поднимаю трубку и произношу дежурную фразу. И вот снова мне БАЦ - ошибка СУБД в 1Ске. Да что с ней такое то? Не программа, а капризный ребенок какой-то. Зная о том, что в базах никто ничего не менял, и сейчас никаких срочных или не запланированных работ не проводилось я спокойно запускаю сеанс удаленного подключения к серверу.
Интересный факт - подключение к SQLке проходит без малейшей проблемы. Все базы на месте, всё ок и нормально. Откуда же ошибка? Залезаю в "события системы" и тут передо мной открывается полномасштабное наступление красной армии. Ошибки уже несколько часов "заполоняют всю планету". А виноват во всем оказался File System Auditor (программа для сбора информации о действиях пользователей с файлами. Частенько возникает проблема перемещения файлов одними сотрудниками и невозможность\неумение найти эти файлы другими сотрудниками), который до отказа забил одну из баз и требовал новую.
Нехитрые манипуляции с базами и проблема решена - аудитор приступил к заполнению новой базы, а 1Ска заработала как надо. На сей раз никакой паники, никакого судорожного поиска решений, всё логично и последовательно.
Мораль истории такова: всегда заглядывайте в журнал, не ленитесь просматривать логи, ковыряйте ошибки.
Результат: отливка стальных шаров (последняя часть), навыки работы с SQLкой (всё еще на нубском уровне), широкое производство разнопрофильных кирпичей.