[ОТВЕТИТЬ]
14.04.2008 12:39
mighty
 
Привет всем.


declare
p pls_integer;
begin
p := supermag.core.startsmapp;
Core.LockObject('1','DB','1');
SMRunTransfer( sysdate, sysdate);
Core.LockObject('0','DB','1');
commit;
end;

для переноса база блокируется, есть желание обойти блокировку(полный перенос делается 3 часа), интересует то разбирался ли кто-нить как супермаг видит что база заблокирована, чтобы подсунуть ему блокировку не блокируя базу?
14.04.2008 12:55
kadr
 
А какой тайный смысл в том чтобы отключить блокировку, только сокращение времени простоя сотрудников? Может имеет смысл запускать перенос в период когда никто не работает (например ночью)?
Блокировка предназначена для того чтобы гарантировать неизменность документов, если же в момент переноса будут делаться изменения, то есть шанс получить недостоверные результаты расчёта ТД. Супермаг видит что база заблокирована по наличию строк в SSLOCKS.
14.04.2008 15:02
mighty
 
Обычно ночью рассчитывается себестоимость, а бывают моменты - сбои какие - то, например сегодня ночью она не рассчиталась, причину конечно выясню, но она нужна менеджерам по заказу, надо её рассчитать в любом случае, но на 3 часа никто не будет работать??? вот весь смысл..блин я вообще не понимаю, почему сервисплюс не делает слепок таблиц обычным create table as select, и не рассчитывает себестоимость без блокировок..бред какой - то..Все равно если я сейчас всех выгоню и рассчитаю себестоимость, через 4 часа какой - то документ поменяется во вчерашнем числе, то себестоимость будет неверна...пепедз..
Вопрос остался в силе - как обмануть супермаг...
14.04.2008 15:22
Mtirt
 
Цитата:
mighty Обычно ночью рассчитывается себестоимость, но она нужна менеджерам по заказу
Зачем менеджерам по заказу себестоимость? им среднесуточную реализацию считать надо...
14.04.2008 15:33
mighty
 
Это уже второй вопрос....меня интересует не зачем кому то нужна себестоимость, а её рассчет без блокировки без базы данных, при всем моем уважении к тебе Mtirt, разве у вас не вставала такая проблема - надо рассчитать и приэтом офис должен работать?
Ну например нужет АВС анализ по прибыли....а его нет без себестоимости..
14.04.2008 15:37
Mtirt
 
У нас себестоимость и так считается 2 раза в неделю, в лучшем случае.
И что-то никто не умер...
Потом ты путаешь перенос и расчет. Перенос даже у нас, на наших объемах длится не больше часа. А при расчете смело можно работать. Так что про 3 часа ты сильно загнул... Только я не про полный перенос, а про инкрементальный. Не понимаю я кстати, зачем каждый раз очищать базу полностью...
14.04.2008 16:38
mighty
 
Я имею ввиду именно перенос..Мы делаем полный перенос. Это связано с тем что если себестоимость рассчиталась сегодня, а смены с касс приняты неверно - их перепринимают и снова считают себестоимость..Считают себестоимость максимизатором, а в нем стоит признак полной очистки чтобы не возникало непредвиденных ошибок..
14.04.2008 17:49
Mtirt
 
Цитата:
mighty Я имею ввиду именно перенос..Мы делаем полный перенос. Это связано с тем что если себестоимость рассчиталась сегодня, а смены с касс приняты неверно - их перепринимают и снова считают себестоимость..Считают себестоимость максимизатором, а в нем стоит признак полной очистки чтобы не возникало непредвиденных ошибок..
Каких именно ошибок? При повторном расчете измененных кассовых документов корректно считается себестоимость и при инкрементальном переносе...
14.04.2008 19:01
mighty
 
Странно - у меня супермаг говорит что перенос уже выполнен...Ладна, так можно обмануть супермаг?
14.04.2008 19:30
mighty
 
О...понял как обмануть...сегодня еще подумаю..а завтра выложу, мож кому пригодится..
16.04.2008 18:11
mighty
 
Не...не получилось..
22.04.2008 17:07
mighty
 
Цитата:
mighty Не...не получилось..
Короче я пошел другим путем..Если кому интересно..Вот скрипт делающий полный перенос без блокировки ан вчерашнюю дату...

Код:
--очищаем таблицы себестоимости
truncate table supermag.ffbadlinks;
truncate table supermag.ffdebuglog;
truncate table supermag.ffdocuments;
truncate table supermag.fffinbases;
truncate table supermag.ffinvalidoutin;
truncate table supermag.ffmapinin;
truncate table supermag.ffmapoutin;
truncate table supermag.ffmaprep;
truncate table supermag.ffmaprep_;
truncate table supermag.ffpartnerhist;
truncate table supermag.ffpayorders;
truncate table supermag.ffpayordersvat;
truncate table supermag.ffproddocuments;
truncate table supermag.ffprodexpspec;
truncate table supermag.ffprodoutspec;
truncate table supermag.ffprodrep;
truncate table supermag.ffremains;
truncate table supermag.ffremains_;
truncate table supermag.ffremincome;
truncate table supermag.ffremincome_;
truncate table supermag.ffremthreshold;
truncate table supermag.ffsalereturns;
truncate table supermag.ffspec;
truncate table supermag.ffspecscale;
truncate table supermag.ffstorehist;
truncate table supermag.ffworkdata;
truncate table supermag.fsremains;
delete from  supermag.sscalclog;
delete from  supermag.sstransfers;

alter session set skip_unusable_indexes = true;

--отключаем индексы
ALTER INDEX SUPERMAG.FFDOCUMENTS_PK UNUSABLE;
ALTER INDEX SUPERMAG.FFCDOCUMENTS_PHYSPK UNUSABLE;
ALTER INDEX SUPERMAG.FFDOCUMENTS_SALEDATEIDX UNUSABLE;
ALTER INDEX SUPERMAG.FFDOCUMENTS_INCOMEDATEIDX UNUSABLE;
ALTER INDEX SUPERMAG.FFDOCUMENTS_CREATEDAT UNUSABLE;

--пихаем все документы в аналитическую таблицу ffdocuments
truncate table supermag.ffdocuments;
insert into supermag.ffdocuments
select rownum,t.* from
(select 
       
       d.doctype,
       d.id,
       d.createdat,
       d.opcode,
       d.locationfrom,
       d.locationto,
       decode(d.doctype,'WI',i.paycash,'WO',o.paycash,1) paycash,
       decode(d.doctype,'WI',i.goodsowner,0) goodsowner,
       d.clientindex,
       d.currencytype,
       d.userop,
       decode(d.doctype,'WI',i.supplierdoc) supplierdoc,
       decode(d.doctype,'WI',i.supplierinvoice) supplierinvoice,
       decode(d.doctype,'WI',i.supplinvoicecreate) supplinvoicecreate,
       decode(d.doctype,'WI',i.supplinvoiceaccept) supplinvoiceaccept,
       0.00000
from 
supermag.smdocuments d,
supermag.smwaybillsin i,
supermag.smwaybillsout o
where 
d.docstate>=3
and d.doctype=i.doctype(+)
and d.id=i.id(+)
and d.doctype=o.doctype(+)
and d.id=o.id(+)
and d.doctype in ('WI','WO','CS','CR')
and d.createdat<=SYSDATE-1
order by d.doctype, d.id
) t;
commit;
--включаем индексы
ALTER INDEX SUPERMAG.FFDOCUMENTS_PK REBUILD;
ALTER INDEX SUPERMAG.FFCDOCUMENTS_PHYSPK REBUILD;
ALTER INDEX SUPERMAG.FFDOCUMENTS_SALEDATEIDX REBUILD;
ALTER INDEX SUPERMAG.FFDOCUMENTS_INCOMEDATEIDX REBUILD;
ALTER INDEX SUPERMAG.FFDOCUMENTS_CREATEDAT REBUILD;

--пихаем все заказы в аналитическую таблицу ffpayorders
truncate table supermag.ffpayorders;
insert into supermag.ffpayorders
select 
      d.doctype,
      d.id,
      d.createdat,
      d.opcode,
      d.userop,
      d.clientindex,
      d.location,
      d.currencytype,
      d.currencyrate,
      0,
      d.totalsum,
      d.totalsumcur,
      d.isroubles,
      p.orderid,
      p.ourselfclient,
      p.paydate,
      p.iscash
from 
     supermag.smdocuments d,
     supermag.smpayorders p
     
where 
      d.doctype in ('EO','RO')
  and d.docstate>=3   
  and d.doctype=p.doctype(+)
  and d.id=p.id(+)
  and d.createdat<=SYSDATE-1  
order by d.createdat;
commit;

ALTER INDEX SUPERMAG.FFCSPEC_PK UNUSABLE;
ALTER INDEX SUPERMAG.FFSPEC_CAUSEIDX UNUSABLE;
ALTER INDEX SUPERMAG.FFSPEC_ART UNUSABLE;

truncate table supermag.ffspec;
--пихаем все  спецификации в аналитическую таблицу ffspec
insert into supermag.ffspec
select 
       d.ndoc,
       s.specitem,
       s.article,
       s.quantity,
       s.expquantity,
       s.itemprice,
       s.totalprice,
       s.causeid,
       s.causetype,
       s.causespecitem,
       null,
       d.doctype,
       d.createdat,
       d.opcode,
       s.totalpricenotax,
       0,
       0,
       nvl(s.itempricecur,0),
       nvl(s.totalpricecur,0)
from 
     supermag.ffdocuments d,
     supermag.smspec s
where 
      d.doctype=s.doctype
  and d.id=s.docid
commit;

--включаем индексы
ALTER INDEX SUPERMAG.FFCSPEC_PK REBUILD;
ALTER INDEX SUPERMAG.FFSPEC_CAUSEIDX REBUILD;
ALTER INDEX SUPERMAG.FFSPEC_ART REBUILD;

alter session set skip_unusable_indexes = false;

insert into supermag.sstransfers t (t.logid,t.enddocdate,t.lastchangedate,t.starttime,t.endtime) values (1000,sysdate-1,sysdate-1,sysdate-1,sysdate-1);
commit;
При больших объемах данных перенос в таблицу FFSPEC можно разбить по периодам..ну и чтобы видеть индикатор процесса
Я опробовал на 5 магазинах - везде перенос сделался и после этого в административном модуле пересчиталась себестоимость..без проблемов..
В принципе можно так же сделать и частичный перенос...просто пока не до него..н сделаю..попозжа.
22.04.2008 18:09
akonev
 
прикольно.
неудобно только, что придется отслеживать возможные изменения структур в будущих версиях.

если внедришь для регулярного использования, то поделись, пожалуйста через пару-тройку десятков запусков статистикой: были ли проблемы.
13.01.2009 13:10
mighty
 
Цитата:
Andrew_Konev если внедришь для регулярного использования, то поделись, пожалуйста через пару-тройку десятков запусков статистикой: были ли проблемы.
Воопчем перешел я на версию СМ+ 1026.3..Перенос супермажным административным модулем завис на 1% и делался 8 часов..отключил я его...Это вынудило меня навалять скрипты для ПОЛНОГО И ЧАСТИЧНОГО переносов без блокировки БД под версию 1026.3

Это рабочие сприпты, если кто будет пользоваться то кратко поясню:
Полный перенос (Transfer.sql)
1) Чистим все таблицы FF
2) Отключаем индексы на FFDOCUMENTS,FFSPEC
3) Переносим данные в FFDOCUMENTS на текущий момент
4) Переносим данные в FFSPEC шапки который перенеслись в FFDOCUMENTS
(у меня в скрипте этот момент делан по месяцам - чтобы UNDO не росло)
5) Включаем индексы
6) заполняем лог переноса Supermag.SsTransfer

Частичный перенос (BitTransfer.sql)
1) Чистим все таблицы FF кроме FFDOCUMENTS,FFSPEC, FFPAYORDERS
2) Удаляем индексы на FFDOCUMENTS,FFSPEC
3) Создаем таблицу с датой самого раннего измененного документа с помента последнего переноса
4) Числим таблицы FFDOCUMENTS,FFSPEC, FFPAYORDERS удаляя документы дата которых больше чем в таблице 3
5) Создаем таблицу с максимальным номером документа в FFDOCUMENTS
6) Переносим данные в FFDOCUMENTS с момента которой указан в таблице 3 до текущего момента
7) Переносим данные в FFSPEC шапки который перенеслись в FFDOCUMENTS с датой документа которой указан в таблице 3
8) Создаем заново индексы
9) заполняем лог переноса Supermag.SsTransfer

Полгода работал на полном переносе(перенос и расчет был каждую ночь) - косяков и глков не заметил, все работало на ура, но вот версия 1026.3 ЖУТКО ТОРМОЗИТ поэтому написал частичный - буду переходить на x64+Oracle 10.2.0.4 x64, потом уже память настраивать.

Люди поделитесь патчем Oracle 10.2.0.4 x64 под Вынь2003x64? Нигде не могу найти - у меня Oracle 10.2.0.3 x64...Пжалстаааааа

Частичный перенос опробовал на 2 магазинах нормально главное базу не надо блокировать - как работали все так и работают

ЗЫ: В скрипте частичного переноса таблспейс для индектов свой пропишите - там мой стоит SM_INDEX..
Вложения
Тип файла: rar Перенос СМ+.rar (3.4 Кб, 124 просмотров)
13.01.2009 13:27
OlegON
 
Странно как-то... У меня перенос (инкрементальный, конечно) занимает около 7 минут. Считается около полутора часов. Где-то 50 магазов. В связи с чем не вижу необходимости что-то дописывать. Патч смогу отдать на выходных.
13.01.2009 13:28
isi
 
Цитата:
mighty Люди поделитесь патчем Oracle 10.2.0.4 x64 под Вынь2003x64? Нигде не могу найти - у меня Oracle 10.2.0.3 x64...Пжалстаааааа
Давай куда залить, залью, он весит гиг
13.01.2009 14:25
mighty
 
Цитата:
OlegON Странно как-то... У меня перенос (инкрементальный, конечно) занимает около 7 минут. Считается около полутора часов. Где-то 50 магазов. В связи с чем не вижу необходимости что-то дописывать. Патч смогу отдать на выходных.
Фигасе...классно...Я буду разбираться с базой только после того как x64 поставлю - сейчас времени нет абсолютно..Олег, я обращусь по любому за помощью в настройке памяти и отдельных параметров оракла здесь на форуме, поможете?

Я даже не знаю куда нить на slil.ru можно выложить патчь или на FTP С+ ? кто доступ имеет. Я гиг заберу быстро - часа 2-3..потом можно будет удалить..или может скажите мне его имя? Патча, я на металинке найду.
13.01.2009 15:01
Arsen
 
на ftp с+ есть твой патч
13.01.2009 18:25
mighty
 
Спасибо!!!! Вижу, качаю..
16.01.2009 15:41
deucel
 
Цитата:
mighty Воопчем перешел я на версию СМ+ 1026.3..Перенос супермажным административным модулем завис на 1% и делался 8 часов..отключил я его...Это вынудило меня навалять скрипты для ПОЛНОГО И ЧАСТИЧНОГО переносов без блокировки БД под версию 1026.3
...

Полгода работал на полном переносе(перенос и расчет был каждую ночь) - косяков и глков не заметил, все работало на ура, но вот версия 1026.3 ЖУТКО ТОРМОЗИТ поэтому написал частичный - буду переходить на x64+Oracle 10.2.0.4 x64, потом уже память настраивать.
У меня тоже перенос идет довольно долго, но ...
Код:
DELETE      sslocks
      WHERE objtype = 'DB';
COMMIT ;
В конце работы переноса СМ-Администратор выдаст ошибку (типа невозможно разблокировать БД) - это нормально.
24.01.2009 14:02
mighty
 
Цитата:
deucel У меня тоже перенос идет довольно долго, но ...
В конце работы переноса СМ-Администратор выдаст ошибку (типа невозможно разблокировать БД) - это нормально.
Обнаружил сейчас только что неиспользвоание индексов "не отвязывает" вставку данных в таблицы от отграничений..Надо еще отключать констарайнты все, ссылки на вторичные ключи, чеки и триггеры..за выходные опробую новый полный и частичные переносы и выложу уже готовые решения. Еще проверить надо что у тебя все такблицы FF% - LOGGING=FALSE у меня после перехода на 1.026.3 70% таблиц FF% стали LOGGING=TRUE, это тормозит - в момент вставки данных в ораклом остаются данные для отката в случае отмена транзакции...
У меня вставка в таблицу FFDOCUMENTS сегодня ночью прошла за 8 минут. А когда я руками сейчас поотключал все вышеописанные ограничения - за 23 секунды вставка прошла..

По поводу кода я не понял к чему ты его привел.

И вопрос: Каким ты СМ-Админстратором пользуешься с полным переносом? или МС-Администратором без переноса? У меня их два..
30.01.2009 12:38
deucel
 
Цитата:
mighty По поводу кода я не понял к чему ты его привел.

И вопрос: Каким ты СМ-Админстратором пользуешься с полным переносом? или МС-Администратором без переноса? У меня их два..
По поводу кода: После запуска переноса в Административном модуле БД Супермага блокируется для всех изменений.
После того как удалены разоприходованные документы и т.п. и начался перенос (появились циферки и проценты) - выполни скрипт и блокировка будет снята.

Использую частичный перенос раз в неделю, который идет около двух часов (закрытых периодов нет, объем документов для переноса около 40000).
25.08.2011 08:37
Romeug
 
mighty, а существует решение для полного переноса в версии 1.028? После перехода с 1.026.4 sp5 на 1.028 sp3 в одном из магазинов перестал делаться перенос. За час переносится менее 1900 документов из 165 тыс., то есть чуть больше 1%. При этом процессом Oracle за это время считано около 7 ГБ данных и записано чуть меньше 1 ГБ, и процессор периодически подгружается около 50%. То есть он чего-то активно делает, но получается очень медленно.
Во всех остальных точках стало чуть медленнее, конечно, но не до такой же степени.
Переиндексация, сбор статистики и все остальные административные утилиты не помогают. Пробовал уже старую базу до перехода заново обновить - результат тот же. Логи у аналитических таблиц отключал - ускоряется очень незначительно. Все это делал на 2 машинах и с разными конфигурациями БД. Правда Oracle у нас до сих пор 8.1.6, но даже на большей базе делается не намного дольше, чем до обновления версии СМ+.
25.08.2011 09:28
OlegON
 
Уже писал выше, попробуйте штатный инкремент, зачем ищешь грабли? Тем более, что есть же задание по расписанию теперь?
Подозреваю, что не отключен какой-то из новых индексов. Если разберешься - убедительно прошу сообщить, какой именно.
25.08.2011 09:43
konst
 
Вообще когда идет перенос документов то первые несколько процентов всегда идут очень медленно (скорее всего кассовые доки переносятся)
25.08.2011 10:02
Romeug
 
Пробовал ждать долго, но на третьей тысяче перенос начинает делаться так медленно, что за 14 часов было сделано меньше 10%.
25.08.2011 10:13
OlegON
 
Я уже говорил, как по простому выкрутиться (если это не неотключенный индекс).
Рвешь его на этой самой третьей тысяче и считаешь статистику по той табличке, куда идет перенос.
25.08.2011 11:40
Romeug
 
А как вычислить эту табличку?
25.08.2011 12:10
OlegON
 
Ты скрипт выполняешь? Вот и посмотри, на каком insert он тупит.
Я уже запутался, ты в администраторе считаешь или скриптом? Если первое, то заведи отдельную тему.
25.08.2011 20:20
mighty
 
Нет, я все еще работаю на версии 1.026 сп5, перенос использую без блокировки, который сам написал, для 1028 версии надо изучать структуру таблиц, возможно что то поменялось. Могу если у кого нибудь есть желание выложить исходники своей программы, доработаете сами. Но у меня переносы быстро идут. Базу вообще не блокирую, рассчет себестоимости еженочный и в магазинах и в базе ЦО. Просто поговорил с бухами, они сказали что блокировка вообще не нужна. Потому что ночью накладные не заводятся, движений нет, и даже если перенос и расчет происходит днем то изменения в себестоимости сотня рублей максимум.


Опции темы


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

 

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