Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > Супермаг Плюс (Супермаг 2000)

Задумался расчёт себестоимости в производстве : Супермаг Плюс (Супермаг 2000)

22.11.2024 10:19


26.06.2012 06:24
Наблюдаю проблему. Считается себестоимость. Основной расчёт проходит с обычной скоростью. На расчёте себестоимости в производстве встаёт примерно на половине бара.
Висит запрос:
insert into FFProdRep(DocType,DocID,SpecItem,IsIncome,Location,ZoneID,DocDate,Article,Quantity,TotalSum,PrimeCost,QuantityForced,PrimeCostForced)
select S_IN.DocType,
S_IN.DocID,
S_IN.SpecItem,
1 IsIncome,
S_IN.StoreLoc,
S_IN.ZoneID,
S_IN.CreatedAt,
S_IN.Article,
S_IN.Quantity,
S_IN.TotalSum,
sum(decode(S_IN.PriceFactor,null,nvl(M.PrimeCost,0),nvl(M.PrimeCost,0)*S_IN.PriceFactor/100)),0,0
from TTProdArticle T,FFProdInSpec S_IN,FFProdOutSpec S_OUT,FFProdRep M
where T.StoreLoc=S_IN.StoreLoc and T.ZoneID=S_IN.ZoneID and T.Article=S_IN.Article and T.CalcNu=3 and S_IN.CreatedAt
between to_date('31.12.2009','DD.MM.YYYY')
and to_date('25.06.2012','DD.MM.YYYY')
and S_IN.DocType='PD'
and S_OUT.DocType='PD'
and S_OUT.DocID=S_IN.DocID
and M.DocType='PD'
and M.DocID = S_OUT.DocID
and M.SpecItem = S_OUT.SpecItem
and M.IsIncome = '0'
group by S_IN.DocType, S_IN.DocID, S_IN.SpecItem,S_IN.StoreLoc, S_IN.ZoneID, S_IN.CreatedAt, S_IN.Article,S_IN.Quantity, S_IN.TotalSum


Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 архивлог включен.
СМ 1.027.4 SP8

SQL> select * from v$sgainfo;

NAME BYTES RESIZEABLE
-------------------------------- ---------- ----------
Fixed SGA Size 2085128 No
Redo Buffers 14688256 No
Buffer Cache Size 4563402752 Yes
Shared Pool Size 6928990208 Yes
Large Pool Size 16777216 Yes
Java Pool Size 16777216 Yes
Streams Pool Size 0 Yes
Granule Size 16777216 No
Maximum SGA Size 1154272460 No
Startup overhead in Shared Pool 100663296 No
Free SGA Memory Available 0

Скрипт для FFProdRep:
ALTER TABLE SUPERMAG.FFPRODREP
DROP PRIMARY KEY CASCADE;

DROP TABLE SUPERMAG.FFPRODREP CASCADE CONSTRAINTS;

CREATE TABLE SUPERMAG.FFPRODREP
(
DOCTYPE CHAR(2 BYTE) NOT NULL,
DOCID VARCHAR2(50 BYTE) NOT NULL,
SPECITEM NUMBER(10) NOT NULL,
LOCATION NUMBER(10) NOT NULL,
ZONEID NUMBER(10) NOT NULL,
DOCDATE DATE NOT NULL,
ARTICLE VARCHAR2(50 BYTE) NOT NULL,
QUANTITY NUMBER(14,3) NOT NULL,
PRIMECOST NUMBER(19,4) NOT NULL,
TOTALSUM NUMBER(19,4) NOT NULL,
ISINCOME CHAR(1 BYTE) NOT NULL,
QUANTITYFORCED NUMBER(14,3) NOT NULL,
PRIMECOSTFORCED NUMBER(19,4) NOT NULL
)
TABLESPACE FFTAB
PCTUSED 0
PCTFREE 0
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 192K
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
)
NOLOGGING
NOCOMPRESS
CACHE
NOPARALLEL
MONITORING;


CREATE UNIQUE INDEX SUPERMAG.FFCPRODREP_PK ON SUPERMAG.FFPRODREP
(DOCTYPE, DOCID, SPECITEM, ISINCOME)
NOLOGGING
TABLESPACE FFTAB
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 522M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
)
NOPARALLEL;


CREATE INDEX SUPERMAG.FFPRODREP_ZONEART ON SUPERMAG.FFPRODREP
(LOCATION, ZONEID, ARTICLE)
NOLOGGING
TABLESPACE FFTAB
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 368M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
)
NOPARALLEL;


ALTER TABLE SUPERMAG.FFPRODREP ADD (
CONSTRAINT FFCPRODREP_PK
PRIMARY KEY
(DOCTYPE, DOCID, SPECITEM, ISINCOME)
USING INDEX
TABLESPACE FFTAB
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 522M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
));

GRANT SELECT ON SUPERMAG.FFPRODREP TO SUPERMAG_FN_PROD_ZAKUPPRICE;

GRANT INSERT, SELECT, UPDATE ON SUPERMAG.FFPRODREP TO SUPERMAG_FN_REPADMIN_CALC;


Полностью очищал данные расчёта и переноса. Таблица и индексы NOLOGGING. Оптимайзер работает в зарегистрированном режиме.
оракл грузит проц, активно читает с диска 20-30Мб/сек, практически при этом не пишет. Ещё на прошлой неделе считалось нормально. Изменения только оптимайзер делает в настройки оракла, сам не трогаю.
Поделитесь опытом что делать, кто сталкивался с такой проблемой ? Что ещё проверить можно ?
26.06.2012 07:02
может статистику обновить именно по табличкам, которые в этом запросе участвуют? но тогда расчёт надо перезапускать.
26.06.2012 08:19
Попробуй BrokenCBO поменять. Если не поможет - выложи лог оптимизатора за время, когда встал расчет.
26.06.2012 09:06
BrokenCBO=no с самого появления
BrokenCBO он при обычной оптимизации сработает или влияет на работу в MaintenanceTime ?
Я к тому что я со вчера не останавливаю расчёт, уже 16 часов работает из них минимум 10 часов висит. Если с BrokenCBO=yes прогнать оптимайзер, то наверняка надо будет расчёт перезапустить. Так вот оптимайзер гонять в MaintenanceTime или в режиме обычной оптимизации ?
Сейчас поставил BrokenCBO=yes, оптимайзер в очередной раз в режиме обычной оптимизации запустился.
Я сделал прерывание расчёта себестоимости. Буду думать что ещё сделать, прежде чем его опять запустить.

Добавлено через 20 минут 26 секунд
Может надо FF таблички (FFProdRep FFProdInSpec FFProdOutSpec FFProdRep) почистить ручками, не только стандартным супермаговским удалением данных предыдущего расчёта + переноса ?

Добавлено через 1 минуту 16 секунд
лог за время - не понятно. Можно лог во время висяка, это имеется ввиду ?
26.06.2012 09:42
лог оптимайзера во время висяка, в начале раб дня (народ только что зашёл), расчёт начат вчера вечером:
Вложения
Тип файла: rar asd.rar (22.4 Кб, 125 просмотров)
28.06.2012 02:39
BrokenCBO менялась на yes, но после этого вчера перезапускался расчёт и производство так же подвисало.
Вчера статистику собрал принудительно по FFProdInSpec, FFProdOutSpec, FFProdRep
Послушал советы техподдержки супермага перейти на новую версию и быть осторожней с оптимайзером олегона. И опаньки - нормально посчиталась себестоимость. И не знаю что больше помогло.... )
28.06.2012 07:28
Я думаю, совет.
Часовой пояс GMT +3, время: 10:19.

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