Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Consistent gets  [new]
Dmitry_L121212
Member

Откуда:
Сообщений: 54
Есть странная и непонятная ситуация - есть две базы, оригинал и рабочая, в которой работают день.
Один и тот же запрос выполняется на несколько порядков дольше, при одинаковых планах запросов.
примерно так:

SELECT * FROM MY_VIEW where A in (123) and B = 321

в оригинале Consistent reads - 60 000, в рабочей - 15 000 000, в чем может быть дело?
=(
15 ноя 12, 15:52    [13478934]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
nf32
Guest
Dmitry_L121212, в количестве данных
15 ноя 12, 15:55    [13478958]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
nf32
Guest
а еще с конкурентной работой с табличкой
15 ноя 12, 15:56    [13478972]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
Dmitry_L121212
Member

Откуда:
Сообщений: 54
Во вьюхе учавствуют три таблицы:
А - 2500 записей, не изменилась
Б - 25000 записей, не изменилась
В - 2000 записей, В НОВОЙ БД выросла на 2500 = 4500

Статистика собрана по всем пользовательским таблицам.
В старой БД - 0,5 сек, в новой 180 сек.

УДАЛИЛ статистику по таблице, с изменившимся количеством - стало работать 1сек.

1. Почему?
2. Как предотвратить автоматический сбор статистики по этой таблице стандартным оракловым джобом? Выключить джоб?
15 ноя 12, 16:22    [13479177]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
comphead
Member

Откуда: Киев
Сообщений: 3390
Dmitry_L121212
Есть странная и непонятная ситуация - есть две базы, оригинал и рабочая, в которой работают день.
Один и тот же запрос выполняется на несколько порядков дольше, при одинаковых планах запросов.
примерно так:

SELECT * FROM MY_VIEW where A in (123) and B = 321

в оригинале Consistent reads - 60 000, в рабочей - 15 000 000, в чем может быть дело?
=(


планы в студию.
15 ноя 12, 16:23    [13479182]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
_Alex_SMIRNOV_
Member

Откуда: Киев
Сообщений: 1519
Dmitry_L121212, покажите оба плана
15 ноя 12, 16:25    [13479210]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
paxah
Member

Откуда:
Сообщений: 10
похожая ситуация, есть две базы боевая и тестовая и запрос


SELECT MAX(B.NLABORIOUSNESS) 
FROM EAM_EQUIPPOSLABOR A,
        EAM_REPAIRLABORIOUSNESS B
WHERE A.IDEQUIPMENT = :B2
  AND A.IDREPAIRLABORIOUSNESS = B.ID
  AND B.IDPARENT IS NULL 
  AND B.IDTYPEREPAIR = :B1 


Боевая база
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   1554      0.12       0.09          0          0          0           0
Fetch     1554    204.84     216.93          0   22246072          0        1554
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     3109    204.96     217.03          0   22246072          0        1554

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 251  (BTK)   (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         1          1          1  SORT AGGREGATE (cr=2 pr=0 pw=0 time=47 us)
         0          0          0   NESTED LOOPS  (cr=2 pr=0 pw=0 time=38 us)
         0          0          0    NESTED LOOPS  (cr=2 pr=0 pw=0 time=36 us cost=5 size=48 card=1)
         0          0          0     TABLE ACCESS BY INDEX ROWID EAM_REPAIRLABORIOUSNESSMAP (cr=2 pr=0 pw=0 time=36 us cost=2 size=32 card=1)
         0          0          0      INDEX RANGE SCAN IDX_EAM_REPAIRLABORIOUSNE_6909 (cr=2 pr=0 pw=0 time=32 us cost=1 size=0 card=1)(object id 111575)
         0          0          0     INDEX RANGE SCAN IDX_EAM_EQUIPPOSLABOR_11_11584 (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=2)(object id 111467)
         0          0          0    TABLE ACCESS BY INDEX ROWID EAM_EQUIPPOSLABOR (cr=0 pr=0 pw=0 time=0 us cost=3 size=16 card=1)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
      1   SORT (AGGREGATE)
      0    NESTED LOOPS
      0     NESTED LOOPS
      0      TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF 
                 'EAM_EQUIPPOSLABOR' (TABLE)
      0       INDEX   MODE: ANALYZED (RANGE SCAN) OF 
                  'IDX_EAM_EQUIPPOSLABOR_11_11582' (INDEX)
      0      INDEX   MODE: ANALYZED (UNIQUE SCAN) OF 
                 'PK_EAM_REPAIRLABORIOUSNES_6899' (INDEX (UNIQUE))
      0     TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF 
                'EAM_REPAIRLABORIOUSNESSMAP' (TABLE)


Тестовая база
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   1554      0.20       0.13          0          0          0           0
Fetch     1554      0.04       0.08          2      37338          0        1554
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     3109      0.24       0.21          2      37338          0        1554

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 83     (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         1          1          1  SORT AGGREGATE (cr=7 pr=0 pw=0 time=65 us)
         0          0          0   NESTED LOOPS  (cr=7 pr=0 pw=0 time=56 us)
         1          1          1    NESTED LOOPS  (cr=6 pr=0 pw=0 time=40 us cost=6 size=108 card=2)
         1          1          1     TABLE ACCESS BY INDEX ROWID EAM_EQUIPPOSLABOR (cr=4 pr=0 pw=0 time=29 us cost=4 size=32 card=2)
         1          1          1      INDEX RANGE SCAN IDX_EAM_EQUIPPOSLABOR_11_11582 (cr=3 pr=0 pw=0 time=21 us cost=3 size=0 card=2)(object id 89621)
         1          1          1     INDEX UNIQUE SCAN PK_EAM_REPAIRLABORIOUSNES_6899 (cr=2 pr=0 pw=0 time=9 us cost=0 size=0 card=1)(object id 89727)
         0          0          0    TABLE ACCESS BY INDEX ROWID EAM_REPAIRLABORIOUSNESSMAP (cr=1 pr=0 pw=0 time=12 us cost=1 size=38 card=1)


итого на выполнение одного действия этот запрос срабатывает 1554 раз(одинакого на обоих базах)
НО
query боевой = 22246072
query боевой = 37338

Итого процедура на тесте - 4 секунды
Итого процедура на боевой- 6 минут

нет ли идей для оптимизации?
21 дек 12, 16:09    [13667060]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
paxah
похожая ситуация
Не смущает, что планы разные?
1) Разный порядок таблиц ведущая/ведомая.
2) Разные индексы используются.

Больше б дала информация из dbms_xplan.display_cursor.
Во-первых можно было бы увидеть оценки оптимизатора, во-вторых можно было бы посмотреть суммированные статистики (Rows) для всех выполнений, а не только для первого.

З.Ы. Несколько удивительно почему при одном Parse в Row Source Operation не попали все статистики по Rows/cr/etc... это поведение зависит от версии, если мне не изменяет склероз.
21 дек 12, 16:37    [13667310]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
paxah
Member

Откуда:
Сообщений: 10
в варианте "боевая база" просто более хитро разбился план запроса при чтении трассировки

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         1          1          1  SORT AGGREGATE (cr=2 pr=0 pw=0 time=47 us)
         0          0          0   NESTED LOOPS  (cr=2 pr=0 pw=0 time=38 us)
         0          0          0    NESTED LOOPS  (cr=2 pr=0 pw=0 time=36 us cost=5 size=48 card=1)
         0          0          0     TABLE ACCESS BY INDEX ROWID EAM_REPAIRLABORIOUSNESSMAP (cr=2 pr=0 pw=0 time=36 us cost=2 size=32 card=1)
         0          0          0      INDEX RANGE SCAN IDX_EAM_REPAIRLABORIOUSNE_6909 (cr=2 pr=0 pw=0 time=32 us cost=1 size=0 card=1)(object id 111575)
         0          0          0     INDEX RANGE SCAN IDX_EAM_EQUIPPOSLABOR_11_11584 (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=2)(object id 111467)
         0          0          0    TABLE ACCESS BY INDEX ROWID EAM_EQUIPPOSLABOR (cr=0 pr=0 pw=0 time=0 us cost=3 size=16 card=1)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
      1   SORT (AGGREGATE)
      0    NESTED LOOPS
      0     NESTED LOOPS
      0      TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF 
                 'EAM_EQUIPPOSLABOR' (TABLE)
      0       INDEX   MODE: ANALYZED (RANGE SCAN) OF 
                  'IDX_EAM_EQUIPPOSLABOR_11_11582' (INDEX)
      0      INDEX   MODE: ANALYZED (UNIQUE SCAN) OF 
                 'PK_EAM_REPAIRLABORIOUSNES_6899' (INDEX (UNIQUE))
      0     TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF 
                'EAM_REPAIRLABORIOUSNESSMAP' (TABLE)


в 1м: EAM_REPAIRLABORIOUSNESSMAP по IDX_EAM_REPAIRLABORIOUSNE_6909 и к ней EAM_EQUIPPOSLABOR по индексу IDX_EAM_EQUIPPOSLABOR_11_11584

в Execution Plan же все как и в "тестовая база" EAM_EQUIPPOSLABOR (IDX_EAM_EQUIPPOSLABOR_11_11582) + EAM_REPAIRLABORIOUSNESSMAP(PK_EAM_REPAIRLABORIOUSNES_6899)


для определенности имена индексов:
PK_EAM_EQUIPPOSLABOR_115_11580 on EAM_EQUIPPOSLABOR (ID)
IDX_EAM_EQUIPPOSLABOR_11_11584 on EAM_EQUIPPOSLABOR (IDREPAIRLABORIOUSNESS)
IDX_EAM_EQUIPPOSLABOR_11_11582 on EAM_EQUIPPOSLABOR (IDEQUIPMENT)


IDX_EAM_REPAIRLABORIOUSNE_6909 on EAM_REPAIRLABORIOUSNESSMAP(IDTYPEREPAIR)
PK_EAM_REPAIRLABORIOUSNES_6899 on EAM_REPAIRLABORIOUSNESSMAP(IDOBJECT)
21 дек 12, 17:22    [13667656]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
paxah
в варианте "боевая база" просто более хитро разбился план запроса при чтении трассировки
Execution Plan попал, отому что tkprof указали опцию explain.
Если ожидаемые планы совпадают, а рельные нет, то, думаю, дело в биндах для которых этот реальный план сдампился в трассировку.
21 дек 12, 17:31    [13667714]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
paxah
Member

Откуда:
Сообщений: 10
ну а на уровне калибровки v$parameter на что стоит обратить внимания?

по части проблемы query 22246072 и 37338
21 дек 12, 17:36    [13667745]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
paxah
ну а на уровне калибровки v$parameter на что стоит обратить внимания?
Ты часто к проблеме bind variable peeking подходишь путем "калибровки v$parameter"?
(не факт, конечно, что она, но я еще раз обращаю внимание на разные актуальные планы)
Покажи лучше с включенной statistics_level (в спойлер):
select * from table(dbms_xplan.display_cursor('...',null,format=>'ADVANCED'));
21 дек 12, 17:47    [13667806]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
paxah
Member

Откуда:
Сообщений: 10
из всех проектов(их немало) тока у данных клиентов постоянные проблемы: у всех скорость нор а у них еле дышит. Поэтому и 1е мысли о "калибровки v$parameter" и настройки железа.
21 дек 12, 17:51    [13667818]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
paxah
Member

Откуда:
Сообщений: 10
+ БАЗУ где все плохо показать не могу(нет подключения до пн, это база где все хорошо
SQL_ID 0p10pf9pxb5dt, child number 1
-------------------------------------
SELECT MAX(B.NLABORIOUSNESS) FROM EAM_EQUIPPOSLABOR A,
EAM_REPAIRLABORIOUSNESS B WHERE A.IDEQUIPMENT = :B2 AND
A.IDREPAIRLABORIOUSNESS = B.ID AND B.IDPARENT IS NULL AND
B.IDTYPEREPAIR = :B1

Plan hash value: 3217544613

-----------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 6 (100)| |
| 1 | SORT AGGREGATE | | 1 | 54 | | |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 2 | 108 | 6 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| EAM_EQUIPPOSLABOR | 2 | 32 | 4 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | IDX_EAM_EQUIPPOSLABOR_11_11582 | 2 | | 3 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | PK_EAM_REPAIRLABORIOUSNES_6899 | 1 | | 0 (0)| |
|* 7 | TABLE ACCESS BY INDEX ROWID | EAM_REPAIRLABORIOUSNESSMAP | 1 | 38 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

1 - SEL$F5BB74E1
4 - SEL$F5BB74E1 / A@SEL$1
5 - SEL$F5BB74E1 / A@SEL$1
6 - SEL$F5BB74E1 / T1@SEL$2
7 - SEL$F5BB74E1 / T1@SEL$2

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

/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.3')
DB_VERSION('11.2.0.3')
ALL_ROWS
OUTLINE_LEAF(@"SEL$F5BB74E1")
MERGE(@"SEL$2")
OUTLINE(@"SEL$1")
OUTLINE(@"SEL$2")
INDEX_RS_ASC(@"SEL$F5BB74E1" "A"@"SEL$1" ("EAM_EQUIPPOSLABOR"."IDEQUIPMENT"))
INDEX(@"SEL$F5BB74E1" "T1"@"SEL$2" ("EAM_REPAIRLABORIOUSNESSMAP"."IDOBJECT"))
LEADING(@"SEL$F5BB74E1" "A"@"SEL$1" "T1"@"SEL$2")
USE_NL(@"SEL$F5BB74E1" "T1"@"SEL$2")
NLJ_BATCHING(@"SEL$F5BB74E1" "T1"@"SEL$2")
END_OUTLINE_DATA
*/

Peeked Binds (identified by position):
--------------------------------------

1 - :B2 (VARCHAR2(30), CSID=171): (null)
2 - :B1 (VARCHAR2(30), CSID=171): (null)

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

5 - access("A"."IDEQUIPMENT"=TO_NUMBER(:B2))
6 - access("A"."IDREPAIRLABORIOUSNESS"="T1"."IDOBJECT")
7 - filter(("T1"."IDTYPEREPAIR"=TO_NUMBER(:B1) AND "T1"."IDCLASS"=18346001 AND "T1"."IDPARENT" IS
NULL))

Column Projection Information (identified by operation id):
-----------------------------------------------------------

1 - (#keys=0) MAX("T1"."NLABORIOUSNESS")[22]
2 - "T1"."NLABORIOUSNESS"[NUMBER,22]
3 - "T1".ROWID[ROWID,10]
4 - "A"."IDREPAIRLABORIOUSNESS"[NUMBER,22]
5 - "A".ROWID[ROWID,10]
6 - "T1".ROWID[ROWID,10]
7 - "T1"."NLABORIOUSNESS"[NUMBER,22]

21 дек 12, 17:56    [13667835]     Ответить | Цитировать Сообщить модератору
 Re: Consistent gets  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
paxah
из всех проектов(их немало) тока у данных клиентов постоянные проблемы: у всех скорость нор а у них еле дышит. Поэтому и 1е мысли о "калибровки v$parameter" и настройки железа.
Обычно если планы разные первые мысли должны быть явно не такие.

З.Ы. В понедельник выложи с format=>'ALLSTATS' а не 'ADVANCED' для обоих баз с тегом SRC. Биндов я все равно не увидел.
Заодно можешь взять аутлайн из "быстрого плана" и прилепить его к медленному запросу и показать статистику для этого.
21 дек 12, 18:08    [13667905]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить