Oracle mechanics

10.10.2014

Простая проблема при создании AWR снапшотов в Oracle 11g

Filed under: bugs,Диагностика системы (instance),Oracle — Игорь Усольцев @ 00:10
Tags: ,

Проблема действительно несложная (более интересный вариант отписывал ранее) и выражается, кроме собственно прекращения генерации снапшотов, сообщениями в alert.log вида:

ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_1245278029_19314 by 128 in tablespace SYSAUX
ORA-1688: unable to extend table SYS.WRH$_ACTIVE_SESSION_HISTORY partition WRH$_ACTIVE_1245278029_19314 by 8192 in tablespace SYSAUX

, ошибками в трейсах процесса Manageability Monitor (mmon) и детей ея m00x, выраженным ростом партиций сегмента WRH$_LATCH_CHILDREN:

11.2.0.4@ SQL> select * from dba_segments where tablespace_name = 'SYSAUX' and bytes > 1e9 order by bytes desc;
 
SEGMENT_NAME                    PARTITION_NAME                 SEGMENT_TYPE       SEGMENT_SUBTYPE TABLESPACE_NAME      BYTES     BLOCKS
------------------------------- ------------------------------ ------------------ --------------- --------------- ---------- ----------
WRH$_LATCH_CHILDREN             WRH$_LATCH__1245278029_19314   TABLE PARTITION    ASSM            SYSAUX          3414687744    4168320
WRH$_LATCH_CHILDREN_PK          WRH$_LATCH__1245278029_19314   INDEX PARTITION    ASSM            SYSAUX          2771281510    3382912
WRH$_ACTIVE_SESSION_HISTORY     WRH$_ACTIVE_1245278029_19314   TABLE PARTITION    ASSM            SYSAUX          1407188992     171776

, отражена в документе поддержки SYSAUX Tablespace can Become Full Due to WRH$_LATCH_CHILDREN growth (Doc ID 874518.1) и чаще всего возникает при установке statistics_level=ALL на уровне системы

Некоторой определённости заслуживают быстрые методы очистки SYSAUX и перезапуска mmon_slave процессов для возобновления автогенерации снапшотов

Самые давние сохраняемые снапшоты могут оказаться достаточно старыми:

SQL> select snap_id, sample_time from WRH$_ACTIVE_SESSION_HISTORY partition(WRH$_ACTIVE_1245278029_19314) where rownum <= 1;
 
SNAP_ID SAMPLE_TIME
------- -------------------------
  19314 12-JAN-14 02.59.55.970 AM

по сравнению с последним, отражённым в AWR:

SQL> select min(snap_id) from dba_hist_snapshot;
 
MIN(SNAP_ID)
------------
       21470

Рекомендованную процедуру:

SQL> exec DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(19314, 19314)

^C 
begin DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(19314, 19314); end;
 
ORA-01013: user requested cancel of current operation
ORA-13509: error encountered during updates to a AWR table
ORA-01013: user requested cancel of current operation
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 154
ORA-06512: at line 2

— приходится прервать ввиду медлительности честного транзакционного удаления:

delete from WRH$_LATCH_CHILDREN tab
 where (:beg_snap <= tab.snap_id and tab.snap_id <= :end_snap and
       dbid = :dbid)
   and not exists (select 1
          from WRM$_BASELINE b
         where (tab.dbid = b.dbid)
           and (tab.snap_id >= b.start_snap_id)
           and (tab.snap_id <= b.end_snap_id))

в отличие от быстрых операций:

SQL> truncate table WRH$_LATCH_CHILDREN
  2  /
 
Table truncated

SQL> truncate table WRH$_ACTIVE_SESSION_HISTORY
  2  /
 
Table truncated

, которые можно выполнить для особо крупных сегментов (если нечего жалеть, конечно), после чего стандартная процедура выполняется за разумное время:

SQL> exec DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(19314, 21469)
 
PL/SQL procedure successfully completed

После освобождения места в SYSAUX генерация снапшотов может легко выполняться при ручном запуске, но с автоматической генерацией в течение длительного времени могут возникать проблемы, сопровождаемые сообщениеми mmon:

*** 2014-10-02 17:00:37.168
Unable to schedule a MMON slave at: Auto Flush Main 1
  Slave action has been temporarily suspended
    - Slave action had prior policy violations.
  Unknown return code: 101

— что, судя по многочисленным следам на сайте Oracle Support является достаточно стандартным поведением

В качестве эффективного решения можно рестартовать/через термининацию (kill) процесс mmon на уровне ос, ибо: killing mmon will not terminate the instance, либо рестартовать инстанс

Варианты приветствуются)

Добавить комментарий »

Комментариев нет.

RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Создайте бесплатный сайт или блог на WordPress.com.

%d такие блоггеры, как: