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

OlegON · █ 03.11.2009 12:22

Я до завтрашнего дня оторван от Супермага, поэтому попробовать не смогу. Но еще раз предложу заполнять ценами через простановку оснований. Будет ли быстрее? И еще раз, кто-нибудь подтвердит, что у него 300 позиций заполняется за какое-то небольшое время? Просто при вале запоросов, думаю, быстрее полусекунды они отстреливаться все равно не должны при такой стоимости.

Starter · █ 03.11.2009 13:15

Цены из оснований - так у этих документов оснований то нету. соответственно цены оснований нулевые.

processes = 150
timed_statistics = TRUE
shared_pool_size = 192937984
sga_max_size = 1370040744
large_pool_size = 268435456
java_pool_size = 33554432
spfile = d:\oracle\database\spfileBRO.ora
control_files = c:\oracle\oradata\BRO\control01.ctl, c:\oracle\oradata\BRO\control02.ctl, c:\oracle\oradata\BRO\control03.ctl
db_block_size = 8192
db_cache_size = 838860800
compatible = 9.2.0.0.0
log_buffer = 10485760
db_file_multiblock_read_count = 16
fast_start_mttr_target = 0
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
O7_DICTIONARY_ACCESSIBILITY = TRUE
remote_login_passwordfile = EXCLUSIVE
instance_name = BRO
dispatchers = (PROTOCOL=TCP) (SERVICE=BROXDB)
job_queue_processes = 3
hash_join_enabled = TRUE
background_dump_dest = d:\oracle\admin\BRO\bdump
user_dump_dest = d:\oracle\admin\BRO\udump
core_dump_dest = d:\oracle\admin\BRO\cdump
sort_area_size = 10485760
db_name = BRO
open_cursors = 300
star_transformation_enabled = FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 513802240
aq_tm_processes = 1

------------
2x DualCore Intel Xeon 5130, 2000 MHz (6 x 333)
Системная плата Intel Star Lake S5000PSL
память
4089 Мб (DDR2-667 Fully Buffered ECC DDR2 SDRAM)
рейд:
Intel(R) RAID Controller SRCSAS18E
база - рейд 10, 4 SAS диска, WD, 15 К
----
OS: Microsoft Windows Server 2003 R2, Standard Edition 5.2.3790 SP2
из ПО- oracle, supermag, Open office.
в памяти практически ничего нет (стандартные процессы, оракл).

OlegON · █ 03.11.2009 13:23

Цитата:

Starter ➤ Цены из оснований - так у этих документов оснований то нету. соответственно цены оснований нулевые.

Типа приходы есть, а оснований нету? ;) Попробуй, поэкспериментируй. Не цены из оснований, а "Проставить основания" - там среди опций были и цены.

vdm · █ 03.11.2009 15:13

Речь же в основном про приходные.
Не вижу там "проставить основания", это для расходных.

В 1.025.1 такой запрос по функции "Заполнить документ ценами последнего прихода", обе галки в доп. диалоге отключены.

Код:

SELECT sp.specitem, sc.doctype, sc.docid, sc.specitem specitem_src,
       sc.itemprice, sc.itempricenotax
  FROM smspec sp, smspec sc, smdocuments d
 WHERE sp.doctype = :b1
   AND sp.docid = :b2
   AND ((:b3 = '0') OR NVL (sp.itemprice, 0) = 0)
   AND sc.doctype = d.doctype
   AND sc.docid = d.ID
   AND d.createdat <= :b4
   AND d.doctype = 'WI'
   AND d.docstate = 3
   AND d.opcode = 0
   AND sc.article = sp.article
   AND d.locationto IN (SELECT ID
                          FROM ttshoplist)
   AND (:b1 != 'WI' OR d.ID != :b2)
   AND d.ID IN (
          SELECT MAX (d2.ID)
            FROM smspec s2, smdocuments d2
           WHERE s2.doctype = d2.doctype
             AND s2.docid = d2.ID
             AND d2.doctype = 'WI'
             AND d2.docstate = 3
             AND d2.opcode = 0
             AND s2.article = sp.article
             AND d2.locationto IN (SELECT ID
                                     FROM ttshoplist)
             AND (:b1 != 'WI' OR d2.ID != :b2)
             AND d2.createdat IN (
                    SELECT MAX (d1.createdat)
                      FROM smspec s1, smdocuments d1
                     WHERE s1.doctype = d1.doctype
                       AND s1.docid = d1.ID
                       AND d1.createdat <= :b4
                       AND d1.doctype = 'WI'
                       AND d1.docstate = 3
                       AND d1.opcode = 0
                       AND s1.article = s2.article
                       AND d1.locationto IN (SELECT ID
                                               FROM ttshoplist)
                       AND (:b1 != 'WI' OR d1.ID != :b2)))
   AND sc.specitem IN (
          SELECT MAX (s3.specitem)
            FROM smspec s3
           WHERE s3.doctype = d.doctype
             AND s3.docid = d.ID
             AND s3.article = sp.article)

Запрос один и стоимость показывает смешную - 5
740 позиций посчитал за 40сек.

Starter · █ 03.11.2009 16:35

Ну если рассматривать шире, то список документов где это широко используется (по крайней мере нами) - РН, ПН, описи, слич. ведомости, расход на производство.
в РН да, основания проставляются, причем если не по результатам товародвижения, а по последнему/первому приходу, то очень быстро.
но это только для РН. для ПН такого пункта нет.

что в версии 1.25.1 отрабатывает быстро - охотно верю, в 1.26.4 и 1.24.6 (стояли до перехода на 1.27.2 и 1.27.1) тоже все срабатывало быстро (ну разве что в инвентаризационных ведомостях где 20-30 тыс. строк - полчаса считал). а накладные до 1000 позиций - максимум минуту-две.
проявилось только после новой версии.
Установил SpotLight, там сделал trace сессии (нажал заполнить ценами прихода), потом trace.
файл могу выложить. а так там же в анализе SQL - первые строки:
SQL ID Elapsed (ms) CPU (ms) Parse Count Execute Count Fetch Count Total Rows Disk IO Logical IO % Total Elapsed Logical IO/Exec Logical IO/Rows CPU/Exec Disk/Exec SQL Statement
4 1525643,03 1486281,25 0 1 0 1 12874 174194294 99,82 174194294,00 174194294,00 1486281,25 12874,00 begin SuperMag.SMDocGetLastIncomePriceFI_WO(:V00001,:V00002); end;
7 559,66 296,88 10 5 0 5 0 1128 0,04 225,60 225,60 59,38 0,00 begin Supermag.SMBeginActionEx(:V00001,:V00002,:V00003,:V00004,:V00005,:V00006,:V00007,:V00008); end;
2 266,78 171,88 0 0 57 56 1213 0 0,02 0,00 SELECT SP.SPECITEM,SC.DOCTYPE,SC.DOCID,S ... 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.DO
20 248,26 281,25 15 15 15 15 0 885 0,02 59,00 59,00 18,75 0,00 select max(nvl(option$,0)) from sysauth$ where privilege#=:1 connect by grantee#=prior privilege# and privilege#>0 start with (grantee#=:2 or grantee#=1) and privilege#>0 group by privilege#
54 191,00 250,00 114 57 57 57 0 2743 0,01 48,12 48,12 4,39 0,00 SELECT DS.DocType, DS.DocID, DS.SpecItem ... from SuperMag.SVCardName C where C.Article=DS.Article) as MeasureID,DS.Quantity,DS.ItemPrice, DS.TotalPrice,DS.ItemPriceNoTax,DS.TotalPriceNoTax, DS.ItemPr
148 173,89 187,50 3 3 0 0 0 558 0,01 186,00 62,50 0,00 set role SUPERMAG_MODULE_

baggio · █ 03.11.2009 17:15

тогда приходит на ум только одно...
изменили функции
SMDocGetLastIncomePriceFI_WO
или
SUPERMAG_FN_DOC_WO_SET_PRICES

проверь... это код от 1.26.1 sp4
по базе не запускать просто визуаль сверь...

ЗЫ... Олег с какого момента файлы формата *.sql у нас являются некоректными ?

Starter · █ 03.11.2009 18:22

первая функция - один в один такая же, вторую - сравнивать не с чем...

baggio · █ 03.11.2009 18:40

Цитата:

Starter ➤ первая функция - один в один такая же, вторую - сравнивать не с чем...

Соврал я не функция вторая... роль...
Если функцию не меняли... смотреть всетаки в настройки базы...
а какой у тебя index_cost_adj ?
и на время я бы попробывал sort_area_size уменьшить мегабайт до 4...
чисто интуитивно...
Кстати у тебя только контрольники на С:\?

Starter · █ 03.11.2009 19:15

index_cost_adj 100

на C: да, только контрольники. когда базу создавали, случайно туда запихнули. Это в одном магазине, в другом все на D:, там сервер послабее.

OlegON · █ 03.11.2009 20:52

Цитата:

vdm ➤ Речь же в основном про приходные.
Не вижу там "проставить основания", это для расходных.

Да, я тормознул. У меня похожая проблема с заполнением расходок была. Но то, что в расходку быстро проставляются все таки двигает в сторону испорченного пакета. Его уже ломали где-то на 1025 версии, ничего не могу сказать про новую, увы. Кстати, в спотлайте красным что-нибудь моргает, когда заполнение идет? Не надо только кучу текста выкидывать, неформатируя. Тот приведенный кусок просто пропустил-нечитаемо.