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

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

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

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


Так что ждать и надеяться...
Провисело всю ночь на одном и том же месте. документы в базе с 2008 года. Как диагностировать проблему.
24.03.2011 14:13
Цитата:
AirAir Что такое LongOps? есть представление v$session_longops - там можно увидеть долговыполняющиеся запросы, а LongOps - это что жаргон или что, я думаю не всем понятно!!!
Главное - без паники. Да, это действительно долго выполняющиеся операции. В журнале оптимизатора они помечены LongOps, я их и привык так звать.
24.03.2011 14:19
Никакой паники нет! Но не все пользуются оптимизаторами и поэтому ни сразу понятно что Вы подразумевали.
24.03.2011 17:02
Вот что висит в базе:
Код:
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
Я понимаю когда что то происходит - тогда можно и подождать. Но процессор не занят, дисковых операций у оракла практически нет (пара килобайт запись), операций ввода-вывода у процесса SMAdmin.exe нет совсем ни байта. Т.е. сервер баз данных стоит совсем. Как тут можно ждать ? На что надеяться ?
24.03.2011 21:04
Если принципиальное неприятие оптимайзера, то хоть будьте последовательны в показаниях (запрос у serj_ содержит два разных среза). Если нет лога оптимизатора, то те несколько килобайт описания ситуации, которые выдает он, вам предстоит сделать вручную. Расчет на одном сервере? Полная неподвижность? Ищите залочки... Но не верится... Можно попробовать в один поток считать.
25.03.2011 04:52
Ответ нашел тут: https://olegon.ru/showthread.php?t=3...outspec&page=3

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

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