Что нужно знать/уметь чтобы быть администратором базы данных? Где/как этому можно научиться?

Перво-наперво нужно научиться выпытывать у работодателя - что понимается под этим определением?

Желающим покидаться помидорами:
1) Какая СУБД?
2) Какая серверная ОС?
3) Какие особенности эксплуатации системы?
Для начала думаю хватит.

Зарплата Oracle DBA покоя не дает?

Для начала можно взять книжку MS Access для чайников и попытаться прочитать ее всю.

Издеваетесь над новичком?
Какое отношение имеет Access к Oracle?

Это самый доступный способ изучения SQL и его обвязки.

Как минимум прочитать книгу "Понимание SQL" Мартина Грабера

Программист должен программировать, администратор - администрировать.
Это по поводу прочитать SQL и обвязку.

Про другие базы не скажу, скажу про Oracle
1. Желательно обучиться курсами администрирования
2. Быть стажером, помощником нормального админа. На предприятие где есть нормальные промышленные базы данных.
И время.

Что нужно знать, что бы быть администратором базы данных?

Базы данные бывают разные. Самые распространенные - реляционные, поддерживающие SQL. К ним относятся такие, как Oracle, MySQL. Они являются классикой жанра и неплохо их изучить в объеме сертифицированного администратора, это дает довольно широкое представление, о том, что они могут и как с ними обращаться.

Но то, что эти базы популярны, не значит, что только ими и следует заниматься. В мире сейчас появляется много других видов баз данных. Есть NoSQL, есть нереляционные, базы, выполненные в виде библиотек, а не процессов. Есть категория in-memory баз данных, есть технологии обработки больших объемов типа Teradata (которая близка к тому же Oracle) или Hadoop (который очень далек). Как часто бывает, выбирая популярный продукт, вам легче его изучить и существует больший рынок работ, но, с другой стороны, существует и больше кандидатов. Поэтому, обычно, небольшой процент самых лучших специалистов получает высокую зарплату, а большинство середнячков и начинающих довольствуются намного меньшим.

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

Если ваша цель - сделать международную карьеру, то я бы шел в узкие специалисты. Скажем, в США администраторов Oracle много и привозить из за рубежа мало кто решится, а вот специалистов по новым технологиям привозят охотно. Да и удаленно берут на работу.

Ну а если цель просто быстро найти работу и рядом с домом, я бы учил MySQL и Oracle. Больше всего DBA занимаются этими базами. Они очень близки (скажем так, намного ближе, чем, скажем, Mongo, Hadoop и т.п.) и переучится с одной на другую не так сложно.

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

После того, как вы освоили программу-минимум, хорошо бы поучится у знающего администратора. Но ключевое слово здесь - "знающего". Если учится у плохого администратора, то может быть больше вреда, чем пользы. Тогда лучше читать. Раньше существовал набор книг, из тех, по которым учили в ВУЗах. Проблема в том, что мир баз данных сейчас очень быстро развивается и "классические" учебники могут быть морально устаревшими (так, реляционные базы держаться на таких понятиях, как "нормальные" формы, атомарность транзакций, сериализация состояния базы, использование SQL запросов и т.п.) - сейчас большой прогресс происходит там, где люди отказываются от этих жестких конструкций и жертвуя некоторыми из принципов решают большее специализированные задачи намного эффективнее. Поэтому учить классику полезно, но нужно и следить за текущим состоянием, а это нужно брать не из книг, а из блогов, материалов конференций, презентаций вендоров и т.п.

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

Вот некоторые ключевые слова:

Базы данных общего назначения: Oracle, MySQL.
Системы обработки больших объемов данных: "классические" Warehouse: Teradata, Exadata. Это тоже реляционные базы, которые оптимизированны для больших данных и специального железа. А вот Hadoop - очень попурярная и быстро развивающаяся технология из разряда Big Data, которая построена на совсем других приципах - на нее в мире сейчас большой спрос.
Объектно-ориентированные базы, например Mongo. Там другие принципы оптимизации, рынок есть, но рост не такой быстрый.
NoSQL, inMemory DB - начиная от BerkeleyDB и кончая многими proprietary базами, которые не представлены на открытом рынке. Там тоже сильно отличаются принципы оптимизации и обеспечения надежности и производительности. Рынок есть, но он очень сегментирован.

Что от администратора ожидают? Большинство запросов обычно о производительности и оптимизации. Еще - добавить больше объем - это святое, базы обычно всегда растут. У резервном копировании обычно не спрашивают до тех пор, пока база не полетит, поэтому хороший админ его сам первым делом организует. Обновление кода - это тоже то, что делает админ. Реже админы занимаются представлением данных. Как правило, данные организуются в соответствии с логикой приложения, но иногда программисты не понимают особенности реализации и админам приходится просить разработчиков изменить модель данных. Другая типично админовская задача - это защита данных.

1) Какая СУБД?
2) Какая серверная ОС?
3) Какие особенности эксплуатации системы?

1. Предположительно MS SQL
2. Предположительно Win
3. А вот здесь поподробнее. Какие особенности бывают? На что обращать внимание? Какие вопросы надо прояснить в первую очередь?

1. Предположительно MS SQL

И что вы там администрировать собрались? Эта СУБД характеризуется тем что "администрирует" себя сама. Можете поставить себе ее на компьютер и самостоятельно изучить весь ее "админский" функционал за пару часов.
Повлиять на ее функционирование можно, например, изменив структуру базы и поведение клиентов. Но этим занимаются разработчики прикладных решений...

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

А, ну тогда все замечательно.
По M$ $QL и винде при любом затруднении тупо Яндекс или Гугл кучу инфы выдаст.

По п.3 - а вот тут даже не подскажу. Может быть все, что угодно.
Распределенные базы, график работы круглосуточный, а не с 9 до 18, особенности корпоративной политики безопасности... Все, что угодно. Нужно в момент, когда обо всей этой белиберде начнут рассказывать, не отвесить челюсть и найти в себе силы сказать - "А, ну да, бывало. Занимался я этим как-то, ничего страшного." А потом быстренько наверстать пробелы в знаниях.