Тема требует продолжения. Меня всегда интересовало, как относятся DBA-профессионалы к использованию Enterprise Manager.
Я сам никогда не администрировал базы профессионально (под понятием профессионально я понимаю такой род деятельности, которым человек зарабатывает по крайней мере половину своих денег; в соответствии с этим определением мы, например, с Димой Волковым не являемся фотографами-профессионалами или водителями-профессионалами). Около семи-восьми лет назад я работал в компании Borlas техническим архитектором проекта внедрения OeBS. Проект только начал разворачиваться и со стороны заказчика еще не было DBA. Мне приходилось делать некоторые базовые операции, характерные для DBA. Для начала я написал select, который объединял 3-4 V$-вьюхи, чтобы посмотреть какие сейчас в базе блокировки. Потом я написал супер-крутой скрипт, чтобы убивать подвисшие сессии, по каким-то там двум id-шникам. Еще через некоторое время у меня возник уже набор различных стриптов. Я хранил их разложенными по папочкам, писал для каждого комментарии, чтобы не забыть, и каждый раз, когда встречалась какая-то уже изученная раньше ситуация, я лез в папочку со скриптами. Через пару месяцев я даже произвел на кого-то впечатление, быстро запустив скрипт из папки номер 16, который срубил пару повисших сессий. Я уже посчитал, что стал страшно крут, и уже хотел было записать в свое резюме отдельной строчкой что я DBA, пока жизнь не познакомила меня с настоящим DBA.
Через три месяца после старта проекта компания Shreya, где мы внедряли OeBS, смогла-таки позволить себе нанять профессионального DBA, который блестяще прошел мое супер-пупер-навороченное техническое интервью, в котором самыми каверзными были вопросы о максимальной длинне строки, которую без ошибки переваривает dbms_output.put_line в Oracle9i (ограничение, на которое я случайно сам налетел неделю назад) и задачка на составление select с конструкцией having. В то время только что лопнул "пузырь .com" и парень возвратился назад из США, потеряв там работу промышленного DBA. В общем, работу он получил и был включен в мою команду со стороны заказчика.
И тут я понял, насколько велика пропасть между мной и этим парнем. Какие тут скрипты? О чем Вы говорите? Этот человек мог хладнокровно разобраться, что именно надо делать, если база OeBS словила corruption. Тут скрипт и написать-то нельзя. Я тогда даже не представлял, что такое corruption и почему он может произойти. Его опыт был настолько велик, что миллион проблем, с которыми я боролся при помощи тряпки, палки и каких-то там скриптов исчезли сами собой. Это был человек другого уровня. Если бы я посвятил всю жизнь осваиванию технических аспектов работы СУБД Oracle, то после запуска нашего проекта в production, я мог бы претендовать максимум на ночные дежурства под присмотром этого парня на уровне если случилось это -- нажми на эту кнопку, а если вот это -- ничего не трогай и спрочно вызывай меня. Про строчку DBA в резюме пришлось забыть.
Да, к чему я это все рассказываю? Потому, что во время этого проекта я понял, что профессия DBA -- это очень широкий пласт опыта, плюс работа головой с тонкими вещами. Я понял, что такие "DBA" как я, не нужны рынку труда. Почему? Ответ: потому, что меня с моими скриптами можно заменить куском продвинутого программного обеспечения, а того, настоящего DBA, нельзя, потому, что есть множество операций, которые принципиально нельзя автоматизировать. Пример -- что делать с corruption? (уверен, что Дима Волков сможет продолжить этот список). В 2003 году выход Oracle 10g с его встроенной концепцией само-настраиваемости окончательно утвердил мой вывод: С Oracle 10g такие как я не нужны рынку -- вся статистика собирается специальным джобом, все работает в режиме auto, и т.п. Для того, чтобы продать себя и представлять ценность для работодателя, нужно быть по крайней мере умнее этого самого режима auto.
Теперь при чем тут Enterprise Manager с его паками? Потому, что этот продукт помогает профессиональному DBA сосредоточиться на той части своей карьеры, которая позволит повысить свою капитализацию на рынке труда (как Вы уже поняли, я обожаю писать про карьеру и меня все время сносит в эту сторону :^). Почему? Потому, что Enterprise Manager поможет DBA сосредоточиться на выработке опыта, который принципиально не может быть автоматизирован. DBA может и должен (!) делать множество технически сложных, но при этом рутинных операций в Enterprise Manager, который по сути представляет высокопараметризированную библиотеку все тех же скриптов. И наоборот, чем DBA будет меньше работать с Enterprise Manager, чем больше он будет придумывать свои скритпы, тем больше и больше он будет похож на меня :^)
Вы DBA-профессионал. Забудьте на минуту о лицензиях Oracle.
Вы используете Enterprise Manager?
(Дим, мы можем сделать на этом блоге опрос?)
P.S. А что же тот DBA? Он опять уехал в Северную Америку, но на этот раз в Канаду. Похоже, что навсегда. ...я иногда вспоминаю о нем...
Читать дальше...
На конференции разработчиков высоконагруженных систем HighLoad++ 2009, которая пройдет 12-13 октября, будут участвовать Геннадий Сигалаев и Игорь Мельников. Тема доклада: Механизмы отказоустойчивости в кластерах RAC. Вы познакомитесь с методами защиты приложений от сбоя в среде Oracle Real Application Clusters. Материал ориентирован в основном на разработчиков, но также будет полезен и для DBA. Будут рассмотрены технологии TAF и FAN. Как всегда никакого маркетинга и рекламы: только конкретная информация для разработчиков и впридачу - живое демо на 4 узловом кластере. Будет показана специально разработанная для демонстрации утилита RAC DD4D*Plus! :-)
Сообщения
