Узнайте, какой процесс/запрос использует табличную область временного файла оракула
Я решил свою собственную проблему, поэтому выкладываю ее здесь!
Фактически индексы кластера B были созданы путем восстановления моментального снимка индексов кластера A (поэтому я добавляю точно такие же данные в каждый кластер) , Я думаю, именно поэтому индексы были сегментированы.
Чтобы решить проблему медлительности, я должен был выполнить принудительное объединение для каждого индекса:
POST /index_*/_forcemerge?max_num_segments=1
2 ответа
Я не уверен точно, какую информацию уже необходимо вручить, но использование следующего запроса укажет, какая программа/пользователь/сессии и т.д. в настоящее время используют временное пространство.
SELECT b.TABLESPACE
, b.segfile#
, b.segblk#
, ROUND ( ( ( b.blocks * p.VALUE ) / 1024 / 1024 ), 2 ) size_mb
, a.SID
, a.serial#
, a.username
, a.osuser
, a.program
, a.status
FROM v$session a
, v$sort_usage b
, v$process c
, v$parameter p
WHERE p.NAME = 'db_block_size'
AND a.saddr = b.session_addr
AND a.paddr = c.addr
ORDER BY b.TABLESPACE
, b.segfile#
, b.segblk#
, b.blocks;
После того как Вы узнаете, какая сессия наносит ущерб, затем взгляните на SQL, выполняемый, и необходимо быть на правильном пути.
Одно эмпирическое правило - то, что почти любой запрос, который берет больше, чем секунда, вероятно, использует некоторое ВРЕМЕННОЕ пространство, и это не справедливые, включающие ПОРЯДОК BYs, но также и:
- ГРУППА BYs (ВИД GROUPBY прежде 10.2 и ХЕШ GROUPBY от 10,2 вперед)
- ХЭШИРОВАНИЯ или СЛИЯНИЯ
- Глобальные временные таблицы (очевидно),
- Индекс восстанавливает
Иногда, использованное пространство во временных табличных областях не становится выпущенным Oracle (ошибка/причуда), таким образом, необходимо вручную отбросить файл от табличной области, отбросить ее от файловой системы и создать другой.