Export, Import : Oracle

Интересно, а в ходе импорта табличные пространства могут создаваться сами? Или обязательно нужно создавать табличные пространства заранее?

Если посмотришь файл экспорта, то увидишь там команды на создание табличных пространств, тем не менее, я предпочитаю создавать их сам, как надо. Только не забывай давать квоту для supermag на эти табличные пространства.

Создавать как надо - это значит делать их такими как в исходной базе или уменьшать размеры табличных пространств исходя из своботного места?

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

Дело вот в чем: периодически возникающая проблема нехватки места например в табличном пространстве INDX заставила увеличить его размер до 6 Гб. Оptimizer показал что свободного места там 2.5 Гб. Перед импортом создаю INDX 4Гб и импортирую. Все нормально, размер базы стал на 2Гб меньше.
Имеет ли смысл производить такие действия?

если это рабочая база - не имеет. все равно она будет расти постепенно. лучше оставить свободное место, чтобы оптимайзеру было где резвиться.

Экспериментирую тут с переездом на win2003/oracle9
Через sm_upgrader.

Новую базу в 9 создал с параметрами по умолчанию, надо было под исходную подогнать, ну да ладно, переделаю.

При импорте:
1) На все CREATE TABLESPACE ругнулось
IMP-00003: ORACLE error 12913 encountered
ORA-12913: Cannot create dictionary managed tablespace

Оставить System - locally managed или есть смысл пересоздавать как dictionary managed ?

2) Мноого ошибок по части DBMS_STATS
IMP-00003: ORACLE error 6502 encountered
ORA-06502: PL/SQL: numeric or value error
и т.п., еще
IMP-00003: ORACLE error 1917 encountered
ORA-01917: user or role 'MDSYS' does not exist
Игнорировать?

3) По всем представлениям и триггерам
IMP-00041: Warning: object created with compilation warnings

В конце
Import terminated successfully with warnings.

Оптимайзером /compile (ok), потом /optimize , но прервал на validate.
Запустил cм2000 - проверка структуры базы, несоответствия:

Плюс немножко отсутствующих ограничений.

В общем как быть ?
Кстати, версия СМ 1024sp5 - обновление для работоспособности на 9 обязательно или не в этом дело?

Где-то в процессе апгрейдов что-то слетало. Вряд ли это результат экспорта-импорта. Самое простое - вручную сделать так, как хочет проверка. Но в данном случае проверка показывает косвенные изменения вьюшек. Посмотри в SQL Navigator'е есть сравнение структуры двух баз, прогони им, заодно результирующий скрипт для синхронизации получишь, только внимательно посмотри, он не всегда 100% верен.

Стоп. То, что написал, оставлю другим, кто столкнется с аналогичным, но когда первая цифра будет правильной. У тебя, судя по всему, просто шаблон криво снялся. Но прогнать навигаторной проверкой по любому не помешает. Из опций только таблицы и колонки поставь. В остальном, кажется, можно и администратору доверять.

olegon,
Ничего не понял *16
Что значит 'слетало в процессе апгрейдов' ?
Какая и где должна быть 'правильная первая цифра' ?
А шаблон - от С+, на рабочей восьмерочной базе расхождения с ним есть, но несущественные.

Т.е. по восьмерочной базе ругательств на размерность 22 нет? Сделай проще, чтобы не морочить голову - создай 9кой чистоую базу, проапгрейдь ее до своей версии и сделай шаблон. С ним и сравнивай.