Тормоза с приходками : Супермаг Плюс (Супермаг 2000)

Стою, смотрю на него, а оно не налаживается... Да? Пост мой выше читал? *15

Извиняюсь за пост. Поменял параметры в инишнике в соответствии с рекомендациями оптимайзера (у меня 2 Гига памяти и 30 пользователей)
db_file_multiblock_read_count = 64
sort_area_size = 8192000
optimizer_index_caching = 90
hash_area_size = 16384000
Ну еще db_block_buffers до 60000 увеличил и shared_pool_size с 80 до 140 метров. Сделал дефрагментацию (затронуло только индексы). Все залетало на вполне приличной скорости. Скорость переноса (полного) с расчетом возросла процентов на 20.
МОжет еще кто ответит - раньше при инициализации базы redo.log рекомендовали ставить - 5 метров, а сейчас (в новой доке) 50 метров. Имеет ли смысл создать новые и убить старые?

Имеет :)

bob, посмотри в alert.log как часто у тебя переключаются логи. Я у себя выставлял размер таким, что бы переключение происходило раз в 20-25 минут

Это в среднем как раз 50 Мб и есть.

olegon, у меня 200 и то иногда переключаются за 10 минут

Поэтому ты таких вопросов не задаешь, не так ли? *02

Так я и написал как размер сам определял, т.к. не могу однозначно утвержадть надо ли поднимать до 50Мб, а может надо поднимать намного больше.
А ещё я в ближайшее время, в качестве промежуточного варианта на пути к архивлогу, собираюсь увеличить количество групп до такого значения чтобы в логах хранилась инфа не менее чем за сутки.
Также считаю не лишним заметить что все логи необходимо зеркалировать средствами Oracle как минум на 2 физически отдельных диска, благо в нем это встроено.

Очень хорошее замечание. Будем разбираться

Уф... Проблема решилась пересчетом статистики оптимизатора...
Да, многому ещё надо научится, но с чего то же надо начинать... *16