17.05.2009 00:57
Итак, первый шаг - апгрейд до 1025 и первое, обо что я споткнулся - то, что на 10ке генератор БД отказался работать, бо не мог найти клиента. Не стал упираться - пнул генератор с соседней машины, где еще 9i стояла и 32бита.
Вторая засада - на шаге 1.025\24_6To25_a
Цитата:
ORA-00955: имя уже задействовано для существующего объекта
ORA-06512: на "SUPERMAG.SMINITNEWCONSTRAINT", line 4
ORA-06512: на line 2
Откатывать из бекапа не стал, сразу в блокнотик сбросил
Код:
update update supermag.sssysinfo set ParamValue='1.029.3' where paramname='Version';
update supermag.sssysinfo set ParamValue='Upgrade complete' where paramname='UpgradeStep';
commit;
Как кто-то упоминал уже - попробовал снять компрессию (у меня она была, например, на smdoclog), с перестройкой таблицы и индексов - не помогло, с матюками на программеров вытащил опять скриптик из блокнота - откатился.
Достал ресурсы, поковырялся, вынес индекс SMCASSORTMATRIXHIST_PK,
запустил, упало, на этот раз в
TTCCollectDiscCard_PK, вынес, оба, поскольку первый опять создался:
Цитата:
alter table TTCollectDiscCard drop constraint TTCCollectDiscCard_PK;
alter table smASSORTMATRIXHIST drop constraint SMCASSORTMATRIXHIST_PK;
drop index TTCCollectDiscCard_PK;
drop index SMCASSORTMATRIXHIST_PK;
для тех, кто читает по диагонали, это была единственная проблема при переходе до 1025. Т.е. по вине программеров генератора, объекты пытались создасться дважды. Дропайте эти два индекса, они пересоздадуться и будет вам счастье. Не поможет - проверьте компрессию (select distinct compression from all_tables;)
Да, еще забыл предупредить по памяти делал перед всеми запусками гранты ибо уже падало раньше, база экспортная.
Вдогонку, SUPERMAG.SMINITNEWCONSTRAINT, как правило, валится из-за существования индекса с именем констрейнта, который пытаются создать. Т.е. просто необходимо найти нужный SMINITNEWCONSTRAINT, второй аргумент у него - имя констрейнта. И набрать drop index второй аргумент.
17.05.2009 01:48
До 1026.1 обновление прошло без приключений, несмотря на секции и другие заморочки...
17.05.2009 02:04
Аналогичным образом добрался и до 1026.3, но могу отметить достаточно долгий прогон скриптов... Сказывается запуск внешних утилит генератором...
18.05.2009 15:07
Программеры говорят, что эта проблема с "SUPERMAG.SMINITNEWCONSTRAINT" после импорта в 10g. Я удалял таблицы SMOPERACCOUNT и SMOPERACCOUNTOP и создавал их заново, что бы первичный ключ создался. Единстрвенная загвоздка, что скрипты в базе не помогали, брал с БД, где есть первичный ключ.
18.05.2009 15:37
Хм, ну удалять таблицы, думаю, не стоит. И что интересно - у тебя другие таблицы.. Судя по всему, проблема та же, что и в почтовике. Он не различает констрейнты и соответствующие индексы.
18.05.2009 15:45
При обновлении с 1.024.6 после появления ошибки лечится удалением индексов SMOPERACCOUNTOP_PK и SMOPERACCOUNT_PK с повторным запуском генератора БД (предварительно исправляем номер версии в sssysinfo).
Обновление с версии 1.026.2 требует также удаления индекса SMCPROCESSDOCCREATESPECORCO_PK.
Всё вышесказанное справедливо только для Oracle 10g, в версиях 32- и 64-бит. К Oracle 9i никакого отношения не имеет.
По словам разработчиков, проявляется не на всех экземплярах 10-го Оракла. В следующих версиях должны исправить.
18.05.2009 15:53
Погоди, ты говоришь о прямом апгрейде? У меня пошаговый до 1025 и далее, как видишь, вызвал совсем другие ошибки. И после их поправки все прошло.
18.05.2009 15:55
Да, апгрейд прямой до 1.026.3 либо 1.026.4
Пошаговым не пользовался.
18.05.2009 16:00
Иххх, а я парился. Опять же по рекомендации ТП :(
18.05.2009 16:04
Могу говорить лишь о собственном опыте, основанном на ограниченном количестве баз данных. Возможно, у ТП есть основания рассуждать иначе.
Часовой пояс GMT +3, время: 22:17.

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