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

[tiroman]

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

[tiroman]

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

[Vlad Drakula]

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

[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, устанавливаемой по умолчанию.

[sergey1234567]

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

[xoomer]

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