По материалам статьи Steve Jones на sqlservercentral.com: " What's a DBA? - An Overview"

Я получаю этот вопрос уже больше чем несколько раз. Обычно он исходит от кого-то, кто желает стать DBA или только начинает свой путь на этом поприще, но я думаю, что администраторы также часто задаются вопросом, чем же является DBA и почему он так необходим. Почему не возможно эту работу поручить только системному администратору? Или старшему разработчику? Есть большое количество серьезных причин, по которым и я думаю, что DBA выполняет важную, узкоспециализированную работу в компании.
Я начал писать эту статью в прошлом году, но это быстро превратилось в длинный цикл статей. Сейчас, я хочу нарушать последовательность изложения цикла и сделать краткий обзор того, чем должен заниматься DBA с учётом полученных от читателей замечаний, предложений и т.п. Эта статья о том, как я вижу роль DBA, и основывается на более детальных статьях, относящихся к режимам работы и ролям различных типов DBA, которые я вижу в мире.

Кто такой - DBA?

Существует большое количество различных режимов работы DBA и не существует хорошего описания содержания его работы. Из того, что я видел, есть несколько основных типов DBA:
Administrative DBA - Работа по поддержке сервера и обеспечение его работоспособности. Резервирование, защита, установка заплат и SP, настройка репликаций и т.д. А также всё, что касается фактического программного обеспечения сервера.
Development DBA - работы по формированию запросов, хранимых процедур и т.д., которые обеспечивают бизнес-задачи. Такой DBA - эквивалент программиста. Он, прежде всего, пишет T-SQL запросы.
Architect - Design schemas. Строит таблицы, FKs, PKs и т.д. Работа по построению структур, которые встречают бизнес-задачи общего характера. Разработанный таким DBA дизайн используется разработчиками и всеми DBA для поддержки пользовательских приложений.
Data Warehouse DBA. Это новая роль, отвечающая за объединённые данные из множественных источников, в хранилище данных. Вероятно, придется проектировать хранилище, оптимизировать данные хранилища, стандартизировать данные, обрабатывать данные перед загрузкой. В SQL Server, этот DBA использовал бы в основном DTS.
OLAP DBA. Строит многомерные кубы для поддержки задач принятия решений или OLAP систем. Основной язык в SQL Server - это MDX, а не SQL.
Быть DBA (вообще) утомительное занятие. Вы должны планировать развитие базы на будущее, резервировать место, где ваша схема будет размещаться или расширяться. План роста чреват множеством ошибок и просчётов. Эта работа не похожа на программирование с помощью "C" или Visual Basic, когда ответственность ограничивается уровнем пользовательского приложения. Ваши решения затрагивают все данные и имеют далеко идущие последствия. Так как Вы работаете в ориентируемой на установку среде (set-oriented), Вы можете легко допустить ошибку, которая затронет большое количество элементов системы. В отличие от класса или структуры, где Вы имеете дело с не большими порциями данных (то есть, один пользователь), единственный SQL запрос может затронуть всех пользователей структуры. Скольких из Вас мучили сомнения при написании delete <имя_таблицы> с предложением where?

Кто должен заботится о системе?

В разных компаниях это может выполняться по-разному. Вообще, в малых компаниях, DBA мог бы исполнять все перечисленные выше роли и применять сервисные пакеты, обновления и т.д. В больших фирмах, DBA не успеет делать дополнительно что-нибудь на NT/UNIX, а сможет только обслуживать само приложение (SQL/Oracle/DB2, и т.д.). В моей компании, я обслуживаю всё, что связано с SQL, включая сервисные пакеты для SQL. Сервисные пакеты для NT/2000 и заплаты применяются sysadmin-ом. Он также заменяет/добавляет жесткие диски, память и т.п. Исполняет резервирование на ленты. Я просто гарантирую, что SQL Server будет работать в требуемом режиме и довожу до сисадмина, нуждаюсь ли я в чём-либо.
Трудно решить, хотите ли Вы стать DBA. С одной стороны это может быть скучно, если всё работает хорошо (для меня это теперь вид раздражения). Но когда что-либо ломается, возникает огромное давление и напряжение. Варианты поведения, когда база данных "умерла" и Президент компании заходит в Ваш офис, чтобы спросить о её состоянии, не преподают ни в какой школе.

Подготовка к DBA-DOM

Изучайте реляционную теорию баз данных. Читайте об этом, и о том, что люди думают по этому поводу. IMHO (по моему скромному мнению), нет никакого "правильного" пути, но существует большое количество особенностей в любом отдельно взятом дизайне. Учитесь столько, сколько Вы можете, и затем принимайте решение, которое соответствует вашей ситуации. Я имею большой опыт в организации сети также как и в программировании, и я думаю, что это действительно мне помогает. Я понимаю, как построена операционная система, и я имею представление, что происходит внутри компьютера. Знание того, как данные перемещаются по сети, также поможет спроектировать лучшую систему и избежать многих проблем. В сегодняшнем мире, я думаю, понимание принципов сетевых соединений является очень важным. В MS мире умение программировать систему требуется только если Вы хотите быть системным программистом. В *nix мире, знание того, как разрабатываются системные утилиты полезно, но я не думаю, что это обязательно требуется.

Заключение

Всё, что изложено в этой статье - это моё мнение и мои эмоции, основанные на личном опыте и изучении соответствующих материалов. Я уверен - некоторые люди, не согласятся со мной, но я хочу иметь обратную связь, чтобы вносить изменения в эту статью. Я особенно хотел бы получить замечания и дополнения от non-SQL Server DBAs. Если Вы знаете кого-то, кто является Oracle, DB2 или другого типа DBA, пожалуйста перешлите ему(ей) эту статью, и попросите, чтобы они послали мне своё мнение об этой статье Steve Jones

[В начало]