Планозависимая ошибка ORA-00600 [kkpamKRange:List]

11.1.0.7.@ SQL> delete from tb_task
  2   where id in (select
  3                       t.id
  4                  from tb_task t
  5                  join tb_session s
  6                    on t.session_id = s.id
  7                 where s.type_id in (78)
  8                   and t.status = 0)
  9  /
delete from tb_task
                  *
ERROR at line 1:
ORA-00600: internal error code, arguments: [kkpamKRange:List], [0], [0], [18], [0], [], [], [], [], [], [], []

Понятно, что это – Bug 8529594 OERI[kkpamKRange:List] on DML to table with constraint enforced with partitioned index – superceded, есть патчи, по описанию относится к компоненте:

kkpam – support for mapping predicate keys expressions to equivalent partitions

и возникает после разбора SQL, на этапе проверки записей в дочерних по FK партициях индексов

Тем не менее, ошибка зависит от плана выполнения, и до установки патча/обновления возможны workaround-ы

SQL Plan Management в практических приложениях-2

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

11.2.0.3.@ SQL> var st char(9)
SQL> var en char(9)
SQL> exec :st := '23-MAY-13'; :en := '23-MAY-13'

PL/SQL procedure successfully completed.

SQL> select place_id, page_id, dt,
            sum(hits) hits,
            sum(partner_bonus_wo_nds) sum1,
            sum(partner_bonus) sum2,
            max(c_id) c_id
            from v_distr
            where dt >=:st and dt <= :en  -- dt типа DATE
            group by dt, place_id, page_id
/

...
140 rows selected.

Elapsed: 00:00:55.14

Статистика DBA_HIST_SQLSTAT подтверждает присутствие нестабильности и в плане, и, что существенно, в среднем времени выполнения ELA_PER_EXEC (us):

Отображение текста, сохранённого в разных кодировках в бд с однобайтной кодировкой, через db link из UTF бд

Непрямой способ для редких случаев когда нужно одновременно получить / отобразить данные, сохранённые в разных однобайтовых кодировках

Orion

Понравились сценарии использования утилиты Orion:

• у вас есть конкретные требования к дисковой подсистеме, и вы хотите удостовериться в том, что предлагаемое оборудование им соответствует
• вы не знаете что потребуется, и хотите выбрать лучшее из доступного

, сформулированные Алексом Горбачевым в презентации:

Естественно логично следовать приведённым сценариям до приобретения дискового оборудования и вместо прослушания sales tales от вендоров ;)

Как оказалось, Orion уже давно переместился из категории Beta software в “основной состав” дистрибутива и документацию, начиная с Oracle 11.2. Важно использование в этом инструменте Oracle I/O software stack для достоверного воспроизведения нагрузки бд и возможность симуляции RAID0 striping, характерного для ASM:

$ orion ... -simulate RAID0 -stripe [1]{MB}

Параметр _very_large_object_threshold

Начиная с Oracle 11.2 на выбор способа чтения блоков индекса между serial direct path read и буферизованным чтением (через db buffer cache SGA) при операции INDEX FAST FULL SCAN (IFFS) влияет параметр:

SQL> @param_ _very_large_object_threshold

NAME                         VALUE IS_DEF   DSC
---------------------------- ----- -------- -----------------------------------------------------
_very_large_object_threshold 500   TRUE     upper threshold level of object size for direct reads

Правильное значение этого параметра: процент от размера буферного кэша (точнее, параметра _db_block_buffers) при превышении которого индекс считается “большим” и в процессе IFFS будет использоваться direct path read, если же размер индекса меньше – IFFS будет выполняться стандартными чтениями блоков через буферный кэш SGA – в точности как показал Саян Малакшинов в своём блоге Example of controlling “direct path reads” decision through SQL profile hints (index_stats/table_stats), где кроме этого параметра описывает хинт INDEX_STATS(“OWNER”.”TABLE_NAME”, “INDEX_NAME”, scale, blocks=X), частовстречаемый / применяемый в SQL Profiles

В процессе тестирования на разных платформах, о котором мы договорились с Саяном, замечено также влияние значения параметра _very_large_object_threshold на управление direct path read с использованием event 10949 при полном сканировании таблиц

Рынок серверов 1Q2013

Заслуживающее исследование Gartner отражает грустную для великих брендов (кроме Dell, успешно торгующей только x86 серверами) картину:

Worldwide: Server Vendor Revenue Estimates, 1Q13 (U.S. Dollars)

Company	1Q13 Revenue	1Q13 Market Share (%)	1Q12 Revenue	1Q12 Market Share (%)	1Q13-1Q12 Growth (%)
IBM	3,016,060,031	25.5	3,490,477,200	28.0	-13.6
HP	2,959,030,197	25.0	3,455,759,513	27.8	-14.4
Dell	2,124,462,397	18.0	1,857,578,951	14.9	14.4
Fujitsu	583,238,840	4.9	626,721,932	5.0	-6.9
Oracle	538,542,499	4.6	739,825,931	5.9	-27.2
Others	2,604,390,348	22.0	2,273,724,071	18.3	14.5
Total	11,825,724,312	100.0	12,444,087,599	100.0	-5.0

• продажи серверов архитектуры x86 сохраняется на стабильном уровне с небольшим (+1.8%) увеличением по суммам несмотря на кризис, т.е. фактически показывают заметный рост
• продажи брендовых RISC/Itanium Unix серверов упали более чем на 35% и в стоимостном, и в количественном выражении
• категория Others отражает, в основном, рост продаж мэйнфреймов под военные и прочие госпрограммы
• рост продаж зафиксирован только в регионах Asia/Pacific (Китай?) и US

Полагаю, наблюдаемые тенденции равномерно распостраняются и на серверы бд, в частности

Блокировки direct path DML

Периодически alert.log версии 11.1.0.7 демонстрирует пакетные сообщения об ошибках ORA-00060:

Sun May 19 20:15:25 2013
ORA-00060: Deadlock detected. More info in file /opt/oracle/admin/diag/rdbms/orcl11107/orcl11107/trace/orcl11107_s000_1386.trc.
Sun May 19 20:15:26 2013
ORA-00060: Deadlock detected. More info in file /opt/oracle/admin/diag/rdbms/orcl11107/orcl11107/trace/orcl11107_s009_6543.trc.
Sun May 19 20:15:27 2013
ORA-00060: Deadlock detected. More info in file /opt/oracle/admin/diag/rdbms/orcl11107/orcl11107/trace/orcl11107_s001_3077.trc.

Причина блокировок известна – попытка одновременного выполнения нескольких транзакций на одной таблице в режиме parallel dml (alter session enable parallel dml => V$SESSION.PDML_ENABLED=’YES’, далее составляющие транзакцию 2 последовательные непараллельные операции DELETE, INSERT /*+ APPEND*/ на непартиционированной таблице TAB1) – и относится к вопросам разработки и архитектуры приложения. Интересны детали отображения и обработки Oracle блокировок типа TM Lock Requesting Mode X (6) (SX X SX X)

Кроме необходимости преобразования / эскалации блокировки TM SX -> X при переходе от DELETE к direct path insert, первый трейс не показывает ничего неожиданного:

ASH-трейс и параметры статистики

Время выполнения SQL запроса в веб-форме OEBS превысило допустимые пределы (таймаут веб-сервера = 10 минут) – как обычно, “вдруг” стало выполняться медленно

Выполнив скрипт “трассировки” ASH_SQLMON.SQL можно заметить, что основное время тратится на доступ к блокам некой штатной таблицы RA_CUSTOMER_TRX_ALL с использованием странного для OEBS метода доступа INDEX SKIP SCAN:

11.2.0.3.OEBS1@ SQL> @ash_sqlmon 5fbmjj0n32rfw "" ""

 ID PLAN_OPERATION                                   OBJECT_OWNER  OBJECT_NAME           COST CARDINALITY      BYTES TEMP_SPACE SESSION_STATE   WAIT_COUNT
--- ------------------------------------------------ ------------- --------------------- ---- ----------- ---------- ---------- --------------- ----------
...
157               NESTED LOOPS OUTER                                                      621           3        189            ON CPU          21
158                 NESTED LOOPS                                                          356         264      13464            ON CPU          1
159                   TABLE ACCESS BY INDEX ROWID    AR            RA_CUST_TRX_TYPES_ALL   10           1         13
160                     INDEX SKIP SCAN              AR            RA_CUST_TRX_TYPES_U1     1          19
161                   TABLE ACCESS BY INDEX ROWID    AR            RA_CUSTOMER_TRX_ALL    346         292      11096            ON CPU          2659 -- основное время (по кол-ву попаданий в ASH)
162                     INDEX SKIP SCAN              AR            RA_CUSTOMER_TRX_N17     40        1437                       ON CPU          1157 -- и тут тоже
163                 TABLE ACCESS BY INDEX ROWID      AR            RA_CUSTOMER_TRX_ALL      2        9048     108576            ON CPU          16
164                   INDEX RANGE SCAN               AR            RA_CUSTOMER_TRX_N6       1           1                       ON CPU          52
...

Новое в статистике

1. Выпуск патча Bug 13262857 Enh: provide some control over DBMS_STATS index clustering factor computation типа enhancement not a bug, допускающего более реалистичный (по описанию – “оптимистичный”) метод расчёта Clustering Factor (CF) индекса, с учётом кэширования недавно прочитанных блоков таблицы

С описанием и тестами патча можно ознакомиться в блоге Richard Foote Important !! Clustering Factor Calculation Improvement (Fix You) и Clustering Factor Calculation Improvement Part II (Blocks On Blocks):

“Традиционно, CF вычисляется методом последовательного сравнения номеров блоков (получаемых из rowid) индексированных строк таблицы в процессе выполнения Full Index Scan. В случае если номер блока следующей в индексе строки отличается от номера блока предыдущей индексированной строки, CF увеличивается на 1. Если номер блока не изменился – CF не увеличивается…
Чем меньше значение CF, тем более эффективным (предпочтительным для оптимизатора) будет использование индекса, поскольку для упорядоченного доступа к данным таблицы (в процессе Index Scan) потребуется прочитать меньше блоков бд…”

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

Семинар с Джонатаном Льюисом

13 мая состоялся семинар Джонатана Льюиса (Jonathan Lewis), высококлассного специалиста по оптимизации / оптимизатору и вопросам производительности Oracle, автора бестселлера Cost-Based Oracle Fundamentals:

• обзор общих / типичных проблем производительности
• доклад об эволюции гистограм – на основе доклада на OOW 2012, как я понимаю – есть возможность ознакомится
• методология и  подходы к решению вопросов и проблем

Наиболее ценно – ответы на практические вопросы и редкостная возможность прямого общения ;)

Огромное спасибо компании “Иннова” и Илье Дееву за организацию этого интереснейшего и крайне полезного образовательно – вдохновляющего мероприятия

Далее – несколько непрофессиональных фото