Дикие тормоза при заполнении ПН ценами последнего прихода : Супермаг Плюс (Супермаг 2000)

█ 01.11.2009 20:58

Установили 1.27.1 (впрочем, 1.27.2 тоже пробовали) и обнаружилась неприятная особенность - заполнение накладных ценами последнего прихода отрабатывает ооочень медленно (15 позиций - около 5 минут, 30 - около получаса). Поддержка сказала что нужно прогнать полный сбор статистики по базе. Прогнали все задания что можно (ппи, чсс, псс) - ничего не помогает. Может кто уже с этим сталкивался ? что еще прогнать/поменять ? И влияет ли на скорость отбора расчет статистики в модуле администратора Аналитика/статистика ?

ЗЫ. Oracle 9.2.0.1.0
ЗЗЫ. Раньше стояла 1.26.4 - там подобного не наблюдалось.

█ 02.11.2009 04:38

Цитата:

Starter ➤ ЗЫ. Oracle 9.2.0.1.0

э-э-э, а не старая версия? Кажись, есть 9.2.0.8.0, может обновиться, для начала?

█ 02.11.2009 07:04

Цитата:

Vovantus ➤ есть 9.2.0.8.0, может обновиться, для начала?

Однозначно. И статистике из заданий не доверять.

█ 02.11.2009 09:58

Предыдущую версию не там посмотрел - в Manager Console, Help/About oracle. Ставили 9.2.0.1.0, потом патч прогоняли (было правда это 2 года назад). Патч 9.2.0.8.0 установить можно, но странно, что это вылезает исключительно после установки СМ 1.27.1 и 1.27.2 (в двух магазинах).
И если не доверять статистике из СМ, то какую еще рассчитать ? Может поделитесь ссылкой где можно почитать как ее из оракла рассчитать ?
В оракле, к сожалению, не силен, иначе бы и не спрашивал...

Просто были подозрения что СП что-то подработал в новой версии и возможно существуют какие-то стандартные действия, которые необходимо проделать ? Кто 1.27.хх ставил с этой проблемой не сталкивался ?

█ 02.11.2009 10:03

У нас 1.027 - проблемы нет.

█ 02.11.2009 10:06

Цитата:

Starter ➤ И если не доверять статистике из СМ, то какую еще рассчитать ? Может поделитесь ссылкой где можно почитать как ее из оракла рассчитать ?

Например, следующим образом. Создаём файлик stat_get.sql . В него помещаем следующий код:

Код:

set feedback off;
set heading off;
set termout off;
set linesize 1000;
set trimspool on;
set verify off;
spool c:\Sql\Stat_Run.sql;

select 'ANALYZE TABLE '||OWNER||'.'||TABLE_NAME||' DELETE STATISTICS;'
    from dba_tables 
    where temporary='Y' and owner='SUPERMAG'
union all
select 'ANALYZE INDEX '||OWNER||'.'||INDEX_NAME||' DELETE STATISTICS;'
    from dba_indexes 
    where temporary='Y' and owner='SUPERMAG'
union all
select 'ANALYZE TABLE '||OWNER||'.'||TABLE_NAME||' COMPUTE STATISTICS;'
    from dba_tables 
    where tablespace_name in ('USERS','INDX') and owner='SUPERMAG'
union all
select 'ANALYZE INDEX '||OWNER||'.'||INDEX_NAME||' COMPUTE STATISTICS;'
    from dba_indexes 
    where tablespace_name in ('USERS','INDX') and owner='SUPERMAG';

prompt exit;
prompt /;
spool off;
set feedback on;
set heading on;
set termout on;
set linesize 100;
exit

далее, выполняем следующую команду:

Код:

qlplus.exe sys/qqq@DATABASE @c:\Sql\stat_get.sql

Само собой, правим расположение файлов и данные для подключения к базе. После выполнению, в каталоге c:\Sql появится файлик stat_run.sql, запускае его на выполнение через следующуюкоманду:

Код:

qlplus.exe sys/qqq@DATABASE @c:\Sql\stat_run.sql

и ждём, пока задача отработает.

█ 02.11.2009 12:11

Попробуем, спасибо. Сейчас юзеров повыгоняем, посмотрим.
Заодно базу в СП отправили, по результатам отпишусь.

█ 02.11.2009 14:03

Скрипт прогнали. база 12 гб, в сжатом виде 1.4 Гб, отрабатывал минут 40. Затем запустили супермаг, проверили - толку никакого. накладная 340 строк, уже минут 20 рассчитывает, конца процессу не видно.
Может есть еще какие мысли ?

█ 02.11.2009 14:27

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

█ 02.11.2009 14:45

Это то ?
Oracle SQL Explain Plan 2 Ноябрь 2009 г. 14:47:57 GMT+03:00

Target:
KNTROICK

Version: Oracle 9.2.0.7.0

Database: KNTROICK

Schema: SUPERMAG

Date: 02.11.2009 3:00:00

SQL Statement:

SELECT sp.specitem, sc.doctype, sc.docid, sc.specitem specitem_src,
sc.itemprice, sc.itempricenotax
FROM smspec sp, smspec sc
WHERE sp.doctype = :b1
AND sp.docid = :b2
AND (:b3 = '0'
OR nvl(sp.itemprice, 0) = 0)
AND sc.article = sp.article
AND sc.doctype || sc.docid = (SELECT substr(max(to_char(d1.createdat,
'YYYYMMDD') || d1.doctype || d1.id),
9)
FROM smspec s1, smdocuments d1
WHERE s1.doctype = d1.doctype
AND s1.docid = d1.id
AND d1.createdat <= :b4
AND d1.docstate = 3
AND d1.doctype IN ('WI', 'PO')
AND d1.opcode IN (0, 13)
AND s1.article = sp.article
AND d1.locationto IN (SELECT id
FROM ttshoplist)
AND (d1.doctype != :b1
OR d1.id != :b2))
AND sc.specitem IN (SELECT max(s3.specitem)
FROM smspec s3
WHERE s3.doctype = sc.doctype
AND s3.docid = sc.docid
AND s3.article = sc.article)

Optimizer Mode Used:

COST ALL ROWS (optimizer: CHOOSE)

Total Cost:

162

Execution Steps:

Step # Step Name
20 SELECT STATEMENT
19 FILTER
18 SORT [GROUP BY]
17 FILTER
13 NESTED LOOPS
11 NESTED LOOPS
8 NESTED LOOPS
5 NESTED LOOPS
2 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
1 SUPERMAG.SMCSPEC_DISPLAYPOS INDEX [RANGE SCAN]
4 INLIST ITERATOR
3 SUPERMAG.SMSPEC_ART INDEX [RANGE SCAN]
7 SUPERMAG.SMDOCUMENTS TABLE ACCESS [BY INDEX ROWID]
6 SUPERMAG.SMCDOCUMENTS_PK INDEX [UNIQUE SCAN]
10 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
9 SUPERMAG.SMSPEC_ART INDEX [RANGE SCAN]
12 SUPERMAG.TTCSHOPLIST_PK INDEX [UNIQUE SCAN]
16 SORT [AGGREGATE]
15 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
14 SUPERMAG.SMSPEC_ART INDEX [RANGE SCAN]

Step # Description Est. Cost Est. Rows Returned Est. KBytes Returned
1 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMCSPEC_DISPLAYPOS. 3 7 --
2 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 4 1 0,032
3 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMSPEC_ART. 2 26 0,482
4 This plan step loops through the query's IN list predicate, executing its child step for each value found.
5 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 6 3 0,152
6 This plan step retrieves a single ROWID from the B*-tree index SMCDOCUMENTS_PK. -- 1 --
7 This plan step retrieves rows from table SMDOCUMENTS through ROWID(s) returned by an index. 1 1 0,021
8 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 9 1 0,072
9 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMSPEC_ART. 2 144 --
10 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 146 1 0,036
11 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 155 1 0,108
12 This plan step retrieves a single ROWID from the B*-tree index TTCSHOPLIST_PK. -- 4 084 51,848
13 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 155 28 3,391
14 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMSPEC_ART. 3 1 --
15 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 4 1 0,021
16 This plan step accepts a row set (its only child) and returns a single row by applying an aggregation function. -- 1 0,021
17 This plan step accepts multiple sets of rows. Rows from the first set are eliminated using the data found in the second through n sets.
18 This plan step accepts a set of rows from its child node, and sorts them into groups based on the columns specified in the query's GROUP BY clause. 158 1 0,121
19 This plan step accepts a set of rows from its child node, eliminates some of them, and returns the rest.
20 This plan step designates this statement as a SELECT statement.