Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

60 сообщений из 60, показаны все 3 страниц

все

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39322049

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Мне нужно соединить в запросе две таблицы, одна из которых довольно большая (под 100М записей).
Проблема в том, что прямой связи по ключу между этими таблицами нет. Нужно соединять либо через строчное поле (что нежелательно, т.к. значение этого поля во второй таблице может изменяться), либо соединять через третью таблицу, которая имеет под 300М записей и в которой будут дубли.
DDL таблиц такой (в листинг не включал констрейны и индексы по неиспользуемым полям).
Первая таблица:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.

CREATE TABLE RADACCT
(
  RADACCTID              NUMBER                 NOT NULL,
  AP_ID                  NUMBER                 NOT NULL,
  ACCTSESSIONID          VARCHAR2(255 BYTE)     NOT NULL,
  ACCTSTARTTIME          DATE                   NOT NULL,
  ACCTSTOPTIME           DATE                   NOT NULL,
  USERNAME               VARCHAR2(255 BYTE),
  REALM                  VARCHAR2(255 BYTE),
  NASPORTID              NUMBER,
  NASPORTTYPE            VARCHAR2(255 BYTE),
  ACCTSESSIONTIME        NUMBER,
  ACCTAUTHENTIC          VARCHAR2(255 BYTE),
  CONNECTINFO            VARCHAR2(255 BYTE),
  ACCTINPUTOCTETS        NUMBER,
  ACCTOUTPUTOCTETS       NUMBER,
  CALLEDSTATIONID        VARCHAR2(255 BYTE),
  CALLINGSTATIONID       VARCHAR2(255 BYTE),
  ACCTTERMINATECAUSE     VARCHAR2(255 BYTE),
  SERVICETYPE            VARCHAR2(255 BYTE),
  FRAMEDPROTOCOL         VARCHAR2(255 BYTE),
  FRAMEDIPADDRESS        VARCHAR2(255 BYTE),
  ACCTSTARTDELAY         NUMBER,
  ACCTSTOPDELAY          NUMBER,
  CISCO_NAS_PORT         VARCHAR2(255 BYTE),
  DNIS                   VARCHAR2(255 BYTE),
  H323_CALL_ORIGIN       VARCHAR2(255 BYTE),
  H323_CALL_TYPE         VARCHAR2(255 BYTE),
  H323_GW_ID             VARCHAR2(255 BYTE),
  H323_DISCONNECT_CAUSE  NUMBER,
  H323_VOICE_QUALITY     NUMBER,
  H323_REMOTE_ADDRESS    VARCHAR2(255 BYTE),
  H323_CONF_ID           VARCHAR2(255 BYTE),
  CIRCUIT_ID_TAG         VARCHAR2(255 BYTE),
  CLIENT_MAC_ADDRESS     VARCHAR2(250 BYTE)
);

CREATE UNIQUE INDEX RADACCT_PK ON RADACCT (RADACCTID) NOPARALLEL REVERSE;
CREATE INDEX RADACCT_ACCTSTARTTIME_IDX ON RADACCT (ACCTSTARTTIME) NOPARALLEL COMPRESS 1;
CREATE INDEX RADACCT_AP_IDX ON RADACCT (AP_ID, ACCTSESSIONID) NOPARALLEL COMPRESS 2;

Вторая таблица:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.

CREATE TABLE SERVICES
(
  SERVICE_ID      NUMBER                        NOT NULL,
  DOMAIN_ID       NUMBER                        NOT NULL,
  GROUP_ID        NUMBER                        NOT NULL,
  CUSTOMER_ID     NUMBER                        NOT NULL,
  ACCOUNT_ID      NUMBER                        NOT NULL,
  TYPE_ID         NUMBER                        NOT NULL,
  TARIFF_ID       NUMBER                        NOT NULL,
  CARD_ID         NUMBER,
  LOGIN           VARCHAR2(255 BYTE)            NOT NULL,
  PASSWD          VARCHAR2(255 BYTE),
  CR_PASSWD       VARCHAR2(255 BYTE),
  STATUS          NUMBER                        NOT NULL,
  ACTUAL_STATUS   NUMBER                        NOT NULL,
  DESCRIPTION     VARCHAR2(255 BYTE),
  CREATE_DATE     DATE,
  RECKONING_DATE  DATE,
  ACTIVITY_DATE   DATE,
  STATUS_DATE     DATE,
  START_DATE      DATE,
  STOP_DATE       DATE,
  PROXY_AP_ID     NUMBER
);

CREATE UNIQUE INDEX SERVICES_PK ON SERVICES (SERVICE_ID) NOPARALLEL REVERSE;
CREATE UNIQUE INDEX SERV_UNILOGIN_IDX ON SERVICES (DOMAIN_ID, TYPE_ID, LOGIN) NOPARALLEL;
CREATE INDEX SERV_LOGIN_IDX ON SERVICES (LOGIN) NOPARALLEL COMPRESS 1;
CREATE INDEX SERV_LOGINU_IDX ON SERVICES (UPPER("LOGIN")) NOPARALLEL COMPRESS 1;
CREATE INDEX SERV_TYPE_IDX ON SERVICES (TYPE_ID) NOPARALLEL COMPRESS 1;

Вообще эти две таблицы можно соединить через RADACCT.USERNAME=SERVICES.LOGIN, но значение SERVICES.LOGIN непостоянно и может изменяться.
Также их можно соединить через третью таблицу:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

CREATE TABLE BM_SERVICE_MONEY
(
  SERVICE_MONEY_ID   NUMBER                     NOT NULL,
  SERVICE_ID         NUMBER                     NOT NULL,
  CHARGE_TYPE_ID     NUMBER                     NOT NULL,
  RADACCTID          NUMBER,
  CDR_ACCT_ID        NUMBER,
  PERIODIC_ACCT_ID   NUMBER,
  APERIODIC_ACCT_ID  NUMBER,
  MOMENT             DATE                       NOT NULL,
  TARIFFEL_ID        NUMBER,
  SERVICE_AMOUNT     NUMBER(38,18)              NOT NULL,
  FDATE              DATE                       NOT NULL,
  TDATE              DATE                       NOT NULL,
  MONEY              NUMBER(15,5),
  COUNTER_CF         NUMBER(15,5)               DEFAULT 1                     NOT NULL,
  RECHARGE_MOMENT    DATE,
  INVOICE_ITEM_ID    NUMBER,
  PREBILL_MONEY      NUMBER(15,5),
  PREFIX_ID          NUMBER,
  DESCRIPTION        VARCHAR2(255 BYTE),
  PARENT_ID          NUMBER
);

CREATE UNIQUE INDEX SERVICE_MONEY_PK ON BM_SERVICE_MONEY (SERVICE_MONEY_ID) NOPARALLEL REVERSE;
CREATE INDEX SVRM_MOMENT_IDX ON BM_SERVICE_MONEY (MOMENT) NOPARALLEL COMPRESS 1;
CREATE INDEX SVRM_RADACCT_IDX ON BM_SERVICE_MONEY (RADACCTID) NOPARALLEL COMPRESS 1;
CREATE INDEX SVRM_SERVICE_IDX ON BM_SERVICE_MONEY (SERVICE_ID, FDATE) NOPARALLEL COMPRESS 2;
CREATE INDEX SVRM_TARIFFEL_IDX ON BM_SERVICE_MONEY (TARIFFEL_ID) NOPARALLEL COMPRESS 1;

Делаю такой запрос:

Код: plsql

1.
2.
3.
4.
5.
6.

select *
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
where R.ACCTSTARTTIME >= date'2016-10-01'
and R.ACCTSTARTTIME < date'2016-10-10'

Запрос выполняется быстро (30мс), план выглядит так:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

SELECT STATEMENT  ALL_ROWSCost: 58  Bytes: 16 809  Cardinality: 39  				
	8 NESTED LOOPS  Cost: 58  Bytes: 16 809  Cardinality: 39  			
		5 NESTED LOOPS  Cost: 19  Bytes: 11 349  Cardinality: 39  		
			2 TABLE ACCESS BY INDEX ROWID TABLE RADACCT Cost: 6  Bytes: 681  Cardinality: 3  	
				1 INDEX RANGE SCAN INDEX RADACCT_ACCTSTARTTIME_IDX Cost: 4  Cardinality: 3  
			4 TABLE ACCESS BY INDEX ROWID TABLE BM_SERVICE_MONEY Cost: 6  Bytes: 896  Cardinality: 14  	
				3 INDEX RANGE SCAN INDEX SVRM_RADACCT_IDX Cost: 3  Cardinality: 14  
		7 TABLE ACCESS BY INDEX ROWID TABLE SERVICES Cost: 1  Bytes: 140  Cardinality: 1  		
			6 INDEX UNIQUE SCAN INDEX (UNIQUE) SERVICES_PK Cost: 0  Cardinality: 1

Но в записи в выборке дублируются — каждому уникальному соединению RADACCTID,SERVICE_ID соответствует несколько строк с разными TARIFFEL_ID.
Такой запрос предотвращает дубли и выполняется относительно быстро (1-2 секунды):

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.

select *
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join BM_TARIFFEL T on (T.TARIFFEL_ID = B.TARIFFEL_ID and T.ZONE_ID is null)
join (select min(SEGMENT_ID) as SEGMENT_ID from BM_SEGMENT where IS_SYSTEM = 0 group by SCHEDULE_ID) P on (P.SEGMENT_ID = T.SEGMENT_ID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
where R.ACCTSTARTTIME >= date'2016-10-01'
and R.ACCTSTARTTIME < date'2016-10-10'

В результате около 10к строк, план выглядит все еще прилично:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

SELECT STATEMENT  ALL_ROWSCost: 69  Bytes: 3 927  Cardinality: 7  						
	15 NESTED LOOPS  Cost: 69  Bytes: 3 927  Cardinality: 7  					
		12 HASH JOIN  Cost: 62  Bytes: 2 947  Cardinality: 7  				
			3 VIEW  Cost: 4  Bytes: 91  Cardinality: 7  			
				2 HASH GROUP BY  Cost: 4  Bytes: 126  Cardinality: 7  		
					1 TABLE ACCESS FULL TABLE BM_SEGMENT Cost: 3  Bytes: 612  Cardinality: 34  	
			11 NESTED LOOPS  Cost: 58  Bytes: 15 912  Cardinality: 39  			
				8 NESTED LOOPS  Cost: 19  Bytes: 11 349  Cardinality: 39  		
					5 TABLE ACCESS BY INDEX ROWID TABLE RADACCT Cost: 6  Bytes: 681  Cardinality: 3  	
						4 INDEX RANGE SCAN INDEX RADACCT_ACCTSTARTTIME_IDX Cost: 4  Cardinality: 3  
					7 TABLE ACCESS BY INDEX ROWID TABLE BM_SERVICE_MONEY Cost: 6  Bytes: 896  Cardinality: 14  	
						6 INDEX RANGE SCAN INDEX SVRM_RADACCT_IDX Cost: 3  Cardinality: 14  
				10 TABLE ACCESS BY INDEX ROWID TABLE BM_TARIFFEL Cost: 1  Bytes: 117  Cardinality: 1  		
					9 INDEX UNIQUE SCAN INDEX (UNIQUE) TAREL_PK Cost: 0  Cardinality: 1  	
		14 TABLE ACCESS BY INDEX ROWID TABLE SERVICES Cost: 1  Bytes: 140  Cardinality: 1  				
			13 INDEX UNIQUE SCAN INDEX (UNIQUE) SERVICES_PK Cost: 0  Cardinality: 1

Но когда я для того, чтобы убедиться, что дублей не осталось, добавил группировку (group by R.RADACCTID, S.SERVICE_ID having count(*)>1), то запрос выполняется очень долго. Я ждал пару минут, затем прерывал запрос.
План такой:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

SELECT STATEMENT  ALL_ROWSCost: 63  Bytes: 50  Cardinality: 1  								
	16 FILTER  							
		15 HASH GROUP BY  Cost: 63  Bytes: 50  Cardinality: 1  						
			14 NESTED LOOPS  Cost: 62  Bytes: 350  Cardinality: 7  					
				12 HASH JOIN  Cost: 62  Bytes: 315  Cardinality: 7  				
					8 NESTED LOOPS  Cost: 58  Bytes: 1 599  Cardinality: 39  			
						5 NESTED LOOPS  Cost: 19  Bytes: 1 170  Cardinality: 39  		
							2 TABLE ACCESS BY INDEX ROWID TABLE BILLING.RADACCT Cost: 6  Bytes: 42  Cardinality: 3  	
								1 INDEX RANGE SCAN INDEX BILLING.RADACCT_ACCTSTARTTIME_IDX Cost: 4  Cardinality: 3  
							4 TABLE ACCESS BY INDEX ROWID TABLE BILLING.BM_SERVICE_MONEY Cost: 6  Bytes: 224  Cardinality: 14  	
								3 INDEX RANGE SCAN INDEX BILLING.SVRM_RADACCT_IDX Cost: 3  Cardinality: 14  
						7 TABLE ACCESS BY INDEX ROWID TABLE BILLING.BM_TARIFFEL Cost: 1  Bytes: 11  Cardinality: 1  		
							6 INDEX UNIQUE SCAN INDEX (UNIQUE) BILLING.TAREL_PK Cost: 0  Cardinality: 1  	
					11 VIEW BILLING. Cost: 4  Bytes: 28  Cardinality: 7  			
						10 HASH GROUP BY  Cost: 4  Bytes: 126  Cardinality: 7  		
							9 TABLE ACCESS FULL TABLE BILLING.BM_SEGMENT Cost: 3  Bytes: 612  Cardinality: 34  	
				13 INDEX UNIQUE SCAN INDEX (UNIQUE) BILLING.SERVICES_PK Cost: 0  Bytes: 5  Cardinality: 1

И я не вижу в нем причины для столь долгого выполнения.
Что я не заметил?
________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

...

Рейтинг:

0 / 0

06.10.2016, 15:49

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39322062

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

И второй вопрос.
В первой таблице поле ACCTSTARTTIME проиндексировано, а поле ACCTSTOPTIME нет.
Но мне хотелось бы найти записи, в которых в искомый диапазон попадало бы не поле ACCTSTARTTIME, а диапазон ACCTSTOPTIME.
То есть если искомый диапазон 2016-06-02...2016-06-03, а в таблице есть запись с ACCTSTARTTIME=2016-06-01 и ACCTSTOPTIME=2016-06-06, то она в выборку не попадет, а мне бы хотелось, чтобы она попала.

Если я напишу так:

Код: plsql

1.
2.

where :PeriodFrom < R.ACCTSTARTTIME
and case when R.ACCTSTOPTIME=DATE'1970-01-01' then :PeriodTo-1 else ACCTSTOPTIME end < :PeriodTo

как это условие сработает?
Набор строк отфильтруется по индексированному ACCTSTARTTIME и к результату применится вторая проверка?
Или я получу full scan?

...

Рейтинг:

0 / 0

06.10.2016, 15:57

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39322070

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Alibek B.Если я напишу так:
Напутал.

Код: plsql

1.
2.

where R.ACCTSTARTTIME < :PeriodTo
and :PeriodFrom < case when R.ACCTSTOPTIME=DATE'1970-01-01' then :PeriodFrom+1 else ACCTSTOPTIME end

...

Рейтинг:

0 / 0

06.10.2016, 16:01

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39322089

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Если без добавления индекса на ACCTSTOPTIME никак не обойтись, то посоветуйте, как его добавить, чтобы не помешать работе сервера и приложений? Или просто добавить, а сервер сам разберется?
И можно ли индекс добавить таким образом, чтобы значение TIMESTAMP'1970-01-01 03:00:00' интерпретировалось как специальное, которое больше любого другого?

...

Рейтинг:

0 / 0

06.10.2016, 16:16

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39322124

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Сделал так:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.

CREATE TABLE TEST_RADACCT
(
  RADACCTID              NUMBER                 NOT NULL,
  AP_ID                  NUMBER                 NOT NULL,
  ACCTSESSIONID          VARCHAR2(255 BYTE)     NOT NULL,
  ACCTSTARTTIME          DATE                   NOT NULL,
  ACCTSTOPTIME           DATE                   NOT NULL,
  USERNAME               VARCHAR2(255 BYTE),
  REALM                  VARCHAR2(255 BYTE),
  NASPORTID              NUMBER,
  NASPORTTYPE            VARCHAR2(255 BYTE),
  ACCTSESSIONTIME        NUMBER,
  ACCTAUTHENTIC          VARCHAR2(255 BYTE),
  CONNECTINFO            VARCHAR2(255 BYTE),
  ACCTINPUTOCTETS        NUMBER,
  ACCTOUTPUTOCTETS       NUMBER,
  CALLEDSTATIONID        VARCHAR2(255 BYTE),
  CALLINGSTATIONID       VARCHAR2(255 BYTE),
  ACCTTERMINATECAUSE     VARCHAR2(255 BYTE),
  SERVICETYPE            VARCHAR2(255 BYTE),
  FRAMEDPROTOCOL         VARCHAR2(255 BYTE),
  FRAMEDIPADDRESS        VARCHAR2(255 BYTE),
  ACCTSTARTDELAY         NUMBER,
  ACCTSTOPDELAY          NUMBER,
  CISCO_NAS_PORT         VARCHAR2(255 BYTE),
  DNIS                   VARCHAR2(255 BYTE),
  H323_CALL_ORIGIN       VARCHAR2(255 BYTE),
  H323_CALL_TYPE         VARCHAR2(255 BYTE),
  H323_GW_ID             VARCHAR2(255 BYTE),
  H323_DISCONNECT_CAUSE  NUMBER,
  H323_VOICE_QUALITY     NUMBER,
  H323_REMOTE_ADDRESS    VARCHAR2(255 BYTE),
  H323_CONF_ID           VARCHAR2(255 BYTE),
  CIRCUIT_ID_TAG         VARCHAR2(255 BYTE),
  CLIENT_MAC_ADDRESS     VARCHAR2(250 BYTE)
);
CREATE UNIQUE INDEX RADACCT_PK ON TEST_RADACCT (RADACCTID);
CREATE INDEX RADACCT_ACCTSTARTTIME_IDX ON TEST_RADACCT (ACCTSTARTTIME);
CREATE INDEX RADACCT_ACCTSTOPTIME_IDX ON TEST_RADACCT (DECODE("ACCTSTOPTIME",TO_DATE(' 1970-01-01 03:00:00', 'syyyy-mm-dd hh24:mi:ss'),TO_DATE(' 9999-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),"ACCTSTOPTIME"));

Insert into CYBERCOM.TEST_RADACCT
   (RADACCTID, AP_ID, ACCTSESSIONID, ACCTSTARTTIME, ACCTSTOPTIME, USERNAME, ACCTAUTHENTIC, FRAMEDIPADDRESS)
 Values
   (1, 1, '123', TO_DATE('10/02/2016 00:00:00', 'MM/DD/YYYY HH24:MI:SS'), TO_DATE('01/01/1970 03:00:00', 'MM/DD/YYYY HH24:MI:SS'), 
    'test', 'RADIUS', '1.2.3.4');
Insert into CYBERCOM.TEST_RADACCT
   (RADACCTID, AP_ID, ACCTSESSIONID, ACCTSTARTTIME, ACCTSTOPTIME, USERNAME, ACCTAUTHENTIC, FRAMEDIPADDRESS)
 Values
   (2, 1, '456', TO_DATE('10/03/2016 07:00:00', 'MM/DD/YYYY HH24:MI:SS'), TO_DATE('10/03/2016 21:59:59', 'MM/DD/YYYY HH24:MI:SS'), 
    'test', 'RADIUS', '1.2.3.4');

Выполняю запрос:

Код: plsql

1.
2.
3.

select *
from TEST_RADACCT R
where R.ACCTSTARTTIME < DATE'2016-10-10' and R.ACCTSTOPTIME > DATE'2016-10-01'

Получаю одну строку, с RADACCTID=2.
А почему не выводится RADACCTID=1? Или function-based-index это что-то другое?

...

Рейтинг:

0 / 0

06.10.2016, 16:38

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39322129

ora601

Участник

Сообщения: 785

Рейтинг: 0 / 0

Alibek B.,

У тебя более 500 сообщений в ветке оракл, Но ты так и не понял , что для того чтобы тебе обьяснили почему что то тормозит, нужно выкладывать больше информации, чем голый explain ? Там же даже нет таймингов . Выкладывай план с рантайм статистиками или ткпроф, тогда можно будет предметно что то ответить)

...

Рейтинг:

0 / 0

06.10.2016, 16:42

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39322168

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Понял, сделаю.
А по плану каких-то очевидных проблем нет?

...

Рейтинг:

0 / 0

06.10.2016, 17:12

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323051

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Наконец удалось сделать трассировку.
Кстати, теперь последний запрос с группировкой выполняется 3-5 секунд, что приемлемо.
Но результаты трассировки прилагаю.

Код: plaintext

TKPROF: Release 10.2.0.4.0 - Production on Пт Окт 7 20:35:15 2016

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Trace file: billing_ora_14695_alibek.trc
Sort options: default

********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

declare  cursor NlsParamsCursor is    SELECT * FROM 
  nls_session_parameters;begin  SELECT Nvl(Lengthb(Chr(65536)), 
  Nvl(Lengthb(Chr(256)), 1))    INTO :CharLength FROM dual;  for NlsRecord in 
  NlsParamsCursor loop    if NlsRecord.parameter = 'NLS_DATE_LANGUAGE' then   
     :NlsDateLanguage := NlsRecord.value;    elsif NlsRecord.parameter = 
  'NLS_DATE_FORMAT' then      :NlsDateFormat := NlsRecord.value;    elsif 
  NlsRecord.parameter = 'NLS_NUMERIC_CHARACTERS' then      
  :NlsNumericCharacters := NlsRecord.value;    elsif NlsRecord.parameter = 
  'NLS_TIMESTAMP_FORMAT' then      :NlsTimeStampFormat := NlsRecord.value;    
  elsif NlsRecord.parameter = 'NLS_TIMESTAMP_TZ_FORMAT' then      
  :NlsTimeStampTZFormat := NlsRecord.value;    end if;  end loop;end;


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       15      0.00       0.00          0          0          0           0
Execute     15      0.00       0.00          0          0          0          15
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       30      0.00       0.00          0          0          0          15

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 59  
********************************************************************************

SELECT NVL(LENGTHB(CHR(65536)), NVL(LENGTHB(CHR(256)), 1)) 
FROM
 DUAL


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       15      0.00       0.00          0          0          0           0
Execute     16      0.00       0.00          0          0          0           0
Fetch       15      0.00       0.00          0          0          0          15
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       46      0.00       0.00          0          0          0          15

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 59     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=5 us)

********************************************************************************

SELECT * 
FROM
 NLS_SESSION_PARAMETERS


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       16      0.00       0.00          0          0          0           0
Execute     16      0.00       0.00          0          0          0           0
Fetch       15      0.00       0.00          0          0          0         255
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       47      0.00       0.00          0          0          0         255

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 59     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
     17  FIXED TABLE FULL X$NLS_PARAMETERS (cr=0 pr=0 pw=0 time=56 us)

********************************************************************************

BEGIN DBMS_OUTPUT.ENABLE(buffer_size => NULL); END;


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           1

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 59  
********************************************************************************

select PARAMETER,VALUE 
from
 nls_session_parameters where PARAMETER in('NLS_NUMERIC_CHARACTERS',
  'NLS_DATE_FORMAT','NLS_CURRENCY')


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        4      0.00       0.00          0          0          0           0
Execute      4      0.00       0.00          0          0          0           0
Fetch        4      0.00       0.00          0          0          0          12
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       12      0.00       0.00          0          0          0          12

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 59  

Rows     Row Source Operation
-------  ---------------------------------------------------
      3  FIXED TABLE FULL X$NLS_PARAMETERS (cr=0 pr=0 pw=0 time=43 us)

********************************************************************************

select to_char(9,'9C') 
from
 dual


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        4      0.00       0.00          0          0          0           0
Execute      4      0.00       0.00          0          0          0           0
Fetch        4      0.00       0.00          0          0          0           4
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       12      0.00       0.00          0          0          0           4

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 59  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=4 us)

********************************************************************************

alter session set timed_statistics=true


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0
Parsing user id: 59  
********************************************************************************

alter session set sql_trace = true


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0
Parsing user id: 59  
********************************************************************************

select R.RADACCTID, S.SERVICE_ID
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join BM_TARIFFEL T on (T.TARIFFEL_ID = B.TARIFFEL_ID and T.ZONE_ID is null)
join (select min(SEGMENT_ID) as SEGMENT_ID from BM_SEGMENT where IS_SYSTEM = 0 group by SCHEDULE_ID) P on (P.SEGMENT_ID = T.SEGMENT_ID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
where R.ACCTSTARTTIME >= date'2016-10-01'
and R.ACCTSTARTTIME < date'2016-10-10'
group by R.RADACCTID, S.SERVICE_ID
having count(*)>1

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     13.44      13.13          0    2267988          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3     13.45      13.14          0    2267988          0           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 59  

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  FILTER  (cr=2267988 pr=0 pw=0 time=13136645 us)
  12194   HASH GROUP BY (cr=2267988 pr=0 pw=0 time=13146082 us)
  12194    NESTED LOOPS  (cr=2267988 pr=0 pw=0 time=13147824 us)
  12194     HASH JOIN  (cr=2255792 pr=0 pw=0 time=13062439 us)
 230007      NESTED LOOPS  (cr=2255785 pr=0 pw=0 time=13110443 us)
 679015       NESTED LOOPS  (cr=897753 pr=0 pw=0 time=8148245 us)
 203016        TABLE ACCESS BY INDEX ROWID RADACCT (cr=104731 pr=0 pw=0 time=1218136 us)
 203016         INDEX RANGE SCAN RADACCT_ACCTSTARTTIME_IDX (cr=1119 pr=0 pw=0 time=204728 us)(object id 53923)
 679015        TABLE ACCESS BY INDEX ROWID BM_SERVICE_MONEY (cr=793022 pr=0 pw=0 time=4907734 us)
 679015         INDEX RANGE SCAN SVRM_RADACCT_IDX (cr=612568 pr=0 pw=0 time=2119085 us)(object id 54266)
 230007       TABLE ACCESS BY INDEX ROWID BM_TARIFFEL (cr=1358032 pr=0 pw=0 time=6626700 us)
 679015        INDEX UNIQUE SCAN TAREL_PK (cr=679017 pr=0 pw=0 time=3228171 us)(object id 53612)
      6      VIEW  (cr=7 pr=0 pw=0 time=559 us)
      6       HASH GROUP BY (cr=7 pr=0 pw=0 time=551 us)
     34        TABLE ACCESS FULL BM_SEGMENT (cr=7 pr=0 pw=0 time=69 us)
  12194     INDEX UNIQUE SCAN SERVICES_PK (cr=12196 pr=0 pw=0 time=53166 us)(object id 53750)

********************************************************************************

alter session set sql_trace = false


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0
Parsing user id: 59

Тайминги по каждой строчке плана я теперь увидел, но остальные моменты непонятны.
На что нужно обращать внимание, если запрос начнет тормозить? На cpu и disk?

И еще непонятно, почему в elapsed указано 13 секунд, запрос выполняется быстрее.

...

Рейтинг:

0 / 0

07.10.2016, 20:40

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323070

softwarer_

Гость

Alibek B.,

Меня только что выебли на работе, а ты про какие-то индексы тут говоришь!!

...

Рейтинг:

0 / 0

07.10.2016, 21:38

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323089

ззЩ

Гость

softwarer_Alibek B.,

Меня только что выебли на работе, а ты про какие-то индексы тут говоришь!!выебли то за индексы небось

...

Рейтинг:

0 / 0

07.10.2016, 22:24

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323102

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Помогите разобраться.

Есть такой запрос:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

select *
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join BM_TARIFFEL T on (T.TARIFFEL_ID = B.TARIFFEL_ID and T.ZONE_ID is null)
join (select min(SEGMENT_ID) as SEGMENT_ID from BM_SEGMENT where IS_SYSTEM = 0 group by SCHEDULE_ID) P on (P.SEGMENT_ID = T.SEGMENT_ID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
join CUSTOMERS C on (C.CUSTOMER_ID = S.CUSTOMER_ID)
join BM_GROUP CG on (CG.GROUP_ID = C.GROUP_ID)
join BM_CUSTOMER_TYPE CT on (CT.CUSTOMER_TYPE_ID = C.CUSTOMER_TYPE_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
left join BM_CUSTOMER_CONTACT CP on (CP.CUSTOMER_ID = C.CUSTOMER_ID and CP.CONTACT_DICT_ID = 6)
left join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
left join RADREPLY SR on (SR.SERVICE_ID = S.SERVICE_ID and SR.ATTRIBUTE = 'Framed-IP-Address' and SR.DATE_BEG <= sysdate and SR.DATE_END is null)
left join CURSESSIONS Z on (Z.SERVICE_ID = S.SERVICE_ID)
where C.GROUP_ID in (select ID from CYBERCOM.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and R.ACCTSTARTTIME >= date'2016-10-01'
and R.ACCTSTARTTIME < date'2016-10-10'

Выполняется вообщем быстро.

Стоит мне заменить select * на select C.CUSTOMER_ID, как запрос выполняется очень долго.
Сделать трассировку до конца не получилось - запрос выполнялся долго, я его прервал.

Код: plaintext

TKPROF: Release 10.2.0.4.0 - Production on Пт Окт 7 23:03:59 2016

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Trace file: billing_ora_16518_alibek.trc
Sort options: default

********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

select C.CUSTOMER_ID as ID
/*, CT.NAME as TYPE
, CC.VALUE as CLIENT
, CP.VALUE as PHONE
, CA.VALUE as ADDRESS
, S.SERVICE_ID as SERVICE_ID
, S.LOGIN as SERVICE_LOGIN
, SR.VALUE as SERVICE_IP
, Z.CURSESSIONS_ID as SESSION_ID
, R.ACCTSESSIONID as SESSION_KEY
, R.ACCTSTARTTIME as SESSION_START
, decode(R.ACCTSTOPTIME, to_date('1970-01-01 03:00:00','yyyy-mm-dd hh24:mi:ss'), null, R.ACCTSTOPTIME) as SESSION_STOP
, R.ACCTSESSIONTIME as SESSION_TIME
, R.ACCTINPUTOCTETS as SESSION_DL
, R.ACCTOUTPUTOCTETS as SESSION_UL
, R.ACCTTERMINATECAUSE as SESSION_TERMINATE
, R.CALLINGSTATIONID as PORT
, R.FRAMEDIPADDRESS as IP
, R.CLIENT_MAC_ADDRESS as MAC*/
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join BM_TARIFFEL T on (T.TARIFFEL_ID = B.TARIFFEL_ID and T.ZONE_ID is null)
join (select min(SEGMENT_ID) as SEGMENT_ID from BM_SEGMENT where IS_SYSTEM = 0 group by SCHEDULE_ID) P on (P.SEGMENT_ID = T.SEGMENT_ID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
join CUSTOMERS C on (C.CUSTOMER_ID = S.CUSTOMER_ID)
join BM_GROUP CG on (CG.GROUP_ID = C.GROUP_ID)
join BM_CUSTOMER_TYPE CT on (CT.CUSTOMER_TYPE_ID = C.CUSTOMER_TYPE_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
left join BM_CUSTOMER_CONTACT CP on (CP.CUSTOMER_ID = C.CUSTOMER_ID and CP.CONTACT_DICT_ID = 6)
left join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
left join RADREPLY SR on (SR.SERVICE_ID = S.SERVICE_ID and SR.ATTRIBUTE = 'Framed-IP-Address' and SR.DATE_BEG <= sysdate and SR.DATE_END is null)
left join CURSESSIONS Z on (Z.SERVICE_ID = S.SERVICE_ID)
where C.GROUP_ID in (select ID from TEMP.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and R.ACCTSTARTTIME >= date'2016-10-01'
and R.ACCTSTARTTIME < date'2016-10-10'

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        4      0.16       0.17          0          0          0           0
Execute      2      0.00       0.01          0          0          0           0
Fetch        2     58.67     105.22     874784    1134203          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        8     58.84     105.41     874784    1134203          0           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 59  

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  HASH JOIN RIGHT OUTER (cr=0 pr=0 pw=0 time=13 us)
   3159   INDEX FAST FULL SCAN CURSESS_SERVICE_IDX (cr=55 pr=0 pw=0 time=3231 us)(object id 53931)
      0   HASH JOIN RIGHT OUTER (cr=0 pr=0 pw=0 time=7 us)
     95    TABLE ACCESS FULL RADREPLY (cr=1887 pr=0 pw=0 time=218386 us)
      0    HASH JOIN  (cr=0 pr=0 pw=0 time=44 us)
 205192     TABLE ACCESS BY INDEX ROWID RADACCT (cr=105749 pr=0 pw=0 time=1026037 us)
 205192      INDEX RANGE SCAN RADACCT_ACCTSTARTTIME_IDX (cr=1132 pr=0 pw=0 time=206965 us)(object id 53923)
1089857     HASH JOIN  (cr=232446 pr=192183 pw=0 time=22982138 us)
      6      VIEW  (cr=7 pr=0 pw=0 time=580 us)
      6       HASH GROUP BY (cr=7 pr=0 pw=0 time=564 us)
     34        TABLE ACCESS FULL BM_SEGMENT (cr=7 pr=0 pw=0 time=112 us)
5860167      HASH JOIN  (cr=232439 pr=192183 pw=0 time=23534544 us)
  61893       TABLE ACCESS FULL BM_TARIFFEL (cr=1480 pr=0 pw=0 time=61912 us)
17196048       HASH JOIN  (cr=230959 pr=192183 pw=0 time=34453965 us)
  29573        HASH JOIN  (cr=2070 pr=0 pw=0 time=116491 us)
   6842         INDEX FAST FULL SCAN CUSTOMER_CONTACT_IDX (cr=376 pr=0 pw=0 time=6882 us)(object id 53716)
  29574         HASH JOIN  (cr=1694 pr=0 pw=0 time=50275 us)
   4702          HASH JOIN OUTER (cr=815 pr=0 pw=0 time=23124 us)
   4702           HASH JOIN OUTER (cr=439 pr=0 pw=0 time=15025 us)
   4702            HASH JOIN  (cr=63 pr=0 pw=0 time=5498 us)
      4             INDEX RANGE SCAN IDGROUPS_PK (cr=2 pr=0 pw=0 time=32 us)(object id 114658)
   9757             TABLE ACCESS FULL CUSTOMERS (cr=61 pr=0 pw=0 time=9789 us)
   6247            INDEX FAST FULL SCAN CUSTOMER_CONTACT_IDX (cr=376 pr=0 pw=0 time=6269 us)(object id 53716)
   6544           INDEX FAST FULL SCAN CUSTOMER_CONTACT_IDX (cr=376 pr=0 pw=0 time=6568 us)(object id 53716)
  47731          TABLE ACCESS FULL SERVICES (cr=879 pr=0 pw=0 time=47755 us)
25310105        TABLE ACCESS FULL BM_SERVICE_MONEY (cr=228889 pr=192183 pw=0 time=25310142 us)

********************************************************************************

alter session set sql_trace = false


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0
Parsing user id: 59

explain plan отличаются сильно:

select *

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.

SELECT STATEMENT  ALL_ROWSCost: 1 013 320  Bytes: 22 146 948  Cardinality: 20 854  																
	31 HASH JOIN RIGHT OUTER  Cost: 1 013 320  Bytes: 22 146 948  Cardinality: 20 854  															
		1 TABLE ACCESS FULL TABLE CURSESSIONS Cost: 24  Bytes: 383 760  Cardinality: 3 280  														
		30 HASH JOIN RIGHT OUTER  Cost: 1 013 295  Bytes: 19 707 030  Cardinality: 20 854  														
			2 TABLE ACCESS FULL TABLE RADREPLY Cost: 417  Bytes: 11 098  Cardinality: 179  													
			29 HASH JOIN  Cost: 1 012 877  Bytes: 18 414 082  Cardinality: 20 854  													
				5 VIEW  Cost: 4  Bytes: 91  Cardinality: 7  												
					4 HASH GROUP BY  Cost: 4  Bytes: 126  Cardinality: 7  											
						3 TABLE ACCESS FULL TABLE BM_SEGMENT Cost: 3  Bytes: 612  Cardinality: 34  										
				28 HASH JOIN  Cost: 1 012 872  Bytes: 106 265 280  Cardinality: 122 144  												
					6 TABLE ACCESS FULL TABLE BM_GROUP Cost: 3  Bytes: 1 936  Cardinality: 16  											
					27 HASH JOIN  Cost: 1 012 867  Bytes: 91 485 856  Cardinality: 122 144  											
						7 TABLE ACCESS FULL TABLE BM_TARIFFEL Cost: 334  Bytes: 7 434 063  Cardinality: 63 539  										
						26 HASH JOIN  Cost: 1 008 444  Bytes: 76 726 064  Cardinality: 121 402  										
							8 TABLE ACCESS FULL TABLE BM_CUSTOMER_CONTACT Cost: 194  Bytes: 253 584  Cardinality: 7 044  									
							25 HASH JOIN RIGHT OUTER  Cost: 1 008 248  Bytes: 95 329 008  Cardinality: 159 948  									
								9 TABLE ACCESS FULL TABLE BM_CUSTOMER_CONTACT Cost: 194  Bytes: 223 272  Cardinality: 6 202  								
								24 HASH JOIN RIGHT OUTER  Cost: 1 008 053  Bytes: 89 570 880  Cardinality: 159 948  								
									10 TABLE ACCESS FULL TABLE BM_CUSTOMER_CONTACT Cost: 194  Bytes: 214 236  Cardinality: 5 951  							
									23 HASH JOIN  Cost: 1 007 857  Bytes: 83 812 752  Cardinality: 159 948  							
										11 TABLE ACCESS FULL TABLE BM_CUSTOMER_TYPE Cost: 3  Bytes: 351  Cardinality: 9  						
										22 HASH JOIN  Cost: 1 007 852  Bytes: 77 574 780  Cardinality: 159 948  						
											12 INDEX RANGE SCAN INDEX (UNIQUE) TEMP.IDGROUPS_PK Cost: 2  Bytes: 72  Cardinality: 4  					
											21 HASH JOIN  Cost: 1 007 831  Bytes: 1 319 727 523  Cardinality: 2 825 969  					
												13 TABLE ACCESS FULL TABLE CUSTOMERS Cost: 14  Bytes: 336 245  Cardinality: 9 607  				
												20 HASH JOIN  Cost: 1 007 797  Bytes: 1 220 850 576  Cardinality: 2 826 043  				
													14 TABLE ACCESS FULL TABLE SERVICES Cost: 195  Bytes: 6 777 802  Cardinality: 47 731  			
													19 TABLE ACCESS BY INDEX ROWID TABLE BM_SERVICE_MONEY Cost: 6  Bytes: 896  Cardinality: 14  			
														18 NESTED LOOPS  Cost: 966 858  Bytes: 819 552 470  Cardinality: 2 826 043  		
															16 TABLE ACCESS BY INDEX ROWID TABLE RADACCT Cost: 128 678  Bytes: 45 610 190  Cardinality: 201 815  	
																15 INDEX RANGE SCAN INDEX RADACCT_ACCTSTARTTIME_IDX Cost: 1 015  Cardinality: 201 815  
															17 INDEX RANGE SCAN INDEX SVRM_RADACCT_IDX Cost: 3  Cardinality: 14

select C.CUSTOMER_ID

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.

SELECT STATEMENT  ALL_ROWSCost: 728 303  Bytes: 3 576 474  Cardinality: 22 077  												
	26 HASH JOIN RIGHT OUTER  Cost: 728 303  Bytes: 3 576 474  Cardinality: 22 077  											
		1 INDEX FAST FULL SCAN INDEX CURSESS_SERVICE_IDX Cost: 11  Bytes: 16 400  Cardinality: 3 280  										
		25 HASH JOIN RIGHT OUTER  Cost: 728 291  Bytes: 3 466 089  Cardinality: 22 077  										
			2 TABLE ACCESS FULL TABLE RADREPLY Cost: 417  Bytes: 5 728  Cardinality: 179  									
			24 HASH JOIN  Cost: 727 873  Bytes: 2 759 625  Cardinality: 22 077  									
				4 TABLE ACCESS BY INDEX ROWID TABLE RADACCT Cost: 128 670  Bytes: 2 825 410  Cardinality: 201 815  								
					3 INDEX RANGE SCAN INDEX RADACCT_ACCTSTARTTIME_IDX Cost: 1 015  Cardinality: 201 815  							
				23 HASH JOIN  Cost: 586 042  Bytes: 245 790 630  Cardinality: 2 214 330  								
					7 VIEW  Cost: 4  Bytes: 91  Cardinality: 7  							
						6 HASH GROUP BY  Cost: 4  Bytes: 126  Cardinality: 7  						
							5 TABLE ACCESS FULL TABLE BM_SEGMENT Cost: 3  Bytes: 612  Cardinality: 34  					
					22 HASH JOIN  Cost: 585 951  Bytes: 1 271 025 210  Cardinality: 12 969 645  							
						8 TABLE ACCESS FULL TABLE BM_TARIFFEL Cost: 332  Bytes: 698 929  Cardinality: 63 539  						
						21 HASH JOIN  Cost: 585 531  Bytes: 1 121 502 732  Cardinality: 12 890 836  						
							19 HASH JOIN  Cost: 383  Bytes: 151 514  Cardinality: 2 134  					
								9 INDEX FAST FULL SCAN INDEX CUSTOMER_CONTACT_IDX Cost: 57  Bytes: 63 396  Cardinality: 7 044  				
								18 HASH JOIN  Cost: 326  Bytes: 173 786  Cardinality: 2 803  				
									16 HASH JOIN OUTER  Cost: 131  Bytes: 28 288  Cardinality: 544  			
										14 HASH JOIN OUTER  Cost: 74  Bytes: 23 392  Cardinality: 544  		
											12 HASH JOIN  Cost: 17  Bytes: 18 496  Cardinality: 544  	
												10 INDEX RANGE SCAN INDEX (UNIQUE) TEMP.IDGROUPS_PK Cost: 2  Bytes: 72  Cardinality: 4  
												11 TABLE ACCESS FULL TABLE CUSTOMERS Cost: 14  Bytes: 153 712  Cardinality: 9 607  
											13 INDEX FAST FULL SCAN INDEX CUSTOMER_CONTACT_IDX Cost: 57  Bytes: 53 559  Cardinality: 5 951  	
										15 INDEX FAST FULL SCAN INDEX CUSTOMER_CONTACT_IDX Cost: 57  Bytes: 55 818  Cardinality: 6 202  		
									17 TABLE ACCESS FULL TABLE SERVICES Cost: 194  Bytes: 477 310  Cardinality: 47 731  			
							20 TABLE ACCESS FULL TABLE BM_SERVICE_MONEY Cost: 583 260  Bytes: 4 535 191 088  Cardinality: 283 449 443

На мой взгляд, второй запрос должен быть быстрее.

...

Рейтинг:

0 / 0

07.10.2016, 23:11

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323104

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Код: plsql

1.
2.

and R.ACCTSTARTTIME >= date'2016-10-01'
and R.ACCTSTARTTIME < date'2016-10-10'

Здесь я ограничиваю список сессий периодом с 2016-10-01 по 2016-10-10.
Если я указываю период с 2016-10-03 по 2016-10-10, то запрос (select C.CUSTOMER_ID) выполняется быстро (150мс), возвращается около 9к строк.
Если я указываю период на день раньше (с 2016-10-02 по 2016-10-10), то этот же запрос выполняется очень долго.
Если я указываю период с 2016-10-03 по 2016-10-15, то запрос снова выполняется быстро.

То есть запрос начинает тормозить, если я пытаюсь выбрать данные до 2016-10-03.
Таблица RADACCT не партиционирована.

...

Рейтинг:

0 / 0

07.10.2016, 23:23

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323133

Sayan Malakshinov

Модератор форума

Откуда: Мск

Сообщения: 5 731

Рейтинг: 0 / 0

Alibek B.

Код: plsql

ACCTSTARTTIME

Покажи результат:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.

select 
     h.owner
   , h.table_name
   , h.column_name
   , c.data_type
   , case 
          when c.data_type='DATE' or c.data_type like 'TIMESTAMP%'
               then to_char(
                         to_date(
                                to_char(h.endpoint_value,'FM99999999') 
                                || '.' 
                                || to_char(86400 * mod(h.endpoint_value,1),'FM99999')
                              ,'J.sssss'
                              )
                        ,'yyyy-mm-dd'
                         )
          when c.data_type in ('FLOAT','NUMBER')
               then to_char(endpoint_value,'tm9')
          when c.data_type in ('CHAR','VARCHAR2','NVARCHAR2')
               then --'use histograms_xml instead'
                    chr(to_number(substr(ltrim(to_char(endpoint_value,'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')), 1,2),'XX'))
                 || chr(to_number(substr(ltrim(to_char(endpoint_value,'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')), 3,2),'XX'))
                 || chr(to_number(substr(ltrim(to_char(endpoint_value,'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')), 5,2),'XX'))
                 || chr(to_number(substr(ltrim(to_char(endpoint_value,'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')), 7,2),'XX'))
                 || chr(to_number(substr(ltrim(to_char(endpoint_value,'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')), 9,2),'XX'))
                 || chr(to_number(substr(ltrim(to_char(endpoint_value,'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')),11,2),'XX'))
          else 'unsupporteed'
     end as ep_value
   , h.endpoint_value
   , h.endpoint_value  - lag(h.endpoint_value ,1,0) over(partition by h.owner,h.table_name,h.column_name order by h.endpoint_value) as delta_values
   , h.endpoint_number
   , h.endpoint_number - lag(h.endpoint_number,1,0) over(partition by h.owner,h.table_name,h.column_name order by h.endpoint_value) as delta_numbers
   , h.endpoint_actual_value
from 
     dba_tab_histograms h
   , dba_tab_columns c
where 
/*     h.owner       like nvl2('&3',upper('&1'),'%')
 and h.table_name  =    nvl2('&3',upper('&2'),upper('&1'))
 and h.column_name like nvl2('&3',upper('&3'),upper('&2'))*/
 h.owner=user and h.table_name='RADACCT' and h.column_name='ACCTSTARTTIME'
 and h.owner       = c.owner
 and h.table_name  = c.table_name
 and h.column_name = c.column_name
order by  h.owner
        , h.table_name
        , h.column_name
        , c.data_type
        , h.endpoint_number
/

зы. простой и не очень надежный вариант: дропни гистограммы по этому полю, выстави high_value у него в 2020-01-01 и зафиксируй статистику :)

...

Рейтинг:

0 / 0

08.10.2016, 00:49

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323179

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

xtenderПокажи результат

OWNERTABLE_NAMECOLUMN_NAMEDATA_TYPEEP_VALUEENDPOINT_VALUEDELTA_VALUESENDPOINT_NUMBERDELTA_NUMBERSENDPOINT_ACTUAL_VALUEBILLINGRADACCTACCTSTARTTIMEDATE2010-03-272455282,52531252455282,525312500BILLINGRADACCTACCTSTARTTIMEDATE2011-03-042455625,03247685342,5071643511BILLINGRADACCTACCTSTARTTIMEDATE2011-05-222455704,4774305679,4449537121BILLINGRADACCTACCTSTARTTIMEDATE2011-07-262455768,8397916764,3623611131BILLINGRADACCTACCTSTARTTIMEDATE2011-09-182455823,4604166754,62062541BILLINGRADACCTACCTSTARTTIMEDATE2011-11-062455872,3512268548,8908101851BILLINGRADACCTACCTSTARTTIMEDATE2011-12-142455909,7198958337,3686689861BILLINGRADACCTACCTSTARTTIMEDATE2012-01-202455946,8029166737,0830208471BILLINGRADACCTACCTSTARTTIMEDATE2012-02-212455978,8554050932,0524884281BILLINGRADACCTACCTSTARTTIMEDATE2012-03-212456007,5419560228,6865509391BILLINGRADACCTACCTSTARTTIMEDATE2012-04-142456031,8849768524,34302083101BILLINGRADACCTACCTSTARTTIMEDATE2012-05-122456060,0000810228,11510417111BILLINGRADACCTACCTSTARTTIMEDATE2012-06-102456088,843796328,84371528121BILLINGRADACCTACCTSTARTTIMEDATE2012-07-062456115,0058564826,16206018131BILLINGRADACCTACCTSTARTTIMEDATE2012-08-012456140,9687615725,96290509141BILLINGRADACCTACCTSTARTTIMEDATE2012-08-262456165,7832523124,81449074151BILLINGRADACCTACCTSTARTTIMEDATE2012-09-202456191,0000810225,21682871161BILLINGRADACCTACCTSTARTTIMEDATE2012-10-132456213,9338657422,93378472171BILLINGRADACCTACCTSTARTTIMEDATE2012-10-302456230,5295486116,59568287181BILLINGRADACCTACCTSTARTTIMEDATE2012-11-172456248,7413078718,21175926191BILLINGRADACCTACCTSTARTTIMEDATE2012-12-012456262,8524189814,11111111201BILLINGRADACCTACCTSTARTTIMEDATE2012-12-162456278,1043171315,25189815211BILLINGRADACCTACCTSTARTTIMEDATE2013-01-012456294,3334259316,2291088221BILLINGRADACCTACCTSTARTTIMEDATE2013-01-222456314,801562520,46813657231BILLINGRADACCTACCTSTARTTIMEDATE2013-02-202456343,599062528,7975241BILLINGRADACCTACCTSTARTTIMEDATE2013-03-042456356,2352199112,63615741251BILLINGRADACCTACCTSTARTTIMEDATE2013-03-172456368,7636458312,52842592261BILLINGRADACCTACCTSTARTTIMEDATE2013-03-292456380,9609143512,19726852271BILLINGRADACCTACCTSTARTTIMEDATE2013-04-092456392,4132870411,45237269281BILLINGRADACCTACCTSTARTTIMEDATE2013-04-202456403,4364351911,02314815291BILLINGRADACCTACCTSTARTTIMEDATE2013-05-022456414,7455555611,30912037301BILLINGRADACCTACCTSTARTTIMEDATE2013-05-112456424,359560199,61400463311BILLINGRADACCTACCTSTARTTIMEDATE2013-05-212456434,187939829,82837963321BILLINGRADACCTACCTSTARTTIMEDATE2013-05-312456444,3544791710,16653935331BILLINGRADACCTACCTSTARTTIMEDATE2013-06-102456454,265150469,91067129341BILLINGRADACCTACCTSTARTTIMEDATE2013-06-202456463,823368069,5582176351BILLINGRADACCTACCTSTARTTIMEDATE2013-06-292456473,16339129,34002314361BILLINGRADACCTACCTSTARTTIMEDATE2013-07-082456482,118831028,95543982371BILLINGRADACCTACCTSTARTTIMEDATE2013-07-172456490,848784728,7299537381BILLINGRADACCTACCTSTARTTIMEDATE2013-07-252456499,227222228,3784375391BILLINGRADACCTACCTSTARTTIMEDATE2013-08-032456508,342557879,11533565401BILLINGRADACCTACCTSTARTTIMEDATE2013-08-132456518,379733810,03717593411BILLINGRADACCTACCTSTARTTIMEDATE2013-08-222456527,166967598,78723379421BILLINGRADACCTACCTSTARTTIMEDATE2013-08-302456535,267789358,10082176431BILLINGRADACCTACCTSTARTTIMEDATE2013-09-082456544,152372698,88458334441BILLINGRADACCTACCTSTARTTIMEDATE2013-09-152456551,228414357,07604166451BILLINGRADACCTACCTSTARTTIMEDATE2013-09-232456559,168472227,94005787461BILLINGRADACCTACCTSTARTTIMEDATE2013-10-012456566,867013897,69854167471BILLINGRADACCTACCTSTARTTIMEDATE2013-10-092456575,058055568,19104167481BILLINGRADACCTACCTSTARTTIMEDATE2013-10-172456582,681724547,62366898491BILLINGRADACCTACCTSTARTTIMEDATE2013-10-242456590,204664357,52293981501BILLINGRADACCTACCTSTARTTIMEDATE2013-11-012456598,36723388,16256945511BILLINGRADACCTACCTSTARTTIMEDATE2013-11-102456606,641087968,27385416521BILLINGRADACCTACCTSTARTTIMEDATE2013-11-172456614,175613437,53452547531BILLINGRADACCTACCTSTARTTIMEDATE2013-11-242456621,098576396,92296296541BILLINGRADACCTACCTSTARTTIMEDATE2013-12-012456628,185694447,08711805551BILLINGRADACCTACCTSTARTTIMEDATE2013-12-092456636,080335657,89464121561BILLINGRADACCTACCTSTARTTIMEDATE2013-12-152456642,261192136,18085648571BILLINGRADACCTACCTSTARTTIMEDATE2013-12-222456648,947314816,68612268581BILLINGRADACCTACCTSTARTTIMEDATE2013-12-282456655,203981486,25666667591BILLINGRADACCTACCTSTARTTIMEDATE2014-01-042456661,998645836,79466435601BILLINGRADACCTACCTSTARTTIMEDATE2014-01-112456668,633055566,63440973611BILLINGRADACCTACCTSTARTTIMEDATE2014-01-182456675,825497697,19244213621BILLINGRADACCTACCTSTARTTIMEDATE2014-01-252456683,057152787,23165509631BILLINGRADACCTACCTSTARTTIMEDATE2014-02-022456691,374548618,31739583641BILLINGRADACCTACCTSTARTTIMEDATE2014-02-092456698,260844916,8862963651BILLINGRADACCTACCTSTARTTIMEDATE2014-02-172456706,103252327,84240741661BILLINGRADACCTACCTSTARTTIMEDATE2014-02-242456712,837337966,73408564671BILLINGRADACCTACCTSTARTTIMEDATE2014-03-032456719,629155096,79181713681BILLINGRADACCTACCTSTARTTIMEDATE2014-03-102456727,354629637,72547454691BILLINGRADACCTACCTSTARTTIMEDATE2014-03-182456735,44973388,09510417701BILLINGRADACCTACCTSTARTTIMEDATE2014-03-262456743,009988437,56025463711BILLINGRADACCTACCTSTARTTIMEDATE2014-04-032456751,073611118,06362268721BILLINGRADACCTACCTSTARTTIMEDATE2014-04-112456759,172337968,09872685731BILLINGRADACCTACCTSTARTTIMEDATE2014-04-192456766,515740747,34340278741BILLINGRADACCTACCTSTARTTIMEDATE2014-04-262456774,316666677,80092593751BILLINGRADACCTACCTSTARTTIMEDATE2014-05-052456783,310185198,99351852761BILLINGRADACCTACCTSTARTTIMEDATE2014-05-132456791,291979177,98179398771BILLINGRADACCTACCTSTARTTIMEDATE2014-05-202456798,427430567,13545139781BILLINGRADACCTACCTSTARTTIMEDATE2014-05-282456806,262476857,83504629791BILLINGRADACCTACCTSTARTTIMEDATE2014-06-072456816,181111119,91863426801BILLINGRADACCTACCTSTARTTIMEDATE2014-06-152456824,291944448,11083333811BILLINGRADACCTACCTSTARTTIMEDATE2014-06-242456832,777534728,48559028821BILLINGRADACCTACCTSTARTTIMEDATE2014-07-032456842,159675939,38214121831BILLINGRADACCTACCTSTARTTIMEDATE2014-07-122456851,16004639,00037037841BILLINGRADACCTACCTSTARTTIMEDATE2014-07-132456852,427395831,26734953851BILLINGRADACCTACCTSTARTTIMEDATE2014-07-142456853,051898150,62450232861BILLINGRADACCTACCTSTARTTIMEDATE2014-07-152456854,227094911,17519676871BILLINGRADACCTACCTSTARTTIMEDATE2014-07-222456861,39093757,16384259881BILLINGRADACCTACCTSTARTTIMEDATE2014-07-302456869,176273157,78533565891BILLINGRADACCTACCTSTARTTIMEDATE2014-08-082456878,026388898,85011574901BILLINGRADACCTACCTSTARTTIMEDATE2014-08-162456886,198101858,17171296911BILLINGRADACCTACCTSTARTTIMEDATE2014-08-232456893,296257,09814815921BILLINGRADACCTACCTSTARTTIMEDATE2014-08-312456900,683333337,38708333931BILLINGRADACCTACCTSTARTTIMEDATE2014-09-082456909,289629638,6062963941BILLINGRADACCTACCTSTARTTIMEDATE2014-09-162456917,32589128,03626157951BILLINGRADACCTACCTSTARTTIMEDATE2014-09-232456924,222835656,89694445961BILLINGRADACCTACCTSTARTTIMEDATE2014-09-302456931,273530097,05069444971BILLINGRADACCTACCTSTARTTIMEDATE2014-10-082456939,20870377,93517361981BILLINGRADACCTACCTSTARTTIMEDATE2014-10-152456946,259224547,05052084991BILLINGRADACCTACCTSTARTTIMEDATE2014-10-222456953,164155096,904930551001BILLINGRADACCTACCTSTARTTIMEDATE2014-10-292456960,123321766,959166671011BILLINGRADACCTACCTSTARTTIMEDATE2014-11-062456968,359282418,235960651021BILLINGRADACCTACCTSTARTTIMEDATE2014-11-132456975,124224546,764942131031BILLINGRADACCTACCTSTARTTIMEDATE2014-11-192456981,054224545,931041BILLINGRADACCTACCTSTARTTIMEDATE2014-11-242456986,294050935,239826391051BILLINGRADACCTACCTSTARTTIMEDATE2014-11-302456992,162800935,868751061BILLINGRADACCTACCTSTARTTIMEDATE2014-12-082456999,725520837,56271991071BILLINGRADACCTACCTSTARTTIMEDATE2014-12-142457005,679537045,954016211081BILLINGRADACCTACCTSTARTTIMEDATE2014-12-202457012,312488436,632951391091BILLINGRADACCTACCTSTARTTIMEDATE2014-12-262457017,62307875,310590271101BILLINGRADACCTACCTSTARTTIMEDATE2015-01-012457023,66254636,03946761111BILLINGRADACCTACCTSTARTTIMEDATE2015-01-082457031,290613437,628067131121BILLINGRADACCTACCTSTARTTIMEDATE2015-01-152457038,121018526,830405091131BILLINGRADACCTACCTSTARTTIMEDATE2015-01-212457044,222361116,101342591141BILLINGRADACCTACCTSTARTTIMEDATE2015-01-282457051,188402786,966041671151BILLINGRADACCTACCTSTARTTIMEDATE2015-02-042457058,132418986,94401621161BILLINGRADACCTACCTSTARTTIMEDATE2015-02-112457064,954814826,822395841171BILLINGRADACCTACCTSTARTTIMEDATE2015-02-172457070,629282415,674467591181BILLINGRADACCTACCTSTARTTIMEDATE2015-02-222457076,330740745,701458331191BILLINGRADACCTACCTSTARTTIMEDATE2015-02-282457082,042025465,711284721201BILLINGRADACCTACCTSTARTTIMEDATE2015-03-062457088,106481486,064456021211BILLINGRADACCTACCTSTARTTIMEDATE2015-03-112457093,189027785,08254631221BILLINGRADACCTACCTSTARTTIMEDATE2015-03-152457097,204432874,015405091231BILLINGRADACCTACCTSTARTTIMEDATE2015-03-192457101,20714124,002708331241BILLINGRADACCTACCTSTARTTIMEDATE2015-03-242457106,11504634,90790511251BILLINGRADACCTACCTSTARTTIMEDATE2015-03-292457110,57942134,4643751261BILLINGRADACCTACCTSTARTTIMEDATE2015-04-032457116,024988435,445567131271BILLINGRADACCTACCTSTARTTIMEDATE2015-04-072457120,234745374,209756941281BILLINGRADACCTACCTSTARTTIMEDATE2015-04-112457124,240381944,005636571291BILLINGRADACCTACCTSTARTTIMEDATE2015-04-162457128,672037044,43165511301BILLINGRADACCTACCTSTARTTIMEDATE2015-04-192457132,480798613,808761571311BILLINGRADACCTACCTSTARTTIMEDATE2015-04-242457136,978379634,497581021321BILLINGRADACCTACCTSTARTTIMEDATE2015-04-282457141,096041674,117662041331BILLINGRADACCTACCTSTARTTIMEDATE2015-05-022457145,230347224,134305551341BILLINGRADACCTACCTSTARTTIMEDATE2015-05-072457149,543402784,313055561351BILLINGRADACCTACCTSTARTTIMEDATE2015-05-112457154,080763894,537361111361BILLINGRADACCTACCTSTARTTIMEDATE2015-05-152457158,210196764,129432871371BILLINGRADACCTACCTSTARTTIMEDATE2015-05-182457161,486122693,275925931381BILLINGRADACCTACCTSTARTTIMEDATE2015-05-222457165,104571763,618449071391BILLINGRADACCTACCTSTARTTIMEDATE2015-05-252457168,423460653,318888891401BILLINGRADACCTACCTSTARTTIMEDATE2015-05-292457172,037696763,614236111411BILLINGRADACCTACCTSTARTTIMEDATE2015-06-022457176,121400464,08370371421BILLINGRADACCTACCTSTARTTIMEDATE2015-06-062457180,090335653,968935191431BILLINGRADACCTACCTSTARTTIMEDATE2015-06-102457183,530532413,440196761441BILLINGRADACCTACCTSTARTTIMEDATE2015-06-132457187,232974543,702442131451BILLINGRADACCTACCTSTARTTIMEDATE2015-06-222457196,139745378,906770831461BILLINGRADACCTACCTSTARTTIMEDATE2015-06-262457200,029178243,889432871471BILLINGRADACCTACCTSTARTTIMEDATE2015-06-302457203,762083333,732905091481BILLINGRADACCTACCTSTARTTIMEDATE2015-07-042457208,195150464,433067131491BILLINGRADACCTACCTSTARTTIMEDATE2015-07-082457211,5581253,362974541501BILLINGRADACCTACCTSTARTTIMEDATE2015-07-112457214,836377313,278252311511BILLINGRADACCTACCTSTARTTIMEDATE2015-07-132457216,962256942,125879631521BILLINGRADACCTACCTSTARTTIMEDATE2015-07-162457219,78379632,821539361531BILLINGRADACCTACCTSTARTTIMEDATE2015-07-192457222,898194443,114398141541BILLINGRADACCTACCTSTARTTIMEDATE2015-07-222457226,303055563,404861121551BILLINGRADACCTACCTSTARTTIMEDATE2015-07-262457229,863634263,56057871561BILLINGRADACCTACCTSTARTTIMEDATE2015-07-302457233,750138893,886504631571BILLINGRADACCTACCTSTARTTIMEDATE2015-08-042457238,644664354,894525461581BILLINGRADACCTACCTSTARTTIMEDATE2015-08-082457243,11057874,465914351591BILLINGRADACCTACCTSTARTTIMEDATE2015-08-122457247,05129633,94071761601BILLINGRADACCTACCTSTARTTIMEDATE2015-08-162457250,936319443,885023141611BILLINGRADACCTACCTSTARTTIMEDATE2015-08-192457254,386805563,450486121621BILLINGRADACCTACCTSTARTTIMEDATE2015-08-232457258,138819443,752013881631BILLINGRADACCTACCTSTARTTIMEDATE2015-08-272457261,632685193,493865751641BILLINGRADACCTACCTSTARTTIMEDATE2015-08-302457265,241458333,608773141651BILLINGRADACCTACCTSTARTTIMEDATE2015-09-042457269,889942134,64848381661BILLINGRADACCTACCTSTARTTIMEDATE2015-09-072457273,246539353,356597221671BILLINGRADACCTACCTSTARTTIMEDATE2015-09-112457277,033645833,787106481681BILLINGRADACCTACCTSTARTTIMEDATE2015-09-162457282,161377315,127731481691BILLINGRADACCTACCTSTARTTIMEDATE2015-09-222457287,689039355,527662041701BILLINGRADACCTACCTSTARTTIMEDATE2015-09-252457291,07067133,381631951711BILLINGRADACCTACCTSTARTTIMEDATE2015-09-282457294,387476853,316805551721BILLINGRADACCTACCTSTARTTIMEDATE2015-10-032457298,640798614,253321761731BILLINGRADACCTACCTSTARTTIMEDATE2015-10-072457302,827731484,186932871741BILLINGRADACCTACCTSTARTTIMEDATE2015-10-102457306,348240743,520509261751BILLINGRADACCTACCTSTARTTIMEDATE2015-10-142457310,25339123,905150461761BILLINGRADACCTACCTSTARTTIMEDATE2015-10-182457314,226689813,973298611771BILLINGRADACCTACCTSTARTTIMEDATE2015-10-222457318,000104173,773414361781BILLINGRADACCTACCTSTARTTIMEDATE2015-10-252457321,12656253,126458331791BILLINGRADACCTACCTSTARTTIMEDATE2015-10-292457324,604907413,478344911801BILLINGRADACCTACCTSTARTTIMEDATE2015-11-012457327,989363433,384456021811BILLINGRADACCTACCTSTARTTIMEDATE2015-11-052457332,079849544,090486111821BILLINGRADACCTACCTSTARTTIMEDATE2015-11-082457335,44093753,361087961831BILLINGRADACCTACCTSTARTTIMEDATE2015-11-122457339,086631943,645694441841BILLINGRADACCTACCTSTARTTIMEDATE2015-11-162457342,808726853,722094911851BILLINGRADACCTACCTSTARTTIMEDATE2015-11-192457346,37718753,568460651861BILLINGRADACCTACCTSTARTTIMEDATE2015-11-232457350,269965283,892777781871BILLINGRADACCTACCTSTARTTIMEDATE2015-11-272457354,052210653,782245371881BILLINGRADACCTACCTSTARTTIMEDATE2015-12-012457357,501967593,449756941891BILLINGRADACCTACCTSTARTTIMEDATE2015-12-042457360,595277783,093310191901BILLINGRADACCTACCTSTARTTIMEDATE2015-12-072457364,195532413,600254631911BILLINGRADACCTACCTSTARTTIMEDATE2015-12-112457367,513587963,318055551921BILLINGRADACCTACCTSTARTTIMEDATE2015-12-142457371,29348383,779895841931BILLINGRADACCTACCTSTARTTIMEDATE2015-12-192457375,750960654,457476851941BILLINGRADACCTACCTSTARTTIMEDATE2015-12-232457379,97807874,227118051951BILLINGRADACCTACCTSTARTTIMEDATE2015-12-272457384,069050934,090972231961BILLINGRADACCTACCTSTARTTIMEDATE2015-12-312457388,067673613,998622681971BILLINGRADACCTACCTSTARTTIMEDATE2016-01-042457391,868680563,801006951981BILLINGRADACCTACCTSTARTTIMEDATE2016-01-082457396,147800934,279120371991BILLINGRADACCTACCTSTARTTIMEDATE2016-01-132457401,051550934,903752001BILLINGRADACCTACCTSTARTTIMEDATE2016-01-172457405,166157414,114606482011BILLINGRADACCTACCTSTARTTIMEDATE2016-01-222457409,810173614,64401622021BILLINGRADACCTACCTSTARTTIMEDATE2016-01-272457415,103541675,293368062031BILLINGRADACCTACCTSTARTTIMEDATE2016-02-012457420,289282415,185740742041BILLINGRADACCTACCTSTARTTIMEDATE2016-02-062457424,795023154,505740742051BILLINGRADACCTACCTSTARTTIMEDATE2016-02-102457429,351736114,556712962061BILLINGRADACCTACCTSTARTTIMEDATE2016-02-152457433,938819444,587083332071BILLINGRADACCTACCTSTARTTIMEDATE2016-02-192457437,928645833,989826392081BILLINGRADACCTACCTSTARTTIMEDATE2016-02-232457442,054675934,12603012091BILLINGRADACCTACCTSTARTTIMEDATE2016-02-272457446,184675934,132101BILLINGRADACCTACCTSTARTTIMEDATE2016-03-022457450,376527784,191851852111BILLINGRADACCTACCTSTARTTIMEDATE2016-03-062457454,460613434,084085652121BILLINGRADACCTACCTSTARTTIMEDATE2016-03-112457459,224155094,763541662131BILLINGRADACCTACCTSTARTTIMEDATE2016-03-162457464,071215284,847060192141BILLINGRADACCTACCTSTARTTIMEDATE2016-03-212457468,975844914,904629632151BILLINGRADACCTACCTSTARTTIMEDATE2016-03-262457474,320138895,344293982161BILLINGRADACCTACCTSTARTTIMEDATE2016-03-312457478,569131944,248993052171BILLINGRADACCTACCTSTARTTIMEDATE2016-04-042457483,079293984,510162042181BILLINGRADACCTACCTSTARTTIMEDATE2016-04-082457487,219490744,140196762191BILLINGRADACCTACCTSTARTTIMEDATE2016-04-122457491,195069443,97557872201BILLINGRADACCTACCTSTARTTIMEDATE2016-04-162457495,182418983,987349542211BILLINGRADACCTACCTSTARTTIMEDATE2016-04-202457499,190914354,008495372221BILLINGRADACCTACCTSTARTTIMEDATE2016-04-252457504,052974544,862060192231BILLINGRADACCTACCTSTARTTIMEDATE2016-04-302457508,98254634,929571762241BILLINGRADACCTACCTSTARTTIMEDATE2016-05-042457513,46004634,47752251BILLINGRADACCTACCTSTARTTIMEDATE2016-05-092457518,22218754,76214122261BILLINGRADACCTACCTSTARTTIMEDATE2016-05-142457522,853553244,631365742271BILLINGRADACCTACCTSTARTTIMEDATE2016-05-182457527,462060194,608506952281BILLINGRADACCTACCTSTARTTIMEDATE2016-05-232457531,911145834,449085642291BILLINGRADACCTACCTSTARTTIMEDATE2016-05-272457536,168738434,25759262301BILLINGRADACCTACCTSTARTTIMEDATE2016-06-012457541,260219915,091481482311BILLINGRADACCTACCTSTARTTIMEDATE2016-06-072457547,384131946,123912032321BILLINGRADACCTACCTSTARTTIMEDATE2016-06-142457553,861944446,47781252331BILLINGRADACCTACCTSTARTTIMEDATE2016-06-212457561,433757,571805562341BILLINGRADACCTACCTSTARTTIMEDATE2016-06-292457569,233865747,800115742351BILLINGRADACCTACCTSTARTTIMEDATE2016-07-052457574,83276625,598900462361BILLINGRADACCTACCTSTARTTIMEDATE2016-07-102457579,675138894,842372692371BILLINGRADACCTACCTSTARTTIMEDATE2016-07-142457584,068090284,392951392381BILLINGRADACCTACCTSTARTTIMEDATE2016-07-182457588,227048614,158958332391BILLINGRADACCTACCTSTARTTIMEDATE2016-07-232457592,511678244,284629632401BILLINGRADACCTACCTSTARTTIMEDATE2016-07-292457599,213634266,701956022411BILLINGRADACCTACCTSTARTTIMEDATE2016-08-052457605,97879636,765162042421BILLINGRADACCTACCTSTARTTIMEDATE2016-08-112457612,232824076,254027772431BILLINGRADACCTACCTSTARTTIMEDATE2016-08-172457617,586840285,354016212441BILLINGRADACCTACCTSTARTTIMEDATE2016-08-222457622,549965284,9631252451BILLINGRADACCTACCTSTARTTIMEDATE2016-08-272457628,259282415,709317132461BILLINGRADACCTACCTSTARTTIMEDATE2016-09-012457633,265162045,005879632471BILLINGRADACCTACCTSTARTTIMEDATE2016-09-062457637,568113434,302951392481BILLINGRADACCTACCTSTARTTIMEDATE2016-09-092457641,134351853,566238422491BILLINGRADACCTACCTSTARTTIMEDATE2016-09-122457644,471898153,33754632501BILLINGRADACCTACCTSTARTTIMEDATE2016-09-162457648,109826393,637928242511BILLINGRADACCTACCTSTARTTIMEDATE2016-09-232457655,011851856,902025462521BILLINGRADACCTACCTSTARTTIMEDATE2016-10-012457662,819965287,808113432531BILLINGRADACCTACCTSTARTTIMEDATE2016-10-082457669,879803247,059837962541

За исключением первой строки в остальном довольно равномерно.
Мне кажется, что дело тут не в индексах.
Если в select я указываю *, то запрос отрабатывает быстро. Если в select я указываю какое-то поле (любое, хоть C.CUSTOMER_ID, хоть R.RADACCTID), то запрос выполняется очень долго (его завершения я не дождался).

...

Рейтинг:

0 / 0

08.10.2016, 10:30

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323185

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Решил дождаться выполнения запроса, запрос выполнялся почти 7 минут.
Трассировка:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
342.
343.
344.
345.
346.
347.
348.
349.
350.
351.
352.
353.
354.
355.
356.
357.
358.
359.
360.
361.
362.
363.
364.
365.
366.
367.
368.
369.
370.
371.
372.
373.
374.
375.
376.
377.
378.
379.
380.
381.
382.
383.
384.
385.
386.
387.
388.
389.
390.
391.
392.
393.
394.
395.
396.
397.
398.
399.
400.
401.
402.
403.
404.
405.
406.
407.
408.
409.
410.
411.
412.
413.
414.
415.
416.
417.
418.
419.
420.
421.
422.
423.
424.
425.
426.
427.
428.
429.
430.
431.
432.
433.
434.
435.
436.
437.
438.
439.
440.
441.
442.
443.
444.
445.
446.
447.
448.
449.
450.
451.
452.
453.
454.
455.
456.
457.
458.
459.
460.
461.
462.
463.
464.
465.
466.
467.
468.
469.
470.
471.
472.
473.
474.
475.
476.
477.
478.
479.
480.
481.
482.
483.
484.
485.
486.
487.
488.
489.
490.
491.
492.
493.
494.
495.
496.
497.
498.
499.
500.
501.
502.
503.
504.
505.
506.
507.
508.
509.
510.
511.
512.
513.
514.
515.
516.
517.
518.
519.
520.
521.
522.
523.
524.
525.
526.
527.
528.
529.
530.
531.
532.
533.
534.
535.
536.
537.
538.
539.
540.
541.
542.
543.
544.
545.
546.
547.
548.
549.
550.
551.
552.
553.

TKPROF: Release 10.2.0.4.0 - Production on Сб Окт 8 11:23:06 2016

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Trace file: billing_ora_7260.trc
Sort options: default

********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

declare  cursor NlsParamsCursor is    SELECT * FROM 
  nls_session_parameters;begin  SELECT Nvl(Lengthb(Chr(65536)), 
  Nvl(Lengthb(Chr(256)), 1))    INTO :CharLength FROM dual;  for NlsRecord in 
  NlsParamsCursor loop    if NlsRecord.parameter = 'NLS_DATE_LANGUAGE' then   
     :NlsDateLanguage := NlsRecord.value;    elsif NlsRecord.parameter = 
  'NLS_DATE_FORMAT' then      :NlsDateFormat := NlsRecord.value;    elsif 
  NlsRecord.parameter = 'NLS_NUMERIC_CHARACTERS' then      
  :NlsNumericCharacters := NlsRecord.value;    elsif NlsRecord.parameter = 
  'NLS_TIMESTAMP_FORMAT' then      :NlsTimeStampFormat := NlsRecord.value;    
  elsif NlsRecord.parameter = 'NLS_TIMESTAMP_TZ_FORMAT' then      
  :NlsTimeStampTZFormat := NlsRecord.value;    end if;  end loop;end;


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        8      0.00       0.00          0          0          0           0
Execute      8      0.00       0.01          0          0          0           8
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       16      0.00       0.01          0          0          0           8

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 59  
********************************************************************************

SELECT NVL(LENGTHB(CHR(65536)), NVL(LENGTHB(CHR(256)), 1)) 
FROM
 DUAL


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        8      0.00       0.01          0          0          0           0
Execute      8      0.00       0.00          0          0          0           0
Fetch        8      0.00       0.00          0          0          0           8
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       24      0.00       0.01          0          0          0           8

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 59     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=5 us)

********************************************************************************

select text 
from
 view$ where rowid=:1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        3      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          3          6          0           3
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        9      0.00       0.01          3          6          0           3

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 2)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS BY USER ROWID VIEW$ (cr=1 pr=1 pw=0 time=35 us)

********************************************************************************

select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#, 
  sample_size, minimum, maximum, distcnt, lowval, hival, density, col#, 
  spare1, spare2, avgcln 
from
 hist_head$ where obj#=:1 and intcol#=:2


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.00       0.00          0          0          0           0
Execute     39      0.00       0.00          0          0          0           0
Fetch       39      0.00       0.01          2        113          0          35
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       80      0.00       0.01          2        113          0          35

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS   (recursive depth: 3)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=2 pr=0 pw=0 time=41 us)
      0   INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=36 us)(object id 257)

********************************************************************************

SELECT * 
FROM
 NLS_SESSION_PARAMETERS


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        8      0.00       0.00          0          0          0           0
Execute      8      0.00       0.00          0          0          0           0
Fetch        8      0.00       0.00          0          0          0         136
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       24      0.00       0.00          0          0          0         136

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 59     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
     17  FIXED TABLE FULL X$NLS_PARAMETERS (cr=0 pr=0 pw=0 time=40 us)

********************************************************************************

select PARAMETER,VALUE 
from
 nls_session_parameters where PARAMETER in('NLS_NUMERIC_CHARACTERS',
  'NLS_DATE_FORMAT','NLS_CURRENCY')


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.00       0.00          0          0          0           0
Execute      2      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          0          0           6
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        6      0.00       0.00          0          0          0           6

Misses in library cache during parse: 2
Optimizer mode: ALL_ROWS
Parsing user id: 59  

Rows     Row Source Operation
-------  ---------------------------------------------------
      3  FIXED TABLE FULL X$NLS_PARAMETERS (cr=0 pr=0 pw=0 time=21 us)

********************************************************************************

select to_char(9,'9C') 
from
 dual


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.00       0.00          0          0          0           0
Execute      2      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          0          0           2
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        6      0.00       0.00          0          0          0           2

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 59  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=3 us)

********************************************************************************

select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.flags,i.property,
  i.pctfree$,i.initrans,i.maxtrans,i.blevel,i.leafcnt,i.distkey,i.lblkkey,
  i.dblkkey,i.clufac,i.cols,i.analyzetime,i.samplesize,i.dataobj#,
  nvl(i.degree,1),nvl(i.instances,1),i.rowcnt,mod(i.pctthres$,256),
  i.indmethod#,i.trunccnt,nvl(c.unicols,0),nvl(c.deferrable#+c.valid#,0),
  nvl(i.spare1,i.intcols),i.spare4,i.spare2,i.spare6,decode(i.pctthres$,null,
  null,mod(trunc(i.pctthres$/256),256)),ist.cachedblk,ist.cachehit,
  ist.logicalread 
from
 ind$ i, ind_stats$ ist, (select enabled, min(cols) unicols,
  min(to_number(bitand(defer,1))) deferrable#,min(to_number(bitand(defer,4))) 
  valid# from cdef$ where obj#=:1 and enabled > 1 group by enabled) c where 
  i.obj#=c.enabled(+) and i.obj# = ist.obj#(+) and i.bo#=:1 order by i.obj#


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0         10          0           2
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5      0.00       0.00          0         10          0           2

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      2  SORT ORDER BY (cr=10 pr=0 pw=0 time=668 us)
      2   HASH JOIN OUTER (cr=10 pr=0 pw=0 time=600 us)
      2    NESTED LOOPS OUTER (cr=7 pr=0 pw=0 time=81 us)
      2     TABLE ACCESS CLUSTER IND$ (cr=5 pr=0 pw=0 time=54 us)
      1      INDEX UNIQUE SCAN I_OBJ# (cr=2 pr=0 pw=0 time=24 us)(object id 3)
      0     TABLE ACCESS BY INDEX ROWID IND_STATS$ (cr=2 pr=0 pw=0 time=16 us)
      0      INDEX UNIQUE SCAN I_IND_STATS$_OBJ# (cr=2 pr=0 pw=0 time=9 us)(object id 712)
      1    VIEW  (cr=3 pr=0 pw=0 time=94 us)
      1     SORT GROUP BY (cr=3 pr=0 pw=0 time=90 us)
      1      TABLE ACCESS CLUSTER CDEF$ (cr=3 pr=0 pw=0 time=24 us)
      1       INDEX UNIQUE SCAN I_COBJ# (cr=2 pr=0 pw=0 time=13 us)(object id 30)

********************************************************************************

select pos#,intcol#,col#,spare1,bo#,spare2 
from
 icol$ where obj#=:1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      2      0.00       0.00          0          0          0           0
Fetch        5      0.00       0.00          0         10          0           3
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        8      0.00       0.00          0         10          0           3

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      2  TABLE ACCESS BY INDEX ROWID ICOL$ (cr=6 pr=0 pw=0 time=16 us)
      2   INDEX RANGE SCAN I_ICOL1 (cr=4 pr=0 pw=0 time=16 us)(object id 40)

********************************************************************************

select /*+ rule */ bucket, endpoint, col#, epvalue 
from
 histgrm$ where obj#=:1 and intcol#=:2 and row#=:3 order by bucket


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     52      0.00       0.00          0          0          0           0
Fetch       52      0.00       0.05         13        156          0         871
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      105      0.00       0.05         13        156          0         871

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS   (recursive depth: 2)

Rows     Row Source Operation
-------  ---------------------------------------------------
     10  SORT ORDER BY (cr=3 pr=1 pw=0 time=19090 us)
     10   TABLE ACCESS CLUSTER HISTGRM$ (cr=3 pr=1 pw=0 time=19077 us)
      1    INDEX UNIQUE SCAN I_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=13 us)(object id 252)

********************************************************************************

select name,intcol#,segcol#,type#,length,nvl(precision#,0),decode(type#,2,
  nvl(scale,-127/*MAXSB1MINAL*/),178,scale,179,scale,180,scale,181,scale,182,
  scale,183,scale,231,scale,0),null$,fixedstorage,nvl(deflength,0),default$,
  rowid,col#,property, nvl(charsetid,0),nvl(charsetform,0),spare1,spare2,
  nvl(spare3,0) 
from
 col$ where obj#=:1 order by intcol#


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        4      0.00       0.00          0          3          0           3
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        6      0.00       0.00          0          3          0           3

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      3  SORT ORDER BY (cr=3 pr=0 pw=0 time=34 us)
      3   TABLE ACCESS CLUSTER COL$ (cr=3 pr=0 pw=0 time=16 us)
      1    INDEX UNIQUE SCAN I_OBJ# (cr=2 pr=0 pw=0 time=7 us)(object id 3)

********************************************************************************

select col#, grantee#, privilege#,max(mod(nvl(option$,0),2)) 
from
 objauth$ where obj#=:1 and col# is not null group by privilege#, col#, 
  grantee# order by col#, grantee#


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          2          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          2          0           0

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  SORT GROUP BY (cr=2 pr=0 pw=0 time=30 us)
      0   TABLE ACCESS BY INDEX ROWID OBJAUTH$ (cr=2 pr=0 pw=0 time=20 us)
      0    INDEX RANGE SCAN I_OBJAUTH1 (cr=2 pr=0 pw=0 time=17 us)(object id 103)

********************************************************************************

select grantee#,privilege#,nvl(col#,0),max(mod(nvl(option$,0),2))
from
 objauth$ where obj#=:1 group by grantee#,privilege#,nvl(col#,0) order by 
  grantee#


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch       21      0.00       0.00          0          4          0          20
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       23      0.00       0.00          0          4          0          20

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
     20  SORT GROUP BY (cr=4 pr=0 pw=0 time=81 us)
     20   TABLE ACCESS BY INDEX ROWID OBJAUTH$ (cr=4 pr=0 pw=0 time=73 us)
     20    INDEX RANGE SCAN I_OBJAUTH1 (cr=2 pr=0 pw=0 time=46 us)(object id 103)

********************************************************************************

select con#,obj#,rcon#,enabled,nvl(defer,0) 
from
 cdef$ where robj#=:1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          2          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          2          0           0

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  TABLE ACCESS BY INDEX ROWID CDEF$ (cr=2 pr=0 pw=0 time=14 us)
      0   INDEX RANGE SCAN I_CDEF3 (cr=2 pr=0 pw=0 time=11 us)(object id 52)

********************************************************************************

select con#,type#,condlength,intcols,robj#,rcon#,match#,refact,nvl(enabled,0),
  rowid,cols,nvl(defer,0),mtime,nvl(spare1,0) 
from
 cdef$ where obj#=:1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        4      0.00       0.00          0          6          0           3
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        6      0.00       0.00          0          6          0           3

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      3  TABLE ACCESS CLUSTER CDEF$ (cr=6 pr=0 pw=0 time=23 us)
      1   INDEX UNIQUE SCAN I_COBJ# (cr=2 pr=0 pw=0 time=13 us)(object id 30)

********************************************************************************

select intcol#,nvl(pos#,0),col#,nvl(spare1,0) 
from
 ccol$ where con#=:1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        7      0.00       0.00          0         14          0           4
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       11      0.00       0.00          0         14          0           4

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS BY INDEX ROWID CCOL$ (cr=4 pr=0 pw=0 time=18 us)
      1   INDEX RANGE SCAN I_CCOL1 (cr=3 pr=0 pw=0 time=16 us)(object id 54)

********************************************************************************

select C.CUSTOMER_ID as ID
, CT.NAME as TYPE
, CC.VALUE as CLIENT
, CP.VALUE as PHONE
, CA.VALUE as ADDRESS
, S.SERVICE_ID as SERVICE_ID
, S.LOGIN as SERVICE_LOGIN
, SR.VALUE as SERVICE_IP
, Z.CURSESSIONS_ID as SESSION_ID
, R.ACCTSESSIONID as SESSION_KEY
, R.ACCTSTARTTIME as SESSION_START
, nullif(R.ACCTSTOPTIME, to_date('1970-01-01 03:00:00','yyyy-mm-dd hh24:mi:ss')) as SESSION_STOP
, R.ACCTSESSIONTIME as SESSION_TIME
, R.ACCTINPUTOCTETS as SESSION_DL
, R.ACCTOUTPUTOCTETS as SESSION_UL
, R.ACCTTERMINATECAUSE as SESSION_TERMINATE
, R.CALLINGSTATIONID as PORT
, R.FRAMEDIPADDRESS as IP
, R.CLIENT_MAC_ADDRESS as MAC
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join BM_TARIFFEL T on (T.TARIFFEL_ID = B.TARIFFEL_ID and T.ZONE_ID is null)
join (select min(SEGMENT_ID) as SEGMENT_ID from BM_SEGMENT where IS_SYSTEM = 0 group by SCHEDULE_ID) P on (P.SEGMENT_ID = T.SEGMENT_ID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
join CUSTOMERS C on (C.CUSTOMER_ID = S.CUSTOMER_ID)
join BM_GROUP CG on (CG.GROUP_ID = C.GROUP_ID)
join BM_CUSTOMER_TYPE CT on (CT.CUSTOMER_TYPE_ID = C.CUSTOMER_TYPE_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
left join BM_CUSTOMER_CONTACT CP on (CP.CUSTOMER_ID = C.CUSTOMER_ID and CP.CONTACT_DICT_ID = 6)
left join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
left join RADREPLY SR on (SR.SERVICE_ID = S.SERVICE_ID and SR.ATTRIBUTE = 'Framed-IP-Address' and SR.DATE_BEG <= sysdate and SR.DATE_END is null)
left join CURSESSIONS Z on (Z.SERVICE_ID = S.SERVICE_ID)
where C.GROUP_ID in (select ID from CYBERCOM.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and R.ACCTSTARTTIME >= date'2016-10-01'
and R.ACCTSTARTTIME < date'2016-10-10'

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.20       0.20          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch       15    203.97     350.11    2623068    2777786          0       13768
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       17    204.18     350.31    2623068    2777786          0       13768

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 59  

Rows     Row Source Operation
-------  ---------------------------------------------------
  13768  HASH JOIN  (cr=2777786 pr=2623068 pw=0 time=350506179 us)
      9   TABLE ACCESS FULL BM_CUSTOMER_TYPE (cr=7 pr=0 pw=0 time=65 us)
  13768   HASH JOIN RIGHT OUTER (cr=2777779 pr=2623068 pw=0 time=350450113 us)
     95    TABLE ACCESS FULL RADREPLY (cr=1887 pr=0 pw=0 time=203911 us)
  13768    HASH JOIN RIGHT OUTER (cr=2775892 pr=2623068 pw=0 time=350397673 us)
   3120     TABLE ACCESS FULL CURSESSIONS (cr=107 pr=0 pw=0 time=3158 us)
  13768     HASH JOIN  (cr=2775785 pr=2623068 pw=0 time=350339999 us)
 220943      TABLE ACCESS BY INDEX ROWID RADACCT (cr=112747 pr=0 pw=0 time=1104783 us)
 220943       INDEX RANGE SCAN RADACCT_ACCTSTARTTIME_IDX (cr=1216 pr=0 pw=0 time=222824 us)(object id 53923)
4930652      HASH JOIN  (cr=2663038 pr=2623068 pw=0 time=340315072 us)
      6       VIEW  (cr=7 pr=0 pw=0 time=562 us)
      6        HASH GROUP BY (cr=7 pr=0 pw=0 time=543 us)
     34         TABLE ACCESS FULL BM_SEGMENT (cr=7 pr=0 pw=0 time=80 us)
87414938       HASH JOIN  (cr=2663031 pr=2623068 pw=0 time=437173510 us)
  61893        TABLE ACCESS FULL BM_TARIFFEL (cr=1480 pr=0 pw=0 time=61917 us)
254225378        HASH JOIN  (cr=2661551 pr=2623068 pw=0 time=508517007 us)
  29576         HASH JOIN  (cr=3549 pr=0 pw=0 time=57331 us)
   4702          HASH JOIN  (cr=2670 pr=0 pw=0 time=25294 us)
   4703           HASH JOIN OUTER (cr=1801 pr=0 pw=0 time=32055 us)
   4703            HASH JOIN OUTER (cr=932 pr=0 pw=0 time=24234 us)
   4703             HASH JOIN  (cr=63 pr=0 pw=0 time=5373 us)
      4              INDEX RANGE SCAN IDGROUPS_PK (cr=2 pr=0 pw=0 time=37 us)(object id 114658)
   9758              TABLE ACCESS FULL CUSTOMERS (cr=61 pr=0 pw=0 time=9792 us)
   6544             TABLE ACCESS FULL BM_CUSTOMER_CONTACT (cr=869 pr=0 pw=0 time=6572 us)
   6248            TABLE ACCESS FULL BM_CUSTOMER_CONTACT (cr=869 pr=0 pw=0 time=6272 us)
   6842           TABLE ACCESS FULL BM_CUSTOMER_CONTACT (cr=869 pr=0 pw=0 time=6865 us)
  47733          TABLE ACCESS FULL SERVICES (cr=879 pr=0 pw=0 time=47757 us)
287336391         TABLE ACCESS FULL BM_SERVICE_MONEY (cr=2658002 pr=2623068 pw=0 time=287336422 us)

********************************************************************************

alter session set timed_statistics=false


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0
Parsing user id: 59  
********************************************************************************

alter session set sql_trace = false


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0
Parsing user id: 59

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.

Rows     Row Source Operation
-------  ---------------------------------------------------
  13768  HASH JOIN  (cr=2777786 pr=2623068 pw=0 time=350.506179s)
      9   TABLE ACCESS FULL BM_CUSTOMER_TYPE (cr=7 pr=0 pw=0 time=65us)
  13768   HASH JOIN RIGHT OUTER (cr=2777779 pr=2623068 pw=0 time=350.450113s)
     95    TABLE ACCESS FULL RADREPLY (cr=1887 pr=0 pw=0 time=0.203911s)
  13768    HASH JOIN RIGHT OUTER (cr=2775892 pr=2623068 pw=0 time=350.397673s)
   3120     TABLE ACCESS FULL CURSESSIONS (cr=107 pr=0 pw=0 time=3158us)
  13768     HASH JOIN  (cr=2775785 pr=2623068 pw=0 time=350.339999s)
 220943      TABLE ACCESS BY INDEX ROWID RADACCT (cr=112747 pr=0 pw=0 time=1.104783s)
 220943       INDEX RANGE SCAN RADACCT_ACCTSTARTTIME_IDX (cr=1216 pr=0 pw=0 time=0.222824s)(object id 53923)
4930652      HASH JOIN  (cr=2663038 pr=2623068 pw=0 time=340.315072s)
      6       VIEW  (cr=7 pr=0 pw=0 time=562us)
      6        HASH GROUP BY (cr=7 pr=0 pw=0 time=543us)
     34         TABLE ACCESS FULL BM_SEGMENT (cr=7 pr=0 pw=0 time=80us)
87414938       HASH JOIN  (cr=2663031 pr=2623068 pw=0 time=437.173510s)
  61893        TABLE ACCESS FULL BM_TARIFFEL (cr=1480 pr=0 pw=0 time=61917us)
254225378        HASH JOIN  (cr=2661551 pr=2623068 pw=0 time=508.517007s)
  29576         HASH JOIN  (cr=3549 pr=0 pw=0 time=57331us)
   4702          HASH JOIN  (cr=2670 pr=0 pw=0 time=25294us)
   4703           HASH JOIN OUTER (cr=1801 pr=0 pw=0 time=32055us)
   4703            HASH JOIN OUTER (cr=932 pr=0 pw=0 time=24234us)
   4703             HASH JOIN  (cr=63 pr=0 pw=0 time=5373us)
      4              INDEX RANGE SCAN IDGROUPS_PK (cr=2 pr=0 pw=0 time=37us)(object id 114658)
   9758              TABLE ACCESS FULL CUSTOMERS (cr=61 pr=0 pw=0 time=9792us)
   6544             TABLE ACCESS FULL BM_CUSTOMER_CONTACT (cr=869 pr=0 pw=0 time=6572us)
   6248            TABLE ACCESS FULL BM_CUSTOMER_CONTACT (cr=869 pr=0 pw=0 time=6272us)
   6842           TABLE ACCESS FULL BM_CUSTOMER_CONTACT (cr=869 pr=0 pw=0 time=6865us)
  47733          TABLE ACCESS FULL SERVICES (cr=879 pr=0 pw=0 time=47757us)
287336391         TABLE ACCESS FULL BM_SERVICE_MONEY (cr=2658002 pr=2623068 pw=0 time=287.336422s)

...

Рейтинг:

0 / 0

08.10.2016, 11:30

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39323202

Sayan Malakshinov

Модератор форума

Откуда: Мск

Сообщения: 5 731

Рейтинг: 0 / 0

Alibek B.,

выполни это и перепроверь:

Код: plsql

DECLARE
   tab_owner          varchar2(30) := 'BILLING';
   tab_name           varchar2(30) := 'RADACCT';
   col_name           varchar2(30) := 'ACCTSTARTTIME';
   high_val_new       date         := date'2017-01-01';
   n_distcnt          NUMBER;
   n_density          NUMBER;
   n_nullcnt          NUMBER;
   rec_srec           DBMS_STATS.statrec;
   datevals           DBMS_STATS.DATEARRAY;
   n_avgclen          NUMBER;
   d_low              DATE;
   d_high             DATE;
   r_low              RAW(4000);
   r_high             RAW(4000);
   /* functions for cast raw */
   function raw_to_num(i_raw raw)
   return varchar2
   as
      m_n number;
   begin
      dbms_stats.convert_raw_value(i_raw,m_n);
      return m_n;
   exception when others then return 'ERROR:'||sqlerrm;
   end;
     
   function raw_to_date(i_raw raw)
   return date
   as
      m_n date;
   begin
      dbms_stats.convert_raw_value(i_raw,m_n);
      return m_n;
   end;
     
   function raw_to_varchar2(i_raw raw)
   return varchar2
   as
      m_n varchar2(4000);
   begin
      dbms_stats.convert_raw_value(i_raw,m_n);
      return m_n;
   end;
   /* end functions */
BEGIN
   dbms_stats.delete_column_stats(
      ownname => tab_owner
    , tabname => tab_name
    , colname => col_name
    , col_stat_type=>'HISTOGRAM'
   );

   DBMS_STATS.get_column_stats (tab_owner,
                                tab_name,
                                col_name,
                                distcnt      => n_distcnt,
                                density      => n_density,
                                nullcnt      => n_nullcnt,
                                srec         => rec_srec,
                                avgclen      => n_avgclen
                               );
    
   --handles just the case when HISTOGRAMS are not set -> rec_srec.epc = 2
   IF rec_srec.epc = 2 THEN
     SELECT low_value, high_value
        INTO r_low,r_high
        FROM dba_tab_col_statistics s
      WHERE 
            s.owner       = tab_owner
        and s.table_name  = tab_name
        AND s.column_name = col_name;
     
     d_low := raw_to_date(r_low);
     d_high:= raw_to_date(r_high);
     
     d_high :=   high_val_new
     datevals := DBMS_STATS.DATEARRAY(d_low, d_high);
     rec_srec.minval:=NULL;
     rec_srec.maxval:=NULL;
     rec_srec.bkvals:=NULL;
     rec_srec.novals:=NULL;
      
     --this procedure will set epc.minval, epc.maxval etc in INTERNAL FORMAT
     DBMS_STATS.PREPARE_COLUMN_VALUES(rec_srec, datevals);
      
     --and then just set statistics
     DBMS_STATS.set_column_stats (tab_owner,
                                  tab_name,
                                  col_name,
                                  distcnt      => n_distcnt,
                                  density      => n_density,
                                  nullcnt      => n_nullcnt,
                                  srec         => rec_srec,
                                  avgclen      => n_avgclen,
                                  force        => true
                                  );
   ELSE
     raise_application_error(-20001,'!!!!! There are more than 1 bucket !!!!!!');
   END IF;   
END;
/

если не исправится, то вернешь статистику обратно через dbms_stats.restore_table_stats

...

Рейтинг:

0 / 0

08.10.2016, 13:16

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325079

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Все как-то само исправилось, статистику я не трогал.
Сейчас запрос отрабатывает достаточно быстро.

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.

select C.CUSTOMER_ID as ID
, CT.NAME as TYPE
, CC.VALUE as CLIENT
, CP.VALUE as PHONE
, CA.VALUE as ADDRESS
, S.SERVICE_ID as SERVICE_ID
, S.LOGIN as SERVICE_LOGIN
, SR.VALUE as SERVICE_IP
, Z.CURSESSIONS_ID as SESSION_ID
, R.ACCTSESSIONID as SESSION_KEY
, R.ACCTSTARTTIME as SESSION_START
, nullif(R.ACCTSTOPTIME,to_date('1970-01-01 03:00:00','yyyy-mm-dd hh24:mi:ss')) as SESSION_STOP
, R.ACCTSESSIONTIME as SESSION_TIME
, R.ACCTINPUTOCTETS as SESSION_DL
, R.ACCTOUTPUTOCTETS as SESSION_UL
, R.ACCTTERMINATECAUSE as SESSION_TERMINATE
, R.CALLINGSTATIONID as PORT
, R.FRAMEDIPADDRESS as IP
, R.CLIENT_MAC_ADDRESS as MAC
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join BM_TARIFFEL T on (T.TARIFFEL_ID = B.TARIFFEL_ID and T.ZONE_ID is null)
join (select min(SEGMENT_ID) as SEGMENT_ID from BM_SEGMENT where IS_SYSTEM = 0 group by SCHEDULE_ID) P on (P.SEGMENT_ID = T.SEGMENT_ID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
join CUSTOMERS C on (C.CUSTOMER_ID = S.CUSTOMER_ID)
join BM_GROUP CG on (CG.GROUP_ID = C.GROUP_ID)
join BM_CUSTOMER_TYPE CT on (CT.CUSTOMER_TYPE_ID = C.CUSTOMER_TYPE_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
left join BM_CUSTOMER_CONTACT CP on (CP.CUSTOMER_ID = C.CUSTOMER_ID and CP.CONTACT_DICT_ID = 6)
left join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
left join RADREPLY SR on (SR.SERVICE_ID = S.SERVICE_ID and SR.ATTRIBUTE = 'Framed-IP-Address' and SR.DATE_BEG <= sysdate and SR.DATE_END is null)
left join CURSESSIONS Z on (Z.RADACCTID = R.RADACCTID)
where C.GROUP_ID in (select ID from TEMP.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and R.ACCTSTARTTIME >= to_date(:period_beg,'yyyy-mm-dd hh24:mi:ss')
and R.ACCTSTARTTIME <= to_date(:period_end,'yyyy-mm-dd hh24:mi:ss')

Теперь мне этот запрос нужно дополнительно отфильтровать.
Добавляю:

Код: plsql

and CA.VALUE like :address

и запрос выполняется очень долго. Например для периода в 4 суток запрос выполняется 100мс (в выборке около 6к строк, все записи фетчатся около секунды), а если добавляю условие по CA.VALUE, то этот же запрос выполняется уже 20 минут и я никак не получу статистику. В чем причина по explain plan я понять не могу — там есть TABLE ACCESS FULL TABLE BM_CUSTOMER_CONTACT, но это не такая уж и большая таблица.

Explain plan

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.

SELECT STATEMENT  ALL_ROWSCost: 218 988  Bytes: 190 226  Cardinality: 419  
	33 HASH JOIN RIGHT OUTER  Cost: 218 988  Bytes: 190 226  Cardinality: 419  
		1 TABLE ACCESS FULL TABLE CURSESSIONS Cost: 24  Bytes: 40 008  Cardinality: 3 334  
		32 HASH JOIN RIGHT OUTER  Cost: 218 963  Bytes: 185 198  Cardinality: 419  
			2 TABLE ACCESS FULL TABLE RADREPLY Cost: 417  Bytes: 10 740  Cardinality: 179  
			31 NESTED LOOPS  Cost: 218 545  Bytes: 160 058  Cardinality: 419  
				28 HASH JOIN  Cost: 89 538  Bytes: 14 504 850  Cardinality: 64 466  
					6 VIEW  Cost: 4  Bytes: 91  Cardinality: 7  
						5 HASH GROUP BY  Cost: 4  Bytes: 126  Cardinality: 7  
							4 FILTER  
								3 TABLE ACCESS FULL TABLE BM_SEGMENT Cost: 3  Bytes: 612  Cardinality: 34  
					27 HASH JOIN  Cost: 89 531  Bytes: 80 048 656  Cardinality: 377 588  
						7 TABLE ACCESS FULL TABLE BM_TARIFFEL Cost: 332  Bytes: 698 929  Cardinality: 63 539  
						26 TABLE ACCESS BY INDEX ROWID TABLE BM_SERVICE_MONEY Cost: 13 773  Bytes: 97 328  Cardinality: 6 083  
							25 NESTED LOOPS  Cost: 89 195  Bytes: 75 434 094  Cardinality: 375 294  
								23 NESTED LOOPS OUTER  Cost: 438  Bytes: 11 470  Cardinality: 62  
									20 NESTED LOOPS  Cost: 316  Bytes: 9 548  Cardinality: 62  
										17 NESTED LOOPS  Cost: 250  Bytes: 1 638  Cardinality: 13  
											14 HASH JOIN  Cost: 215  Bytes: 1 710  Cardinality: 18  
												8 TABLE ACCESS FULL TABLE BM_CUSTOMER_CONTACT Cost: 194  Bytes: 9 610  Cardinality: 310  
												13 HASH JOIN  Cost: 20  Bytes: 34 816  Cardinality: 544  
													9 TABLE ACCESS FULL TABLE BM_CUSTOMER_TYPE Cost: 3  Bytes: 270  Cardinality: 9  
													12 HASH JOIN  Cost: 17  Bytes: 18 496  Cardinality: 544  
														10 INDEX RANGE SCAN INDEX (UNIQUE) temp.IDGROUPS_PK Cost: 2  Bytes: 72  Cardinality: 4  
														11 TABLE ACCESS FULL TABLE CUSTOMERS Cost: 14  Bytes: 153 712  Cardinality: 9 607  
											16 TABLE ACCESS BY INDEX ROWID TABLE BM_CUSTOMER_CONTACT Cost: 2  Bytes: 31  Cardinality: 1  
												15 INDEX RANGE SCAN INDEX CUSTOMER_CONTACT_IDX Cost: 1  Cardinality: 1  
										19 TABLE ACCESS BY INDEX ROWID TABLE SERVICES Cost: 7  Bytes: 140  Cardinality: 5  
											18 INDEX RANGE SCAN INDEX SERV_CUSTOMER_IDX Cost: 1  Cardinality: 7  
									22 TABLE ACCESS BY INDEX ROWID TABLE BM_CUSTOMER_CONTACT Cost: 2  Bytes: 31  Cardinality: 1  
										21 INDEX RANGE SCAN INDEX CUSTOMER_CONTACT_IDX Cost: 1  Cardinality: 1  
								24 INDEX RANGE SCAN INDEX SVRM_SERVICE_IDX Cost: 319  Cardinality: 71 759  
				30 TABLE ACCESS BY INDEX ROWID TABLE RADACCT Cost: 2  Bytes: 157  Cardinality: 1  
					29 INDEX UNIQUE SCAN INDEX (UNIQUE) RADACCT_PK Cost: 1  Cardinality: 1

При этом поле BM_CUSTOMER_CONTACT.VALUE проиндексировано (составной индекс по полям CONTACT_DICT_ID,VALUE), а в :address символ процента указывается только в конце (:address='улица%'). То есть на мой взгляд индекс должен использоваться.

Можно ли тут что-нибудь сделать?
Если заменить left join на объединение через union нескольких запросов, это поможет?

...

Рейтинг:

0 / 0

12.10.2016, 10:40

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325121

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Перенес условие в JOIN:

Код: plsql

left join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3 and CA.VALUE like :address)

Теперь запрос отрабатывает моментально.
Видимо оптимизатор такое не распознал и индекс не задействовал.

У меня SQL-запрос формируется динамически и мне было бы проще в тех случаях, когда фильтрация по CA.VALUE не нужна, просто указывать :address='%' (вместо того, чтобы убирать из JOIN это условие).
Это очень плохо?
По скорости отработки запросов особой разницы я не заметил.

...

Рейтинг:

0 / 0

12.10.2016, 11:11

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325155

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Мда, поспешил.
Запрос отрабатывает быстро, но не фильтруется.
А если добавить в WHERE критерий CA.VALUE is not null, то запрос снова выполняется долго.

...

Рейтинг:

0 / 0

12.10.2016, 11:35

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325262

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Последняя версия запроса:

Код: plsql

select C.CUSTOMER_ID as ID
, CT.NAME as TYPE
, CC.VALUE as CLIENT
, CP.VALUE as PHONE
, CA.VALUE as ADDRESS
, S.SERVICE_ID as SERVICE_ID
, S.LOGIN as SERVICE_LOGIN
, SR.VALUE as SERVICE_IP
, null as SESSION_ID
, R.ACCTSESSIONID as SESSION_KEY
, R.ACCTSTARTTIME as SESSION_START
, R.ACCTSTOPTIME as SESSION_STOP
, R.ACCTSESSIONTIME as SESSION_TIME
, R.ACCTINPUTOCTETS as SESSION_DL
, R.ACCTOUTPUTOCTETS as SESSION_UL
, R.ACCTTERMINATECAUSE as SESSION_TERMINATE
, R.CALLINGSTATIONID as PORT
, R.FRAMEDIPADDRESS as IP
, R.CLIENT_MAC_ADDRESS as MAC
from (
select /*+ LEADING(SERVICES BM_SERVICE_MONEY RADACCT) USE_NL(SERVICES BM_SERVICE_MONEY RADACCT BM_TARIFFEL) INDEX(RADACCT RADACCT_PK) */ R.RADACCTID
, S.SERVICE_ID
, R.USERNAME
, R.ACCTSESSIONID
, R.ACCTSTARTTIME
, R.ACCTSTOPTIME
, R.ACCTSESSIONTIME
, R.ACCTINPUTOCTETS
, R.ACCTOUTPUTOCTETS
, R.ACCTTERMINATECAUSE
, R.CALLINGSTATIONID
, R.FRAMEDIPADDRESS
, R.CLIENT_MAC_ADDRESS
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join BM_TARIFFEL T on (T.TARIFFEL_ID = B.TARIFFEL_ID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
where S.TYPE_ID = 14
and R.ACCTSTARTTIME >= to_date(:period_beg,'yyyy-mm-dd hh24:mi:ss')
and R.ACCTSTARTTIME <= to_date(:period_end,'yyyy-mm-dd hh24:mi:ss')
group by R.RADACCTID
, S.SERVICE_ID
, R.USERNAME
, R.ACCTSESSIONID
, R.ACCTSTARTTIME
, R.ACCTSTOPTIME
, R.ACCTSESSIONTIME
, R.ACCTINPUTOCTETS
, R.ACCTOUTPUTOCTETS
, R.ACCTTERMINATECAUSE
, R.CALLINGSTATIONID
, R.FRAMEDIPADDRESS
, R.CLIENT_MAC_ADDRESS
) R
join SERVICES S on (S.SERVICE_ID = R.SERVICE_ID)
join CUSTOMERS C on (C.CUSTOMER_ID = S.CUSTOMER_ID)
join BM_GROUP CG on (CG.GROUP_ID = C.GROUP_ID)
join BM_CUSTOMER_TYPE CT on (CT.CUSTOMER_TYPE_ID = C.CUSTOMER_TYPE_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
left join BM_CUSTOMER_CONTACT CP on (CP.CUSTOMER_ID = C.CUSTOMER_ID and CP.CONTACT_DICT_ID = 6)
left join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
left join RADREPLY SR on (SR.SERVICE_ID = S.SERVICE_ID and SR.ATTRIBUTE = 'Framed-IP-Address' and SR.DATE_BEG <= sysdate and SR.DATE_END is null)
where C.GROUP_ID in (select ID from TEMP.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
--and R.USERNAME = :login
--and R.FRAMEDIPADDRESS = :ip
--and R.CLIENT_MAC_ADDRESS = :mac
--and CA.CONTACT_DICT_ID = 3 and CA.VALUE like :address

Закомментированные строки в конце — это фильтры, которые можно применять дополнительно.
Запрос работает быстро, за исключением последнего фильтра (:address).
Как только его раскомментирую, запрос выполняется очень долго.

Подскажите, как задать критерий отбора по CA.VALUE, чтобы работало быстрее?
В BM_CUSTOMER_CONTACT есть составной индекс по полям CONTACT_DICT_ID,VALUE.

...

Рейтинг:

0 / 0

12.10.2016, 13:01

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325274

nata44845

Участник

Откуда: Красноярск

Сообщения: 356

Рейтинг: 0 / 0

Alibek B.,

Если можешь, делай like 'x%' вместо '%x%', тогда будет индекс задействован по range scan, если он есть конечно на адрес.

...

Рейтинг:

0 / 0

12.10.2016, 13:15

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325333

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Я его именно так и делаю.
Если вложенную таблицу убрать, то индекс используется.
А с ним почему-то не используется (или используется, но на времени выполнения это не ощущается).

...

Рейтинг:

0 / 0

12.10.2016, 14:14

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325365

nata44845

Участник

Откуда: Красноярск

Сообщения: 356

Рейтинг: 0 / 0

Что значит или? план где?
В плане же видно используется или нет.

...

Рейтинг:

0 / 0

12.10.2016, 14:45

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325407

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Запрос выполняется очень долго, его завершения я не дождался.
Explain выглядит так:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.

SELECT STATEMENT  ALL_ROWSCost: 202 369  Bytes: 1 275 074  Cardinality: 2 438  
	30 HASH GROUP BY  Cost: 202 369  Bytes: 1 275 074  Cardinality: 2 438  
		29 FILTER  
			28 HASH JOIN RIGHT OUTER  Cost: 202 097  Bytes: 1 275 074  Cardinality: 2 438  
				1 TABLE ACCESS FULL TABLE BM_CUSTOMER_CONTACT Cost: 194  Bytes: 255 893  Cardinality: 5 951  
				27 HASH JOIN RIGHT OUTER  Cost: 201 902  Bytes: 1 170 240  Cardinality: 2 438  
					2 TABLE ACCESS FULL TABLE RADREPLY Cost: 417  Bytes: 11 098  Cardinality: 179  
					26 HASH JOIN  Cost: 201 484  Bytes: 1 019 084  Cardinality: 2 438  
						4 TABLE ACCESS BY INDEX ROWID TABLE RADACCT Cost: 150 927  Bytes: 21 829 996  Cardinality: 131 506  
							3 INDEX RANGE SCAN INDEX RADACCT_ACCTSTARTTIME_IDX Cost: 1 191  Cardinality: 236 711  
						25 TABLE ACCESS BY INDEX ROWID TABLE BM_SERVICE_MONEY Cost: 13 773  Bytes: 191 424  Cardinality: 11 964  
							24 NESTED LOOPS  Cost: 44 757  Bytes: 94 570 560  Cardinality: 375 280  
								22 NESTED LOOPS  Cost: 378  Bytes: 7 316  Cardinality: 31  
									19 NESTED LOOPS  Cost: 316  Bytes: 14 074  Cardinality: 62  
										16 NESTED LOOPS  Cost: 250  Bytes: 2 431  Cardinality: 13  
											13 HASH JOIN  Cost: 215  Bytes: 2 592  Cardinality: 18  
												5 TABLE ACCESS FULL TABLE BM_CUSTOMER_CONTACT Cost: 194  Bytes: 13 330  Cardinality: 310  
												12 NESTED LOOPS  Cost: 20  Bytes: 54 944  Cardinality: 544  
													10 HASH JOIN  Cost: 20  Bytes: 46 240  Cardinality: 544  
														6 TABLE ACCESS FULL TABLE BM_CUSTOMER_TYPE Cost: 3  Bytes: 351  Cardinality: 9  
														9 HASH JOIN  Cost: 17  Bytes: 25 024  Cardinality: 544  
															7 INDEX RANGE SCAN INDEX (UNIQUE) temp.IDGROUPS_PK Cost: 2  Bytes: 72  Cardinality: 4  
															8 TABLE ACCESS FULL TABLE CUSTOMERS Cost: 14  Bytes: 268 996  Cardinality: 9 607  
													11 INDEX UNIQUE SCAN INDEX (UNIQUE) GROUP_PK Cost: 0  Bytes: 16  Cardinality: 1  
											15 TABLE ACCESS BY INDEX ROWID TABLE BM_CUSTOMER_CONTACT Cost: 2  Bytes: 43  Cardinality: 1  
												14 INDEX RANGE SCAN INDEX CUSTOMER_CONTACT_IDX Cost: 1  Cardinality: 1  
										18 TABLE ACCESS BY INDEX ROWID TABLE SERVICES Cost: 7  Bytes: 200  Cardinality: 5  
											17 INDEX RANGE SCAN INDEX SERV_CUSTOMER_IDX Cost: 1  Cardinality: 7  
									21 TABLE ACCESS BY INDEX ROWID TABLE SERVICES Cost: 1  Bytes: 9  Cardinality: 1  
										20 INDEX UNIQUE SCAN INDEX (UNIQUE) SERVICES_PK Cost: 0  Cardinality: 1  
								23 INDEX RANGE SCAN INDEX SVRM_SERVICE_IDX Cost: 319  Cardinality: 71 759

В таблице BM_CUSTOMER_CONTACT есть следующие индексы:
UNIQUE INDEX CUSTOMER_CONTACT_PK ON BM_CUSTOMER_CONTACT (CUSTOMER_CONTACT_ID)
INDEX CUSTOMER_CONTACT_IDX ON BM_CUSTOMER_CONTACT (CUSTOMER_ID, CONTACT_DICT_ID)
INDEX CUSTOMER_CONTACT_VAL_IDX ON BM_CUSTOMER_CONTACT (CONTACT_DICT_ID, UPPER("VALUE"))

И похоже что CUSTOMER_CONTACT_VAL_IDX не используется.

...

Рейтинг:

0 / 0

12.10.2016, 15:28

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325426

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.,

Код: plsql

/*+ LEADING(SERVICES BM_SERVICE_MONEY RADACCT) USE_NL(SERVICES BM_SERVICE_MONEYRADACCT BM_TARIFFEL) INDEX( RADACCT RADACCT_PK) */

Если таблице дан элиас то в хинте необходимо указывать его а не имя таблицы:

Код: plsql

SQL> explain plan for
  2  select /*+ use_nl(dept,emp) */ * from emp e,dept d where d.deptno = e.deptno;

Explained.

SQL> select * from table(dbms_xplan.display);

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

Plan hash value: 844388907

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |    14 |   826 |     5   (0)| 00:00:01 |
|   1 |  MERGE JOIN                  |         |    14 |   826 |     5   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    80 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |         |    14 |   546 |     3   (0)| 00:00:01 |
|   5 |    TABLE ACCESS FULL         | EMP     |    14 |   546 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   4 - access("D"."DEPTNO"="E"."DEPTNO")
       filter("D"."DEPTNO"="E"."DEPTNO")

18 rows selected.

SQL> explain plan for
  2  select /*+ use_nl(d,e) */ * from emp e,dept d where d.deptno = e.deptno;

Explained.

SQL> select * from table(dbms_xplan.display);

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

Plan hash value: 4192419542

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |    14 |   826 |    10   (0)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |    14 |   826 |    10   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPT |     4 |    80 |     3   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| EMP  |     4 |   156 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   3 - filter("D"."DEPTNO"="E"."DEPTNO")

15 rows selected.

SQL>

SY.

...

Рейтинг:

0 / 0

12.10.2016, 15:42

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325467

nimad

Гость

Alibek B.,

В индексе

Код: plsql

UPPER("VALUE")

В запросе

Код: plsql

CA.VALUE like :address

...

Рейтинг:

0 / 0

12.10.2016, 16:21

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325508

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

SYЕсли таблице дан элиас то в хинте необходимо указывать его а не имя таблицы:
Исправил.

nimadВ индексе

Код: plsql

UPPER("VALUE")

Я почему-то считал, что like регистронезависимый.
Исправил, указал upper(CA.VALUE) like upper(:address).

План поменялся:

Код: plaintext

-----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                          |  2381 |  1216K|       |   601M  (1)|999:59:59 |
|   1 |  HASH GROUP BY                           |                          |  2381 |  1216K|  2552K|   601M  (1)|999:59:59 |
|*  2 |   FILTER                                 |                          |       |       |       |            |          |
|*  3 |    HASH JOIN RIGHT OUTER                 |                          |  2381 |  1216K|       |   601M  (1)|999:59:59 |
|*  4 |     TABLE ACCESS FULL                    | BM_CUSTOMER_CONTACT      |  5951 |   249K|       |   194   (1)| 00:00:03 |
|   5 |     NESTED LOOPS                         |                          |  2381 |  1116K|       |   601M  (1)|999:59:59 |
|*  6 |      HASH JOIN                           |                          |  2381 |  1078K|       |   601M  (1)|999:59:59 |
|   7 |       TABLE ACCESS FULL                  | BM_CUSTOMER_TYPE         |     9 |   351 |       |     3   (0)| 00:00:01 |
|*  8 |       HASH JOIN                          |                          |  2381 |   988K|       |   601M  (1)|999:59:59 |
|*  9 |        TABLE ACCESS FULL                 | BM_CUSTOMER_CONTACT      |  7044 |   295K|       |   194   (1)| 00:00:03 |
|* 10 |        HASH JOIN                         |                          |  3128 |  1166K|       |   601M  (1)|999:59:59 |
|* 11 |         INDEX RANGE SCAN                 | IDGROUPS_PK              |     4 |    72 |       |     2   (0)| 00:00:01 |
|* 12 |         HASH JOIN                        |                          | 55261 |    19M|       |   601M  (1)|999:59:59 |
|  13 |          TABLE ACCESS BY INDEX ROWID     | BM_CUSTOMER_CONTACT      |   310 | 13330 |       |    46   (0)| 00:00:01 |
|* 14 |           INDEX RANGE SCAN               | CUSTOMER_CONTACT_VAL_IDX |    56 |       |       |     3   (0)| 00:00:01 |
|* 15 |          HASH JOIN                       |                          |  1711K|   523M|       |   601M  (1)|999:59:59 |
|* 16 |           TABLE ACCESS FULL              | CUSTOMERS                |  9607 |   262K|       |    14   (0)| 00:00:01 |
|* 17 |           HASH JOIN RIGHT OUTER          |                          |  1841K|   514M|       |   601M  (1)|999:59:59 |
|* 18 |            TABLE ACCESS FULL             | RADREPLY                 |   179 | 11098 |       |   417   (1)| 00:00:06 |
|* 19 |            HASH JOIN                     |                          |  1841K|   405M|  2432K|   601M  (1)|999:59:59 |
|  20 |             TABLE ACCESS FULL            | SERVICES                 | 47769 |  1865K|       |   194   (1)| 00:00:03 |
|  21 |             NESTED LOOPS                 |                          |  1841K|   335M|       |   601M  (1)|999:59:59 |
|  22 |              NESTED LOOPS                |                          |   283M|  6757M|       |    33M  (1)|113:03:10 |
|* 23 |               TABLE ACCESS FULL          | SERVICES                 | 23691 |   208K|       |   194   (1)| 00:00:03 |
|* 24 |               TABLE ACCESS BY INDEX ROWID| BM_SERVICE_MONEY         | 11964 |   186K|       | 13773   (1)| 00:02:46 |
|* 25 |                INDEX RANGE SCAN          | SVRM_SERVICE_IDX         | 71759 |       |       |   319   (1)| 00:00:04 |
|* 26 |              TABLE ACCESS BY INDEX ROWID | RADACCT                  |     1 |   166 |       |     2   (0)| 00:00:01 |
|* 27 |               INDEX UNIQUE SCAN          | RADACCT_PK               |     1 |       |       |     1   (0)| 00:00:01 |
|* 28 |      INDEX UNIQUE SCAN                   | GROUP_PK                 |     1 |    16 |       |     0   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------------

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

2 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
3 - access("CP"."CUSTOMER_ID"(+)="C"."CUSTOMER_ID")
4 - filter("CP"."CONTACT_DICT_ID"(+)=6)
6 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
8 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID")
9 - filter("CC"."CONTACT_DICT_ID"=100)
10 - access("C"."GROUP_ID"="ID")
11 - access("SCOPE"='client-groups-sms')
12 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID")
14 - access("CA"."CONTACT_DICT_ID"=3 AND UPPER("VALUE") LIKE UPPER(:ADDRESS)) filter(UPPER("VALUE") LIKE UPPER(:ADDRESS))
15 - access("C"."CUSTOMER_ID"="S"."CUSTOMER_ID")
16 - filter("C"."STATUS">0)
17 - access("SR"."SERVICE_ID"(+)="S"."SERVICE_ID")
18 - filter("SR"."ATTRIBUTE"(+)='Framed-IP-Address' AND "SR"."DATE_END"(+) IS NULL AND "SR"."DATE_BEG"(+)<=SYSDATE@!)
19 - access("S"."SERVICE_ID"="S"."SERVICE_ID")
23 - filter("S"."TYPE_ID"=14)
24 - filter("B"."TARIFFEL_ID" IS NOT NULL)
25 - access("S"."SERVICE_ID"="B"."SERVICE_ID")
26 - filter("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND "R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
27 - access("B"."RADACCTID"="R"."RADACCTID")
28 - access("CG"."GROUP_ID"="C"."GROUP_ID")

Даже INDEX RANGE SCAN для CUSTOMER_CONTACT_VAL_IDX появился.
Но запрос по прежнему отрабатывает очень долго.

Сейчас поэкспериментирую, мне кажется, что дальше я уже разберусь.

...

Рейтинг:

0 / 0

12.10.2016, 17:00

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325572

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

SYЕсли таблице дан элиас то в хинте необходимо указывать его а не имя таблицы:
Странно, стало намного хуже.
Без хинтов запрос выполняется полторы минуты, с хинтами за полчаса не завершился.
Оставил только USE_NL(S B R T), он вроде бы дает положительный эффект.
А LEADING и INDEX убрал.
В LEADING определяется порядок соединений и по идее LEADING(S B R) должен помогать, но видимо я неправильно понимаю идею.

...

Рейтинг:

0 / 0

12.10.2016, 18:04

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325729

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Чем дальше, тем меньше понимаю.

Есть запрос, выполняемый веб-приложением (скриптом на PHP). Запрос возвращает несколько строк (не более пары десятков).
Выполняется очень долго, веб-сервер закрывает скрипт по таймауту.

Код: plsql

select * from (
select
  C.CUSTOMER_ID as ID
, CT.NAME as TYPE
, CC.VALUE as CLIENT
, CP.VALUE as PHONE
, CA.VALUE as ADDRESS
, S.SERVICE_ID as SERVICE_ID
, S.LOGIN as SERVICE_LOGIN
, SR.VALUE as SERVICE_IP
, Z.CURSESSIONS_ID as SESSION_ID
, R.USERNAME as SESSION_USERNAME
, R.ACCTSESSIONID as SESSION_KEY
, R.ACCTSTARTTIME as SESSION_START
, null as SESSION_STOP
, 86400 * (sysdate - R.ACCTSTARTTIME) as SESSION_TIME
, R.ACCTINPUTOCTETS as SESSION_DL
, R.ACCTOUTPUTOCTETS as SESSION_UL
, R.ACCTTERMINATECAUSE as SESSION_TERMINATE
, R.CALLINGSTATIONID as PORT
, R.FRAMEDIPADDRESS as IP
, R.CLIENT_MAC_ADDRESS as MAC
from CUSTOMERS C
join BM_GROUP CG on (CG.GROUP_ID = C.GROUP_ID)
join BM_CUSTOMER_TYPE CT on (CT.CUSTOMER_TYPE_ID = C.CUSTOMER_TYPE_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
left join BM_CUSTOMER_CONTACT CP on (CP.CUSTOMER_ID = C.CUSTOMER_ID and CP.CONTACT_DICT_ID = 6)
left join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
join SERVICES S on (S.CUSTOMER_ID = C.CUSTOMER_ID and S.TYPE_ID = 14 and S.STATUS != -20 and not exists (select TARIFFEL_ID from BM_TARIFFEL where TARIFF_ID = S.TARIFF_ID and TARIFFEL_TYPE_ID = 908))
left join RADREPLY SR on (SR.SERVICE_ID = S.SERVICE_ID and SR.ATTRIBUTE = 'Framed-IP-Address' and SR.DATE_BEG <= sysdate and SR.DATE_END is null)
left join CURSESSIONS Z on (Z.SERVICE_ID = S.SERVICE_ID)
left join RADACCT R on (R.RADACCTID = Z.RADACCTID)
where C.GROUP_ID in (select ID from TEMP.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and coalesce(R.FRAMEDIPADDRESS,SR.VALUE,'-') = :ip
and CA.CONTACT_DICT_ID = 3 and upper(CA.VALUE) like upper(:address)
and R.ACCTSTARTTIME >= to_date(:period_beg,'yyyy-mm-dd hh24:mi:ss')
and R.ACCTSTARTTIME <= to_date(:period_end,'yyyy-mm-dd hh24:mi:ss')
union all
select
  C.CUSTOMER_ID as ID
, CT.NAME as TYPE
, CC.VALUE as CLIENT
, CP.VALUE as PHONE
, CA.VALUE as ADDRESS
, S.SERVICE_ID as SERVICE_ID
, S.LOGIN as SERVICE_LOGIN
, SR.VALUE as SERVICE_IP
, null as SESSION_ID
, R.USERNAME as SESSION_USERNAME
, R.ACCTSESSIONID as SESSION_KEY
, R.ACCTSTARTTIME as SESSION_START
, R.ACCTSTOPTIME as SESSION_STOP
, R.ACCTSESSIONTIME as SESSION_TIME
, R.ACCTINPUTOCTETS as SESSION_DL
, R.ACCTOUTPUTOCTETS as SESSION_UL
, R.ACCTTERMINATECAUSE as SESSION_TERMINATE
, R.CALLINGSTATIONID as PORT
, R.FRAMEDIPADDRESS as IP
, R.CLIENT_MAC_ADDRESS as MAC
from (
select --/*+ USE_NL(S B R T) */
  R.RADACCTID
, S.SERVICE_ID
, R.USERNAME
, R.ACCTSESSIONID
, R.ACCTSTARTTIME
, R.ACCTSTOPTIME
, R.ACCTSESSIONTIME
, R.ACCTINPUTOCTETS
, R.ACCTOUTPUTOCTETS
, R.ACCTTERMINATECAUSE
, R.CALLINGSTATIONID
, R.FRAMEDIPADDRESS
, R.CLIENT_MAC_ADDRESS
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
join BM_TARIFFEL T on (T.TARIFFEL_ID = B.TARIFFEL_ID)
join SERVICES S on (S.SERVICE_ID = B.SERVICE_ID)
where S.TYPE_ID = 14
and R.ACCTSTARTTIME >= to_date(:period_beg,'yyyy-mm-dd hh24:mi:ss')
and R.ACCTSTARTTIME <= to_date(:period_end,'yyyy-mm-dd hh24:mi:ss')
group by
  R.RADACCTID
, S.SERVICE_ID
, R.USERNAME
, R.ACCTSESSIONID
, R.ACCTSTARTTIME
, R.ACCTSTOPTIME
, R.ACCTSESSIONTIME
, R.ACCTINPUTOCTETS
, R.ACCTOUTPUTOCTETS
, R.ACCTTERMINATECAUSE
, R.CALLINGSTATIONID
, R.FRAMEDIPADDRESS
, R.CLIENT_MAC_ADDRESS
) R
join SERVICES S on (S.SERVICE_ID = R.SERVICE_ID)
join CUSTOMERS C on (C.CUSTOMER_ID = S.CUSTOMER_ID)
join BM_GROUP CG on (CG.GROUP_ID = C.GROUP_ID)
join BM_CUSTOMER_TYPE CT on (CT.CUSTOMER_TYPE_ID = C.CUSTOMER_TYPE_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
left join BM_CUSTOMER_CONTACT CP on (CP.CUSTOMER_ID = C.CUSTOMER_ID and CP.CONTACT_DICT_ID = 6)
left join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
left join RADREPLY SR on (SR.SERVICE_ID = S.SERVICE_ID and SR.ATTRIBUTE = 'Framed-IP-Address' and SR.DATE_BEG <= sysdate and SR.DATE_END is null)
where C.GROUP_ID in (select ID from TEMP.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and R.FRAMEDIPADDRESS = :ip
and CA.CONTACT_DICT_ID = 3 and upper(CA.VALUE) like upper(:address)
)

Этот же запрос я сегодня запускал в TOAD — в первый раз он выполнялся около полутора минут, в следующие разы отрабатывал быстро (секунды), даже если я изменял некоторые параметры.

Затем я этот же запрос запустил в SQL*Plus, предварительно задав параметры (такие же как на сайте и в TOAD):

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.

var ip varchar2(20)
exec :ip:='11.22.33.44'
var address varchar2(40)
exec :address:='Международная%'
var period_beg varchar2(20)
exec :period_beg:='2016-10-01 00:00:00'
var period_end varchar2(20)
exec :period_end:='9999-01-01 23:59:59'

В первый раз запрос выполнялся больше минуты, в следующие разы выполнялся за секунды.

С сайта запрос по прежнему выполнялся очень долго (точнее его прерывал сервер по таймауту).

Сейчас решил снова проверить, запустил его в SQL*Plus — и он выполняется уже почти 10 минут.

Запустил его же в TOAD, с теми же параметрами — запрос выполнился за 31 секунду.
Повторные запуски — около 400мс.

Остановил запрос в SQL*Plus (прошло более 10 минут, он так и не завершился).
Запустил его еще раз, прошло уже минуты четыре, а он так и не завершился.

Почему в TOAD запрос выполняется быстро? Даже если изменять параметры (:ip или :address), время выполнения не превышает десятка секунд.
Почему в SQL*Plus днем он выполнялся быстро, а сейчас долго? SQL*Plus один и тот же, на одной и той же машине (она же сервер СУБД), никаких настроек или окружение среды я не изменял (да и не умею).
Почему из PHP (используется библиотека OCI) запрос выполняется долго? В PHP я первоначально использовал хинт RESULT_CACHE, но я пробовал его убирать, ничего не менялось.

Вот текущий план из TOAD:

Код: plaintext

-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                   | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                            |                           |     2 |  3284 |   151K  (1)| 00:30:22 |
|   1 |  VIEW                                       |                           |     2 |  3284 |   151K  (1)| 00:30:22 |
|   2 |   UNION-ALL                                 |                           |       |       |            |          |
|*  3 |    FILTER                                   |                           |       |       |            |          |
|   4 |     NESTED LOOPS                            |                           |     1 |   437 |   202   (2)| 00:00:03 |
|   5 |      NESTED LOOPS                           |                           |     3 |   852 |   196   (2)| 00:00:03 |
|   6 |       NESTED LOOPS OUTER                    |                           |     4 |  1012 |   188   (2)| 00:00:03 |
|   7 |        NESTED LOOPS OUTER                   |                           |     4 |   888 |   180   (2)| 00:00:03 |
|   8 |         NESTED LOOPS                        |                           |     4 |   648 |   172   (2)| 00:00:03 |
|*  9 |          HASH JOIN ANTI                     |                           |     4 |   580 |   167   (2)| 00:00:03 |
|* 10 |           TABLE ACCESS BY INDEX ROWID       | SERVICES                  |     2 |    82 |     7   (0)| 00:00:01 |
|  11 |            NESTED LOOPS                     |                           |    35 |  4760 |   155   (2)| 00:00:02 |
|* 12 |             HASH JOIN                       |                           |    18 |  1710 |    66   (5)| 00:00:01 |
|  13 |              TABLE ACCESS BY INDEX ROWID    | BM_CUSTOMER_CONTACT       |   310 |  9610 |    46   (0)| 00:00:01 |
|* 14 |               INDEX RANGE SCAN              | CUSTOMER_CONTACT_VAL_IDX  |    56 |       |     3   (0)| 00:00:01 |
|  15 |              NESTED LOOPS                   |                           |   544 | 34816 |    19  (11)| 00:00:01 |
|* 16 |               HASH JOIN                     |                           |  9607 |   431K|    18   (6)| 00:00:01 |
|  17 |                TABLE ACCESS FULL            | BM_CUSTOMER_TYPE          |     9 |   270 |     3   (0)| 00:00:01 |
|* 18 |                TABLE ACCESS FULL            | CUSTOMERS                 |  9607 |   150K|    14   (0)| 00:00:01 |
|* 19 |               INDEX UNIQUE SCAN             | IDGROUPS_PK               |     1 |    18 |     0   (0)| 00:00:01 |
|* 20 |             INDEX RANGE SCAN                | SERV_CUSTOMER_IDX         |     7 |       |     1   (0)| 00:00:01 |
|  21 |           TABLE ACCESS BY INDEX ROWID       | BM_TARIFFEL               |   254 |  2286 |    12   (0)| 00:00:01 |
|* 22 |            INDEX RANGE SCAN                 | TAREL_TYPE_IDX            |   254 |       |     1   (0)| 00:00:01 |
|  23 |          TABLE ACCESS BY INDEX ROWID        | CURSESSIONS               |     1 |    17 |     2   (0)| 00:00:01 |
|* 24 |           INDEX RANGE SCAN                  | CURSESS_SERVICE_IDX       |     1 |       |     1   (0)| 00:00:01 |
|* 25 |         TABLE ACCESS BY INDEX ROWID         | RADREPLY                  |     1 |    60 |     3   (0)| 00:00:01 |
|* 26 |          INDEX RANGE SCAN                   | RADREPLY_SERVICE_IDX      |     8 |       |     1   (0)| 00:00:01 |
|  27 |        TABLE ACCESS BY INDEX ROWID          | BM_CUSTOMER_CONTACT       |     1 |    31 |     2   (0)| 00:00:01 |
|* 28 |         INDEX RANGE SCAN                    | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
|  29 |       TABLE ACCESS BY INDEX ROWID           | BM_CUSTOMER_CONTACT       |     1 |    31 |     2   (0)| 00:00:01 |
|* 30 |        INDEX RANGE SCAN                     | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
|* 31 |      TABLE ACCESS BY INDEX ROWID            | RADACCT                   |     1 |   153 |     2   (0)| 00:00:01 |
|* 32 |       INDEX UNIQUE SCAN                     | RADACCT_PK                |     1 |       |     1   (0)| 00:00:01 |
|  33 |    HASH GROUP BY                            |                           |     1 |   524 |   151K  (1)| 00:30:19 |
|* 34 |     FILTER                                  |                           |       |       |            |          |
|  35 |      NESTED LOOPS OUTER                     |                           |     1 |   524 |   151K  (1)| 00:30:19 |
|  36 |       NESTED LOOPS                          |                           |     1 |   462 |   151K  (1)| 00:30:19 |
|  37 |        NESTED LOOPS                         |                           |     1 |   446 |   151K  (1)| 00:30:19 |
|  38 |         NESTED LOOPS                        |                           |     1 |   407 |   151K  (1)| 00:30:19 |
|  39 |          NESTED LOOPS OUTER                 |                           |     1 |   364 |   151K  (1)| 00:30:19 |
|* 40 |           HASH JOIN                         |                           |     1 |   321 |   151K  (1)| 00:30:19 |
|  41 |            NESTED LOOPS                     |                           |    38 | 10564 |   151K  (1)| 00:30:19 |
|* 42 |             HASH JOIN                       |                           |   665 |   168K|   151K  (1)| 00:30:19 |
|* 43 |              HASH JOIN                      |                           |   665 |   150K|   151K  (1)| 00:30:19 |
|* 44 |               HASH JOIN                     |                           |   663 |   123K|   151K  (1)| 00:30:16 |
|* 45 |                TABLE ACCESS BY INDEX ROWID  | BM_SERVICE_MONEY          |    14 |   224 |     6   (0)| 00:00:01 |
|  46 |                 NESTED LOOPS                |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 47 |                  TABLE ACCESS BY INDEX ROWID| RADACCT                   |    47 |  7802 |   150K  (1)| 00:30:12 |
|* 48 |                   INDEX RANGE SCAN          | RADACCT_ACCTSTARTTIME_IDX |   236K|       |  1191   (1)| 00:00:15 |
|* 49 |                  INDEX RANGE SCAN           | SVRM_RADACCT_IDX          |    14 |       |     3   (0)| 00:00:01 |
|* 50 |                TABLE ACCESS FULL            | SERVICES                  | 23960 |   210K|   194   (1)| 00:00:03 |
|  51 |               TABLE ACCESS FULL             | SERVICES                  | 47772 |  1912K|   194   (1)| 00:00:03 |
|* 52 |              TABLE ACCESS FULL              | CUSTOMERS                 |  9607 |   262K|    14   (0)| 00:00:01 |
|* 53 |             INDEX UNIQUE SCAN               | IDGROUPS_PK               |     1 |    18 |     0   (0)| 00:00:01 |
|  54 |            TABLE ACCESS BY INDEX ROWID      | BM_CUSTOMER_CONTACT       |   310 | 13330 |    46   (0)| 00:00:01 |
|* 55 |             INDEX RANGE SCAN                | CUSTOMER_CONTACT_VAL_IDX  |    56 |       |     3   (0)| 00:00:01 |
|  56 |           TABLE ACCESS BY INDEX ROWID       | BM_CUSTOMER_CONTACT       |     1 |    43 |     2   (0)| 00:00:01 |
|* 57 |            INDEX RANGE SCAN                 | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
|  58 |          TABLE ACCESS BY INDEX ROWID        | BM_CUSTOMER_CONTACT       |     1 |    43 |     2   (0)| 00:00:01 |
|* 59 |           INDEX RANGE SCAN                  | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
|  60 |         TABLE ACCESS BY INDEX ROWID         | BM_CUSTOMER_TYPE          |     1 |    39 |     1   (0)| 00:00:01 |
|* 61 |          INDEX UNIQUE SCAN                  | BM_CUSTOMER_TYPE_PK       |     1 |       |     0   (0)| 00:00:01 |
|* 62 |        INDEX UNIQUE SCAN                    | GROUP_PK                  |     1 |    16 |     0   (0)| 00:00:01 |
|* 63 |       TABLE ACCESS BY INDEX ROWID           | RADREPLY                  |     1 |    62 |     3   (0)| 00:00:01 |
|* 64 |        INDEX RANGE SCAN                     | RADREPLY_SERVICE_IDX      |     8 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------------

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

3 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
9 - access("TARIFF_ID"="S"."TARIFF_ID")
10 - filter("S"."TYPE_ID"=14 AND "S"."STATUS"<>(-20))
12 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID")
14 - access("CA"."CONTACT_DICT_ID"=3 AND UPPER("VALUE") LIKE UPPER(:ADDRESS))
filter(UPPER("VALUE") LIKE UPPER(:ADDRESS))
16 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
18 - filter("C"."STATUS">0)
19 - access("SCOPE"='client-groups-sms' AND "C"."GROUP_ID"="ID")
20 - access("S"."CUSTOMER_ID"="C"."CUSTOMER_ID")
22 - access("TARIFFEL_TYPE_ID"=908)
24 - access("Z"."SERVICE_ID"="S"."SERVICE_ID")
25 - filter("SR"."ATTRIBUTE"(+)='Framed-IP-Address' AND "SR"."DATE_END"(+) IS NULL AND
"SR"."DATE_BEG"(+)<=SYSDATE@!)
26 - access("SR"."SERVICE_ID"(+)="S"."SERVICE_ID")
28 - access("CP"."CUSTOMER_ID"(+)="C"."CUSTOMER_ID" AND "CP"."CONTACT_DICT_ID"(+)=6)
30 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CC"."CONTACT_DICT_ID"=100)
31 - filter("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND
"R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss') AND
COALESCE("R"."FRAMEDIPADDRESS","SR"."VALUE",'-')=:IP)
32 - access("R"."RADACCTID"="Z"."RADACCTID")
34 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
40 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID")
42 - access("C"."CUSTOMER_ID"="S"."CUSTOMER_ID")
43 - access("S"."SERVICE_ID"="S"."SERVICE_ID")
44 - access("S"."SERVICE_ID"="B"."SERVICE_ID")
45 - filter("B"."TARIFFEL_ID" IS NOT NULL)
47 - filter("R"."FRAMEDIPADDRESS"=:IP)
48 - access("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND
"R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
49 - access("B"."RADACCTID"="R"."RADACCTID")
50 - filter("S"."TYPE_ID"=14)
52 - filter("C"."STATUS">0)
53 - access("SCOPE"='client-groups-sms' AND "C"."GROUP_ID"="ID")
55 - access("CA"."CONTACT_DICT_ID"=3 AND UPPER("VALUE") LIKE UPPER(:ADDRESS))
filter(UPPER("VALUE") LIKE UPPER(:ADDRESS))
57 - access("CP"."CUSTOMER_ID"(+)="C"."CUSTOMER_ID" AND "CP"."CONTACT_DICT_ID"(+)=6)
59 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CC"."CONTACT_DICT_ID"=100)
61 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
62 - access("CG"."GROUP_ID"="C"."GROUP_ID")
63 - filter("SR"."ATTRIBUTE"(+)='Framed-IP-Address' AND "SR"."DATE_END"(+) IS NULL AND
"SR"."DATE_BEG"(+)<=SYSDATE@!)
64 - access("SR"."SERVICE_ID"(+)="S"."SERVICE_ID")

С SQL*Plus план срисовать не смог, из-за переноса строк он совершенно нечитаем.

...

Рейтинг:

0 / 0

12.10.2016, 22:47

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325747

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.С SQL*Plus план срисовать не смог, из-за переноса строк он совершенно нечитаем.

А что SET LINESIZE отменили?

Начни с проcтого. Просмoтри LEFT JOIN. Какой смысл в аутер джойнах типа:

Код: plsql

1.
2.

                  left join RADACCT R
                    on (R.RADACCTID = Z.RADACCTID)

Когда в WHERE стоит:

Код: plsql

1.
2.

              and R.ACCTSTARTTIME >= to_date(:period_beg,'yyyy-mm-dd hh24:mi:ss')
              and R.ACCTSTARTTIME <= to_date(:period_end,'yyyy-mm-dd hh24:mi:ss')

Или:

Код: plsql

1.
2.

                  left join BM_CUSTOMER_CONTACT CA
                    on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)

Когда в WHERE стоит:

Код: plsql

1.
2.

              and CA.CONTACT_DICT_ID = 3
              and upper(CA.VALUE) like upper(:address)

Зачем два раза джойн с SERVICES? Почему бы не:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.

            from       (
                        select  --/*+ USE_NL(S B R T) */
                                R.RADACCTID,
--                                S.SERVICE_ID,
                                B.SERVICE_ID,
                                R.USERNAME,
                                R.ACCTSESSIONID,
                                R.ACCTSTARTTIME,
                                R.ACCTSTOPTIME,
                                R.ACCTSESSIONTIME,
                                R.ACCTINPUTOCTETS,
                                R.ACCTOUTPUTOCTETS,
                                R.ACCTTERMINATECAUSE,
                                R.CALLINGSTATIONID,
                                R.FRAMEDIPADDRESS,
                                R.CLIENT_MAC_ADDRESS
                          from       RADACCT R
                                join BM_SERVICE_MONEY B
                                  on (B.RADACCTID = R.RADACCTID)
                                join BM_TARIFFEL T
                                  on (T.TARIFFEL_ID = B.TARIFFEL_ID)
--                                join SERVICES S
--                                  on (S.SERVICE_ID = B.SERVICE_ID)
                          where S.TYPE_ID = 14
                            and R.ACCTSTARTTIME >= to_date(:period_beg,'yyyy-mm-dd hh24:mi:ss')
                            and R.ACCTSTARTTIME <= to_date(:period_end,'yyyy-mm-dd hh24:mi:ss')
                          group by R.RADACCTID,
--                                   S.SERVICE_ID,
                                   B.SERVICE_ID,
                                   R.USERNAME,
                                   R.ACCTSESSIONID,
                                   R.ACCTSTARTTIME,
                                   R.ACCTSTOPTIME,
                                   R.ACCTSESSIONTIME,
                                   R.ACCTINPUTOCTETS,
                                   R.ACCTOUTPUTOCTETS,
                                   R.ACCTTERMINATECAUSE,
                                   R.CALLINGSTATIONID,
                                   R.FRAMEDIPADDRESS,
                                   R.CLIENT_MAC_ADDRESS
                       ) R

Да и "в первый раз он выполнялся около полутора минут, в следующие разы отрабатывал быстро (секунды)" - данные поле первого выполнения остаются в buffer cache.

SY.

...

Рейтинг:

0 / 0

12.10.2016, 23:36

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325882

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

SYКакой смысл в аутер джойнах типа:

Код: plsql

1.
2.

                  left join RADACCT R
                    on (R.RADACCTID = Z.RADACCTID)

Это в первом запросе (до union), с ним вообще никаких проблем нет.
SQL формируется динамически и мне удобнее, когда тело запроса постоянное и я только добавляю ограничения в WHERE.
Во втором запросе (после union) от внешних соединений попробую избавиться.

SYЗачем два раза джойн с SERVICES? Почему бы не:

Смысл в SERVICES.TYPE_ID=14.
Записи в таблице RADACCT формируются только из SERVICES.TYPE_ID=14.
Но записи в таблице BM_SERVICE_MONEY могут быть для любого SERVICES.TYPE_ID.
И SERVICES.TYPE_ID!=14 гораздо больше, чем SERVICES.TYPE_ID=14.
Я таким образом хотел упростить наиболее "тяжелое" соединение самых больших таблиц RADACCT и BM_SERVICE_MONEY.
Попробую убрать внутреннее соединение с SERVICES, возможно оптимизатор Oracle лучше меня с этим разберется.

SYДа и "в первый раз он выполнялся около полутора минут, в следующие разы отрабатывал быстро (секунды)" - данные поле первого выполнения остаются в buffer cache.

Про кеширование после первого выполнения я предполагал. Возможно что и план запроса кешируется.
Но все равно мне непонятно, почему один и тот же запрос с одними и теми же входными параметрами и в одной и той же среде днем и вечером выполняется разное время.
Даже в TOAD, вчера днем повторные запросы (после первого запуска) отрабатывали 1-2 секунды, а вечером повторные запросы отрабатывали 400мс?

...

Рейтинг:

0 / 0

13.10.2016, 09:11

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39325992

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Убрал left join (заменил на обычный join), убрал из запроса пару таблиц.
Выполнил запрос в TOAD, запрос вернул около десятка строк, в первый раз выполнялся 600мс, в следующие разы выполнялся около 400мс.
Запустил этот же запрос в SQL*Plus, запрос выполнялся более 10 минут, затем я его прервал.
Затем попробовал запустить запрос в TOAD — и он висит уже более 5 минут.

Это может быть из-за блокировок?
Запросы из этой темы блокировок не показывают.

...

Рейтинг:

0 / 0

13.10.2016, 10:39

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326072

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Всем большое спасибо за советы, вроде бы удалось добиться быстрой работы.
Второй подзапрос (после union) теперь выглядит так:

Код: plsql

select * from (
select /*+ RESULT_CACHE */
  C.CUSTOMER_ID as ID
, CT.NAME as TYPE
, CC.VALUE as CLIENT
, CA.VALUE as ADDRESS
, S.SERVICE_ID as SERVICE_ID
, S.LOGIN as SERVICE_LOGIN
, null as SERVICE_IP
, null as SESSION_ID
, R.USERNAME as SESSION_USERNAME
, R.ACCTSESSIONID as SESSION_KEY
, R.ACCTSTARTTIME as SESSION_START
, R.ACCTSTOPTIME as SESSION_STOP
, R.ACCTSESSIONTIME as SESSION_TIME
, R.ACCTINPUTOCTETS as SESSION_DL
, R.ACCTOUTPUTOCTETS as SESSION_UL
, R.ACCTTERMINATECAUSE as SESSION_TERMINATE
, R.CALLINGSTATIONID as PORT
, R.FRAMEDIPADDRESS as IP
, R.CLIENT_MAC_ADDRESS as MAC
from (
select /* USE_NL(B R) */
  R.RADACCTID
, B.SERVICE_ID
, R.USERNAME
, R.ACCTSESSIONID
, R.ACCTSTARTTIME
, R.ACCTSTOPTIME
, R.ACCTSESSIONTIME
, R.ACCTINPUTOCTETS
, R.ACCTOUTPUTOCTETS
, R.ACCTTERMINATECAUSE
, R.CALLINGSTATIONID
, R.FRAMEDIPADDRESS
, R.CLIENT_MAC_ADDRESS
from RADACCT R
join BM_SERVICE_MONEY B on (B.RADACCTID = R.RADACCTID)
where B.TARIFFEL_ID is not null
and R.ACCTSTARTTIME >= to_date(:period_beg,'yyyy-mm-dd hh24:mi:ss')
and R.ACCTSTARTTIME <= to_date(:period_end,'yyyy-mm-dd hh24:mi:ss')
group by
  R.RADACCTID
, B.SERVICE_ID
, R.USERNAME
, R.ACCTSESSIONID
, R.ACCTSTARTTIME
, R.ACCTSTOPTIME
, R.ACCTSESSIONTIME
, R.ACCTINPUTOCTETS
, R.ACCTOUTPUTOCTETS
, R.ACCTTERMINATECAUSE
, R.CALLINGSTATIONID
, R.FRAMEDIPADDRESS
, R.CLIENT_MAC_ADDRESS
) R
join SERVICES S on (S.SERVICE_ID = R.SERVICE_ID)
join CUSTOMERS C on (C.CUSTOMER_ID = S.CUSTOMER_ID)
join BM_GROUP CG on (CG.GROUP_ID = C.GROUP_ID)
join BM_CUSTOMER_TYPE CT on (CT.CUSTOMER_TYPE_ID = C.CUSTOMER_TYPE_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
where C.GROUP_ID in (select ID from TEMP.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and R.FRAMEDIPADDRESS = :ip
and CA.CONTACT_DICT_ID = 3 and upper(CA.VALUE) like upper(:address)
);

В TOAD этот запрос выполняется достаточно быстро, в SQL*Plus тоже.
План выглядит так:

Код: plaintext

set linesize 1000;
set pagesize 0;

var  ip          varchar2(20);
var  address     varchar2(40);
var  period_beg  varchar2(20);
var  period_end  varchar2(20);

exec  :ip         := '11.22.33.44';
exec  :address    := 'Международная%';
exec  :period_beg := '2016-10-01 00:00:00';
exec  :period_end := '9999-01-01 23:59:59';

explain plan for
<мой SQL-запрос>;

select * from table(dbms_xplan.display);

------------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                           |     1 |   997 |   151K  (1)| 00:30:16 |
|   1 |  TABLE ACCESS BY INDEX ROWID         | BM_CUSTOMER_CONTACT       |     1 |    31 |     2   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                       |                           |     1 |   997 |   151K  (1)| 00:30:16 |
|   3 |    NESTED LOOPS                      |                           |     1 |   966 |   151K  (1)| 00:30:16 |
|*  4 |     HASH JOIN                        |                           |     1 |   936 |   151K  (1)| 00:30:16 |
|   5 |      TABLE ACCESS BY INDEX ROWID     | SERVICES                  |     5 |   145 |     7   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                   |                           |    91 |  8554 |   150   (1)| 00:00:02 |
|   7 |        NESTED LOOPS                  |                           |    18 |  1170 |    61   (2)| 00:00:01 |
|*  8 |         HASH JOIN                    |                           |   310 | 14570 |    61   (2)| 00:00:01 |
|   9 |          TABLE ACCESS BY INDEX ROWID | BM_CUSTOMER_CONTACT       |   310 |  9610 |    46   (0)| 00:00:01 |
|* 10 |           INDEX RANGE SCAN           | CUSTOMER_CONTACT_VAL_IDX  |    56 |       |     3   (0)| 00:00:01 |
|* 11 |          TABLE ACCESS FULL           | CUSTOMERS                 |  9607 |   150K|    14   (0)| 00:00:01 |
|* 12 |         INDEX UNIQUE SCAN            | IDGROUPS_PK               |     1 |    18 |     0   (0)| 00:00:01 |
|* 13 |        INDEX RANGE SCAN              | SERV_CUSTOMER_IDX         |     7 |       |     1   (0)| 00:00:01 |
|  14 |      VIEW                            |                           |   662 |   544K|   151K  (1)| 00:30:14 |
|  15 |       HASH GROUP BY                  |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 16 |        FILTER                        |                           |       |       |            |          |
|* 17 |         TABLE ACCESS BY INDEX ROWID  | BM_SERVICE_MONEY          |    14 |   224 |     6   (0)| 00:00:01 |
|  18 |          NESTED LOOPS                |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 19 |           TABLE ACCESS BY INDEX ROWID| RADACCT                   |    47 |  7802 |   150K  (1)| 00:30:12 |
|* 20 |            INDEX RANGE SCAN          | RADACCT_ACCTSTARTTIME_IDX |   236K|       |  1191   (1)| 00:00:15 |
|* 21 |           INDEX RANGE SCAN           | SVRM_RADACCT_IDX          |    14 |       |     3   (0)| 00:00:01 |
|  22 |     TABLE ACCESS BY INDEX ROWID      | BM_CUSTOMER_TYPE          |     1 |    30 |     1   (0)| 00:00:01 |
|* 23 |      INDEX UNIQUE SCAN               | BM_CUSTOMER_TYPE_PK       |     1 |       |     0   (0)| 00:00:01 |
|* 24 |    INDEX RANGE SCAN                  | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------------

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

   4 - access("S"."SERVICE_ID"="R"."SERVICE_ID")
   8 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID")
  10 - access("CA"."CONTACT_DICT_ID"=3 AND UPPER("VALUE") LIKE UPPER(:ADDRESS))
       filter(UPPER("VALUE") LIKE UPPER(:ADDRESS))
  11 - filter("C"."STATUS">0)
  12 - access("SCOPE"='client-groups-sms' AND "C"."GROUP_ID"="ID")
  13 - access("C"."CUSTOMER_ID"="S"."CUSTOMER_ID")
  16 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  17 - filter("B"."TARIFFEL_ID" IS NOT NULL)
  19 - filter("R"."FRAMEDIPADDRESS"=:IP)
  20 - access("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND
              "R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  21 - access("B"."RADACCTID"="R"."RADACCTID")
  23 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
  24 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CC"."CONTACT_DICT_ID"=100)

Но из PHP-скрипта этот запрос по прежнему выполняется долго.
Как можно выяснить, в чем причина? Различные настройки окружения и сессии?

И как убедиться, что на результаты не влияет кеширование?
Я выполнял команды:

Код: plaintext

1.
2.

alter system flush shared_pool;
alter system flush buffer_cache;

и затем запускал запрос, в первый раз запрос выполнялся в течении десятка секунд.
Можно считать, что это чистый результат, без влияния кеширования?

...

Рейтинг:

0 / 0

13.10.2016, 11:36

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326240

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.,

1. план от client tool не зависит.
2. оптимайзер достаточно умен чтобы проверять CA.CONTACT_DICT_ID = 3 один раз так-что незачем его тестировать :

Код: plsql

1.
2.
3.
4.
5.

join BM_CUSTOMER_CONTACT CA on (CA.CUSTOMER_ID = C.CUSTOMER_ID and CA.CONTACT_DICT_ID = 3)
where C.GROUP_ID in (select ID from TEMP.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and R.FRAMEDIPADDRESS = :ip
and CA.CONTACT_DICT_ID = 3 and upper(CA.VALUE) like upper(:address)

3. убери хинты и проверь план и время выполнения.

SY.

...

Рейтинг:

0 / 0

13.10.2016, 13:40

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326254

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Так хинты выключены (я убрал плюс).
Или речь про RESULT_CACHE?

...

Рейтинг:

0 / 0

13.10.2016, 13:48

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326266

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.,

Код: plsql

1.
2.
3.
4.
5.

|* 19 |           TABLE ACCESS BY INDEX ROWID| RADACCT                   |    47 |  7802 |   150K  (1)| 00:30:12 |
|* 20 |            INDEX RANGE SCAN          | RADACCT_ACCTSTARTTIME_IDX |   236K|       |  1191   (1)| 00:00:15 |
  19 - filter("R"."FRAMEDIPADDRESS"=:IP)
  20 - access("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND
              "R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))

Напрашивается добавить поле FRAMEDIPADDRESS к индексу RADACCT_ACCTSTARTTIME_IDX (хотя estimated плану на 100% доверять нельзя).

SY.

...

Рейтинг:

0 / 0

13.10.2016, 13:53

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326271

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Убрал все хинты:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.

------------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                           |     1 |   997 |   151K  (1)| 00:30:16 |
|   1 |  TABLE ACCESS BY INDEX ROWID         | BM_CUSTOMER_CONTACT       |     1 |    31 |     2   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                       |                           |     1 |   997 |   151K  (1)| 00:30:16 |
|   3 |    NESTED LOOPS                      |                           |     1 |   966 |   151K  (1)| 00:30:16 |
|*  4 |     HASH JOIN                        |                           |     1 |   936 |   151K  (1)| 00:30:16 |
|   5 |      TABLE ACCESS BY INDEX ROWID     | SERVICES                  |     5 |   145 |     7   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                   |                           |    91 |  8554 |   150   (1)| 00:00:02 |
|   7 |        NESTED LOOPS                  |                           |    18 |  1170 |    61   (2)| 00:00:01 |
|*  8 |         HASH JOIN                    |                           |   310 | 14570 |    61   (2)| 00:00:01 |
|   9 |          TABLE ACCESS BY INDEX ROWID | BM_CUSTOMER_CONTACT       |   310 |  9610 |    46   (0)| 00:00:01 |
|* 10 |           INDEX RANGE SCAN           | CUSTOMER_CONTACT_VAL_IDX  |    56 |       |     3   (0)| 00:00:01 |
|* 11 |          TABLE ACCESS FULL           | CUSTOMERS                 |  9607 |   150K|    14   (0)| 00:00:01 |
|* 12 |         INDEX UNIQUE SCAN            | IDGROUPS_PK               |     1 |    18 |     0   (0)| 00:00:01 |
|* 13 |        INDEX RANGE SCAN              | SERV_CUSTOMER_IDX         |     7 |       |     1   (0)| 00:00:01 |
|  14 |      VIEW                            |                           |   662 |   544K|   151K  (1)| 00:30:14 |
|  15 |       HASH GROUP BY                  |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 16 |        FILTER                        |                           |       |       |            |          |
|* 17 |         TABLE ACCESS BY INDEX ROWID  | BM_SERVICE_MONEY          |    14 |   224 |     6   (0)| 00:00:01 |
|  18 |          NESTED LOOPS                |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 19 |           TABLE ACCESS BY INDEX ROWID| RADACCT                   |    47 |  7802 |   150K  (1)| 00:30:12 |
|* 20 |            INDEX RANGE SCAN          | RADACCT_ACCTSTARTTIME_IDX |   236K|       |  1191   (1)| 00:00:15 |
|* 21 |           INDEX RANGE SCAN           | SVRM_RADACCT_IDX          |    14 |       |     3   (0)| 00:00:01 |
|  22 |     TABLE ACCESS BY INDEX ROWID      | BM_CUSTOMER_TYPE          |     1 |    30 |     1   (0)| 00:00:01 |
|* 23 |      INDEX UNIQUE SCAN               | BM_CUSTOMER_TYPE_PK       |     1 |       |     0   (0)| 00:00:01 |
|* 24 |    INDEX RANGE SCAN                  | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access("S"."SERVICE_ID"="R"."SERVICE_ID")
   8 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID")
  10 - access("CA"."CONTACT_DICT_ID"=3 AND UPPER("VALUE") LIKE UPPER(:ADDRESS))
       filter(UPPER("VALUE") LIKE UPPER(:ADDRESS))
  11 - filter("C"."STATUS">0)
  12 - access("SCOPE"='client-groups-sms' AND "C"."GROUP_ID"="ID")
  13 - access("C"."CUSTOMER_ID"="S"."CUSTOMER_ID")
  16 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  17 - filter("B"."TARIFFEL_ID" IS NOT NULL)
  19 - filter("R"."FRAMEDIPADDRESS"=:IP)
  20 - access("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND
              "R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  21 - access("B"."RADACCTID"="R"."RADACCTID")
  23 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
  24 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CC"."CONTACT_DICT_ID"=100)

Кстати, если условие проверки на :address убрать, то PHP-скрипт результаты отображает довольно быстро.
А с дополнительной проверкой на :address (в которой задействован индекс) выполняется долго.

...

Рейтинг:

0 / 0

13.10.2016, 13:58

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326273

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

SYНапрашивается добавить поле FRAMEDIPADDRESS к индексу RADACCT_ACCTSTARTTIME_IDX (хотя estimated плану на 100% доверять нельзя).
В таблице RADACCT за 100М записей, я бы не хотел добавлять в нее индекс без особой необходимости.
Кроме того, если в запросе задается только эта проверка:

Код: plsql

1.
2.
3.

where C.GROUP_ID in (select ID from TEMP.IDGROUPS where SCOPE = 'client-groups-sms')
and C.STATUS > 0
and R.FRAMEDIPADDRESS = :ip

то запрос выполняется быстро (в том числе в PHP-скрипте).
А вот когда я к нему добавляю

Код: plsql

and CA.CONTACT_DICT_ID = 3 and upper(CA.VALUE) like upper(:address)

то он выполняется долго.

...

Рейтинг:

0 / 0

13.10.2016, 14:01

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326276

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.Так хинты выключены (я убрал плюс).
Или речь про RESULT_CACHE?

Не заметил + убран в хинтe NL. А что тут дает RESULT_CACHE? В плане не вижу ни

Код: plsql

|   x |  RESULT CACHE            | xxxxxxxxxxxxxxxxxxxxxxxxxxx |       | ... |       |       |

ни:

Код: plsql

1.
2.

Result Cache Information (identified by operation id):
------------------------------------------------------

SY.

...

Рейтинг:

0 / 0

13.10.2016, 14:04

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326281

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Вот план без проверки на :address (только с :ip)

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.

--------------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |                           |    18 |  7146 |   151K  (1)| 00:30:18 |
|   1 |  HASH GROUP BY                         |                           |    18 |  7146 |   151K  (1)| 00:30:18 |
|*  2 |   FILTER                               |                           |       |       |            |          |
|*  3 |    HASH JOIN                           |                           |    18 |  7146 |   151K  (1)| 00:30:18 |
|   4 |     TABLE ACCESS BY INDEX ROWID        | BM_CUSTOMER_CONTACT       |     1 |    43 |     2   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                      |                           |    18 |  6444 |   151K  (1)| 00:30:18 |
|   6 |       NESTED LOOPS                     |                           |    24 |  7560 |   151K  (1)| 00:30:17 |
|   7 |        NESTED LOOPS                    |                           |    38 | 10336 |   151K  (1)| 00:30:16 |
|*  8 |         HASH JOIN                      |                           |   664 |   162K|   151K  (1)| 00:30:16 |
|*  9 |          HASH JOIN                     |                           |   664 |   144K|   151K  (1)| 00:30:16 |
|* 10 |           TABLE ACCESS BY INDEX ROWID  | BM_SERVICE_MONEY          |    14 |   224 |     6   (0)| 00:00:01 |
|  11 |            NESTED LOOPS                |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 12 |             TABLE ACCESS BY INDEX ROWID| RADACCT                   |    47 |  7802 |   150K  (1)| 00:30:12 |
|* 13 |              INDEX RANGE SCAN          | RADACCT_ACCTSTARTTIME_IDX |   236K|       |  1191   (1)| 00:00:15 |
|* 14 |             INDEX RANGE SCAN           | SVRM_RADACCT_IDX          |    14 |       |     3   (0)| 00:00:01 |
|  15 |           TABLE ACCESS FULL            | SERVICES                  | 47772 |  1912K|   194   (1)| 00:00:03 |
|* 16 |          TABLE ACCESS FULL             | CUSTOMERS                 |  9607 |   262K|    14   (0)| 00:00:01 |
|* 17 |         INDEX UNIQUE SCAN              | IDGROUPS_PK               |     1 |    21 |     0   (0)| 00:00:01 |
|  18 |        TABLE ACCESS BY INDEX ROWID     | BM_CUSTOMER_CONTACT       |     1 |    43 |     2   (0)| 00:00:01 |
|* 19 |         INDEX RANGE SCAN               | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
|* 20 |       INDEX RANGE SCAN                 | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
|  21 |     TABLE ACCESS FULL                  | BM_CUSTOMER_TYPE          |     9 |   351 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
   3 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
   8 - access("C"."CUSTOMER_ID"="S"."CUSTOMER_ID")
   9 - access("S"."SERVICE_ID"="B"."SERVICE_ID")
  10 - filter("B"."TARIFFEL_ID" IS NOT NULL)
  12 - filter("R"."FRAMEDIPADDRESS"=:IP)
  13 - access("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND
              "R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  14 - access("B"."RADACCTID"="R"."RADACCTID")
  16 - filter("C"."STATUS">0)
  17 - access("SCOPE"='client-groups-sms' AND "C"."GROUP_ID"="ID")
  19 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CA"."CONTACT_DICT_ID"=3)
  20 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CC"."CONTACT_DICT_ID"=100)

SYА что тут дает RESULT_CACHE?
Версии:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

Возможно в моей версии этот хинт недоступен или отключен.

...

Рейтинг:

0 / 0

13.10.2016, 14:08

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326285

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.,

Я не предлагал новый индекс. Я педлагал добавить поле к существующему. Тогда отпадет необходимость в TABLE ACCESS BY INDEX ROWID. Насчет "А вот когда я к нему добавляю" - зачем добавлять условие CA.CONTACT_DICT_ID = 3 дважды - один раз в ON а торой раз в WHERE? Масло масляное? Контроьный выстрел?

SY.

...

Рейтинг:

0 / 0

13.10.2016, 14:09

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326290

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.Возможно в моей версии этот хинт недоступен или отключен.

Query result cache появился, если не ошибаюсь, в 11g.

SY.

...

Рейтинг:

0 / 0

13.10.2016, 14:14

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326295

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

SYЯ педлагал добавить поле к существующему.
Но в системе часто требуется быстрый доступ по ACCTSTARTTIME (без учета FRAMEDIPADDRESS).
Или в этом случае составной индекс тоже будет использоваться?

...

Рейтинг:

0 / 0

13.10.2016, 14:18

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326341

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.Но в системе часто требуется быстрый доступ по ACCTSTARTTIME (без учета FRAMEDIPADDRESS).
Или в этом случае составной индекс тоже будет использоваться?

Будет, разве-что FRAMEDIPADDRESS очень длинноe поле, хотя судя по имени это IP адрес. В любом случае тестировать всeгда надо.

SY.

...

Рейтинг:

0 / 0

13.10.2016, 14:48

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326419

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Ок, буду иметь ввиду этот способ, как запасной.

А как мне найти причину, почему один и тот же запрос, с одними и теми же параметрами в TOAD выполняется быстро, а в PHP-скрипте долго?
Я подсунул в PHP-скрипт explain plan, получил такой результат:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.

-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                           |     1 |   989 |   151K  (1)| 00:30:16 |
|   1 |  SORT ORDER BY                        |                           |     1 |   989 |   151K  (1)| 00:30:16 |
|   2 |   TABLE ACCESS BY INDEX ROWID         | BM_CUSTOMER_CONTACT       |     1 |    31 |     2   (0)| 00:00:01 |
|   3 |    NESTED LOOPS                       |                           |     1 |   989 |   151K  (1)| 00:30:16 |
|   4 |     NESTED LOOPS                      |                           |     1 |   958 |   151K  (1)| 00:30:16 |
|*  5 |      HASH JOIN                        |                           |     1 |   928 |   151K  (1)| 00:30:16 |
|   6 |       TABLE ACCESS BY INDEX ROWID     | SERVICES                  |     5 |   145 |     7   (0)| 00:00:01 |
|   7 |        NESTED LOOPS                   |                           |    91 |  8554 |   150   (1)| 00:00:02 |
|   8 |         NESTED LOOPS                  |                           |    18 |  1170 |    61   (2)| 00:00:01 |
|*  9 |          HASH JOIN                    |                           |   310 | 14570 |    61   (2)| 00:00:01 |
|  10 |           TABLE ACCESS BY INDEX ROWID | BM_CUSTOMER_CONTACT       |   310 |  9610 |    46   (0)| 00:00:01 |
|* 11 |            INDEX RANGE SCAN           | CUSTOMER_CONTACT_VAL_IDX  |    56 |       |     3   (0)| 00:00:01 |
|* 12 |           TABLE ACCESS FULL           | CUSTOMERS                 |  9607 |   150K|    14   (0)| 00:00:01 |
|* 13 |          INDEX UNIQUE SCAN            | IDGROUPS_PK               |     1 |    18 |     0   (0)| 00:00:01 |
|* 14 |         INDEX RANGE SCAN              | SERV_CUSTOMER_IDX         |     7 |       |     1   (0)| 00:00:01 |
|  15 |       VIEW                            |                           |   662 |   539K|   151K  (1)| 00:30:14 |
|  16 |        HASH GROUP BY                  |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 17 |         FILTER                        |                           |       |       |            |          |
|* 18 |          TABLE ACCESS BY INDEX ROWID  | BM_SERVICE_MONEY          |    14 |   224 |     6   (0)| 00:00:01 |
|  19 |           NESTED LOOPS                |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 20 |            TABLE ACCESS BY INDEX ROWID| RADACCT                   |    47 |  7802 |   150K  (1)| 00:30:12 |
|* 21 |             INDEX RANGE SCAN          | RADACCT_ACCTSTARTTIME_IDX |   236K|       |  1191   (1)| 00:00:15 |
|* 22 |            INDEX RANGE SCAN           | SVRM_RADACCT_IDX          |    14 |       |     3   (0)| 00:00:01 |
|  23 |      TABLE ACCESS BY INDEX ROWID      | BM_CUSTOMER_TYPE          |     1 |    30 |     1   (0)| 00:00:01 |
|* 24 |       INDEX UNIQUE SCAN               | BM_CUSTOMER_TYPE_PK       |     1 |       |     0   (0)| 00:00:01 |
|* 25 |     INDEX RANGE SCAN                  | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   5 - access("S"."SERVICE_ID"="R"."SERVICE_ID")
   9 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID")
  11 - access("CA"."CONTACT_DICT_ID"=3 AND UPPER("VALUE") LIKE UPPER(:ADDRESS))
       filter(UPPER("VALUE") LIKE UPPER(:ADDRESS))
  12 - filter("C"."STATUS">0)
  13 - access("SCOPE"='client-groups-sms' AND "C"."GROUP_ID"="ID")
  14 - access("C"."CUSTOMER_ID"="S"."CUSTOMER_ID")
  17 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  18 - filter("B"."TARIFFEL_ID" IS NOT NULL)
  20 - filter("R"."FRAMEDIPADDRESS"=:IP)
  21 - access("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND 
              "R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  22 - access("B"."RADACCTID"="R"."RADACCTID")
  24 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
  25 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CC"."CONTACT_DICT_ID"=100)

Насколько могу судить, в плане особых отличий нет.

...

Рейтинг:

0 / 0

13.10.2016, 16:00

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326454

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Оказывается дело не совсем в скрипте.
В PHP выполняется такой запрос:

Код: plsql

1.
2.
3.
4.
5.
6.

select * from (
select ... --запрос1
union all
select ... --запрос2
)
order by SESSION_START, CLIENT, LOGIN

То есть два запроса, соединенных через union all и отсортированных.
В TOAD этот составной запрос выполняется быстро, также как по отдельности запрос1 и запрос2.
В PHP-скрипте каждый запрос по отдельности выполняется быстро, даже если он обернут во внешний запрос с сортировкой (то есть select * from (запрос1) order by ...).
А вот составной запрос в PHP-скрипте выполняется долго.

Из-за чего может быть такое поведение?
Вот план составного запроса при выполнении его в PHP-скрипте:

Код: plaintext

-----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                 | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                          |                           |     2 |  3026 |   151K  (1)| 00:30:19 |
|   1 |  VIEW                                     |                           |     2 |  3026 |   151K  (1)| 00:30:19 |
|   2 |   UNION-ALL                               |                           |       |       |            |          |
|*  3 |    FILTER                                 |                           |       |       |            |          |
|   4 |     TABLE ACCESS BY INDEX ROWID           | BM_CUSTOMER_CONTACT       |     1 |    31 |     2   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                         |                           |     1 |   406 |   190   (2)| 00:00:03 |
|   6 |       NESTED LOOPS                        |                           |     1 |   375 |   188   (2)| 00:00:03 |
|   7 |        NESTED LOOPS OUTER                 |                           |     4 |   888 |   180   (2)| 00:00:03 |
|   8 |         NESTED LOOPS                      |                           |     4 |   648 |   172   (2)| 00:00:03 |
|*  9 |          HASH JOIN ANTI                   |                           |     4 |   580 |   167   (2)| 00:00:03 |
|* 10 |           TABLE ACCESS BY INDEX ROWID     | SERVICES                  |     2 |    82 |     7   (0)| 00:00:01 |
|  11 |            NESTED LOOPS                   |                           |    35 |  4760 |   155   (2)| 00:00:02 |
|* 12 |             HASH JOIN                     |                           |    18 |  1710 |    66   (5)| 00:00:01 |
|  13 |              TABLE ACCESS BY INDEX ROWID  | BM_CUSTOMER_CONTACT       |   310 |  9610 |    46   (0)| 00:00:01 |
|* 14 |               INDEX RANGE SCAN            | CUSTOMER_CONTACT_VAL_IDX  |    56 |       |     3   (0)| 00:00:01 |
|  15 |              NESTED LOOPS                 |                           |   544 | 34816 |    19  (11)| 00:00:01 |
|* 16 |               HASH JOIN                   |                           |  9607 |   431K|    18   (6)| 00:00:01 |
|  17 |                TABLE ACCESS FULL          | BM_CUSTOMER_TYPE          |     9 |   270 |     3   (0)| 00:00:01 |
|* 18 |                TABLE ACCESS FULL          | CUSTOMERS                 |  9607 |   150K|    14   (0)| 00:00:01 |
|* 19 |               INDEX UNIQUE SCAN           | IDGROUPS_PK               |     1 |    18 |     0   (0)| 00:00:01 |
|* 20 |             INDEX RANGE SCAN              | SERV_CUSTOMER_IDX         |     7 |       |     1   (0)| 00:00:01 |
|  21 |           TABLE ACCESS BY INDEX ROWID     | BM_TARIFFEL               |   254 |  2286 |    12   (0)| 00:00:01 |
|* 22 |            INDEX RANGE SCAN               | TAREL_TYPE_IDX            |   254 |       |     1   (0)| 00:00:01 |
|  23 |          TABLE ACCESS BY INDEX ROWID      | CURSESSIONS               |     1 |    17 |     2   (0)| 00:00:01 |
|* 24 |           INDEX RANGE SCAN                | CURSESS_SERVICE_IDX       |     1 |       |     1   (0)| 00:00:01 |
|* 25 |         TABLE ACCESS BY INDEX ROWID       | RADREPLY                  |     1 |    60 |     3   (0)| 00:00:01 |
|* 26 |          INDEX RANGE SCAN                 | RADREPLY_SERVICE_IDX      |     8 |       |     1   (0)| 00:00:01 |
|* 27 |        TABLE ACCESS BY INDEX ROWID        | RADACCT                   |     1 |   153 |     2   (0)| 00:00:01 |
|* 28 |         INDEX UNIQUE SCAN                 | RADACCT_PK                |     1 |       |     1   (0)| 00:00:01 |
|* 29 |       INDEX RANGE SCAN                    | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
|  30 |    HASH GROUP BY                          |                           |     1 |   410 |   151K  (1)| 00:30:17 |
|* 31 |     FILTER                                |                           |       |       |            |          |
|  32 |      TABLE ACCESS BY INDEX ROWID          | BM_CUSTOMER_CONTACT       |     1 |    43 |     2   (0)| 00:00:01 |
|  33 |       NESTED LOOPS                        |                           |     1 |   410 |   151K  (1)| 00:30:17 |
|  34 |        NESTED LOOPS                       |                           |     1 |   367 |   151K  (1)| 00:30:17 |
|  35 |         NESTED LOOPS                      |                           |     1 |   351 |   151K  (1)| 00:30:17 |
|* 36 |          HASH JOIN                        |                           |     1 |   312 |   151K  (1)| 00:30:17 |
|  37 |           NESTED LOOPS                    |                           |    38 | 10222 |   151K  (1)| 00:30:16 |
|* 38 |            HASH JOIN                      |                           |   664 |   162K|   151K  (1)| 00:30:16 |
|* 39 |             HASH JOIN                     |                           |   664 |   144K|   151K  (1)| 00:30:16 |
|* 40 |              TABLE ACCESS BY INDEX ROWID  | BM_SERVICE_MONEY          |    14 |   224 |     6   (0)| 00:00:01 |
|  41 |               NESTED LOOPS                |                           |   662 |   117K|   151K  (1)| 00:30:14 |
|* 42 |                TABLE ACCESS BY INDEX ROWID| RADACCT                   |    47 |  7802 |   150K  (1)| 00:30:12 |
|* 43 |                 INDEX RANGE SCAN          | RADACCT_ACCTSTARTTIME_IDX |   236K|       |  1191   (1)| 00:00:15 |
|* 44 |                INDEX RANGE SCAN           | SVRM_RADACCT_IDX          |    14 |       |     3   (0)| 00:00:01 |
|  45 |              TABLE ACCESS FULL            | SERVICES                  | 47772 |  1912K|   194   (1)| 00:00:03 |
|* 46 |             TABLE ACCESS FULL             | CUSTOMERS                 |  9607 |   262K|    14   (0)| 00:00:01 |
|* 47 |            INDEX UNIQUE SCAN              | IDGROUPS_PK               |     1 |    18 |     0   (0)| 00:00:01 |
|  48 |           TABLE ACCESS BY INDEX ROWID     | BM_CUSTOMER_CONTACT       |   310 | 13330 |    46   (0)| 00:00:01 |
|* 49 |            INDEX RANGE SCAN               | CUSTOMER_CONTACT_VAL_IDX  |    56 |       |     3   (0)| 00:00:01 |
|  50 |          TABLE ACCESS BY INDEX ROWID      | BM_CUSTOMER_TYPE          |     1 |    39 |     1   (0)| 00:00:01 |
|* 51 |           INDEX UNIQUE SCAN               | BM_CUSTOMER_TYPE_PK       |     1 |       |     0   (0)| 00:00:01 |
|* 52 |         INDEX UNIQUE SCAN                 | GROUP_PK                  |     1 |    16 |     0   (0)| 00:00:01 |
|* 53 |        INDEX RANGE SCAN                   | CUSTOMER_CONTACT_IDX      |     1 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   3 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
   9 - access("TARIFF_ID"="S"."TARIFF_ID")
  10 - filter("S"."TYPE_ID"=14 AND "S"."STATUS"<>(-20))
  12 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID")
  14 - access("CA"."CONTACT_DICT_ID"=3 AND UPPER("VALUE") LIKE UPPER(:ADDRESS))
       filter(UPPER("VALUE") LIKE UPPER(:ADDRESS))
  16 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
  18 - filter("C"."STATUS">0)
  19 - access("SCOPE"='client-groups-sms' AND "C"."GROUP_ID"="ID")
  20 - access("S"."CUSTOMER_ID"="C"."CUSTOMER_ID")
  22 - access("TARIFFEL_TYPE_ID"=908)
  24 - access("Z"."SERVICE_ID"="S"."SERVICE_ID")
  25 - filter("SR"."ATTRIBUTE"(+)='Framed-IP-Address' AND "SR"."DATE_END"(+) IS NULL AND 
              "SR"."DATE_BEG"(+)<=SYSDATE@!)
  26 - access("SR"."SERVICE_ID"(+)="S"."SERVICE_ID")
  27 - filter("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND 
              "R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss') AND 
              COALESCE("R"."FRAMEDIPADDRESS","SR"."VALUE",'-')=:IP)
  28 - access("R"."RADACCTID"="Z"."RADACCTID")
  29 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CC"."CONTACT_DICT_ID"=100)
  31 - filter(TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss')<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  36 - access("CA"."CUSTOMER_ID"="C"."CUSTOMER_ID")
  38 - access("C"."CUSTOMER_ID"="S"."CUSTOMER_ID")
  39 - access("S"."SERVICE_ID"="B"."SERVICE_ID")
  40 - filter("B"."TARIFFEL_ID" IS NOT NULL)
  42 - filter("R"."FRAMEDIPADDRESS"=:IP)
  43 - access("R"."ACCTSTARTTIME">=TO_DATE(:PERIOD_BEG,'yyyy-mm-dd hh24:mi:ss') AND 
              "R"."ACCTSTARTTIME"<=TO_DATE(:PERIOD_END,'yyyy-mm-dd hh24:mi:ss'))
  44 - access("B"."RADACCTID"="R"."RADACCTID")
  46 - filter("C"."STATUS">0)
  47 - access("SCOPE"='client-groups-sms' AND "C"."GROUP_ID"="ID")
  49 - access("CA"."CONTACT_DICT_ID"=3 AND UPPER("VALUE") LIKE UPPER(:ADDRESS))
       filter(UPPER("VALUE") LIKE UPPER(:ADDRESS))
  51 - access("CT"."CUSTOMER_TYPE_ID"="C"."CUSTOMER_TYPE_ID")
  52 - access("CG"."GROUP_ID"="C"."GROUP_ID")
  53 - access("CC"."CUSTOMER_ID"="C"."CUSTOMER_ID" AND "CC"."CONTACT_DICT_ID"=100)

В TOAD план точно такой-же (специально сохранял два плана в текстовые файлы и сравнивал).
Но в TOAD запрос отрабатывает быстро.

...

Рейтинг:

0 / 0

13.10.2016, 16:31

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326539

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Alibek B.Но в TOAD запрос отрабатывает быстро.

Toad выдает на гора первые строки результата, пoсему и может казаться бысто. Ты в Toad'e нажми пимпочку "до упора", вот тогда и узнаешь полное время всех fetch'ей.

SY.

...

Рейтинг:

0 / 0

13.10.2016, 17:46

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326665

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Конкретно в последнем запросе возвращалось около десятка строк, так что дело точно не в этом (TOAD загружает по 500 строк).
Ну и в случае PHP-скрипта запрос у меня выполняется дважды — первый раз select count(*) from <sql> (чтобы посчитать число строк), второй раз select *, rn from (select *, rownum rn from <sql> where rownum<=...) where rn>=... (чтобы отобразить выбранную страницу). До второго раза PHP-скрипт не доходит, зависает на select count(*), в котором возвращается только одна строка.

Подобные побочные эффекты могут быть из-за union all? Или причина точно не в этом?
В крайнем случае я завтра попробую обойтись без union, выполняя запросы отдельно и объединяя результаты уже на клиентской стороне.

...

Рейтинг:

0 / 0

13.10.2016, 22:12

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39326712

Участник

Откуда: Middlebury, CT USA

Сообщения: 10 588

Рейтинг: 0 / 0

Так добaвь

COUNT(*) OVER() cnt

к select list и первый-же фетч покажет число строк.

SY.

...

Рейтинг:

0 / 0

14.10.2016, 03:19

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39340701

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Спасибо, не знал про такое, так действительно проще.

У меня еще такой вопрос.
Есть запрос с такой строкой:

Код: plsql

where trunc(PA.MOMENT) = trunc(sysdate)

Запрос возвращает около десятка строк, выполняется моментально. PA.MOMENT проиндексирован.

Если сделать так:

Код: plsql

where PA.MOMENT > CB.CHANGED

то запрос выполняется 10-15 секунд, возвращает пару десятков строк. CB.CHANGED не проиндексирован.
В таблице PA строк много, в таблице CB строк меньше тысячи.

Может быть такая разница из-за того, что CB.CHANGED неиндексирован?
Или нужно изучать план выполнения?

...

Рейтинг:

0 / 0

03.11.2016, 12:27

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39340706

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Alibek B.В таблице PA строк много, в таблице CB строк меньше тысячи.
Всего в PA порядка 1М строк.
Для фильтра trunc(PA.MOMENT) = trunc(sysdate) около 1-2 тысяч строк.
Для фильтра PA.MOMENT > CB.CHANGED около 3-5 тысяч строк (CB.CHANGED очень редко отстает от текущей даты больше чем на несколько дней).

...

Рейтинг:

0 / 0

03.11.2016, 12:31

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39340916

Elic

Участник

Сообщения: 30 360

Рейтинг: 0 / 0

Alibek B.

Код: plsql

where trunc(PA.MOMENT) = trunc(sysdate)

Запрос возвращает около десятка строк, выполняется моментально. PA.MOMENT проиндексирован.Где-то ты врёшь.

...

Рейтинг:

0 / 0

03.11.2016, 15:37

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39340999

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

А зачем мне врать, спрашивая совета на форуме?
Запрос выполняется 80мс, я считаю это моментальным.

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.

------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                              |                        |     1 |    71 |  1509   (1)| 00:00:19 |
|   1 |  HASH GROUP BY                                |                        |     1 |    71 |  1509   (1)| 00:00:19 |
|   2 |   VIEW                                        |                        |     1 |    71 |  1509   (1)| 00:00:19 |
|*  3 |    FILTER                                     |                        |       |       |            |          |
|   4 |     HASH GROUP BY                             |                        |     1 |   486 |  1509   (1)| 00:00:19 |
|   5 |      NESTED LOOPS OUTER                       |                        |     1 |   486 |  1508   (1)| 00:00:19 |
|   6 |       VIEW                                    |                        |     1 |   450 |  1507   (1)| 00:00:19 |
|   7 |        NESTED LOOPS OUTER                     |                        |     1 |   730 |  1507   (1)| 00:00:19 |
|   8 |         VIEW                                  |                        |     1 |   702 |  1505   (1)| 00:00:19 |
|*  9 |          TABLE ACCESS BY INDEX ROWID          | BM_SERVICE_MONEY       |     1 |    31 |   253   (0)| 00:00:04 |
|  10 |           NESTED LOOPS                        |                        |     1 |   250 |  1505   (1)| 00:00:19 |
|  11 |            NESTED LOOPS                       |                        |     1 |   219 |  1251   (1)| 00:00:16 |
|  12 |             NESTED LOOPS                      |                        |     3 |   624 |  1248   (1)| 00:00:15 |
|  13 |              NESTED LOOPS                     |                        |    22 |  4048 |   908   (1)| 00:00:11 |
|  14 |               NESTED LOOPS                    |                        |    14 |  2436 |   867   (1)| 00:00:11 |
|* 15 |                HASH JOIN                      |                        |   107 | 13803 |   207   (2)| 00:00:03 |
|  16 |                 NESTED LOOPS                  |                        |   302 | 25670 |    11  (10)| 00:00:01 |
|* 17 |                  HASH JOIN                    |                        |   302 | 24160 |    11  (10)| 00:00:01 |
|* 18 |                   TABLE ACCESS FULL           | CASHBACK_STATUS        |     2 |    18 |     3   (0)| 00:00:01 |
|* 19 |                   HASH JOIN                   |                        |   402 | 28542 |     8  (13)| 00:00:01 |
|  20 |                    TABLE ACCESS BY INDEX ROWID| CASHBACK_ACL           |     6 |   234 |     1   (0)| 00:00:01 |
|  21 |                     NESTED LOOPS              |                        |     6 |   288 |     4   (0)| 00:00:01 |
|  22 |                      TABLE ACCESS FULL        | CASHBACK_TYPES         |     1 |     9 |     3   (0)| 00:00:01 |
|* 23 |                      INDEX RANGE SCAN         | CASHBACK_ACL_TYPE      |     6 |       |     0   (0)| 00:00:01 |
|  24 |                    TABLE ACCESS FULL          | CASHBACK               |    67 |  1541 |     3   (0)| 00:00:01 |
|* 25 |                  INDEX UNIQUE SCAN            | CUSTOMERS_PK           |     1 |     5 |     0   (0)| 00:00:01 |
|* 26 |                 TABLE ACCESS FULL             | SERVICES               | 29747 |  1278K|   195   (2)| 00:00:03 |
|* 27 |                TABLE ACCESS FULL              | BM_TARIFF              |     1 |    45 |     6   (0)| 00:00:01 |
|  28 |               TABLE ACCESS BY INDEX ROWID     | BM_SERVICE_TARIFF      |     2 |    20 |     3   (0)| 00:00:01 |
|* 29 |                INDEX RANGE SCAN               | SERTARIFF_SERVICE_IDX  |     2 |       |     1   (0)| 00:00:01 |
|* 30 |              TABLE ACCESS BY INDEX ROWID      | BM_PERIODIC_ACCT       |     1 |    24 |    51   (0)| 00:00:01 |
|* 31 |               INDEX RANGE SCAN                | PER_ACCT_SERVICE_IDX   |    57 |       |     2   (0)| 00:00:01 |
|* 32 |             TABLE ACCESS BY INDEX ROWID       | BM_TARIFFEL            |     1 |    11 |     1   (0)| 00:00:01 |
|* 33 |              INDEX UNIQUE SCAN                | TAREL_PK               |     1 |       |     0   (0)| 00:00:01 |
|* 34 |            INDEX RANGE SCAN                   | SVRM_PERIODIC_ACCT_IDX |   333 |       |     2   (0)| 00:00:01 |
|* 35 |         TABLE ACCESS BY INDEX ROWID           | SERVICES_EXT           |     1 |    28 |     2   (0)| 00:00:01 |
|* 36 |          INDEX RANGE SCAN                     | SRV_EXT_SRV_ID_IDX     |     1 |       |     1   (0)| 00:00:01 |
|* 37 |       TABLE ACCESS BY INDEX ROWID             | DICT                   |     1 |    36 |     1   (0)| 00:00:01 |
|* 38 |        INDEX UNIQUE SCAN                      | DICT_QUNIQ_IDX         |     1 |       |     0   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------------------

...

Рейтинг:

0 / 0

03.11.2016, 16:48

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39341018

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

PA это BM_PERIODIC_ACCT.
DDL такой:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

CREATE TABLE BM_PERIODIC_ACCT
(
  PERIODIC_ACCT_ID      NUMBER                  NOT NULL,
  SERVICE_TARIFF_ID     NUMBER                  NOT NULL,
  TARIFFEL_ID           NUMBER                  NOT NULL,
  PERIOD_START          DATE                    NOT NULL,
  PERIOD_STOP           DATE                    NOT NULL,
  MOMENT                DATE                    NOT NULL,
  PERIOD_CF             NUMBER(15,5)            NOT NULL,
  POSTPAID_CALC_MOMENT  DATE
);

CREATE INDEX PER_ACCT_MOMENT_IDX ON BM_PERIODIC_ACCT (MOMENT);
CREATE INDEX PER_ACCT_SERVICE_IDX ON BM_PERIODIC_ACCT (SERVICE_TARIFF_ID);
CREATE INDEX PER_ACCT_START_IDX ON BM_PERIODIC_ACCT (PERIOD_START);
CREATE INDEX PER_ACCT_STOP_IDX ON BM_PERIODIC_ACCT (PERIOD_STOP);
CREATE INDEX PER_ACCT_TARIFFEL_IDX ON BM_PERIODIC_ACCT (TARIFFEL_ID);
CREATE UNIQUE INDEX PERIODIC_ACCT_PK ON BM_PERIODIC_ACCT (PERIODIC_ACCT_ID);

...

Рейтинг:

0 / 0

03.11.2016, 16:57

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39341051

Elic

Участник

Сообщения: 30 360

Рейтинг: 0 / 0

Alibek B.А зачем мне врать, спрашивая совета на форуме?Потому что маловероятно, что ты никак не можешь догнать, что моментальная проиндексированность никакой погоды не делает.

...

Рейтинг:

0 / 0

03.11.2016, 17:34

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39341123

Alibek B

Участник

Сообщения: 3 885

Рейтинг: 0 / 0

Я как-бы о другом говорил.
Поскольку PA.MOMENT проиндексировано, то условие PA.MOMENT > CB.CHANGED должно использовать индекс и не должно быть причиной долгого выполнения запроса.
Поэтому причиной долгого выполнения запроса при условии PA.MOMENT > CB.CHANGED должно быть не отсутствие индексов (для PA.MOMENT или CB.CHANGED), а что-то другое.
Но мне непонятно, что это может быть, если при условии trunc(PA.MOMENT) = trunc(sysdate) запрос выполняется моментально, кардинальность в обоих вариантах различается не так уж и сильно.

...

Рейтинг:

0 / 0

03.11.2016, 19:08

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39341329

Вячеслав Любомудров

Участник

Откуда: Владивосток

Сообщения: 18 655

Рейтинг: 0 / 0

ElicAlibek B.

Код: plsql

where trunc(PA.MOMENT) = trunc(sysdate)

Запрос возвращает около десятка строк, выполняется моментально. PA.MOMENT проиндексирован.Где-то ты врёшь.Ну почему же
С некоторых версий нормально юзает индекс по дате при TRUNC (INDEX FULL SCAN)
А с использованием Transitive Closure (с 10.2, вроде) может юзать CHECK констрэйнты и использовать нормальный IRS

Код: plsql

tst> create table t1 as select rownum id, trunc(sysdate)+rownum-5 dt from dual connect by level <= 10;

Table created.

tst> create index t1_idx on t1(dt);

Index created.

tst> exec dbms_stats.gather_table_stats(user, 't1', cascade=>true)

PL/SQL procedure successfully completed.

tst> select count(*) from t1 where trunc(dt) =  trunc(sysdate);

  COUNT(*)
----------
         1

tst> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------
SQL_ID  1x3wvdx30ffpy, child number 0
-------------------------------------
select count(*) from t1 where trunc(dt) =  trunc(sysdate)

Plan hash value: 3693069535

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |     3 (100)|          |
|   1 |  SORT AGGREGATE    |      |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| T1   |     1 |     8 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   2 - filter(TRUNC(INTERNAL_FUNCTION("DT"))=TRUNC(SYSDATE@!))


19 rows selected.

tst> alter table t1 modify (dt not null);

Table altered.

tst> select count(*) from t1 where trunc(dt) =  trunc(sysdate);

  COUNT(*)
----------
         1

tst> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------
SQL_ID  1x3wvdx30ffpy, child number 0
-------------------------------------
select count(*) from t1 where trunc(dt) =  trunc(sysdate)

Plan hash value: 2615206913

---------------------------------------------------------------------------
| Id  | Operation        | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT |        |       |       |     1 (100)|          |
|   1 |  SORT AGGREGATE  |        |     1 |     8 |            |          |
|*  2 |   INDEX FULL SCAN| T1_IDX |     1 |     8 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   2 - filter(TRUNC(INTERNAL_FUNCTION("DT"))=TRUNC(SYSDATE@!))


19 rows selected.

tst> alter table t1 add constraint t1_chk check(dt=trunc(dt));

Table altered.

tst> select count(*) from t1 where trunc(dt) =  trunc(sysdate);

  COUNT(*)
----------
         1

tst> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------
SQL_ID  1x3wvdx30ffpy, child number 0
-------------------------------------
select count(*) from t1 where trunc(dt) =  trunc(sysdate)

Plan hash value: 657220527

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |       |       |     1 (100)|          |
|   1 |  SORT AGGREGATE   |        |     1 |     8 |            |          |
|*  2 |   INDEX RANGE SCAN| T1_IDX |     1 |     8 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------

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

   2 - access("DT"=TRUNC(SYSDATE@!))
       filter(TRUNC(INTERNAL_FUNCTION("DT"))=TRUNC(SYSDATE@!))


20 rows selected.

...

Рейтинг:

0 / 0

04.11.2016, 08:10

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39341334

Elic

Участник

Сообщения: 30 360

Рейтинг: 0 / 0

Вячеслав ЛюбомудровНу почему жеЗдесь и по духу, и по факту не тот случай.

...

Рейтинг:

0 / 0

04.11.2016, 08:43

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39341381

AlexFF__|

Участник

Сообщения: 2 776

Рейтинг: 0 / 0

Вячеслав ЛюбомудровElicпропущено...
Где-то ты врёшь.Ну почему же
С некоторых версий нормально юзает индекс по дате при TRUNC (INDEX FULL SCAN)
А с использованием Transitive Closure (с 10.2, вроде) может юзать CHECK констрэйнты и использовать нормальный IRS
Слишком притянуто за уши )
Первый случай чистый подлог, использующий факт нахождения всех нужных данных в индексе.
Во втором случае фокус не работает с bind.
К запросу ТС это не имеет отношения.

...

Рейтинг:

0 / 0

04.11.2016, 11:53

| Ответить | Цитировать | Написать

Подскажите, как правильно составить запрос, чтобы эффективно использовались индексы

#39341412

Вячеслав Любомудров

Участник

Откуда: Владивосток

Сообщения: 18 655

Рейтинг: 0 / 0

Да нет, конечно
Мне просто показалось, что Elic намекает на то, что в данном случае индекс не будет использован (каюсь, смотрел только на заголовок темы, в тонкости не вникал)

...

Рейтинг:

0 / 0

04.11.2016, 13:04

| Ответить | Цитировать | Написать

60 сообщений из 60, показаны все 3 страниц

все

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=52&tid=1887083]:	0ms
get settings:	4ms
get forum list:	8ms
check forum access:	2ms
check topic access:	2ms
track hit:	138ms
get topic data:	6ms
get forum data:	2ms
get page messages:	48ms
get tp. blocked users:	1ms
others:	206ms

total:	417ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы