Oracle mechanics

25.03.2015

12c: ASH.SQL_PLAN_HASH_VALUE и адаптивные эффекты

Filed under: Active Session History,Oracle — Игорь Усольцев @ 00:15
Tags: ,

В Active Session History (ASH) версии 11g содержалось относительно небольшое кол-во записей с PLAN_HASH_VALUE = 0 о запросах в стадии выполнения (IN_SQL_EXECUTION = ‘Y’):

11.2@ SQL> select decode(sql_plan_hash_value, 0, '0', '>0') as sql_plan_hash_value,
  2         case when sql_plan_line_id is null then 'NULL' else '>= 0' end as SQL_PLAN_LINE_ID,
  3        count(*)
  4   from v$active_session_history
  5  where IN_PARSE         = 'N'
  6    and IN_HARD_PARSE    = 'N'
  7    and IN_SQL_EXECUTION = 'Y'
  8  group by decode(sql_plan_hash_value, 0, '0', '>0'),
  9           case when sql_plan_line_id is null then 'NULL' else '>= 0' end
 10  order by count(*)
 11  /
 
SQL_PLAN_HASH_VALUE SQL_PLAN_LINE_ID   COUNT(*)
------------------- ---------------- ----------
>0                  NULL                   1120
0                   NULL                   1903 -- немного, SQL_PLAN_LINE_ID is NULL - "служебные записи"
>0                  >= 0                 141186

, и, в основном, это ожидаемые куски PL/SQL кода или какие-то специальные случаи типа ожиданий по db link, etc…

В Oracle 12c кол-во таких записей может внезапно/периодически увеличиться:

12.1@ SQL> select decode(sql_plan_hash_value, 0, '0', '>0') as sql_plan_hash_value,
  2         count(*)
  3    from v$active_session_history
  4   where IN_PARSE         = 'N'
  5     and IN_HARD_PARSE    = 'N'
  6     and IN_SQL_EXECUTION = 'Y'
  7   group by decode(sql_plan_hash_value, 0, '0', '>0')
  8   order by count(*)
  9  /
 
SQL_PLAN_HASH_VALUE   COUNT(*)
------------------- ----------
0                        33215
>0                      163247

(more…)

12.03.2015

12c: ошибки

Filed under: error,Oracle — Игорь Усольцев @ 23:30
Tags: ,

, всплывающие при тестировании:

1) Подробно разобранная у Jonathan Lewis. Subquery with OR проблема и отражённая в Bug 18650065 : WRONG RESULTS ON QUERY WITH SUBQUERY USING OR EXISTS проблема при тестировании ОЁБС (aka Oracle Apps) на версии бд 12.1.0.* заиграла новыми красками

Дело в том, что проблемная конструкция используется в VPD политиках стандартных модулей OEBS при использовании Multi-Org Access Control (MOAC), что легко видеть из запроса:

select distinct object_owner, object_name, policy
  from v$vpd_policy
 where predicate like 'EXISTS (SELECT 1
                        FROM mo_glob_org_access_tmp oa
                       WHERE oa.organization_id = security_id_int_1) OR security_id_int_1 IS NULL%'

А непонятность, собственно, состоит в том, что в рекомендациях оёбс по миграции на 12c ни этот баг, ни доступные workaround-ы никак не отмечены, несмотря на попытки Леонида Борчука донести это простое соображение до команды поддержки (more…)

07.03.2015

12c: управление адаптивными фичами

Filed under: CBO,Oracle — Игорь Усольцев @ 23:03
Tags: ,

По умолчанию, ответственный параметр OPTIMIZER_ADAPTIVE_FEATURES enables or disables all of the adaptive optimizer features, including adaptive plan (adaptive join methods and bitmap plans), automatic re-optimization, SQL plan directives, and adaptive distribution methods, установлен в TRUE и перечисленные функции оптимизатора 12c могут работать

Если же отключить параметр на уровне любого простого запроса:

12.1.0.2.SCOTT@/ORCL1201 SQL> select /*+ opt_param('optimizer_adaptive_features' 'false')*/ sysdate from dual;

1 row selected.

, секция Outline плана выполнения показывает параметы управления адаптивными компонентами по отдельности: (more…)

02.03.2015

Стабильность SQL Plan Baseline при обновлениях

Filed under: Oracle,Plan Management,SQL Tuning — Игорь Усольцев @ 22:13
Tags:

Всё указывало на запрос 9s7ppf88qzx2w: и экспресс-анализ по пользователю/модулю доморощенным скриптом ASH_SQL_WAIT_TREE.SQL:

SQL> @ash_sql_wait_tree "client_id  = 'APPS_USER' and module = 'e:AR:frm:XXXXX'" 0
 
LVL BLOCKING_TREE  EVENT                     WAITS_COUNT EXECS_COUNT AVG_WA SQL_ID
--- -------------- ------------------------- ----------- ----------- ------ -------------
  1 (USER)         On CPU / runqueue                 691          10      0 9s7ppf88qzx2w
  1 (USER)         db file sequential read            83           7     53 9s7ppf88qzx2w
  1 (USER)         gc current block 2-way             29           3      3 9s7ppf88qzx2w
  1 (USER)         gc cr grant 2-way                  12           3      4 9s7ppf88qzx2w
  1 (USER)         db file sequential read             9           9    295 63sr2px4kd9da
...

, и данные SQL трейса: (more…)

22.02.2015

Особенности SQL Patch

Filed under: Oracle,SQL Tuning — Игорь Усольцев @ 21:24
Tags:

Лишь частично документированный, но достаточно удобный для простого манипулирования планами выполнения SQL Patch, как и всякий инструмент имеет свои ограничения/особенности

Так, например, длина добавляемой к запросу подсказки имеет точное ограничение:
(more…)

30.01.2015

DBA_AUDIT_TRAIL, ORA-64203 и китайская грамота

Filed under: commonplace,error,Oracle — Игорь Усольцев @ 01:00
Tags:

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

SQL> select max(lengthb(sql_text)), max(lengthb(sql_bind)) from DBA_AUDIT_TRAIL;
 
select max(lengthb(sql_text)), max(lengthb(sql_bind)) from DBA_AUDIT_TRAIL
 
ORA-64203: Destination buffer too small to hold CLOB data after character set conversion.

Найти проблемные строки несложно: (more…)

14.12.2014

SPM подходы к изменению плана запроса с hardcoded подсказками

Filed under: Oracle,SQL Tuning — Игорь Усольцев @ 20:18
Tags: ,

Вопрос: как максимально корректно изменить план выполнения уже хинтованного запроса? Корректно, в смысле не меняя текста запроса (само собой) и, желательно, не меняя параметров сессии, т.е. используя, например, безконтактный SQL Plan Management (SPM)?

Простейшая тестовая схема:

11.2.0.3@SCOTT SQL> create table emp123
  2  as
  3  select * from emp
  4  /

Table created.

SQL> exec dbms_stats.gather_table_stats('','EMP123')

PL/SQL procedure successfully completed.

SQL> create index emp123_sal_idx on emp123(sal)
  2  /

Index created.

Простой запрос с использованием FTS: (more…)

12.12.2014

Гарантированный DOP и параметр PARALLEL_MIN_PERCENT

Filed under: Oracle,SQL Tuning — Игорь Усольцев @ 23:16
Tags: , ,

Встречаются запросы с завидным потреблением временного табличного пр-ва для HASH JOIN-ов разного рода и других сортировочно-группировочных операций, при недостатке показывающие:

ORA-01652: невозможно увеличить временный сегмент до 64 в разделе TEMP

Одним из методов сокращения требуемых объёмов temp является использование параллельного выполнения благодаря которому, попутно с улучшением общей скорости выполнения запроса, можно съэкономить временное пр-во, используя бОльший объём PGA большИм кол-вом px-процессов

В этом случае бывает необходимо обеспечить определённый Degree Of Parallelism (DOP) для выполнения конкретного запроса, т.е. ограничить DOP «снизу», для чего теоретически идеально подходит механизм parallel statement queuing, однако установка параметра _PARALLEL_STATEMENT_QUEUING = TRUE не всегда срабатывает, например, при выполнении DBMS_SCHEDULER-ного задания (job) запросы без ожидания resmgr:pq queued, начинают выполняться непараллельно, невзирая на отсутствие свободных PX

Как оказалось, в заданиях DBMS_SCHEDULER отлично срабатывает другой параметр PARALLEL_MIN_PERCENT, со своими особенностями, но срабатывает и в PL/SQL блоке DBMS_SCHEDULER, и на уровне обычной пользовательской сессии

Итак, на сервере со следующими ресурсами: (more…)

07.12.2014

ROWID доступ к партицированной таблице

Filed under: Oracle,Plan Management,SQL Tuning — Игорь Усольцев @ 10:53
Tags: ,

С Леонидом Борчуком разбирали страшное:

SQL ordered by Elapsed Time           DB/Inst: OEBS/OEBS1  Snaps: 77632-77633

        Elapsed                  Elapsed Time                                   
        Time (s)    Executions  per Exec (s)  %Total   %CPU    %IO    SQL Id    
---------------- -------------- ------------- ------ ------ ------ -------------
        49,260.9            139        354.39   72.4    9.0   93.5 2b01txt3hnjha -- запрос потребляет более 70% DB Time
Module: e:SQLAP:bes:oracle.apps.xla.accounting.postproce
UPDATE /*+ PARALLEL (AEL) */ XLA_AE_LINES AEL SET AEL.ANALYTICAL_BALANCE_FLAG = 
:B8 ,AEL.LAST_UPDATE_DATE = :B5 ,AEL.LAST_UPDATED_BY = :B7 ,AEL.LAST_UPDATE_LOGI
N = :B6 ,AEL.PROGRAM_UPDATE_DATE = :B5 ,AEL.PROGRAM_APPLICATION_ID = :B4 ,AEL.PR
OGRAM_ID = :B3 ,AEL.REQUEST_ID = :B2 WHERE (AEL.ROWID) IN (SELECT ...

         5,312.4          1,801          2.95    7.8   99.2     .0 7r2xtc0ru1h0s -- , на порядок опережая конкурентов
...

Один из стандартных запросов OEBS, судя по истории обычно выполнялся небыстро, потребляя значительные I/O ресурсы на direct path read (судя по соотношению DISK_READS_PER_EXEC и READS_PER_EXEC) большим количеством параллельных процессов (PX_PER_EXEC): (more…)

04.12.2014

ORA-8103 при использовании BCT на standby db

Filed under: Active Data Guard,bugs,Oracle — Игорь Усольцев @ 22:59
Tags: ,

После восстановления очередной тестовой бд с использованием инкрементальных бэкапов, сделанных с использованием Block Change Tracking (BCT) на standby версии 11.2.0.3 получили при попытке последовательно прочитать определённые блоки таблицы:

SQL> select/*+ full(t)*/ count(*) from U2.CALL_STAT t;
 
select/*+ full(t)*/ count(*) from U2.CALL_STAT t
 
ORA-08103: object no longer exists

SQL> analyze table U2.CALL_STAT validate structure;
 
analyze table U2.CALL_STAT validate structure
 
ORA-08103: object no longer exists

, при этом в трейсах можно видеть фактический источник ошибки: (more…)

Следующая страница →

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

Отслеживать

Get every new post delivered to your Inbox.

Join 147 other followers