24.03.2011 10:58
Mtirt
 
Судя по вчерашнему списку изменений 1.028.1 , это происходит на этапе предварительного рассчета:
Цитата:
Расчет товародвижения в производстве. Нотификация хода расчета.

Процедура расчета товародвижения в производстве производит расчет в несколько этапов. Это связано с тем, что артикулы промежуточного производства, то есть полуфабрикаты, необходимо обрабатывать раньше, чем будут обработаны артикулы, произведенные с их использованием. В промежутке между этапами выполняется расчет себестоимости полуфабрикатов по результатам выполненной трассировки.

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

В текущей версии нотификация хода расчета дополнена сообщением о расчете себестоимости приходов для группы артикулов. Внесены также изменения в процедуру расчета себестоимости для сокращения времени расчета на больших объемах данных.
Так что ждать и надеяться...
24.03.2011 10:58
John Doe
 
LongOps есть какие-нибудь?
24.03.2011 13:10
AirAir
 
Цитата:
John Doe LongOps есть какие-нибудь?
Что такое LongOps? есть представление v$session_longops - там можно увидеть долговыполняющиеся запросы, а LongOps - это что жаргон или что, я думаю не всем понятно!!!
24.03.2011 13:12
serj_
 
Цитата:
Mtirt Судя по вчерашнему списку изменений 1.028.1 , это происходит на этапе предварительного рассчета:


Так что ждать и надеяться...
Провисело всю ночь на одном и том же месте. документы в базе с 2008 года. Как диагностировать проблему.
24.03.2011 14:13
John Doe
 
Цитата:
AirAir Что такое LongOps? есть представление v$session_longops - там можно увидеть долговыполняющиеся запросы, а LongOps - это что жаргон или что, я думаю не всем понятно!!!
Главное - без паники. Да, это действительно долго выполняющиеся операции. В журнале оптимизатора они помечены LongOps, я их и привык так звать.
24.03.2011 14:19
AirAir
 
Никакой паники нет! Но не все пользуются оптимизаторами и поэтому ни сразу понятно что Вы подразумевали.
24.03.2011 17:02
serj_
 
Вот что висит в базе:
Код:
Index Fast Full Scan:  SUPERMAG.FFSPEC: 162940 out of 162940 Blocks done
Table Scan:  SUPERMAG.FFPRODOUTSPEC: 75383 out of 75383 Blocks done
Table Scan:  SUPERMAG.FFPRODOUTSPEC: 75383 out of 75383 Blocks done
Table Scan:  SUPERMAG.SMSTOCKLEVELS: 10103 out of 10103 Blocks done
Table Scan:  SUPERMAG.SMSTOCKLEVELS: 10103 out of 10103 Blocks done
и в нескольких сессиях запрос:
Код:
SELECT s.docid, s.doctype, 0 isincome, s.createdat, s.specitem, s.article, 
       s.quantity * 1000, s.totalsum
    FROM supermag.ffprodoutspec s
    WHERE s.createdat BETWEEN to_date('20081014', 'YYYYMMDD') AND to_date(
          '20110322', 'YYYYMMDD')
      AND s.storeloc = :v00001
      AND s.zoneid = :v00002
      AND s.article = :v00003
    ORDER BY s.createdat, decode(s.doctype, 'PD', 0, 'PO', 2, 3), s.docid, 
             s.specitem
24.03.2011 17:26
AlexeyF
 
Я понимаю когда что то происходит - тогда можно и подождать. Но процессор не занят, дисковых операций у оракла практически нет (пара килобайт запись), операций ввода-вывода у процесса SMAdmin.exe нет совсем ни байта. Т.е. сервер баз данных стоит совсем. Как тут можно ждать ? На что надеяться ?
24.03.2011 21:04
OlegON
 
Если принципиальное неприятие оптимайзера, то хоть будьте последовательны в показаниях (запрос у serj_ содержит два разных среза). Если нет лога оптимизатора, то те несколько килобайт описания ситуации, которые выдает он, вам предстоит сделать вручную. Расчет на одном сервере? Полная неподвижность? Ищите залочки... Но не верится... Можно попробовать в один поток считать.
25.03.2011 04:52
serj_
 
Ответ нашел тут: https://olegon.ru/showthread.php?t=3...outspec&page=3

перевел аналитические таблицы FF... в NOLOGGING посчиталось за 8 часов
Часовой пояс GMT +3, время: 20:01.

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