[ОТВЕТИТЬ]
Опции темы
13.07.2010 02:49  
whitewizard
Началось всё с того, что перестало работать товародвижение с ошибкой неуникальностью индекса 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), из-за битых строк в таблицах, которые выявились следующими действиями:
(Oracler: ORA-02298: cannot validate)

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. оптимизатор лечит не всё
 
13.07.2010 08:37  
OlegON
Спасибо за столь объемное пояснение, но
1. Надо понимать, что в результате подобного "восстановления" ты просто поудалял часть записей из базы в произвольном порядке. Т.е целостность данных нарушена.
2. "Нехватка кое-каких объектов" обозначает, что часть данных в базу могла и не попасть. А часть - не обработана. Еще один довод в пользу нарушения целостности данных.
Я к чему... Что есть повод подумать об удалении всех документов и их журналов, чтобы не быть введенным в заблуждение их наличием. Они неправильные.
 
13.07.2010 11:21  
whitewizard
Так как была нарушена каскадность, то при удалении кассовых документов, произошло удаление не со всех табличек.

Кассовые документы пересоздали заново.

Но так лучше, чем вообще ничего :)
 
 
Опции темы



Часовой пояс GMT +3, время: 17:14.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.