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

john_the_ripper · █ 22.01.2018 04:07

Периодически, на центральной базе базе залипает перенос базы в аналитическую базу. Заходим в админ модуль, в статусе видим что идет перенос и запись "ведется перенос документов 0 из 0", при этом крутится запрос(ниже приведу листинг запроса) и может так крутиться часов 8. Тут же отменяем перенос, очищаем аналитическую базу, срабатывает снова перенос по расписанию и выполняется за 20 минут без любых проблем и в статусе сразу появляется "ведется перенос документов 12 из 99999(числа условные)".

Нагрузки на диски не было в это время, инстанс не перезапускался, каких-то аномальных сообщений в алерте нет. Единственное могу связать с тем, что проблема появилась после обновления на SM 1.035 SP3 с SM 1.034. Oracle 11, windows 2012 R2 64bit.

Может сталкивался кто-то с аналогичной ситуацией или есть какие-то мысли по выявлению проблемы?

SQL:
скрытое

SQL код:

  insert /*+ APPEND NOLOGGING */ into TTFIFOChangedDocs (RowIdx,DocType,ID,CreatedAt,OpCode,LocationFrom,LocationTo,PayCash,TotalSum,ClientIndex,GoodsOwner,CurrencyType,CurrencyRate,CurrencyMultOrder,IsRoubles,TotalSumCur,UserOp,SupplierDoc,SupplierInvoice,SupplInvoiceCreate,TotalSumVAT,IsPeriod) select ROWNUM,H.DocType,H.ID,H.CreatedAt,H.OpCode,H.LocationFrom,H.LocationTo,nvl(nvl(XIn.PayCash,XOut.PayCash), decode(H.DocType,:"SYS_B_00",:"SYS_B_01",:"SYS_B_02",:"SYS_B_03",:"SYS_B_04")) PayCash,H.TotalSum, H.ClientIndex,nvl(XIn.GoodsOwner,:"SYS_B_05"),H.CurrencyType,H.CurrencyRate,H.CurrencyMultOrder,H.IsRoubles,H.TotalSumCur, H.UserOp,XIn.SupplierDoc, nvl(XIn.SupplierInvoice,XOut.Invoice),nvl(XIn.SupplInvoiceCreate, XOut.InvoiceDate),H.TotalSumVAT,nvl((select :"SYS_B_06" from SMDocProps P where P.DocType=H.DocType and P.DocID=H.ID and P.ParamName=:"SYS_B_07" and P.ParamValue=:"SYS_B_08"),:"SYS_B_09") IsPeriod from (select H.DocType, H.ID, TRUNC(H.CreatedAt) CreatedAt, H.OpCode, H.LocationFrom, H.LocationTo, H.TotalSum, H.ClientIndex, H.CurrencyType, H.CurrencyRate, H.CurrencyMultOrder, H.IsRoubles, H.TotalSumCur, H.UserOp, nvl(sum(T.TaxSum), :"SYS_B_10") TotalSumVAT from ( select D.ID, D.DocType, D.CreatedAt, D.LocationFrom, D.LocationTo, D.OpCode, D.UserOp, D.ClientIndex, D.CurrencyType,D.CurrencyRate,D.CurrencyMultOrder,D.IsRoubles, D.TotalSum, D.TotalSumCur from SMDocuments D where D.DocType in (:"SYS_B_11",:"SYS_B_12",:"SYS_B_13",:"SYS_B_14",:"SYS_B_15",:"SYS_B_16",:"SYS_B_17",:"SYS_B_18") and D.CreatedAt<=to_date(:"SYS_B_19",:"SYS_B_20") and D.DocState=:"SYS_B_21" and D.CreatedAt >= to_date(:"SYS_B_22",:"SYS_B_23") and ( D.CreatedAt>to_date(:"SYS_B_24",:"SYS_B_25") or exists (select :"SYS_B_26" from SMDocLog L where    L.DocType = D.DocType and L.ID = D.ID and (L.EventTime>to_date(:"SYS_B_27",:"SYS_B_28") and L.EventTime<=to_date(:"SYS_B_29",:"SYS_B_30")))) ) H, SMDocTax T where    T.DocType(+) = H.DocType and T.DocID(+) = H.ID and T.TaxId(+) = :"SYS_B_31" group by H.DocType, H.ID, TRUNC(H.CreatedAt), H.OpCode,H.LocationFrom, H.LocationTo, H.TotalSum, H.ClientIndex,H.CurrencyType, H.CurrencyRate, H.CurrencyMultOrder, H.IsRoubles,H.TotalSumCur, H.UserOp ) H, SMWayBillsIn XIn, SMWayBillsOut XOut where H.DocType=XIn.DocType(+) and H.ID=XIn.ID(+) and H.DocType=XOut.DocType(+) and H.ID=XOut.ID(+)

OlegON · █ 22.01.2018 06:49

Мысли есть, сталкивался. Из общедоступного - период когда закрывал в последний раз?

john_the_ripper · █ 22.01.2018 07:12

Период закрывался пару лет назад, но больше всего в этой проблеме смущает её нелинейность и рандомность, поэтому чисто логически, не могу её увязать напрямую с обьемом данных, да и нагрузкой т.к. в это время какой-то повышенной нагрузки на сервер не наблюдается.

OlegON · █ 22.01.2018 07:22

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

john_the_ripper · █ 22.01.2018 08:29

Цитата:

OlegON ➤ добавил в оптимизатор решение. Но период все равно надо закрыть. Иначе, так и будет дальше колбасить.

А как давно добавлено было решение в оптимизатор? Спрашиваю потому-что проблема проскочила впервые накануне нового года, и периодически проскакивает до сих пор, при работающем оптимизаторе.

OlegON · █ 22.01.2018 09:38

Где-то полгода назад. Потому и говорю, надо закрыть период, чтобы не колбасило.