Raid 5 надо разобрать вам какой-нибудь криво настроенный по таймаутам redo-log manager будет не давать в таблицы своевременно писать. сделайте disable_loggin и увидите что жить стало легче, тока при малейшем сбое бд никогда не встанет.
А первазиву Raid 5 вполне подходит так как процес записи у него 1! единственный.
Так и у меня стоит db_writer_processes=1.
Завтра человек из Галактики посмотрит сервер - может, что еще что предложит... А если ничего не выйдет, можно будет на Raid 1 попробовать перейти.
Nikos писал(а):Так и у меня стоит db_writer_processes=1.
Завтра человек из Галактики посмотрит сервер - может, что еще что предложит... А если ничего не выйдет, можно будет на Raid 1 попробовать перейти.
Журнал у нас за 4-5 месяцев. Особой надобности в таком большом нет, но пока не начинает притормаживать я его не трогаю. Иногда бывает полезно, а разворачивать БД из архива долго на Oracle. Перешли на Oracle по весне, большого опыта работы нет, за это время я только один раз чистил журнал, используя TRUNCATE, после Нового года планирую почистить более корректно. А что такое rebuild для индексов я и не знаю. На Pervasive делал rebuild постоянно, а как перешел на Oracle, так ничего и не делал - все хорошо работает.
под ораклом растет размер индексного табличного пространства достаточно бысто. У меня один раз был рост за 1 неделю на 1 Гб. Если эксплуатации БД позволяет никому не работать в течение 3-4 часов (для вашего размера БД), то размер индексного табличного пространства (реально занятого) уменьшается. Это и делает rebuild
Я в Oracle Enterprise Manager запускаю Database Instance: galtest2.ak.transneft.ru > Advisor Central, далее выбираю Segment Advisor, указываю индексное пространство (например), он отрабатывает, выдает рекомендации, и я их выполняю.