Поломался расчёт себестоимости : Супермаг Плюс (Супермаг 2000)

Stels · █ 12.03.2020 15:13

Как обычно "вдруг" сломался расчёт себестоимости.
темы на форуме по ошибке почитал :)
База центральная
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit
Версия СМ - 1.039.2
ОСЬ - Win Serv 2012 R2 Stand
база ~ 350Гб
Себестоимость рассчитывалась на автомате каждое утро.

Код:

2020.03.11 (среда) 22:19:50
Версия 1.039.2
>>> Запись 1
Источник: OraOLEDB
HRESULT=80040e14 custom=1502 SQLState=<none>
ORA-01502: index 'SUPERMAG.FFSPEC_CAUSEIDX' or partition of such index is in unusable state
ORA-06512: at "SUPERMAG.FIFOTRANSFER", line 407
ORA-06512: at "SUPERMAG.FIFOTRANSFER", line 654
ORA-06512: at "SUPERMAG.FIFOTRANSFER", line 679
ORA-06512: at "SUPERMAG.SMRUNTRANSFER", line 6
ORA-06512: at line 1
>>> Запись 2
Источник: SmLibaryBase trace
HRESULT=80004005 custom=0 SQLState=<none>
{ call Supermag.SMRunTransfer(?, ?) }
Params:
{0} [0](0,0): vt=7 value=11.03.2020 22:09:11
{1} [0](0,0): vt=7 value=11.03.2020 22:09:00

в алерте

Код:

Wed Mar 11 22:24:52 2020
Archived Log entry 5983 added for thread 1 sequence 6114 ID 0xc8b68d17 dest 1:
Wed Mar 11 22:28:57 2020
Index SUPERMAG.FFDOCUMENTS_SALEDATEIDX or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFDOCUMENTS_INCOMEDATEIDX or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFDOCUMENTS_CREATEDAT or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFDOCUMENTS_CLIENTIDX or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFSPEC_CAUSEIDX or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFSPEC_ART or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFPRODDOCUMENTS_DATE or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFPRODDOCUMENTS_ZONE or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFPRODINSPEC_ZONEART or some [sub]partitions of the index have been marked unusable
Index SUPERMAG.FFPRODOUTSPEC_ZONEART or some [sub]partitions of the index have been marked unusable
Wed Mar 11 22:31:21 2020

Есть закрытый период по 01-01-2019
Место во всех табличных пространствах перепроверил.
добавил на всякий случай.
Очистку базы кнопкой делал.

Работает купленный оптимайзер Олегона - ошибок не показывает.
(после поломки расчёта отработал уже две ночи)
есть вот

Код:

11.03.20 06:11:07 -- Log filename: C:\Oracle\diag\rdbms\krasco\krasco\trace/alert_krasco.log 5Mb
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFDOCUMENTS_CREATEDAT" rebuild - indexes rebuild [1/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFPRODOUTSPEC_ZONEART" rebuild - indexes rebuild [2/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFDOCUMENTS_CLIENTIDX" rebuild - indexes rebuild [3/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFSPEC_ART" rebuild - indexes rebuild [4/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFPRODDOCUMENTS_DATE" rebuild - indexes rebuild [5/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFDOCUMENTS_SALEDATEIDX" rebuild - indexes rebuild [6/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFSPEC_CAUSEIDX" rebuild - indexes rebuild [7/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFPRODDOCUMENTS_ZONE" rebuild - indexes rebuild [8/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFDOCUMENTS_INCOMEDATEIDX" rebuild - indexes rebuild [9/10]
11.03.20 06:11:08 -- alter index "SUPERMAG"."FFPRODINSPEC_ZONEART" rebuild - indexes rebuild [10/10]
11.03.20 06:11:23 -- Wasted space .......

Код:

12.03.20 02:16:11 -- Purge DBA recyclebin
12.03.20 02:16:11 -- Bad blocks check
12.03.20 02:16:11 --  - SYS tables validation [1/921]
12.03.20 02:16:11 --  - SYS tables validation [2/921]
12.03.20 02:16:11 --  - SYS tables validation [3/921]
12.03.20 02:16:11 --  - SYS tables validation [4/921]
...

пробовал руками

Код:

alter INDEX SUPERMAG.FFSPEC_CAUSEIDX unusable;
alter INDEX SUPERMAG.FFSPEC_CAUSEIDX rebuild;
....

отрабатывает без ошибок, но валится так же ...

По объективным причинам могу ковырять базу только ночью.
Сервер перегружал ...
Никаких обновлений давно не делал..

Кто может - ткните носом, пожалуйста, куда дальше смотреть..

Nik_75 · █ 12.03.2020 16:09

Подобная ошибка , так же вылезла недавно. При чем валится сам перенос с ошибкой записи номеров оснований. Пока решил проблему поставив перезагрузку сервера перед началом расчета.

Stels · █ 12.03.2020 16:37

Цитата:

Nik_75 ➤ При чем валится сам перенос с ошибкой записи номеров оснований.

да именно так
перезагрузка сервера не помогает

Nik_75 · █ 12.03.2020 16:48

После ребилда индескса полную очистку базы делал?

Stels · █ 12.03.2020 17:04

Цитата:

Nik_75 ➤ После ребилда индескса полную очистку базы делал?

дак там нечего очищать ... всё уже очищено

OlegON · █ 12.03.2020 17:06

Цитата:

Stels ➤ index 'SUPERMAG.FFSPEC_CAUSEIDX' or partition of such index is in unusable state

Это говорит о том, что скорее всего sqlldr уже начал работать или подготовка к нему началась, для ускорения заливки Супермаг сам отключает свои индексы.

Цитата:

Stels ➤ Index SUPERMAG.FFSPEC_CAUSEIDX or some [sub]partitions of the index have been marked unusable

собственно, в алерте видно, что он это сам делает...

Хронология появления ошибки, видимо, такая...
- Работало ТД, упало с отключенными индексами
- Очередной заход упал, потому, что индекс битый
Вот интересна больше первая ошибка, почему первый заход екнулся.

Что делать:
1) Убедиться, что в системном и твоем %TEMP% минимум 350Гб свободного места. Особо важно, поскольку ты выполнил уже полную очистку.
2) Ребутнуть сервер
3) Посчитать вручную и засечь точно, где упадет и по какой ошибке.

Nik_75 · █ 12.03.2020 17:10

Странно, ну мне еще удаление всех сессий и остановка почтовика помогала.

Stels · █ 12.03.2020 17:16

Цитата:

OlegON ➤ 1) Убедиться, что в системном и твоем %TEMP% минимум 350Гб свободного места

хм ... в темпе столько отродясь не было ... там 180гб ...
попробую переназначить в на другой диск ... там >500 есть

OlegON · █ 12.03.2020 17:38

Цитата:

Stels ➤ попробую переназначить в на другой диск

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

Stels · █ 12.03.2020 19:40

Цитата:

OlegON ➤ 1) Убедиться, что в системном и твоем %TEMP% минимум 350Гб свободного места. Особо важно, поскольку ты выполнил уже полную очистку.
2) Ребутнуть сервер
3) Посчитать вручную и засечь точно, где упадет и по какой ошибке.

Перенёс темп
Ребутнул сервак
Запустил руками - снова ошибка (на скрине)