[ОТВЕТИТЬ]
Опции темы
22.08.2006 16:34  
bob
Оптимайзером прошел с ключом /optimize. Все нормально.Создал эталон на пустой базе. Сравнил. Различия только в ограничениях:
Отсутствует ограничение SYS_C001977 таблицы SMUSEROP ("ID" IS NOT NULL)
Отсутствует ограничение SYS_C003627 таблицы TTZLONGDATA
Отсутствует ограничение SYS_C005503 таблицы SVLOCALSHOPS
Отсутствует ограничение SYS_C005504 таблицы SVPRODGOODSART
Лишнее ограничение SYS_C003191 таблицы TTZLONGDATA

Не большой спец, но кажется дело не в этом.
На пустой, базе завел накладную и распечатал - все нормально.
Проблема с индексами, кто подскажет?
 
22.08.2006 16:40  
OlegON
Поубивай и создай заново на smcard. Quest Space Manager тебе в руки.
 
22.08.2006 16:49  
bob
Спасибо за помощь, нам тоже так показалось. С "поубивай и создай" разберемся. Но завтра еще разверну копию до апгрейда и проделаю всю процедуру заново, попробую разобраться, откуда ноги растут
 
22.08.2006 17:11  
bob
Ну вот, все оказалось, гораздо проще. Убрал optimizer_index_caching = 90 и все заработало.
Olegon, не подскажешь сколько его можно поставить? Экспериментально от 0 до 90 пробовать и ну жен ли он вообще?
 
22.08.2006 17:18  
OlegON
Фигасе... Странно что-то. Глюк. Думаю, что стоит их все попереубивать и создать. Что-то здесь нечисто. Патчи не забыл никакие?

OPTIMIZER_INDEX_CACHING

Parameter type:

Integer
Parameter class:

Dynamic. Scope = ALTER SESSION.
Default value:

0
Range of values:

0 to 100

OPTIMIZER_INDEX_CACHING lets you adjust the behavior of cost-based optimization to favor nested loops joins and IN-list iterators.

The cost of executing an index using an IN-list iterator or of executing a nested loops join when an index is used to access the inner table depends on the caching of that index in the buffer cache. The amount of caching depends on factors that the optimizer cannot predict, such as the load on the system and the block access patterns of different users.

You can modify the optimizer's assumptions about index caching for nested loops joins and IN-list iterators by setting this parameter to a value between 0 and 100 to indicate the percentage of the index blocks the optimizer should assume are in the cache. Setting this parameter to a higher value makes nested loops joins and IN-list iterators look less expensive to the optimizer. As a result, it will be more likely to pick nested loops joins over hash or sort-merge joins, and to pick indexes using IN-list iterators over other indexes or full table scans. The default for this parameter is 0, which results in default optimizer behavior.
 
22.08.2006 17:21  
OlegON
Пока не поубивал - сними план запроса, который тормозил (тот, что выше). Выставление его в 90 или близкие значения существенно увеличивают производительность.
 
22.08.2006 17:47  
bob
На 80 нормально отрабатывает. 85 уже виснет. План запроса завтра выложу, когда программист придет. Сам не умею. А вообще всегда все нормально работали, если бы у каго были проблемы, давно бы вылезло наружу (по крайней мере я так думаю)
 
22.08.2006 19:07  
bob
Также зависает и на пустой базе, с которой брал эталон (пройдена оптимайзером)(только инициализация подчиненной базы и создана одна расходная накладная). Железо абсолютно аналогичное боевому серваку (благо у меня их сейчас несколько). Так что дело только в этом параметре и индексы тут ни при чем. Функция SUPERMAG.GET_BARCODEDATE, при помощи которой и формируется этот злополучный запрос. Если запрос немного изменить (iwinter выше писала), то все проходит нормально
 
22.08.2006 19:09  
bob
Патчи абсолютно точно для 8-ки все стоят (мы эти тестовые серваки потоком переставляем для развлечения *06 )
 
22.08.2006 20:25  
OlegON
Он виснет или все таки винты грузит? Уж больно похоже, что индексы навернулись.
 
 


Опции темы



Часовой пояс GMT +3, время: 01:16.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.