-
Игорь Шевченко © (27.03.10 16:53) [19]
Вот это место имеется в виду:
"The original semantics saved in the export file will be ignored for pre-created objects."?
да, оно
отпишитесь о результатах?
-
Кщд (27.03.10 17:02) [20]
Боюсь, что замучаюсь. Сейчас посмотрел файл от дампа небольшой базы, imp show=y нагенерировал 2 мегабайта SQL, пока я из него вытащу нужные объекты, с меня семь потов сойдет.
Почему, собственно, озаботились проблемой без предварительного создания объектов: довольно трудно найти актуальный скрипт для конкретного дампа, объектов, как я и говорил, довольно много, даже по частям их выковыривать не очень удобно.
Юникодную базу на полсотни гиг оказалось создать гораздо быстрее.
-
По одной таблице все прошло нормально Написан скрипт CREATE TABLE foobar (
id NUMBER(12, 0) NOT NULL,
code VARCHAR2(2) NOT NULL,
name_int VARCHAR2(32),
name_nat VARCHAR2(32)
)
/
CREATE UNIQUE INDEX ...
ALTER TABLE FOOBAR ADD CONSTRAINT foobar_pk PRIMARY KEY (id) ....
и т.п.
в SQL*Plus первой командой выдана ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR выполнен скрипт на создание таблицы imp foo/bar@ora11u ignore=Y tables=(FOOBAR) fromuser=FROMUSER touser=TOUSER file=expdat.dmp log=foobar.log import done in CL8MSWIN1251 character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
. importing FROMUSER's objects into TOUSER
. . importing table "FOOBAR" 210 rows imported
Import terminated successfully without warnings. ну и, соответственно, данные оттуда select length(name_nat),lengthb(name_nat) from foobar where rownum < 10
LENGTH(NAME_NAT) LENGTHB(NAME_NAT)
-------------------- ---------------------
6 12
8 16
6 12
7 14
8 16
7 14
6 12
3 6
7 14
10 20
24 45
LENGTH(NAME_NAT) LENGTHB(NAME_NAT)
-------------------- ---------------------
9 18
15 28
7 14
7 14
14 26
7 13
10 18
4 8 Видно, что как минимум одно из значений длины в байтах (45) больше, чем объявленное при создании таблицы 32 а максимальное значение длины в байтах для этого поля - 48. Для меня резюме такое - можно импортировать таким образом, но уж очень напряжно. Делать файл со скриптом для пары тысяч таблиц, немерянного количества пакетов, триггеров, типов - проще удавиться сразу :) Или может, PL/SQL Developer умеет делать такое по всей схеме, с учетом зависимостей, не знаю.
-
>Игорь Шевченко © (27.03.10 20:03) [22]
>По одной таблице все прошло нормально
спасибо
для нас - оптимальное решение, т.к. импортируемая схема содержит с десяток таблиц - без пакетов, процедур и т.п.
-
Может я не все проблемы понял, но PL/SQL Developer может: 1) скопировать/поправить структуры (Tools - Compare User Objects...) 2) сгенерить скрипт для создания структуры базы с выбором объектов, кот. необходимо туда включить (Tools - Export User Objects) Далее пишется процедурка для переноса данных: 1) отключаются все констрейнты, триггера 2) пишется курсор для формирования строк str = 'insert into <table> select * from <table@dblink>' 3) выполняется execute immediate str 4) включаются констрейнты, триггера если нужны детали, могу и подробнее.
-
>evvcom © (30.03.10 15:44) [24]
>Далее пишется процедурка для переноса данных:
2) PL/SQL Dev умеет выгружать таблицы в виде insert into
т.е. создавать dblink(если его, конечно, нет) вовсе не обязательно
кстати, если есть поля пользовательского типа (create type), то метод и вовсе не сработает
кроме прочего, к чему эти сложности, если есть файл экспорта, в который можно включить все объекты определенной схемы(а можно и потаблично, коли нужда такая есть)?
-
evvcom © (30.03.10 15:44) [24]
PL/SQL умеет делать объектов базы данных с учетом зависимостей. Я в [14] писал, что пользовался. Беда в том, что на больших объемах этот процесс слегка затруднителен.
> Далее пишется процедурка для переноса данных:
И это он тоже умеет, сам.
На мелких базах это срабатывает на ура, на больших - не очень на ура
-
> 2) PL/SQL Dev умеет выгружать таблицы в виде insert into
> т.е. создавать dblink(если его, конечно, нет) вовсе не обязательно
Да, умеет. Но многомегабайтный sql, состоящий из кучи insert values и работать будет не один час. Гораздо быстрее отработает insert select, а dblink сделать не так уж и затруднительно :)
> Игорь Шевченко © (30.03.10 18:01) [26]
Ну понятие больших баз весьма неопределенно, не очень ура, значит не очень. Ну а если стандартный exp/imp нельзя из-за описаной выше проблемы, то что еще остается?
-
evvcom © (30.03.10 19:23) [27]
> Да, умеет. Но многомегабайтный sql, состоящий из кучи insert
> values и работать будет не один час. Гораздо быстрее отработает
> insert select, а dblink сделать не так уж и затруднительно
> :)
ты пост [14] почитай :)
> Ну понятие больших баз весьма неопределенно, не очень ура,
> значит не очень
объектов много. в сумме десяток тысяч, из них пара тысяч - таблицы.
> Но многомегабайтный sql
Ты хотел сказать - многогигабайтный :)
объем базы, которую хотелось бы перенести таким образом - под терабайт.
Хотелось бы перенести при жизни :)
-
>evvcom © (30.03.10 19:23) [27]
Да, умеет. Но многомегабайтный sql, состоящий из кучи insert values и работать будет не один час. Гораздо быстрее отработает insert select, а dblink сделать не так уж и затруднительно :)
ещё раз: у select from dblink - масса ограничений - пользовательские типы - лишь одно из них
во-вторых, создание dblink может быть недопустимо как по требованиям безопасности, так и чисто физически - из-за отсутствия доступа
в-третьих, что может select from dblink, чего не может exp/imp?
-
> ты пост [14] почитай :)
Почитал. Учитывая это, я написал [24]
> Далее пишется процедурка для переноса данных:
> 1) отключаются все констрейнты, триггера
после этого последовательность не важна
> из них пара тысяч - таблицы
- А 10 бананов это куча?
- 10? 10 - это куча...
Согласен, база большая :)
Поэтому и пишется курсор, на выборке которого строится цикл execute immediate "insert into ... select"
> Ты хотел сказать - многогигабайтный :)
Или так :)
> у select from dblink - масса ограничений - пользовательские
> типы - лишь одно из них
Ну я не претендую на единственность предложенного решения. Если можно сделать через imp/exp, то, конечно, лучше воспользоваться стандартными средствами, но я так понял из [14], что с этим засада:
> Как минимум прочитал, что:
> "You cannot just export data, and import it into a character
> semantics database, because export/import preserves original
> semantics of the exported tables."
-
>evvcom © (31.03.10 13:37) [30]
Ну я не претендую на единственность предложенного решения. Если можно сделать через imp/exp, то, конечно, лучше воспользоваться стандартными средствами, но я так понял из [14], что с этим засада:
дальше прочитайте: для pre-created таблиц при импорте семантика полей из дампа будет проигнорирована
|
Есть новые 
Нет новых [134433 +22][b:0][p:0.003]