CftClub.ru

[dbmaslov]

Коллеги,
в Навигаторе при учете процентов по депозитам, видим сообщение:
ORA-03113: end-of-file on communication channel

а затем (после ОК):
ORA-03114: not connected to ORACLE

на сервере видим сообщение:
ORA-07445: ЮСЭРагЦХЭЮ ЯаХалТРЭШХ: core dump [pfrxca()+207] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []

что это может быть?

[dnk_dz]

Error: ORA-07445 exception encountered: core dump
Cause : An operating system exception occurred which should result in the creation of a core file. This is an internal error.
Action : Contact Oracle Customer Support.

Common precipitators of the ORA-07445 include:

High volume user transactions
Software bugs (i.e. Bug 4098853)
Too-small RAM regions (shared_pool_size, java pool, large_pool_size), and a too-small application memory stack (e.g. PL/SQL array too small)
Too small undo and temp segments
Program errors (addressing outside of RAM region), e.g. S0C4.
Improper NLS parameter settings
Hardware errors
Oracle block corruption

and a host of other related issues.

Oracle DBA's use alert mechanisms to send an e-mail to the DBA when ORA-07445 errors occur, e-mailing the associated core dump file. Metalink now offers an ORA-7445 search tool, as described in MetaLink note Note:208922.1, and you can supply details from the Oracle trace file to see the exact cause.

Other common causes of the ORA-07445 include:

High-volume, high RAM usage can cause ORA-07445
The shared pool is too small to hold the fixed structures
Improper SCSI disk configuration

In sum, the ORA-07445 has a multitude of causes and contact with Oracle technical support is always required.

Смотрите из вышеперечисленного.

[dbmaslov]

Симптомы: в alert.log пишется ошибка
ORA-07445: exception encountered: core dump [pfrxca()+207] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []

На сайте metalink.oracle.com есть варианты багов, но для нашей версии нет решения.

Обходное решение: рестарт базы или выполнение alter system flush shared_pool;

От ЦФТ ничего вразумительного получить не удалось:

[Serj]

Управление памятью автоматическое? - неплохо бы платформу сервера посмотреть - что за ОС? - если управление памяти в автомате, то Оракл любит shared_pool раздувать до соотношения 65% от sga, можно по-пробовать выделить ему мегов 700 под разделяемый пул и уйти на ручное распределение памяти. Также неплохо посмотреть название пакетов что PL/SQL стэке ошибок и поиграться с dbms_shared_pool.unkeep - чтобы выкидывать из пула объекты а не весь пул чистить.

[Serj]

На металинке есть такой - Bug 7021754 Dump [pfrxca] during concurrent DML or DDL, последний CPU - ставили?

[Kozyrev]

[tsktalk]

автоматическое управление памятью - штука конечно хорошая, особенно для тестовых баз - а вот для боевых не все так гладко как хотелось бы (тем более для ибсо).
постоянные ошибки валятся из динамически рапределяемых ресурсов.
и 600 ошибки и 7445 и наведенные бывают и т.д.
накат патчика или CPU (PSU) - не всегда спасает от этого, а вот бывает что другое калечит.


посмотрите в период наибольшой загрузки бд какие размеры у вас сегментов - потом во время перезагрузки выставьте управление ручками и подавляющее большинство ошибок как рукой снимет.

[Serj]

[Serj]

[Serj]

[tsktalk]

[tsktalk]

[tsktalk]

[Serj]

[Serj]