Всем доброго времени суток!
Имеется инстанс 12.2.0.1 на Windows Server 2012 R2
Напрягает вывод в алерт.лог:
...
Thread 1 advanced to log sequence 14907 (LGWR switch)
Current log# 3 seq# 14907 mem# 0: C:\ORACLE12201\ORADATA\KUPOL\REDO03.LOG
2019-03-14T07:10:12.784636+07:00
WARNING: too many parse errors, count=3120 SQL hash=0x750004bb
PARSE ERROR: ospid=2024, error=933 for statement:
2019-03-14T07:10:12.785633+07:00
DELETE FROM wri$_adv_sqlt_rtn_planWHERE task_id = :tid AND exec_name = :execution_name
Additional information: hd=00007FF6E06EFAD8 phd=00007FF7902C5050 flg=0x28 cisid=0 sid=0 ciuid=0 uid=0
2019-03-14T07:10:12.787632+07:00
----- PL/SQL Call Stack -----
object line object
handle number name
00007FF74671B0C0 259 type body SYS.WRI$_ADV_SQLTUNE.SUB_DELETE_EXECUTION
00007FF673CC3CC0 2134 package body SYS.PRVT_ADVISOR.COMMON_DELETE_TASK
00007FF673CC3CC0 7342 package body SYS.PRVT_ADVISOR.DELETE_EXPIRED_TASKS
00007FF790FA65B0 1 anonymous block
WARNING: too many parse errors, count=3220 SQL hash=0x750004bb
PARSE ERROR: ospid=2024, error=933 for statement:
2019-03-14T07:10:13.130676+07:00
DELETE FROM wri$_adv_sqlt_rtn_planWHERE task_id = :tid AND exec_name = :execution_name
Additional information: hd=00007FF6E06EFAD8 phd=00007FF7902C5050 flg=0x28 cisid=0 sid=0 ciuid=0 uid=0
2019-03-14T07:10:13.131676+07:00
...

Повторяется каждые сутки.
Проглядел как SYSAUX раздулся до 8 гигов, трунканул табличку но вывод в нее продолжается а устаревшие снимки не удаляются.
гуглил но безрезультатно...
кстати примерно в то же время как обламывается адвизор встают в стопор некоторые пользовательские джобы, собственно из-за них и начала раскручиваться разборка с этим недоадвизором....

Памяти PGA аж 5 гиг, даже близко не задействуется, хотя в состоянии зависающих джобов пишется что они застревают в состоянии Allocated PGA....

Кто подскажет как победить этого дракона ?

Оба-на....
А поддержки-то и нетути....

А руками никак не заглушить и не задушить этого змея ???

Это же я понимаю производится автоматический подсчет статистики и прочего...
Может эту автоматизацию можно как-то остановить ?
И делать сборы и пересчеты вручную по мере необходимости ?

пытаться разврапливать это конечно слишком))))

Как будто их всего трое:
auto optimizer stats collection
auto space advisor
sql tuning advisor

Сделал вчера:
SQL> BEGIN
2 dbms_auto_task_admin.disable(
3 client_name => 'sql tuning advisor',
4 operation => NULL,
5 window_name => NULL);
6 END;
7 /
PL/SQL procedure successfully completed

Но как и было по расписанию вылезло:
WARNING: too many parse errors, count=1006 SQL hash=0x750004bb
PARSE ERROR: ospid=8064, error=933 for statement:
2019-03-21T07:15:10.697785+07:00
DELETE FROM wri$_adv_sqlt_rtn_planWHERE task_id = :tid AND exec_name = :execution_name
Additional information: hd=00007FF7603E3AD0 phd=00007FF7902C5050 flg=0x28 cisid=0 sid=0 ciuid=0 uid=0
2019-03-21T07:15:10.698785+07:00
----- PL/SQL Call Stack -----
object line object
handle number name
00007FF7A4D3CE60 259 type body SYS.WRI$_ADV_SQLTUNE.SUB_DELETE_EXECUTION
00007FF673CC3CC0 2134 package body SYS.PRVT_ADVISOR.COMMON_DELETE_TASK
00007FF673CC3CC0 7342 package body SYS.PRVT_ADVISOR.DELETE_EXPIRED_TASKS
00007FF790FA65B0 1 anonymous block

Проблема так и не решена на системном уровне (как бы хотелось)
Пользуюсь заданиями через JOB (или шедулер сервера, как нравится) для периодической очистки (TRUNCATE) таблиц, но этот вариант жутко как не нравится.

Если кто нашел приличное общее решение (патчировать не могу нет техподдержки, но на другую версию выше перебраться возможность всегда есть) вэлкам ! поделитесь