Enq: SS- Contention

На эту тему есть хорошее описание от Riyaj Shamsudeen( https://orainternals.wordpress.com/2012/02/13/temporary-tablespaces-in-rac/). Откуда берётся это ожидание и почему так. Также есть ещё статья https://ebs12blog.wordpress.com/2017/09/24/enq-ss-contention-and-enq-ts-contention-waits-in-a-rac-database-in-ebs-environment , есть и другие статьи.

И есть нота на MOS: EVENT: DROP_SEGMENTS — Forcing cleanup of TEMPORARY segments (Doc ID 47400.1). Но всё выше описанное может ‘показаться’ не рабочим или ресурсоёмким.

Я пройдусь по возможным вариантам(а может есть ещё варианты ?), как избежать enq: ss- contention:

1. Выполнить ‘какой либо’ resize.

Это может быть, как добавление темп файлов, так и выполнение shrink табличного пространства или coalesce.

Данный метод неэффективен (сколько можно добавлять файлов?) и ресурсоёмким, шринк/coalesce темпа создаёт нагрузку на ввод-вывод (регулярно это делать- сомнительное дело).

2. Выполнить рекомендацию из ноты 47400.1

Если выполнить так как описано, то с виду будет выглядеть так, как будто решение alter session set events ‘immediate trace name DROP_SEGMENTS level TS#+1 не работает, эффект будет не заметен.

Первый вариант выглядит нерациональным, но если выбора нет, то и он сойдёт)))

А вот второй вариант выглядит более интересным, и он описан в блоге ebs12blog.wordpress.com(ссылка выше).

И тут главное не упустить две важные детали:

1. Выполнять alter session set events ‘immediate trace name DROP_SEGMENTS level TS#+1 нужно в цикле, т.к. за одно выполнение освобождается определённое количество (или % ?) экстентов.

2. Выполнять нужно на каждом экземпляре бд (для освобождения не занятых экстентов, и дальнейшего равномерного использования по всем экземплярам) или на том экземпляре, где больше всего свободных экстентов.

После выполнения скрипта на каждом инстансе бд, выглядит это так (gv$sort_segment):