[ТЕМА ЗАКРЫТА]
14.12.2011 11:46
OlegON
 
ужас какой... ты полный расчет делаешь всегда? на 120Гб базе расчет идет 4 часа, т.е. в 3 запускаем, в 7 он есть... Параллельно в БД еще куча всего происходит, тот же бекап.
14.12.2011 11:49
Mtirt
 
Цитата:
AlexeyF у меня расчёт идёт 12 часов. мне его надо запускать как можно раньше.
Расчет же, не перенос идет 12 часов.
Чем тебе мешает расчет товародвижения в рабочее время?
14.12.2011 11:59
AlexeyF
 
Не во мне проблема. Утром приходят работнички и начинают делать отчёты в головную контору + чуть попозже головная контора начинает мотать отчёты, проверяя присланное от местных.
ТД успело досчитаться до 9-ти утра и начинаются звонки и жалобы....

Добавлено через 47 секунд
"ТД НЕ успело досчитаться до 9-ти утра"
14.12.2011 12:23
Mtirt
 
Но там же отчет честно говорит "В базе нет рассчитанной себестоимости". Т.е. причина и пользователям известна.
Хорошо, а как поступают пользователи в те 3 дня, когда ты не считаешь себестоимость?
14.12.2011 17:02
AlexeyF
 
Себестоимость считается в понед, среду, пятницу вечером. Это мероприятие приурочено к какому то собранию отчётному в центр офисе. Это мутное дело - главное что на выходе ситуация как я описал.
Кладутся на стол отчёты на тему оборотов, остатков и т.д. по всему холдингу. В случае если "В базе нет рассчитанной себестоимости" - в отчётах нет актуальной информации, наш директорат и отделы, зависящие от фин показателей в напряжении.

И так три раза в неделю...
Ну а если нет себестоимости, а продажи были - виноват Супермаг, т.е. я ;)
14.12.2011 17:06
Mtirt
 
Тогда остается запускать оптимайзер в МТ во вторник, четверг, субботу и воскресенье. Самый простой вариант - написать скрипт и менять время исполнения в МТ с нескольких часов до 1 мин. в понедельник среду и пятницу.
27.12.2011 10:33
Mr_Vito
 
возникла проблема:
26 числа у меня оптимизатор на базе отработал в 18-40
Затем следующий раз он смог подключится только 27 в 1-45
затем он смог подключится только в 7-42
время уже 12-30 дня а оптимизатор до сих пор не может подключится :(
постоянно выходит:
Sorry, too much unregistered sessions. Please, change your schedule.
и такая фигня происходит каждый день

в планировщике задач запуск стоит каждые 42 минуты
вопрос, как запускать оптимизатор? что делать?
27.12.2011 11:12
OlegON
 
Могу предположить только, что кто-то занял твое время длинной операцией... Варианты - либо то, что предлагает, т.е. сменить расписание, либо зарегить опт. На незарегистрированных ограничение по количеству сессий, я писал раньше.
08.01.2012 07:21
whitewizard
 
Имеем 1.027.5сп6
Сразу после развёртывания базы параметры следующие:

Oracle9
optimizer_mode='CHOOSE';
optimizer_index_cost_adj=100;
optimizer_index_caching=0;

Oracle10
optimizer_mode='ALL_ROWS';
optimizer_index_cost_adj=100;
optimizer_index_caching=0;

после работы оптимизатора на Оракле9 ничего не меняется,
а на Оракл10 становится вот так:

optimizer_mode='FIRST_ROWS_100';
optimizer_index_cost_adj=1;
optimizer_index_caching=80;

со всеми вытекающими из этого.

Из-за чего так?
08.01.2012 09:06
OlegON
 
Судя по приведенному - большая БД. Из опыта использования ставлю так.
08.01.2012 09:42
whitewizard
 
но после таких параметров тормозить начинает кошмар как.
куда копать?

select sum(decode(f.saletype,'CR',-f.salesum,f.salesum)) realiz from supermag.ffmaprep f where f.rectype=1 and f.saletype in ('CR','CS')
and f.saledate>=to_date('01.01.2011','DD.MM.YYYY')
and f.saledate<=to_date('10.01.2011','DD.MM.YYYY')
and f.article in ( select c.article from supermag.smcard c where c.accepted<>-1 )

при ALL_ROWS - 2.83 cек
при FIRST_ROW_100 - 20,67 сек

ну и собственно с остальными запросами не за последние дни такая же картина
08.01.2012 11:49
OlegON
 
Это твои запросы или супермаговские отчеты какие-то?
08.01.2012 12:30
whitewizard
 
это пока лазил по форуму, взял запрос
по нему на одной из тем скорость считали

select count(*) from supermag.smspec
ROW# COUNT (*)
1 28902016

ALL- 5,34 сек
FIRST - 16,94 сек
08.01.2012 12:58
OlegON
 
Попробуй лучше СМ-операции погонять с этими параметрами. Я ж не от балды это все понатыкал. Долго работал оптимизатор? Или ты его раз в месяц запускаешь и это второй раз был? Регулярные запуски и все должно быть хорошо.
08.01.2012 13:21
whitewizard
 
каждые полчаса запуск уже весьма давненько.
так-то нареканий особо и не было.
на днях перетащил FFMAPREP и FFINDEX в отдельгые ТП, а юзеры начали жаловаться на тормоза.
вот и начал проверять параметры
08.01.2012 15:44
whitewizard
 
Отчёт "Доходность по товарам" за 4 квартал, итоги по товарным группам с группировкой по местам хранения:

RAW_FIRST_100 - 240 сек
RAW_ALL - 16 сек

слишком уж большая разница
08.01.2012 16:36
OlegON
 
Я имел ввиду фильтры и т.п., перепроверю по возможности. У меня в приоритете работающие в интерфейсе, а не отчетники. И, раз раньше было все ок (а параметры эти в оптимизаторе уже год, наверное), то проблема не в них. Где-то что-то еще зацепил при переносе.
09.01.2012 06:42
whitewizard
 
Так я добавил только ТП, а перенос делал оптимайзер
09.01.2012 10:23
OlegON
 
Ну, мало ли что с ТП не так, например. Или еще что-то изменилось... Он переносит тоже чисто технически, без оптимизаций по дороге. Т.е. я с него претензию снимаю :)
09.01.2012 12:31
whitewizard
 
Ишь :)
ладно, тогда вот пишет в логе что есть "Даты кривых Z-отчетов",
но кассовые документы есть за ту дату есть.
Что имеется в виду?
09.01.2012 12:45
OlegON
 
Означает, что они есть, но кривые. Например, несоответствующие Z-отчету, что отбирается по фильтру в самом СМ.
09.01.2012 12:53
whitewizard
 
Цитата:
OlegON Означает, что они есть, но кривые. Например, несоответствующие Z-отчету, что отбирается по фильтру в самом СМ.
не отбирается. и по сумме с чеками совпадает.
09.01.2012 12:57
konst
 
Попробуй выполнить вот этот запрос:
Код:
SELECT z.locid, z.desknum, z.znum, z.closedate, z.zready, z.doccreated FROM supermag.smcashz z WHERE z.zready != 1 or z.doccreated != 1
09.01.2012 13:03
whitewizard
 
отобрал он как раз его.
поставить doccreated=1 и не париться значит больше
09.01.2012 13:54
Mtirt
 
Может лучше пересоздать кассовые документы?
09.01.2012 13:56
OlegON
 
Цитата:
Mtirt Может лучше пересоздать кассовые документы?
голосую за это
10.01.2012 17:20
akonev
 
пока не отловил систему, но у меня довольно часто расползаются smcashz.doccreated и SMDocCashZ. в кассовом есть, а Z не помечен.

первый раз отчет оптера увидел с кривыми Z-отчетами - чуть дурно не стало.

потом долго перекрестно сверяли по суммам, артикулам и всему подряд, что в голову пришло: все чисто, есть почти все эти Z-ы в кассовых в полном объеме. четыре штуки пересоздать пришлось, а на остальных просто smcashz.doccreated взвели.
10.01.2012 17:33
OlegON
 
в нескольких моих подконтрольных БД, как правило, кривые отчеты появлялись до того, как я приходил и впоследствии не появлялись, что дает право предполагать кривизну в приеме или работе БД. напоминаю, что помечает кривыми отчеты сам Супермаг. Чем ломать голову, что еще не сравнили, проще пересоздать...
10.01.2012 17:41
akonev
 
в целом полностью согласен и к рекомендации присоединяюсь.

но у меня их было в ЦО что-то в районе 370 штук. и половина - в закрытом периоде.
решил, что для меня пересоздавать не будет проще, в данном конкретном случае.
11.01.2012 05:40
whitewizard
 
было всё нормально, но пересоздал


Опции темы


Часовой пояс GMT +3, время: 23:56.

 

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