[ОТВЕТИТЬ]
22.08.2006 10:22
bob
 
Сегодня, после нескольких дней поисков, выявили следующую вещь. При печати расходной накладной в базовой валюте в форме внутреннего штрих-кода и показывать штрих-коды, печать зависает на форматировании страницы 1. Висит активная сессия rwrbe60.exe и нагружает проц на 50 процентов, пока ее не убьешь. Если таких сессий несколько, то сервак вообще жутко тормозит. Во вкладке SQL запроса
SELECT COUNT(*) FROM SMCLIENTFUNCTIONS WHERE ID = :b1 AND ORAROLE LIKE '%' || 'PRINT' || '%'

Пробовали запускать запрос из SQL-навигатора - все отрабатывает нормально. Кто-нибудь сталкивался с подобной проблемой. Появилась у нас на версии 1024.4
22.08.2006 10:26
kadr
 
bob, Только что попробовал, печатает. Версия 1.024.4 без СП
22.08.2006 10:32
OlegON
 
В какой вкладке? Сдается, что это не самый тормозящий запрос. Прогони оптимайзера на валидацию таблиц...
22.08.2006 10:40
reddevil
 
to bob "Во вкладке SQL запроса
SELECT COUNT(*) FROM SMCLIENTFUNCTIONS WHERE ID = :b1 AND ORAROLE LIKE '%' || 'PRINT' || '%' " - вкладка не в DBA STUDIO находиться?
22.08.2006 10:45
OlegON
 
Вот я и думаю, что это про last SQL речь, а не long operations... Тогда бесполезная информация.
22.08.2006 13:23
iwinter
 
уточнение к 1-вому сообщению:
при формировании печатной формы расходной накладной
подвисает запрос (снято спотлайтом):
SELECT H.EVENTTIME,H.RECID,H.BARCODE
FROM SVSTOREUNITS U, SMCARD CRD, SMSTOREUNITHIST H
WHERE U.ARTICLE = :b1 AND (CRD.DATATYPE != 0 OR U.SUBARTICLE IS NULL ) AND
U.QUANTITY = NVL(:b2,U.QUANTITY)
AND U.BARCODETYPE = 7
AND U.ARTICLE = CRD.ARTICLE
AND U.BARCODE = H.BARCODE
AND H.EVENTTIME = (SELECT MAX(HH.EVENTTIME)
FROM SUPERMAG.SMSTOREUNITHIST HH
WHERE H.BARCODE = HH.BARCODE )
AND H.RECID = (SELECT MAX(HH.RECID)
FROM SUPERMAG.SMSTOREUNITHIST HH
WHERE H.BARCODE = HH.BARCODE AND H.EVENTTIME = HH.EVENTTIME )
AND ((:b3 = '0' ) OR BITAND(U.FLAGS,4) != 0 )

ORDER BY H.EVENTTIME DESC,H.RECID DESC,H.BARCODE DESC

Причем, если попробовать отработать его в SQL Navigator'e, то:
1. запрос отрабатывает, если исключить соединение с табл. SmCard
2. запрос отрабатывает, если при соединении таблиц добавить (+)
иначе - зависает....
22.08.2006 13:30
OlegON
 
Оптимайзера-то прогнали?
22.08.2006 13:50
kadr
 
может стоит сверить структуру с эталонном?
22.08.2006 14:36
bob
 
То Kadr. А где ее взять? Я сейчас на тестовом серваке развернул копию, которую создал сразу после перехода на 1.024.4. Там тоже самое.
To olegon. Прогонял оптимайзер неделю назад с параметром /optimize. Сейчас прогоняю еще раз.
Да, еще нашел трейсы. Создаются после убийства сессии
Dump file f:\oracle\admin\TEOREMA\udump\ORA02408.TRC
Tue Aug 22 12:02:10 2006
ORACLE V8.1.6.3.0 - Production vsnsta=0
vsnsql=e vsnxtr=3
Windows 2000 Version 5.2 Service Pack 1, v.1039, CPU type 586
Oracle8i Enterprise Edition Release 8.1.6.3.0 - Production
JServer Release 8.1.6.3.0 - Production
Windows 2000 Version 5.2 Service Pack 1, v.1039, CPU type 586
Instance name: teorema

Redo thread mounted by this instance: 1

Oracle process number: 99

Windows thread id: 2408, image: ORACLE.EXE


*** 2006-08-22 12:02:10.796
*** SESSION ID:(100.7894) 2006-08-22 12:02:10.796
FATAL ERROR IN TWO-TASK SERVER: error = 12571
*** 2006-08-22 12:02:10.796
ksedmp: internal or fatal error
ORA-00028: ┬р° ёхрэё єфрыхэ
ORA-06512: эр "SUPERMAG.REP_GETBARCODEDATE", line 83
ORA-06512: эр "SUPERMAG.RUSSIANSPELL", line 1008
ORA-06512: эр "SUPERMAG.REP_GETBARCODE", line 10
ORA-06512: эр line 1
Current SQL information unavailable - no session.
22.08.2006 14:43
kadr
 
bob, ты её убил вот она и валит ошибки
а по поводу эталона, обратись на горячку либо абсолютно новую БД создай и оттуда создавай эталон.
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
 
Он виснет или все таки винты грузит? Уж больно похоже, что индексы навернулись.
23.08.2006 11:28
bob
 
Не винты вообще не грузит, только проц. Это на только что развернутой пустой базе запускали.

Explain Plan
SQL Statement from editor:
-----------------------------------------------------------
Statement Id=C899629B Type=SELECT STATEMENT
Cost=18 TimeStamp=23-АВГ-06::11:49:42

(18) SELECT STATEMENT CHOOSE
Est. Rows: 1 Cost: 18

(17) SORT ORDER BY
Est. Rows: 1 Cost: 18

(16) NESTED LOOPS
Est. Rows: 1 Cost: 12

(9) NESTED LOOPS Est. Rows: 1 Cost: 10
(2) TABLE ACCESS BY INDEX ROWID SUPERMAG.SMCARD [Analyzed]
(2) Blocks: 1 692 Est. Rows: 1 of 64 633 Cost: 1 Tablespace: USERS
(1) UNIQUE INDEX UNIQUE SCAN
SUPERMAG.SMCARD_PK [Analyzed] Est. Rows: 1 Cost: 1
(8) UNIQUE INDEX FULL SCAN
SUPERMAG.SMCSTOREUNITHIST_PK [Analyzed]Est. Rows: 1 Cost: 41
(4) SORT AGGREGATE Est. Rows: 1
(3) UNIQUE INDEX FAST FULL SCAN
SUPERMAG.SMCSTOREUNITHIST_PK [Analyzed]Est. Rows: 2 Cost: 37
(7) SORT AGGREGATE Est. Rows: 1
(6) FIRST ROW Est. Rows: 1 Cost: 3
(5) UNIQUE INDEX RANGE SCAN (MIN/MAX)
SUPERMAG.SMCSTOREUNITHIST_PK [Analyzed]Est. Rows: 1 Cost: 3
(15) VIEW SUPERMAG.SVSTOREUNITS Est. Rows: 2
(14) UNION-ALL
(11) TABLE ACCESS BY INDEX ROWID SUPERMAG.SMSTOREUNITS [Analyzed](11) Blocks: 428 Est. Rows: 1 of 74 659
Cost: 1 Tablespace: USERS(10) NON-UNIQUE INDEX RANGE SCAN
SUPERMAG.SMISTOREUNITS_ARTICLE [Analyzed]Est. Rows: 1 Cost: 1
(13) TABLE ACCESS BY INDEX ROWID SUPERMAG.SMFOREIGNUNITS [Analyzed]
(13) Est. Rows: 1 Cost: 1 Tablespace: USERS(12) NON-UNIQUE INDEX RANGE SCAN
SUPERMAG.SMIFOREIGNUNITS_ARTICLE [Analyzed]Est. Rows: 1 Cost: 1
23.08.2006 14:10
reddevil
 
create index SMSTOREUNITHIST_BC on SMSTOREUNITHIST (BARCODE)
tablespace users;
analyze index SMSTOREUNITHIST_BC;

вот так попорбуй
23.08.2006 17:18
bob
 
Смысл создавать новый индекс? ПОнизили параметр до 80, и все прекрасно работает.
24.08.2006 11:54
Propil
 
Вот что я писал в поддержку:
"Поставил версию СМ 1.024.4, пока ошибок не обнаружил.
Однако одна проблема осталась с предыдущих версий:
При попытке распечатать расходную накладную с установленной опцией "Показывать штриховые коды" сервер зависает (занят Ораклом) почти намертво. Причем накладная может содержать лишь три артикула. Без штрих-кодов буквально за секунды.
Пробовал на разных базах. Базы настраивал и оптимизировал Оптимайзером."

Получил ответ (14 июня):
"Этот вопрос сейчас рассматриваем, поскольку не только Вы жалуетесь на данную проблему. По всей видимости
исправление будет выпущено в одном из сервис-паке."
И действительно, после установки SP1 эта проблема ушла
Опции темы


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

 

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