Какая версия Oracle? (и вообще блин, как-бы народ приучить сразу писать версию Oracle, ОС итд итп). Чему равны параметры log_checkpoint_interval и log_checkpoint_timeout?

Лихо ты выставляешь log_checkpoint_interval = 10000 одинаково, что для 8.0.5, что для 8.1.5.
Принцип применения поменялся в 8.1.5. Если в 8.0.5 это значение означало кол-во блоков ОС после которого выполняется контрольная точка, то в 8.1.5 это означает, кол-во блоков, которое остаётся не заполненным до конца файла редо-лога.

Какой у тебя размер блока ОС?

"5м - это "база для себя, поиграться" ? Нужно пересоздать журналы с бОльшим размером"


to killed: Какой размер для log-file ты считаешь оптимально "бОльшим размером"? Меня интересует конкретное число.

500Mb - это размер файла редо-лога? Что такое DW?
И как насчёт восстанавливаемости? Если БД грохнется, сколько времени уходит на восстановление с таким файлом?

to killed: тогда это понятно. Но ведь человек спрашивал не уточняя что какого типа у него БД. Но скорее всего OLTP. Меня интересует для OLTP каким ты считаешь оптимальным размером?

to AlexAA:
Обращать надо в любом случае. Практика показывает что при таких симптомах и при интенсивных транзакциях - производительность падает.
Мне кажется этот вопрос до сих пор ни в одной конфе до конца не освещён.
Многие говорят что это связано с тем что arch не успевает заархивировать. Однако это происходит и в режиме noarchivelog.

to killed:
А как быть в ситуации, когда база скажем моментально падает, в результате отказа оборудования, например отказа блока питания. Допусти всё есть:бэкап файлов данных, контрол-файл, архивные редо-логи. Но в момент падения был текущий редо-лог размером 200M, который был почти заполнен. А там транзакций скажем за неделю. И как я буду восстанавливать это всё?
Может я чего-то непонимаю.

Лично у меня нет такой нагрузки, что-бы редо-лог за 20-30 минут переключился на другой файл при размере 200Mb. Ты опять же судишь по своей базе. Хотя если у тебя DW, то вообще странно что за такое время такое кол-во транзакций.
Мне кажется говорить что 5Mb мало, не зная какая у человека нагрузка - это не совсем правильно.

Кстати какой размер буффера redo-лога ты выставляешь для базы при 500Mb размере файла?

Что может приводить к переключению файлов?
1) журнал заполнен
2) явно выдана команда пользователем(администратором БД)

Какие еще могут быть причины? Сама контрольная точка может приводить к переключению?

Каким оптимально должен быть размер log-буфера относительно размеров лог-файла?
Допустим такие варианты(размер лог-файла):
1) 2Mb
2) 5Mb
3) 15Mb
4) 150Mb
5) 500Mb

ОЗУ доступное на машине 1G.

Значит если я вас правильно понял размер лог-буфера абсолютно никак на связан с рамером самого лог-файла?

to Noname_:
Первое:
" Вы ищете оптимальные значения с точки зрения размеров (файлов, памяти и т.д.), а надо искать оптимум с точки зрения средней (лучше - среднестатистической) нагрузки на сервер.

Второе:
"Определитесь с частотой чекпоинтов и исходя из этого задавайте размеры буферов (в рамках физических возможностей, естественно)."

Хочется прокомментировать ваше утверждение - мне кажется оно не совсем логичным.

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

Далее. Из статьи "Открыто о СУБД Oracle на русском : Переключение журналов и немного терминологии":


То есть если не правильно подобран размер файла, то переключение(соответственно и контрольная точка) будет происходить еще и при недостатке места в файле. Размер же этого недостатка не зависит от нагрузки на сервер, а зависит видимо от размера транзакции.

При этом видимо размер лог-буфера тоже играет не последнюю роль. Потомучто перед переключением на новый журнал происходит сброс:


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

Если размер буфера слишком маленький, то будет слишком частый сброс, что тоже не очень хорошо.

">>Многие говорят что это связано с тем что arch не успевает заархивировать. Однако это происходит и в режиме noarchivelog.
Мне кажется что arch здесь ни при чем. LGWR ждет завершения checkpoint а не архивации."

to Lazy:

Естественно, что если база не в режиме archivelog, то не причём. Я об этом и говорил. Только в режиме archivelog LGWR ждёт в том числе и ARCH, когда он заархивирует лог-файл, на который происходит переключение.

Давай только не будет углублять тему LGWR и ARCH. Это имеет косвенное отношение к первоначальной теме.

Можно подробнее по 1Mb - откуда эта цифра растёт, источники?