Господа, есть дельные мысли об этом печальном ожидании?

Причем в AWR его почти нет,а в ASH он занимает почти 100% ожиданий.
Появляется второй день примерно в одно и тоже время (поздно вечером), быстро копит весящие сессии ждущие ЦПУ с этим ожиданием.
На первом этапе почти все работает в инстансе БД живо.
Но с самого начала отваливаются консоли и ЕМ Express и Enterprise ManagerCloud Control.
Также перестают отзываться все кластерные команды.
crs_stat -t
crsctl status resource -t
srvctl
запускаются и висят бесконечно долго.
так же не могу залогиниться с правами sysdba(отваливается по таймауту)
В логах сервера БД, Кластерного ПО и самой ОСИ ничего необычного.
Помогает (не весгда) reboot от рута.

Помедитировав на досуге,прочел скудную инфу по ожиданию,
сделал пока такие выводы.
1. Отваливает все системный джоб.
2. Случилось так что пару дней назад(я это сегодня выяснил) у меня стало что общий размер дисковой группы АСМ стал чуть меньше суммарного размера max_size всех таблспейсов на этой группе. В паре источников вскользь упоминается о наличии бага в этой невинной ситуации, когда джобу сносит крышу. ужал обратно max_size, но это не надолго база растет.
3. Таксже вероятно с этим ожиданием зависает процесс SCM0, который кушает ЦПУ и мешает остальным, говорят при невозможности запретить его запуск. его нужно убивать системной командой.
лечится установкой.
alter system set "_dlm_stats_collect" = 0 scope = spfile sid = '*';
4. Также возможно отключение вообще этого месседжа. и типа это ожидание исчезнет.
alter system set "_notify_crs"=false scope = spfile sid = '*';

обе команды требуют рестарта.
что скажите, уважаемые?
доступ к металинку в данный момент у меня отсутствует.
Все заранее спасибо.

Этого, кажется, оказалось достаточно (уменьшение max_size TS) воспроизводить и повторять пока не буду. ибо больно.