Началось всё с того, что перестало работать товародвижение с ошибкой неуникальностью индекса FFSMSPEC.
Дальнейшее разбирательство показало неуникальность индекса SMSPEC, куча битых FOREIGN INDEX и битые блоки
в таблицах SMSPECTAX, SMSPECSTAT итд
т.к. бэкапа свежего не было, а магазин должен был работать, то дальше восстановление проводилось практически на работающей базе.
Последовательность действий по восстановлению:
1. бэкапа того, что осталось
2. проверка в администраторе несоответсвие структуры, которая показала нехватку кое-каких объектов.
3. пересоздание табличного пространства TEMP
4. выяснились все кривые PRIMARY INDEX путем экспорта - Переход с 8i на 9i (для баз Супермага) - (в логе все они показались)
5. т.к. такие индексы нельзя просто так удалить (из-за наличия FOREIGN INDEX), то сначала удалились FOREIGHN INDEX, а потом у сам первичный индекс, с пересозданием.
6. расхождение в таблицах SMSPECTAX, SMSPECSTAT итп, имеющих ссылку на SMSPEC решилось удалением лишних строк скриптом типа
delete smspectax where docid not in (select docid from smspec) и delete smspectax where docid not in (select id from smdocuments)
7. после всего вышеперечисленного перестроились не все FOREIGN INDEX (ORA-02298), из-за битых строк в таблицах, которые выявились следующими действиями:
()
1) Создать таблицу куда будут записываться все строки, для которых возникла ошибка
create table exceptions(row_id rowid,
owner varchar2(30),
table_name varchar2(30),
constraint varchar2(30));
2) Попробовать создать foreign key constraint с ключевыми словами "exceptions into exceptions"
Например,
ALTER TABLE SMSPECTAX ADD (
CONSTRAINT emp_fk_test
FOREIGN KEY (DOCTYPE, DOCID, SPECITEM)
REFERENCES dept (ID)
exceptions into exceptions);
3) Посмотреть все записи , для которых возникает ошибка select * from exceptions;
в моем случае оказались битые строки с ROW_ID типа "AAABFYAADAAA2i2AAF". Они удалились с таблицы и индексы перестроились нормально.
8. остались проблемы с таблицей "smdocprops", которые решились только выгрузкой с SQL навигатора, очисткой кривых записей, пересозданием таблицы и загрузкой обратно.
Предвидя выкрики из зала, чего же это я не накатил Oracle 9i и не запустил оптимизатор, скажу следующее:
1. интернета там не было
2. оптимизатор лечит не всё
Спасибо за столь объемное пояснение, но
1. Надо понимать, что в результате подобного "восстановления" ты просто поудалял часть записей из базы в произвольном порядке. Т.е целостность данных нарушена.
2. "Нехватка кое-каких объектов" обозначает, что часть данных в базу могла и не попасть. А часть - не обработана. Еще один довод в пользу нарушения целостности данных.
Я к чему... Что есть повод подумать об удалении всех документов и их журналов, чтобы не быть введенным в заблуждение их наличием. Они неправильные.