Доброго времени суток All
Такие вот дела. Устроился я в контору как Oracle DBA. Причем сервер там уже стоит, клиенты расставлены, к производительности сервера претензий пока нет (база только формируется так что я думаю большая часть находится в буферном кэше), написал скрипты для бакапа, но тьфу тьфу применить еще не пришлось. Так вот проблема в том что в качестве DBA работы-то нет, все работает. Я конечно без дела не сижу запросики, процедурки пописываю, но IMHO это работа не DBA, а разработчика. Хотелось бы узнать мнение уважаемых DBA в чем состоит работа-то с 8-00 до 17-00. А то боюсь у начальства закрадутся нехорошие мысли, а нахрена он нам нужен, торчит на sql.ru. Варианты типа остановить сервер и героически его поднять не предлагать. Или это временно, то есть когда база будет больше проблем добавится.

>Интересно, а кем вы работали до этого?
Был разработчиком PL/SQL процедур и интерфейса на С++Builder. А тут есть готовое приложение (Парус) и его надо рулить.
Так что это мой дебют в качестве админа.

>написание ПО для мониторинга вашей базы
можно поподробнее плиз. То есть результаты utlbstat/utlestat в графическом виде что-ли? Или что? Буду рад любой идее.

>мне кажется это не плохой повод обсудить здесь специфику работы DBA и
> свои служебные обязанности

Всецело поддерживаю. Мне (и другим) будет очень интересно/полезно.

2 Fenka
Я делаю бакап ночью переводя базу потаблеспейсно в begin backup плюс в обед полный экспорт, база маленькая экспортируется шустро. Хотя импорт занимает много времени, и я боюсь что бухам будет быстрее набить инф. за полдня чем ждать импорта. Скрипты на использование RMAN я написал, но не применил в живой базе. Может просто на воду дую, но знакомые админы не используют, а бакап такая область где нужна 100% надежность. Хотя если Oracle сообщество порекомендует... :-)

>3. А также есть огромное поле для деятельности по оптимизации запросов и >процедур Паруса
Вот то то и оно, что это работа не DBA, а разработчика. В результате я не трогаю сервер, его параметры (типа работает себе и пусть) до жалоб пользователей.

Я понял, что надо написать несколько скриптов типа utlbstat которые бы замеряли "температуру" базы и фильтр на отклонение от нормы.
Простите за наивность, но могли бы вы привести примеры "пожаров". Начну сам
1. Отказ железа - память, диск, питание, мама
2. Фрагментация, разбалансировка индексов, рост таблиц и т.п. следствие нормальной работы приложения. Результат замедление работы и реорганизация базы когда нибудь когда пользователей нет
3. "Страшная" ошибка пользователей, типа в Парусе отметить группу записей, нажать "удалить", подтвердить удаление, а потом пожалеть об этом.
.....

TO Vladimirgs
Объясните пожалуйста зачем используется инкрементный импорт. Как показывает опыт самые большие таблицы (журналы изменений) как раз самые изменяемые, то есть при вставке/изменении записи вся таблица снова экспортируется и импортируется. Или в Парусе не так?
Как влияет инкрементный экспорт/импорт на перекомпиляцию схемы. В парусе перекомпиляция схемы занимает больше времени чем импорт данных (у меня).
В этом отношении RMAN гораздо умнее.
Тут просьба к .dba и остальным:
Успокойте нас с Fenka, заверьте что этот зверь надежно работает.