Ноя 152012
 

Про параметр event я писал неоднократно. В этом посте речь пойдёт о том, как установить одновременно несколько событий. Если мы попробуем посмотреть значение этого параметра на базе, где оно множественное, увидим следующее:

SQL> sho parameter event

NAME  TYPE   VALUE
----- ------ ------------------------------
event string 10235 trace name context forev
             er, level 2, 10501 trace name
             context forever, level 1

Однако при попытке добавить ещё одно значение через запятую, получим вот что: Continue reading »

Сен 202012
 

Наткнулся сегодня на интересное явление: после попытки завершения любой сессии путём убивания серверного процесса командой kill -9, PMON не вычищает эту сессию из v$session и не освобождает блокировки. Таким образом, не удаётся убить никакую сессию, даже сессию, не выполняющую никаких транзакций. При этом и "убитые" сессии и сам PMON висят с ожиданием latch free. Версия ORACLE - 9.2.0.8.

Решение найти удалось, но довольно странное. Continue reading »

Мар 242011
 

Некоторые из этих событий я уже описывал и буду продолжать описывать по мере того, как буду находить что-нибудь полезное.
Вот список событий. Надо понимать, что большинство из них совершенно недокументировано и включать их без разрешения Oracle Support нельзя. Continue reading »

Мар 172011
 

Событие 10261 позволяет ограничить потребление PGA сессиями. Его удобно использовать, когда из-за кривого кода часто происходят утечки памяти.

Установим эвент:

-- Не разрешим сессии использовать более 200 Мб (Параметр эвента - килобайты)
ALTER SYSTEM SET event = '10261 trace name context forever, level 204800' SCOPE=SPFILE;
 
-- Обязательно перезапустим базу
SHUTDOWN ABORT;
STARTUP;

Continue reading »

Фев 172011
 

При удалении пользователя могут возникнуть ошибки, вот некоторые из них (9.2.0.8):

Ошибка с Oracle rules


SQL> DROP USER test CASCADE;
DROP USER test CASCADE
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-24170:
ORA-06512: at "SYS.DBMS_RULE_ADM", line 129
ORA-06512: at line 1

Эту ошибку исправляем так: Continue reading »

Янв 202011
 

Столкнулся с ситуацией: на полностью идентичных наборах данных многие запросы, прежде всего DELETE и INSERT на БД версии 11.2.0.1 выполняются в десятки-сотни раз медленнее, чем на 10.2.0.4. Данные получены экспортом с 10-й БД на 11-ю. В трейсах было видно, что большая часть времени в запросе уходила не на ожидания, а на CPU.
Сначала я грешил на баги Оракла, но после длительной возни с трейсами, профилировщиком процессов ОС и их техподдержкой, удалось разобраться, наконец, в чём дело. Continue reading »