Янв 282013
 

Утилита DataPump работает немного не так, как старинные exp/imp. В отличие от них, она не просто открывает сессию, по которой выкачивает/заливает данные, но создаёт несколько серверных процессов (они называются DataPump jobs, но путать их с заданиями, запускаемыми с помошью пакета dbms_job не стоит, тут другой механизм). Кстати, именно поэтому если убить процесс expdp/impdp командой kill -9, то сессии DataPump всё равно останутся в базе и могут помешать повторному запуску утилиты.
Иногда бывает необходимо убедиться, что сессии не подвисли и процесс перекачки данных идёт нормально. Раньше можно было просто поискать в v$session записи с полем program, содержащим строку 'imp%' или 'exp%' соответственно, но теперь всё немного хитрее. Для мониторинга сессий DataPump есть представление dba_datapump_sessions.

Вот так можно определить, на каком событии висят сессии DataPump и кто их блокирует: Continue reading »

Дек 292012
 

Начиная с версии 10g, в представлении v$session появилось поле blocking_session, которое содержит SID сессии, блокирующей исходную. В 11.2.0.3 всё стало ещё удобнее, ибо появилось поле final_blocking_session, в котором указан SID сессии, являющейся "корнем" дерева блокировок. Убиваем её и либо всё дерево блокировок разрешается, либо "корнем" становится другая сессия. Как говорится, в таком случае надо смыть, повторить.

Если поля final_blocking_session в v$session нет, то нам поможет иерархический запрос. Continue reading »

Июн 062011
 

Я уже писал, как выявить блокирующие сессии и сгенерировать команды на их завершение. Проблема в том, что команда KILL SESSION не всегда быстро отрабатывает. Гораздо быстрее (особенно, если сессий нужно завершить много) будет убивать серверный процесс, соответствующий этой сессии, средствами ОС, после чего фоновый процесс PMON удалит из памяти экземпляра БД данные об убитой сессии, снимет все блокировки и откатит транзакции.

Итак, запрос: Continue reading »

Фев 242011
 

Вот пример триггера, в котором устанавливается ограничение на количество сессий, открытых одновременно и удовлетворяющих определённому условию (в дополнение к этому посту): Continue reading »

Фев 142011
 

Чтобы узнать, какие транзакции наиболее активно потребляют место в Undo tablespaces с привязкой к сессиям, поможет такой запрос (для версий 10g и выше):

SELECT DISTINCT s.sid, s.serial#, s.schemaname, s.osuser, s.program, t.start_time,  
       t.used_ublk, r.name rollback_segment_name, 
       st.sql_text, st_prev.sql_text prev_sql_text, s.event
FROM v$session s, v$transaction t, v$rollname r, v$sql st, v$sql st_prev
WHERE 
	t.addr = s.taddr AND
	t.USED_UBLK > 0 AND 
	t.xidusn = r.usn AND
	st.SQL_ID(+) = s.SQL_ID AND
	st_prev.SQL_ID(+) = s.SQL_ID
ORDER BY t.USED_UBLK DESC;

Continue reading »

Янв 282011
 

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

Дек 302010
 

Получить Top10 сессий, потребляющих PGA можно так:

SELECT * 
FROM
  (SELECT s.sid, s.serial#, s.module, s.program, ROUND(p.pga_alloc_mem/1048576) mb
   FROM v$session s, v$process p 
    WHERE p.addr = s.paddr 
   ORDER BY 5 DESC
  )
WHERE ROWNUM < = 10;

Continue reading »

Дек 302010
 

Иногда бывает необходимо определить, что за сессия занимает много CPU или памяти (Например, по выводу prstat).

Это можно сделать запросом (в скобках - список проблемных ID процессов через запятую):
Continue reading »