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

Нужна помощь!
Расчет себестоимости вывалился с ошибкой...

ORA-01410: ROWID неверен
ORA-06512: ia "SUPERMAG.FIFOTRANSFER", line 216
ORA-06512: ia "SUPERMAG.FIFOTRANSFER", line 359
ORA-06512: ia "SUPERMAG.FIFOTRANSFER", line 816
ORA-06512: ia "SUPERMAG.FIFOTRANSFER", line 843
ORA-06512: ia "SUPERMAG.SMRUNTRANSFER", line 6
ORA-06512: ia line 1

{ call Supermag.SMRunTransfer(?, ?) }
Params:
{0} (null)[0](0,0): vt=7 value=16.11.2008
{1} (null)[0](0,0): vt=7 value=16.11.2008

Что можно сделать? Где смотреть?
Возможно это как-то связано с очень медленной обработкой некоторых запросов? Например, выборка накладных за 15 последних дней выполняется на протяжении 15(!) минут... Отображение текущих остатков или выполнение рукописных отчетов по реализации (использую SMDOCUMENTS, SMSPEC...) по времени в пределах нормы...

Надо смотреть в глубь Alert.log
Но похоже, что экспорт/импорт не помог.

Что касается медленной работы: статистика по таблицам после импорта собиралась? По temp-овым таблицам может имеет смысл удалить статитсику?

в том то и дело, что в alert.log ничего страшного нет... лишь последовательные вставки в redo, типа:

Thread 1 advanced to log sequence 934
Current log# 1 seq# 934 mem# 0: R:\ORACLE\ORADATA\DBCOSTR\REDO01.LOG

Статистика собиралась неоднократно административными заданиями.

а не через административные задания статистику собирал ?

нет, не собирал...
при помощи - dbms_stats?

или analyze table...

Посмотрел план выполнения запроса (select * from supermag.smspec where docid in('КЗ01200282')) - SELECT STATEMENT, GOAL = CHOOSE 1307 1786 105374
TABLE ACCESS FULL SUPERMAG SMSPEC 1307 1786 105374
- как я понимаю, индексы не используются. Вот и причина?...
Выполнил сбор статистики вручную следующим образом (правильно?):

begin
dbms_stats.gather_schema_stats (
ownname => 'SUPERMAG',
cascade => TRUE,
estimate_percent => dbms_stats.auto_sample_size,
method_opt=>'for all columns size skewonly'
);
end;

Перезапустил базу. План запроса не изменился... как, собственно, и скорость работы с документами...

Этот запрос выдаёт СМ или это от ваших приложекний?
А если переписать запрос так
Просто сама конструкция in медленная, так ещё и индекс уникальный по двум полям построен, поэто Оракель и не может понять что именно от него хотят.

Так... План запроса получил через PL/SQL Developer. По второму запросу:
SELECT STATEMENT, GOAL = CHOOSE 4 5 265
TABLE ACCESS BY INDEX ROWID SUPERMAG SMSPEC 4 5 265
INDEX RANGE SCAN SUPERMAG SMCSPEC_DISPLAYPOS 5 5

Все-таки, выходит, индексы используются...
Первый запрос - 0,266с
Второй запрос - 0,047с
Работа с документами по-прежнему очень медленная.. что же еще можно предпринять?

Чувствую, что не в тему ляпну, но все-же:
Может быть, запустить задания на пересоздание индексов в Адм. модуле?
У нас как-то были тормоза дикие, решилось запуском заданий...

з.ы. если ступил, не ругайте строго:)