Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > Супермаг Плюс (Супермаг 2000)

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

23.11.2024 7:26


16.04.2008 18:11
Не...не получилось..
22.04.2008 17:07
Цитата:
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
прикольно.
неудобно только, что придется отслеживать возможные изменения структур в будущих версиях.

если внедришь для регулярного использования, то поделись, пожалуйста через пару-тройку десятков запусков статистикой: были ли проблемы.
13.01.2009 13:10
Цитата:
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 Кб, 150 просмотров)
13.01.2009 13:27
Странно как-то... У меня перенос (инкрементальный, конечно) занимает около 7 минут. Считается около полутора часов. Где-то 50 магазов. В связи с чем не вижу необходимости что-то дописывать. Патч смогу отдать на выходных.
13.01.2009 13:28
Цитата:
mighty Люди поделитесь патчем Oracle 10.2.0.4 x64 под Вынь2003x64? Нигде не могу найти - у меня Oracle 10.2.0.3 x64...Пжалстаааааа
Давай куда залить, залью, он весит гиг
13.01.2009 14:25
Цитата:
OlegON Странно как-то... У меня перенос (инкрементальный, конечно) занимает около 7 минут. Считается около полутора часов. Где-то 50 магазов. В связи с чем не вижу необходимости что-то дописывать. Патч смогу отдать на выходных.
Фигасе...классно...Я буду разбираться с базой только после того как x64 поставлю - сейчас времени нет абсолютно..Олег, я обращусь по любому за помощью в настройке памяти и отдельных параметров оракла здесь на форуме, поможете?

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

Полгода работал на полном переносе(перенос и расчет был каждую ночь) - косяков и глков не заметил, все работало на ура, но вот версия 1026.3 ЖУТКО ТОРМОЗИТ поэтому написал частичный - буду переходить на x64+Oracle 10.2.0.4 x64, потом уже память настраивать.
У меня тоже перенос идет довольно долго, но ...
Код:
DELETE      sslocks
      WHERE objtype = 'DB';
COMMIT ;
В конце работы переноса СМ-Администратор выдаст ошибку (типа невозможно разблокировать БД) - это нормально.
Часовой пояс GMT +3, время: 07:26.

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