Расхождение в остатках и сумме по Таре : Супермаг Плюс (Супермаг 2000)

Mtirt · █ 05.08.2020 15:01

Нехорошо сравнивать мелкое с мягким...

Сальдо бухгалтерского учета и остаток в ценах последней поставки.
Они и не должны совпадать.

А сделайте "Остатки в закупочных ценах" (в бухгалтерских) по группе Тара с максимальной расшифровкой.
Увидите суммы по товарам, по которым у вас нет остатков..

Mtirt · █ 05.08.2020 15:02

Цитата:

MrSTEP ➤ Остатки в закупочных ценах показывает то же, что и просто Остатки

Сформируйте отчет в варианте "Все карточки".
Найдете для себя много интересного.

DMaslov · █ 05.08.2020 21:42

SQL код:

 SQL> select count(1) from smspec;

  COUNT(1)
----------
  37907996

В моей центральной БД этот запрос дает в два раза больше, 67 млн. строк, и такого

Цитата:

в сличительной ведомости операция Проставка цен выполняется 2-3 часа

не наблюдается.

Дайте еще параметры сервера центральной БД - процессор, память, диски.

Сделайте банальное

SQL код:

 begin
  dbms_stats.gather_schema_stats('SUPERMAG');
end;

В целом, у вас две задачи:

1. Производительность. Т.е. нужна ли обрезка. Пока, по моему мнению, не нужна. Нужен Oracle DBA. Мы готовы по мере возможности его изобразить (бесплатно !!!), если вы будете предоставлять информацию по запросу.

2. Претензии бухгалтеров, маркетинга и т.п., должны ли совпадать результаты отчетов, сделанные по разным алгоритмам. Краткий ответ: не должны. Развернутый ответ зависит от претензий, озвучьте их.

DMaslov · █ 05.08.2020 21:49

Товарный отчет - для начала укажите те же группы товаров, что и в отчете об остатках.
Вы там используете галки "только итоги", "итоги по таре", и ожидаете неких совпадений с отчетом, в котором указаны конкретные группы товарных карточек. Уберите галки "только итоги", и сможете разбирать суммы - из чего они складываются.
Видимо, раз вы вышли на форум, сами SQL-запросы отчетов вы не анализировали.

OlegON · █ 06.08.2020 07:37

SQL код:

 SQL> select count(1) from supermag.smspec;

  COUNT(1)
----------
 547152041

вот еще, на слабеньком железе

SQL код:

 SQL> select count(1) from supermag.smspec;

  COUNT(1)
----------
 415703386

вот вообще на виртуалке

SQL код:

 SQL> select count(1) from supermag.smspec;

  COUNT(1)
----------
 306959084

критичных замедлений нет, обрезка не требуется... Рекомендую использовать оптимизатор: https://olegon.ru/showthread.php?t=19224

MrSTEP · █ 10.08.2020 12:07

Цитата:

DMaslov ➤ Видимо, раз вы вышли на форум, сами SQL-запросы отчетов вы не анализировали.

Ну да, SQL не анализировал в принципе. Да и базу Оракла знаю очень поверхностно, честно признаю.
И вообще с отчетами я мало ковырялся - устоявшийся порядок работы был заведен предыдущим админом, суть всего происходящего мне объяснить не потрудились.. Поэтому я просто поддерживал то, что было настроено, пока остро не встал вопрос с производительностью (или скорее быстродействием отдельных точек).

Да, сейчас я понимаю, что сравниваю разные отчеты, да еще и с разным набором опций. Но изначально бухгалтерия анализировала два упомянутых отчета по всем группам товаров и обнаружила, что сумма по таре отличается в 10 раз. В этом и была главная претензия бухгалтеров.

Ладно, давайте я над отчетами чуть позже подумаю, пока голова другими цифрами занята. Могу поделиться системными параметрами центрального сервера:
Процессор 2x QuadCore Intel Xeon E5630, 2533 MHz
24 Гб Памяти DDR3-1333 Reg. ECC
Дисковая подсистема - 2 массива RAID-1 из дисков WD Blue по 2Тб
Операционка - Windows 2008 R2 Server, под центральную базу выделено 6 Гб памяти.

А вот параметры подчиненного сервера, который долго проставляет цены в сличилке:
Процессор QuadCore Intel Core i5-2500K, 3400 MHz
4 Гб памяти DDR3
RAID-1 из дисков WD Red по 2Тб
Операционка - Win7 Pro x86, боль очей моих. И под базу выделено всего метров 700-800.

Да, я знаю, что это мало. И уже успел провести эксперимент с этой же базой на х64 системе, с выделением под нее памяти больше двух гигов. Там проставка цен выполнилась за 10-15 минут.
Я озвучил руководству, что эту конкретную проблему на конкретном магазине готов решить, дайте мне 4 тыщи на оперативку и неделю на работу, будут вам быстрые сличилки. Но нет, они хотят решать глобальную задачу по центральной базе, при этом не потеряв отчетность и все такое.

А вот этот запрос не получился.. sql не очень понял, что я от него хочу.

SQL код:

 begin
  dbms_stats.gather_schema_stats('SUPERMAG');
end;

Нажмите на изображение для увеличения
Название: stats.PNG
Просмотров: 30
Размер: 8.0 Кб
ID: 10971

OlegON · █ 10.08.2020 13:30

Базу 11.2.0.1 лучше проапгрейдить до 11.2.0.4, если есть возможность по Супермагу. Если нет - до 11.2.0.3. Ну, если, конечно, есть заинтересованность, чтобы это стабильно работало и не заваливалось набок от разных чихов. На .1 gather_schema_stats лучше не использовать. Там, собственно, лучше вообще ничего не использовать, а то она вообще запускаться перестанет.

DMaslov · █ 10.08.2020 20:05

Цитата:

На .1 ........ лучше вообще ничего не использовать, а то она вообще запускаться перестанет.

Это мы вас "пугаем", чтоб поставили патч. Но если

Цитата:

базу Оракла знаю очень поверхностно

то сначала сделайте "тренировку на кошках".

Цитата:

24 Гб Памяти

На таких объемах данных памяти вам за глаза.

Цитата:

под центральную базу выделено 6 Гб памяти.

Остальное используется для других целей? Если нет, выделите СУБД 17-20 ГБ.

Цитата:

4 Гб памяти

Цитата:

под базу выделено всего метров 700-800.

Снова мало. Выделяйте 2 ГБ смело.

Цитата:

проставка цен выполнилась за 10-15 минут.

Все равно много.

Вопросы: сколько строк в сличилке? зачем вообще "проставлять цены"? Они же (вид цены) при заполнении выбираются. Или вы "проставлением цен" называете заполнение сличилки? В целом заполнение сличилки - исторически сложившаяся у Супермага беда, построчное заполнение документа с выполнением запросов на клиентской стороне, для тысяч строк имеем "Row By Agonizing Row". С этим просто надо смириться, вряд ли они в обозримом будущем займутся оптимизацией этого дела. Да и полная ревизия проводится обычно раз в год, можно подождать.

Цитата:

А вот этот запрос не получился

В конце забыл один символ, "/".

Код:

C:\dm\setup\UKM4>sqlplus supermag@DBOFFICE

SQL*Plus: Release 11.2.0.1.0 Production on Mon Aug 10 18:46:32 2020

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Enter password:

Connected to:
Oracle Database 11g Release 11.2.0.1.0 - 64bit Production

SQL> begin
  2    dbms_stats.gather_schema_stats('SUPERMAG');
  3  end;
  4  /

PL/SQL procedure successfully completed.

SQL>

MrSTEP · █ 10.08.2020 23:54

Цитата:

OlegON ➤ Базу 11.2.0.1 лучше проапгрейдить до 11.2.0.4, если есть возможность по Супермагу.

Вспоминаю один случай.. Пришлось мне переустанавливать винду на одном сервере, и я накатил туда именно 11.2.0.4 в 64-битной версии (до переустановки было 32). Выполнил по базе скрипты utlirp и utlrp, вроде все запустилось. Но потом уже в самом Супермаге полезло много ошибок с ролями. С ними тогда разбирался Сергей Шеремета и он сказал, что "на 11.2.0.4 проявляется баг с ролями". Может, конечно, надо было обновляться как-то более грамотно, но по итогу мы откатились на 11.2.0.1, как и везде.

И да, по апгрейду мне тоже нужен мануал. И ссылка на скачивание версии 0.3. На FTP ServPlus только 0.1 и 0.4.

Цитата:

DMaslov ➤ dbms_stats.gather_schema_stats('SUPERMAG');

Попробовал на тестовой базе.. Процедура завершилась, каких результатов ждать - не знаю.

MrSTEP · █ 11.08.2020 00:20

Цитата:

DMaslov ➤ сколько строк в сличилке? ... Да и полная ревизия проводится обычно раз в год, можно подождать.

Около 3500. У нас такие ревизии делают раз в квартал.

Цитата:

DMaslov ➤ зачем вообще "проставлять цены"? Они же (вид цены) при заполнении выбираются. Или вы "проставлением цен" называете заполнение сличилки? В целом заполнение сличилки - исторически сложившаяся у Супермага беда ... С этим просто надо смириться, вряд ли они в обозримом будущем займутся оптимизацией этого дела.

Нуууу как бы... Функции - Проставить цены. А как иначе они узнают сумму разности? Пару лет назад там даже сделали настройку многопоточности.

Нажмите на изображение для увеличения
Название: простановка цен.PNG
Просмотров: 22
Размер: 10.5 Кб
ID: 10972

Цитата:

"Row By Agonizing Row"

Что ещё за "агонизирующие" строки?