12.03.2020 15:13
Stels
 
Как обычно "вдруг" сломался расчёт себестоимости.
темы на форуме по ошибке почитал :)
База центральная
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;
....
отрабатывает без ошибок, но валится так же ...

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

Кто может - ткните носом, пожалуйста, куда дальше смотреть..
12.03.2020 16:09
Nik_75
 
Подобная ошибка , так же вылезла недавно. При чем валится сам перенос с ошибкой записи номеров оснований. Пока решил проблему поставив перезагрузку сервера перед началом расчета.
12.03.2020 16:37
Stels
 
Цитата:
Nik_75 При чем валится сам перенос с ошибкой записи номеров оснований.
да именно так
перезагрузка сервера не помогает
12.03.2020 16:48
Nik_75
 
После ребилда индескса полную очистку базы делал?
12.03.2020 17:04
Stels
 
Цитата:
Nik_75 После ребилда индескса полную очистку базы делал?
дак там нечего очищать ... всё уже очищено
12.03.2020 17:06
OlegON
 
Цитата:
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) Посчитать вручную и засечь точно, где упадет и по какой ошибке.
12.03.2020 17:10
Nik_75
 
Странно, ну мне еще удаление всех сессий и остановка почтовика помогала.
12.03.2020 17:16
Stels
 
Цитата:
OlegON 1) Убедиться, что в системном и твоем %TEMP% минимум 350Гб свободного места
хм ... в темпе столько отродясь не было ... там 180гб ...
попробую переназначить в на другой диск ... там >500 есть
12.03.2020 17:38
OlegON
 
Цитата:
Stels попробую переназначить в на другой диск
Вот когда будешь потом вручную считать, убедись, что оно льется туда, куда назначил. А если посчитается, то потом убедись, что и по расписанию туда же.
У меня в свое время какая-то засада с этим была, упирался долго, но в чем суть была точно не помню. Сам процесс расчета ТД заключается в том, что создаются большие файлики, а потом заливаются в базу. Вот этим файликам может места и не хватить.
12.03.2020 19:40
Stels
 
Цитата:
OlegON 1) Убедиться, что в системном и твоем %TEMP% минимум 350Гб свободного места. Особо важно, поскольку ты выполнил уже полную очистку.
2) Ребутнуть сервер
3) Посчитать вручную и засечь точно, где упадет и по какой ошибке.
Перенёс темп
Ребутнул сервак
Запустил руками - снова ошибка (на скрине)
Миниатюры
Нажмите на изображение для увеличения
Название: Скриншот от 2020-03-12 19-34-54.png
Просмотров: 33
Размер:	52.8 Кб
ID:	10681  

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