Oracle mechanics

15.06.2013

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

Filed under: CBO,Oracle — Igor Usoltsev @ 23:01
Tags: ,
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-ы (далее…)

10.06.2013

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): (далее…)

09.06.2013

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

Filed under: NLS,Oracle — Igor Usoltsev @ 22:54
Tags: , ,

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

06.06.2013

Orion

Filed under: commonplace,install-config-migration,Oracle — Igor Usoltsev @ 09:20
Tags: ,

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

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

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

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

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

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

03.06.2013

Параметр _very_large_object_threshold

Filed under: Oracle,Oracle new features,parameters — Igor Usoltsev @ 23:20
Tags: ,

Начиная с 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 при полном сканировании таблиц (далее…)

01.06.2013

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

Filed under: commonplace — Igor Usoltsev @ 11:06
Tags:

Заслуживающее исследование 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

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

30.05.2013

Блокировки 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, первый трейс не показывает ничего неожиданного:
(далее…)

26.05.2013

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

Filed under: Oracle,SQL Tuning — Igor Usoltsev @ 01:13
Tags: ,

Время выполнения 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
...

(далее…)

15.05.2013

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

Filed under: Oracle,statistics — Igor Usoltsev @ 23:20
Tags: , ,

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) потребуется прочитать меньше блоков бд…”

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

14.05.2013

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

Filed under: commonplace,Oracle — Igor Usoltsev @ 21:47

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

IMG_0246_

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

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

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

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

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

Theme: Rubric. Блог на WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 66 other followers