Форум OlegON > Компьютеры и Программное обеспечение > Операционные системы и программное обеспечение > Oracle

Восстановление базы после падения жесткого диска : Oracle

19.03.2024 14:07


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), из-за битых строк в таблицах, которые выявились следующими действиями:
()

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, время: 14:07.

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