Перенос БД с 32 бит на 64 : Oracle

qwrty40 · █ 12.01.2016 06:06

Доброго времени суток всем!
Не пинайте за дурацкий вопрос, но...
Нужно перенести БД из 32-битной среды Oracle 10.2.0.4.0 в 64-битную. Можно ли это сделать холодным бэкапом?

OlegON · █ 12.01.2016 07:17

нельзя, в случае с Супермагом - экспорт/импорт

qwrty40 · █ 07.07.2016 01:13

Как бы в продолжение темы.
Искал инфу по переносу базы из 10 в 11 и наткнулся на это:

Цитата:

With this approach, we first installed Oracle 11g software on development server and created empty database by using provided standard template New_Database.dbt, which could be found at $ORACLE_HOME/assistants/dbca/templates. After that, we followed the following steps to move data from 10g database to newly created 11g database.

Step 1: Pre-create tablespaces on target 11g database

- using the Generate_Create_Tablespaces.sql to generate tablespace script
- editing generated script to remove entries for SYSTEM, USERS tablespaces

Step 2: Export full database of source 10g database

Собсно вопрос: зачем нужен Step 1? Из-за того, что при создании пустой базы использовали стандартный шаблон?

OlegON · █ 07.07.2016 06:52

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

Neutron · █ 07.07.2016 17:03

Здесь все подробно разжевано про экспорт и импорт

qwrty40 · █ 06.03.2017 01:44

Цитата:

Neutron ➤ Здесь все подробно разжевано про экспорт и импорт

Очень уж старая инфа там...

qwrty40 · █ 06.03.2017 02:07

Подниму тему...
Наконец-то дошли руки до повозиться. Накатил тестовый 11.2.0.4 (64 бит), импорптнул в него 10.2.0.4 (32 бит). Вполне ождидаемо получил кучу ошибок. Посмотрел лог, почитал всяко разное, создал недосозданное (tablespace) при создании БД, повторил импорт. Опять вылезло много чего:
1. Не та версия management system (там и прав на объекты нет, и с ограничениями проблемы и т.д.);
2. Триггера скомпилены с предупреждениями (IMP-00041: Warning: object created with compilation warnings – в чем прикол непонятно, критично или нет - тоже);
3. ORA-01741: illegal zero-length identifier куча на CREATE PUBLIC SYNONYM "" FOR "SYS"...
Так пока и не понял: взлетит, не взлетит...

qwrty40 · █ 06.03.2017 02:09

Лог - https://storage.olegon.ru/supermag/u...imp_dbshams.7z сюда положил на всякий случай...

OlegON · █ 06.03.2017 07:15

Описал безобразно... Думаю, что к миграции 32->64 это все отношения не имеет, просто косячишь.
Создавал несозданное уже в новой БД?
1. Ошибка-то какая?

По итогам перекомпиляции инвалидов не должно остаться, если ты опции БД не менял и СУБД только в битности менялась. Если менял - пиши, что менял.

qwrty40 · █ 09.03.2017 00:10

Цитата:

OlegON ➤ Описал безобразно... Думаю, что к миграции 32->64 это все отношения не имеет, просто косячишь.
Создавал несозданное уже в новой БД?
1. Ошибка-то какая?

По итогам перекомпиляции инвалидов не должно остаться, если ты опции БД не менял и СУБД только в битности менялась. Если менял - пиши, что менял.

Собсно, лог я выложил. Чего там только нет: ошибки, предупреждения, черт лысый, овощ собачий... При всем при том перекомпиляция прошла - оба сообщения на выходе с нулями.
Запустился с тестовой лицензией - с виду все на местах: СМ запускается, документы в списках показывает, выборочная сверка с исходной базой различий не кажет (вроде все одинаково)...