ReSQL.ru
     
powered by simpleCommunicator - 2.0.39     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / статистика
25 сообщений из 28, страница 1 из 2
  1  все
статистика
    #32046660
Фотография Lexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lexis
Участник
Построил статистику по индексам и таблицам - упала производительность...как правильно строить статитсику, что принимать во внимание?
...
Рейтинг: 0 / 0
28.08.2002, 22:00
| Ответить | Цитировать | Написать  
статистика
    #32046661
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>как правильно строить статитсику, что принимать во
>внимание?

Опишите свое приложение. Какой режим оптимизатора? Используются ли хинты в запросах? Найдите наиболее медленные запросы и помотрите план выполнения.
...
Рейтинг: 0 / 0
28.08.2002, 22:25
| Ответить | Цитировать | Написать  
статистика
    #32046757
Фотография Lexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lexis
Участник
в файле ini режим оптимизатора не прописан, значит будет выбираться RBO при отсутствии статистики? Хинтов в запросе нет, в плане выполнения запроса FTS отсутствует. Когда удалил статистику, скорость выполнения запросов увеличилась. Правильно ля я понимаю, что после создания статистики надо заново отлаживать запросы?
...
Рейтинг: 0 / 0
29.08.2002, 11:43
| Ответить | Цитировать | Написать  
статистика
    #32046791
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>в файле ini режим оптимизатора не прописан, значит
>будет выбираться RBO при отсутствии статистики?

это зависит от версии. Кажется начиная с 8-ки по дефолту (независимо от наличия статистики) CBO

покажите свои параметры (вот мои, например):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
 SQL> conn system/manager@lyr_z
Connect durchgef³hrt.
SQL> show parameter opt

NAME                                 TYPE    VALUE
 ------------------------------------ ------- ------
 
object_cache_optimal_size            integer  102400 
optimizer_features_enable            string   8 . 1 . 7 
optimizer_index_caching              integer  0 
optimizer_index_cost_adj             integer  5 
optimizer_max_permutations           integer  80000 
optimizer_mode                       string  CHOOSE
optimizer_percent_parallel           integer  0 
SQL>


>Хинтов в запросе нет, в плане выполнения запроса FTS
>отсутствует. Когда удалил статистику, скорость
>выполнения запросов увеличилась.

Приведите план выполнения запроса. После этого можно будет сказать определеннее в чем проблема.

>Правильно ля я
>понимаю, что после создания статистики надо заново
>отлаживать запросы?

В общем случае нет. Если статистика собирается регулярно (или когда необходимо), необходимые индесы созданы, ненужные удалены, а также хорошо подобраны параметры влияющие на работу оптимизатора.
...
Рейтинг: 0 / 0
29.08.2002, 12:55
| Ответить | Цитировать | Написать  
статистика
    #32046827
Noname
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Noname
Гость
По умолчанию используется CHOOSE. При этом если ни для одной таблицы в запросе не существует статистики, то используется RBO. Если хоть для одной -- то CBO с расчетом статистики для всех таблиц из запроса, не имеющих статистики. Вообще, использовать CHOOSE не рекомендуется. Лучше явно указывать оптимизатор. Ну а насчет CBO можно сказать, что это старая проблема Oracle. Им до сих пор не удалось создать хороший CBO. В системах, для которых созданы хорошие CBO (например, Informix), уже давно отказались от использования RBO.
...
Рейтинг: 0 / 0
29.08.2002, 13:54
| Ответить | Цитировать | Написать  
статистика
    #32046862
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>Ну а насчет CBO можно сказать, что это старая проблема
>Oracle. Им до сих пор не удалось создать хороший CBO.

А мне вот нравится оракловский CBO. Глупо только, что они для optimizer_index_cost_adj выбрали дефолтное значение 100. Не все ж data warehouse юзают.

Вообще если вы так утверждаете, то приведите, пожалуйста примеры того, что CBO плох.
...
Рейтинг: 0 / 0
29.08.2002, 14:44
| Ответить | Цитировать | Написать  
статистика
    #32046882
Noname
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Noname
Гость
>Вообще если вы так утверждаете, то приведите, пожалуйста примеры того, что CBO плох.


А разве данная тема не является ответом на ваш вопрос?
...
Рейтинг: 0 / 0
29.08.2002, 15:38
| Ответить | Цитировать | Написать  
статистика
    #32046884
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>А разве данная тема не является ответом на ваш вопрос?

Нет конечно, т.к. мы все-таки не выяснили в чем причина. Я предпочитаю владеть полной информацией прежде чем делать какие-либо выводы.
...
Рейтинг: 0 / 0
29.08.2002, 15:43
| Ответить | Цитировать | Написать  
статистика
    #32046887
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
2 Noname

посмотрите 9-ку. Там вопрос связных переменных решен насколько я знаю
...
Рейтинг: 0 / 0
29.08.2002, 15:46
| Ответить | Цитировать | Написать  
статистика
    #32046892
Noname
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Noname
Гость
По опыту могу сказать, что для Oracle лучше использовать RBO с хинтами.
...
Рейтинг: 0 / 0
29.08.2002, 15:59
| Ответить | Цитировать | Написать  
статистика
    #32046898
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
У меня противоположное мнение (также по опыту)
...
Рейтинг: 0 / 0
29.08.2002, 16:14
| Ответить | Цитировать | Написать  
статистика
    #32046899
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>По опыту могу сказать, что для Oracle лучше
>использовать RBO с хинтами.

Возможно это позволит вам максимально оптимизировать текущие запросы, но сам по себе этот путь тупиковый. Потому что используя хинты вы фактически используете CBO, т.е. сбор статистики в этом случае "испортит" ваш план выполнения. Т.е. вам надо самостоятельно следить за ростом базы и настраивать до 100% запросов.
...
Рейтинг: 0 / 0
29.08.2002, 16:15
| Ответить | Цитировать | Написать  
статистика
    #32046933
ora600
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora600
Участник
2 Noname
А как быть в типичнейшей ситуации - приложение динамически генерирует условие для фильтра ?
Генерировать хинт ? Закладываться на жесткий набор объектов БД ( индексы и их имена в хинтах ) ?
...
Рейтинг: 0 / 0
29.08.2002, 17:33
| Ответить | Цитировать | Написать  
статистика
    #32046988
Фотография Lexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lexis
Участник
завтра покажу все данные, которые нужны..сервер на работе остался
сегодня смотрел планы запросов в зависимости от наличия статистики или её отсутствия..при наличии статистики появляются FTS
...
Рейтинг: 0 / 0
29.08.2002, 23:25
| Ответить | Цитировать | Написать  
статистика
    #32046989
Фотография Lexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lexis
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
NAME                                 TYPE    VALUE
 ------------------------------------ ------- ---------
 
object_cache_optimal_size            integer  102400 
optimizer_features_enable            string   8 . 1 . 7 
optimizer_index_caching              integer  0 
optimizer_index_cost_adj             integer  100 
optimizer_max_permutations           integer  80000 
optimizer_mode                       string  CHOOSE
optimizer_percent_parallel           integer  0
...
Рейтинг: 0 / 0
29.08.2002, 23:32
| Ответить | Цитировать | Написать  
статистика
    #32047064
Noname
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Noname
Гость
2ora600:
Панацеи не существует! Если-бы какой-то оптимизатор однозначно превосходил другой, то этого другого не существовало-бы. Тем не менее RBO+hint=CBO(all_rows) обычно обеспечивает немного меньшую стоимость, чем просто CBO(all_rows).
...
Рейтинг: 0 / 0
30.08.2002, 10:48
| Ответить | Цитировать | Написать  
статистика
    #32047082
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>сегодня смотрел планы запросов в зависимости от
>наличия статистики или её отсутствия..при наличии
>статистики появляются FTS

Ну скорее всего то о чем я и говорил:
Код: plaintext
optimizer_index_cost_adj             integer  100


Поставьте от 1 до 5 и посмотрите план (со статистикой естественно). Лучше сначала только для сессии в которой план смотрите.
...
Рейтинг: 0 / 0
30.08.2002, 11:48
| Ответить | Цитировать | Написать  
статистика
    #32047118
Фотография Lexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lexis
Участник
а как лучше статистику собирать? там несколько параметров (SIZE, Table, Ibdex, compute, estimate.....)?
...
Рейтинг: 0 / 0
30.08.2002, 12:50
| Ответить | Цитировать | Написать  
статистика
    #32047127
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>а как лучше статистику собирать? там несколько
>параметров (SIZE, Table, Ibdex, compute, estimate.....)?

Сбор статистики связан с некоторыми накладными расходами (например FTS), поэтому если есть узкие места, а таблицы очень большие, то статистику надо собирать по минимуму - только столько, сколько необходимо для нормальной работы оптимизатора (используя estimate, samle size и т.д.)

Если же не критично, то лучше всего с использованием процедуры DBMS_STATS.GATHER_SCHEMA_STATS с параметрами по умолчанию. Можно организовать job и запускать на ночь.
...
Рейтинг: 0 / 0
30.08.2002, 13:09
| Ответить | Цитировать | Написать  
статистика
    #32047248
Фотография Lexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lexis
Участник
потестировал
запрос стал работать несколько быстрее, но не догнал по производительности RBO. Лучше всего получилось при
optimizer_index_cost_adj=1
optimizer_index_caching=90
может еще что подкрутить? какие счетчики желательно проверить?
...
Рейтинг: 0 / 0
30.08.2002, 18:02
| Ответить | Цитировать | Написать  
статистика
    #32047255
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>может еще что подкрутить? какие счетчики желательно
>проверить?

дык не видя планов выполнения запросов сказать ничего нельзя. По крайней мере я не оракУл :-)
...
Рейтинг: 0 / 0
30.08.2002, 18:48
| Ответить | Цитировать | Написать  
статистика
    #32047281
Фотография Lexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lexis
Участник
тело запроса
Код: 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.
SELECT 	AoAdInfo.ID AS AdID, 
	AoAdInfo.AdNumber AS AdNumber, 
	AoAdType.Name AS Type, 
	AoAdContent.NumColumns AS NumColumns, 
	AoAdContent.NumLines AS NumLines, 
	Customer.Name1 AS Customer, 
	AoAdOrder.AdOrderNumber AS OrderNumber, 
	AoProducts.Name AS ProductName, 
	AoEditions.Name AS EditionName, 
	AoZones.Name AS ZoneName, 
	AoAdProdStatus.Name AS Status, 
	AoAdRunDates.StartDate AS StartDate, 
	AoAdRunDates.EndDate AS EndDate, 
	AoAdContent.AdWidth AS Width, 
	AoAdContent.AdDepth AS Depth, 
	AoAdInfo.AssignedTo AS AssignedTo_ID, 
	U1.UserFname AS AssignedTo_FName, 
	U1.UserMname AS AssignedTo_MName, 
	U1.UserLname AS AssignedTo_LName, 
	U1.JobTitle AS AssignedTo_JobTitle, 
	AoAdInfo.FileCreatorID AS Application, 
	ShBlobData.BlobBytes AS EpsImageSize, 
	LockObject.UserID AS LockedBy_ID, 
	U2.UserFname AS LockedBy_FName, 
	U2.UserMname AS LockedBy_MName, 
	U2.UserLname AS LockedBy_LName, 
	U2.JobTitle  AS LockedBy_JobTitle 
FROM 	adbase.AoAdType, 
	adbase.Customer, 
	adbase.AoOrderCustomers, 
	adbase.AoAdRunDates, 
	adbase.AoAdInfo, 
	adbase.AoAdOrder, 
	adbase.AoAdContent, 
	adbase.AoAdRunSchedule, 
	adbase.AoProducts, 
	adbase.AoEditions, 
	adbase.AoZones, 
	adbase.AoAdProdStatus, 
	adbase.UsrUsers U1, 
	adbase.ShBlobData, 
	adbase.LockObject, 
	adbase.UsrUsers U2 
WHERE AoAdType.ID = AoAdInfo.AdTypeID AND 
	AoAdContent.AdInfoID = AoAdInfo.ID AND 
	Customer.AccountID = AoOrderCustomers.CustomerID AND 
	AoOrderCustomers.AdOrderID = AoAdOrder.ID AND 
	AoOrderCustomers.OrderedBy = '1' AND 
	AoOrderCustomers.PrimaryOrdererFlag = '1' AND 
	AoAdOrder.ID = AoAdRunSchedule.AdOrderID AND 
	AoAdRunSchedule.AdID = AoAdInfo.ID AND 
	AoAdRunSchedule.EditionID = AoEditions.ID(+) AND 
	AoAdRunSchedule.ZoneID = AoZones.ID(+) AND 
	AoAdInfo.AssignedTo = U1.UserID(+) AND 
	AoAdRunSchedule.ProductID = AoProducts.ID(+) AND 
	AoAdInfo.ProdStatusID = AoAdProdStatus.ID(+) AND 
	AoAdContent.EPSBlobID = ShBlobData.ID(+) AND 
	LockObject.ObjectID(+) = AoAdOrder.ID AND 
	LockObject.ObjectType(+) =  2  AND 
	LockObject.UserID = U2.UserID(+) AND 
	AoAdRunDates.AdRunScheduleID = AoAdRunSchedule.ID AND 
	AoAdInfo.PubContentVer = AoAdContent.VersionNum and 
	rownum< 5

на базе без статистики
Код: 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.
Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    COUNT (STOPKEY)
    2      1      NESTED LOOPS
    3      2        NESTED LOOPS
    4      3          NESTED LOOPS
    5      4            NESTED LOOPS (OUTER)
    6      5              NESTED LOOPS
    7      6                NESTED LOOPS (OUTER)
    8      7                  NESTED LOOPS (OUTER)
    9      8                    NESTED LOOPS
   10      9                      NESTED LOOPS (OUTER)
   11     10                        NESTED LOOPS (OUTER)
   12     11                          NESTED LOOPS
   13     12                            NESTED LOOPS
   14     13                              NESTED LOOPS (OUTER)
   15     14                                NESTED LOOPS (OUTER)
   16     15                                  NESTED LOOPS (OUTER)
   17     16                                    TABLE ACCESS (FULL) OF 'AOADRUNSCHEDULE'
   18     16                                    TABLE ACCESS (BY INDEX ROWID) OF 'AOZONES'
   19     18                                      INDEX (UNIQUE SCAN) OF 'PK_AOZONES' (UNIQUE)
   20     15                                  TABLE ACCESS (BY INDEX ROWID) OF 'AOEDITIONS'
   21     20                                    INDEX (UNIQUE SCAN) OF 'PK_AOEDITIONS' (UNIQUE)
   22     14                                TABLE ACCESS (BY INDEX ROWID)  OF 'AOPRODUCTS'
   23     22                                  INDEX (UNIQUE SCAN) OF 'PK_AOPRODUCTS' (UNIQUE)
   24     13                              TABLE ACCESS (BY INDEX ROWID) OF 'AOADORDER'
   25     24                                INDEX (UNIQUE SCAN) OF 'PK_AOADORDER' (UNIQUE)
   26     12                            TABLE ACCESS (BY INDEX ROWID) OF 'AOADINFO'
   27     26                              INDEX (UNIQUE SCAN) OF 'PK_AOADINFO' (UNIQUE)
   28     11                          TABLE ACCESS (BY INDEX ROWID) OF 'USRUSERS'
   29     28                            INDEX (UNIQUE SCAN) OF 'PK_USRUSERS' (UNIQUE)
   30     10                        TABLE ACCESS (BY INDEX ROWID) OF 'AOADPRODSTATUS'
   31     30                          INDEX (UNIQUE SCAN) OF 'PK_AOADPRODSTATUS' (UNIQUE)
   32      9                      TABLE ACCESS (BY INDEX ROWID) OF 'AOADTYPE'
   33     32                        INDEX (UNIQUE SCAN) OF 'PK_AOADTYPE' (UNIQUE)
   34      8                    TABLE ACCESS (BY INDEX ROWID) OF 'LOCKOBJECT'
   35     34                      INDEX (RANGE SCAN) OF 'PK_LOCKOBJECT' (NON-UNIQUE)
   36      7                  TABLE ACCESS (BY INDEX ROWID) OF 'USRUSERS'
   37     36                    INDEX (UNIQUE SCAN) OF 'PK_USRUSERS' (UNIQUE)
   38      6                TABLE ACCESS (BY INDEX ROWID) OF 'AOADCONTENT'
   39     38                  INDEX (RANGE SCAN) OF 'IDX_AOADCONTENT1' (NON-UNIQUE)
   40      5              TABLE ACCESS (BY INDEX ROWID) OF 'SHBLOBDATA'
   41     40                INDEX (UNIQUE SCAN) OF 'PK_SHBLOBDATA' (UNIQUE)
   42      4            TABLE ACCESS (BY INDEX ROWID) OF 'AOADRUNDATES'
   43     42              INDEX (RANGE SCAN) OF 'IDX_AOADRUNDATES1' (NON-UNIQUE)
   44      3          TABLE ACCESS (BY INDEX ROWID) OF 'AOORDERCUSTOMERS'
   45     44            INDEX (RANGE SCAN) OF 'IDX_AOORDERCUSTOMERS1' (NON-UNIQUE)
   46      2        TABLE ACCESS (BY INDEX ROWID) OF 'CUSTOMER'
   47     46          INDEX (UNIQUE SCAN) OF 'PK_CUSTOMER' (UNIQUE)

Statistics
 ----------------------------------------------------------
 
           0   recursive calls
           4   db block gets
         117   consistent gets
           0   physical reads
           0   redo size
        2603   bytes sent via SQL*Net to client
         650   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           4   rows processed

SQL>

на базе со статистикой
Код: 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.
Elapsed:  00 : 00 : 02 . 56 

Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 114  Card= 227  Bytes= 6 
           6057 )

    1      0    COUNT (STOPKEY)
    2      1    NESTED LOOPS (OUTER) (Cost= 114  Card= 227  Bytes= 66057 )
    3      2    NESTED LOOPS (Cost= 112  Card= 227  Bytes= 64014 )
    4      3    NESTED LOOPS (Cost= 110  Card= 183  Bytes= 47946 )
    5      4    NESTED LOOPS (OUTER) (Cost= 108  Card= 183  Bytes= 45201 )
    6      5    NESTED LOOPS (Cost= 106  Card= 183  Bytes= 39894 )
    7      6    NESTED LOOPS (OUTER) (Cost= 100  Card= 680  Bytes= 139400 )
    8      7    NESTED LOOPS (Cost= 93  Card= 680  Bytes= 132600 )
    9      8    NESTED LOOPS (OUTER) (Cost= 86  Card= 680  Bytes= 122400 )
   10      9    NESTED LOOPS (OUTER) (Cost= 79  Card= 680  Bytes= 110160 )
   11     10    NESTED LOOPS (OUTER) (Cost= 72  Card= 680  Bytes= 102680 )
   12     11    NESTED LOOPS (Cost= 66  Card= 680  Bytes= 96560 )
   13     12    NESTED LOOPS (Cost= 60  Card= 596  Bytes= 66156 )
   14     13    NESTED LOOPS (OUTER) (Cost= 42  Card= 1771  Bytes= 154077 )
   15     14    NESTED LOOPS (OUTER) (Cost= 24  Card= 1771  Bytes= 102718 )
   16     15    HASH JOIN (Cost= 6  Card= 1771   Bytes= 79695 )
   17     16    TABLE ACCESS (FULL) OF 'AOADTYPE' (Cost= 1  Card= 11  Bytes= 165 )
   18     16    TABLE ACCESS (FULL) OF 'AOADINFO' (Cost= 3  Card= 1776  Bytes= 53280 )
   19     15    TABLE ACCESS (BY INDEX ROWID) OF 'AOADPRODSTATUS' (Cost= 1  Card= 10  Bytes= 130 )
   20     19    INDEX (UNIQUE SCAN) OF 'PK_AOADPRODSTATUS' (UNIQUE)
   21     14    TABLE ACCESS (BY INDEX ROWID) OF 'USRUSERS' (Cost= 1  Card= 14  Bytes= 406 )
   22     21    INDEX (UNIQUE SCAN) OF 'PK_USRUSERS' (UNIQUE)
   23     13    TABLE ACCESS (BY INDEX ROWID) OF 'AOADCONTENT' (Cost= 1  Card= 1800  Bytes= 43200 )
   24     23    INDEX (RANGE SCAN) OF 'IDX_AOADCONTENT1' (NON-UNIQUE)
   25     12    TABLE ACCESS (BY INDEX ROWID) OF 'AOADRUNSCHEDULE' (Cost= 1  Card= 2031  Bytes= 62961 )
   26     25    INDEX (RANGE SCAN) OF 'IDX_AOADRUNSCHEDULE1' (NON-UNIQUE)
   27     11    TABLE ACCESS (BY INDEX ROWID) OF 'AOEDITIONS' (Cost= 1  Card= 1  Bytes= 9 )
   28     27    INDEX (UNIQUE SCAN) OF 'PK_AOEDITIONS' (UNIQUE)
   29     10    TABLE ACCESS (BY INDEX ROWID) OF 'AOZONES' (Cost= 1  Card= 7  Bytes= 77 )
   30     29    INDEX (UNIQUE SCAN) OF 'PK_AOZONES' (UNIQUE)
   31      9    TABLE ACCESS (BY INDEX ROWID) OF 'AOPRODUCTS' (Cost= 1  Card= 17  Bytes= 306 )
   32     31    INDEX (UNIQUE SCAN) OF 'PK_AOPRODUCTS' (UNIQUE)
   33      8    TABLE ACCESS (BY INDEX ROWID) OF 'AOADORDER' (Cost= 1  Card= 1720  Bytes= 25800 )
   34     33    INDEX (UNIQUE SCAN) OF 'PK_AOADORDER' (UNIQUE)
   35      7    TABLE ACCESS (BY INDEX ROWID) OF 'LOCKOBJECT' (Cost= 1  Card= 11  Bytes= 110 )
   36     35    INDEX (UNIQUE SCAN) OF 'PK_LOCKOBJECT' (UNIQUE)
   37      6    TABLE ACCESS (BY INDEX ROWID) OF 'AOORDERCUSTOMERS' (Cost= 1  Card= 460  Bytes= 5980 )
   38     37    INDEX (RANGE SCAN) OF 'IDX_AOORDERCUSTOMERS1 ' (NON-UNIQUE)
   39      5    TABLE ACCESS (BY INDEX ROWID) OF 'USRUSERS' (Cost= 1  Card= 14  Bytes= 406 )
   40     39    INDEX (UNIQUE SCAN) OF 'PK_USRUSERS' (UNIQUE)
   41      4    TABLE ACCESS (BY INDEX ROWID) OF 'CUSTOMER' (Cost= 1  Card= 33  Bytes= 495 )
   42     41    INDEX (UNIQUE SCAN) OF 'PK_CUSTOMER' (UNIQUE)
   43      3    TABLE ACCESS (BY INDEX ROWID) OF 'AOADRUNDATES' (Cost= 1  Card= 2428  Bytes= 48560 )
   44     43    INDEX (RANGE SCAN) OF 'IDX_AOADRUNDATES1' (NON-UNIQUE)
   45      2    TABLE ACCESS (BY INDEX ROWID) OF 'SHBLOBDATA' (Cost= 1  Card= 2964  Bytes= 26676 )
   46     45    INDEX (UNIQUE SCAN) OF 'PK_SHBLOBDATA' (UNIQUE)




Statistics
 ----------------------------------------------------------
 
          23   recursive calls
           8   db block gets
          92   consistent gets
           0   physical reads
           0   redo size
        1611   bytes sent via SQL*Net to client
         483   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
          16   sorts (memory)
           0   sorts (disk)
           4   rows processed

SQL>
...
Рейтинг: 0 / 0
31.08.2002, 00:42
| Ответить | Цитировать | Написать  
статистика
    #32047343
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
на первый взгляд осталось только сделать:
hash_join_enabled = false
и планы выполнения станут одинаковыми.
Кстате, а какой у вас hash_area_size? Возможно, достаточно его просто уменьшить.

Вообще, интересно было бы услышать мнения других участников форума насчет hash join против nested loops.
...
Рейтинг: 0 / 0
01.09.2002, 19:59
| Ответить | Цитировать | Написать  
статистика
    #32047400
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Если сравнить статистику, то разница составляет 20 блоков.
Думаю они практически одинаково отрабатывают по времени. Вся "мощь" RBO как правило сводится к нехитрому факту: "хватаю индекс если попадется на пути". Поэтому обычно план выглядит как гирлянда из NN.

Такие запросы (соединение 16 таблиц!!) в совокупности со слабой подсистемой ВВ (усредненно) и сабоптимальной настройкой мультиблочного чтения как правило будут работать лучше по сценарию, описанному выше.

2dba: hash join - более эффективное соединение таблиц чем NN если на выходе достаточно большой сет строк и/или предикаты не селективны.
...
Рейтинг: 0 / 0
02.09.2002, 12:50
| Ответить | Цитировать | Написать  
статистика
    #32047453
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.dba
Участник
>2dba: hash join - более эффективное соединение таблиц
>чем NN если на выходе достаточно большой сет строк
>и/или предикаты не селективны.

Насчет неселективных предикатов я согласен, а вот в случаи наличия селективных предикатов/индексов и больших таблиц, то тут по-моему hash join будет проигрывать.
Вот разгребусь немного с работой - попробую примерчик сделать :-)
...
Рейтинг: 0 / 0
02.09.2002, 14:33
| Ответить | Цитировать | Написать  
25 сообщений из 28, страница 1 из 2
  1  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / статистика
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=32047281&tid=1993143]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 29ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 58ms
get tp. blocked users:
 1ms
others: 26ms
total:  154ms
созд. / загр.: 154ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]