Кто поможет с Oracle ?
 

Народ помогите!!!
Сейчас нахожусь в отпуске, через два дня выходить. На работе стоит сервак под Win 2000 Server, на нём пашет Oracle 9.2. Последнюю неделю происходит глюк - день работает нормально, утром работяги приходят Oracle висит. Перезагружают - работает. Опыта у меня пока немного, уверен разберусь но надо много времени, а его нет. Не будешь же постоянно перезагружать. Настройки сервака пробовал разные (память увеличивал и т.п.), не помогает. Выяснить причину затрудняюсь. Есть файл alert, где все сообщения об ошибках записываются, там должна быть причина описана. Файл прикрепляю. Там последние записи за эти дни смотрите. Пожалуйста, кто что-нибудь смыслит в этом деле - посмотрите, может поможете разобраться. Заранее благодарен.

Тема закрыта, с проблемой разобрался, почитал Том Кайт "Оракл для профессионалов"

tiroman
хоть бы написал как решил проблему...

Этот глюк был вызван ожиданиями доступа к файлам журнала повторного выполнения (REDO).
Вот как описывает причины этого Tom Kyte:

1) Файлы журнала повторного выполнения размещены на низкоскоростном устрой-
стве. Диск просто имеет низкую производительность. Пришло время покупать бо-
лее высокоскоростные диски.
2) Размещение журнала повторного выполнения на том же устройстве, что и другие
файлы. Журнал повторного выполнения создавался для выполнения больших пос-
ледовательных записей и размещения на отдельных устройствах. Если другие ком-
поненты системы, даже компоненты сервера Oracle, пытаются читать и записы-
вать данные на это устройство одновременно с процессом LGWR, определенный
уровень конфликтов неизбежен. Необходимо обеспечить исключительный доступ
процесса LGWR к соответствующим устройствам.
3) Использование устройств с буферизацией. Речь идет об использовании файлов в
файловой системе (вместо неформатированных дисков). Операционная система
буферизует данные, СУБД тоже буферизует данные (речь идет о буфере журнала
повторного выполнения). Двойная буферизация замедляет работу. По возможно-
сти используйте неформатированные устройства. Способ такого использования за-
висит от операционной системы и устройства, но обычно это возможно.
4) Размещение журнала повторного устройства на низкоскоростных дисковых мас-
сивах, например RAID-5. Массивы RAID-5 прекрасно подходят для чтения, но
резко снижают производительность записи. Как было показано ранее, при фик-
сации транзакции необходимо дождаться, пока процесс LGWR сбросит данные
на диск. Использование любых технологий, замедляющих процесс записи, пло-
хая идея.

Для решения этой проблемы можно сделать следующее:

1) Ускорить работу процесса DBWR. Пусть администратор базы данных настроит
процесс DBWR: включит поддержку асинхронного ввода/вывода, используя под-
чиненные процессы ввода/вывода DBWR или запустив несколько процессов
DBWR. Посмотрите на статистическую информацию о вводе/выводе в системе —
может обнаружиться "горячий" диск или ряд дисков, ввод/вывод на которые надо
распределить. Такой же общий совет относится и к процессу ARCH. Преимуще-
ство этого решения в том, что оно "бесплатное" — повышение производительно-
сти достигается без изменения логики/структур/кода. Недостатков у него по сути
нет.
2) Добавить файлы в журнал повторного выполнения. Это отсрочит возникновение
сообщений Checkpoint not complete, причем, после добавления определенного ко-
личества — настолько, что они вообще не будут выдаваться (у процесса DBWR
появляется пространство для обработки контрольной точки). Это же относится и
к сообщению Archival required. Преимущество этого подхода — устранение "пауз"
в работе системы. Недостаток — требуется больше дискового пространства, но пре-
имущество в данном случае намного перевешивает недостаток.
3) Пересоздать файлы журнала, сделав их больше. Это отсрочит заполнение актив-
ного файла журнала повторного выполнения и увеличит период времени, после
которого он снова понадобится. Это решает и проблему с выдачей сообщений
Archival required, если файлы журнала повторного выполнения используются в
"пульсирующем" режиме. Если за периодами интенсивного генерирования дан-
ных повторного выполнения (еженощные загрузки данных, пакетная обработка)
следуют периоды относительного затишья, увеличив активные журналы повтор-
ного выполнения, можно дать процессу ARCH дополнительное время для рабо-
ты в периоды затишья. Преимущества и недостатки этого подхода те же, что и в
случае добавления файлов. Кроме того, может быть отсрочена обработка конт-
рольной точки, поскольку она выполняется при переходе с одного логического
журнала на другой, а переключения будут происходить реже.
4) Вызвать более частую и постоянную обработку контрольной точки. Для этого можно
уменьшить буферный кэш (что вообще-то нежелательно) или изменить значения не-
которых параметров инициализации, в частности FAST_START_IO_TARGET,
DB_BLOCK_MAX_DIRTY_TARGET, LOG_CHECKPOINT_INTERVAL и
LOG_CHECKPOINT_TIMEOUT. Это приведет к более частому сбросу грязных
блоков на диск процессом DBWR. К преимуществам этого подхода можно отне-
сти уменьшение времени восстановления в случае сбоя. Будет оставаться меньше
изменений в активных журналах повторного выполнения для сброса на диск. Не-
достаток же в том, что блоки будут записываться на диск чаще. Буферный кэш
будет работать с меньшей эффективностью, да и весь описанный далее механизм
очистки блоков может при этом пострадать.

Я пересоздал файлы увеличив их размер с 50мб до 100мб, сделал 2 группы по 3 файла,
расположил их на разных носителях. Плюс ещё увеличил время между созданием контрольных
точек с 30 минут (по умолчанию) до 2 часов. В общем это были действительно недостатки
стартовой конфигурации Oracle, устанавливаемой по умолчанию.

Это давольно распрастранённая ошибка, ну она не приводит к падению ORACLE она лишь на некоторое время создаёт эффект зависания входящих запросов пока конкурирующие процессы неразрулят ситуацию.

sergey1234567
Мы конечно, ценим Ваш ответ, но он, боюсь уже не понадобится автору темы. :) (смотрим даты постов выше)