Oracle mechanics

01.07.2016

12c: Wrong results в запросах и апрельский DB Bundle Patch

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

Коллега Александр Шведунов указал проблему:

SQL> select
  2   t1.id, t1.category
  3    from t1
  4   where t1.id in
  5         (select p_id from t2 where service_id = 11)
  6     and t1.firm_id in (111)
  7     and t1.category in ('yt', 'ytph')
  8  /

        ID CATEGORY
---------- --------------------
  11101013 ytph -- Wrong results for CATEGORY column
  11101014 ytph
  11101023 ytph
  11101036 ytph

4 rows selected.

SQL> select t1.id, t1.category
  2    from t1
  3   where t1.id in (11101013, 11101014, 11101023, 11101036)
  4  /
 
        ID CATEGORY
---------- --------------------
  11101013 yt   -- True results for CATEGORY column
  11101014 yt
  11101023 yt
  11101036 yt

Из плана ошибочного запроса:

SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor('','',format => '+outline'));

Plan hash value: 3964752377

-------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |            |       |       |    17 (100)|       |
|   1 |  NESTED LOOPS                      |            |     2 |    48 |    17   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                     |            |    67 |    48 |    17   (0)| 00:00:01 |
|*  3 |    INDEX FAST FULL SCAN            | T2_PK      |    67 |   603 |     3   (0)| 00:00:01 |
|   4 |    BITMAP CONVERSION TO ROWIDS     |            |       |       |            |          |
|   5 |     BITMAP AND                     |            |       |       |            |          |
|   6 |      BITMAP CONVERSION FROM ROWIDS |            |       |       |            |          |
|*  7 |       INDEX RANGE SCAN             | T1_PK      |     1 |       |     0   (0)|          |
|   8 |      BITMAP OR                     |            |       |       |            |          |
|   9 |       BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |
|* 10 |        INDEX RANGE SCAN            | T1_CAT_IDX |     1 |       |     0   (0)|          | -- индекс по T1(CATEGORY)
|  11 |       BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |
|* 12 |        INDEX RANGE SCAN            | T1_CAT_IDX |     1 |       |     0   (0)|          | -- --//--
|* 13 |   MAT_VIEW ACCESS BY INDEX ROWID   | T1         |     1 |    15 |    17   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('12.1.0.2')
      DB_VERSION('12.1.0.2')
      ALL_ROWS
      ...
      BITMAP_TREE(@"SEL$5DA710D3" "T1"@"SEL$1" AND(("T1"."ID") OR(1 1 ("T1"."CATEGORY") 2 ("T1"."CATEGORY")))) -- *
      ...
      END_OUTLINE_DATA
  */

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("SERVICE_ID"=11)
   7 - access("T1"."ID"="P_ID")
  10 - access("T1"."CATEGORY"='yt')
  12 - access("T1"."CATEGORY"='ytph')
  13 - filter("T1"."FIRM_ID"=111)

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - this is an adaptive plan                            -- **
   - 2 Sql Plan Directives used for this statement

— можно предположить, что ошибка может быть связана с обновлённой комплексной операцией BITMAP_TREE, определённой соответствующим хинтом Outline (*) — что оказалось верным, в комбинации с 12c Adaptive Plan (**)

Т.е. при отключении или одного (‘_b_tree_bitmap_plans’ ‘false’), или другого (‘_optimizer_adaptive_plans’ ‘false’) запрос возвращает правильный рез-т, причём в последнем случае с абсолютно тем же планом выполнения Plan hash value = 3964752377:

SQL> select--+ opt_param('_optimizer_adaptive_plans' 'false')
  2   t1.id, t1.category
  3    from t1
  4   where t1.id in
  5         (select p_id from t2 where service_id = 11)
  6     and t1.firm_id in (111)
  7     and t1.category in ('yt', 'ytph')
  8  /

        ID CATEGORY
---------- --------------------
  11101013 yt
  11101014 yt
  11101023 yt
  11101036 yt

SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor('','',format => '+outline'));

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------

Plan hash value: 3964752377

-------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |            |       |       |    17 (100)|       |
|   1 |  NESTED LOOPS                      |            |     2 |    48 |    17   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                     |            |    67 |    48 |    17   (0)| 00:00:01 |
|*  3 |    INDEX FAST FULL SCAN            | T2_PK      |    67 |   603 |     3   (0)| 00:00:01 |
|   4 |    BITMAP CONVERSION TO ROWIDS     |            |       |       |            |          |
|   5 |     BITMAP AND                     |            |       |       |            |          |
|   6 |      BITMAP CONVERSION FROM ROWIDS |            |       |       |            |          |
|*  7 |       INDEX RANGE SCAN             | T1_PK      |     1 |       |     0   (0)|          |
|   8 |      BITMAP OR                     |            |       |       |            |          |
|   9 |       BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |
|* 10 |        INDEX RANGE SCAN            | T1_CAT_IDX |     1 |       |     0   (0)|          |
|  11 |       BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |
|* 12 |        INDEX RANGE SCAN            | T1_CAT_IDX |     1 |       |     0   (0)|          |
|* 13 |   MAT_VIEW ACCESS BY INDEX ROWID   | T1         |     1 |    15 |    17   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

Outline Data
-------------

  /*+
      ...
      BITMAP_TREE(@"SEL$5DA710D3" "T1"@"SEL$1" AND(("T1"."ID") OR(1 1 ("T1"."CATEGORY") 2 ("T1"."CATEGORY"))))
      ...
  */

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - 2 Sql Plan Directives used for this statement

— только не-Адаптивным!

Как оказалось, Bug 21363395 : WRONG RESULTS FOR ADAPTIVE PLAN WHEN _B_TREE_BITMAP_PLANS = TRUE / Base Bug 18430870 Wrong Results with Adaptive Plans and INLIST ITERATOR давно зарегистрирован, входит в апрельский 12.1.0.2. DB Bundle Patch:160419, который, кстати, отныне рекомендуется ставить везде, а не только на EXADATA:

The important change in the April PSU/BP release:The database patch for «Engineered Systems and Database In-Memory 12.1.0.2» luckily got renamed into «Proactive Bundle Patch 12.1.0.2». That is not only a rebranding but it should express that we would like to encourage you to apply the Bundle Patches instead of the PSUs. Simple reason is that the BPs will contain optimizer fixes.

По дороге попался полезный проактивный документ по теме — Things to Consider to Avoid Poor Performance or Wrong Results on 12.1.0.2 (Doc ID 2034610.1)

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

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

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 такие блоггеры, как: