Идея следующая (и думаю не новая). Есть мои таблицы на сервере Oracle предприятия. Имея доступ к ним я хочу копировать их (с данными) на виртуальную машину, где установлен свой Oracle (чистый без таблиц).
Зная имя таблицы (например Z_OMTS), нужно скопировать структуру таблицы с базы предприятия в мою базу. Как это реализовать?
Примеры искал, но находил не Oracle таблицы, так что сильно не судите.

можно из одной БД подключиться к другой и перелить

тынц:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/apb.htm

>Игорь Шевченко ©   (25.03.10 23:09) [2]
The COPY command will be obsoleted in future releases of SQL*Plus. No new datatypes will be supported by COPY.

и оттуда же:
In general, the COPY command was designed to be used for copying data between Oracle and non-Oracle databases. You should use SQL commands (CREATE TABLE AS and INSERT) to copy data between Oracle databases.

да и чем плох exp/imp?

Экспорт/импорт ИМХО самое простое.

Кщд   (26.03.10 07:52) [3]


> да и чем плох exp/imp?


Не в службу,а в дружбу - научи, как в базу с кодировкой AL32UTF8 и NLS_LENGTH_SEMANTICS = CHAR импортировать базу в кириллице с длинными значениями строковых полей ?

Импорт считает своим долгом выставить NLS_LENGTH_SEMANTICS = BYTE и длинные значения не помещаются, например "Фигня" в varchar2(5)

>Игорь Шевченко ©   (26.03.10 11:43) [5]
>Импорт считает своим долгом выставить NLS_LENGTH_SEMANTICS = BYTE и длинные значения не помещаются, например "Фигня" в varchar2(5)
про самозамену импортом семантики слышу впервые, честно - можно подробности: конкретная кодировка в БД экспорта, NLS_LENGTH_SEMANTICS в БД экспорта?
когда принесли базу с семантикой byte и потребовали проимпортировать, изменили FAR'ом BYTE на CHAR прямо в файле экспорта, протестировали, залили
это, конечно, не рекомендация к использованию

PS У автора как-будто проблема с разными кодировками и семантиками не стояла?

Кщд   (26.03.10 11:55) [6]


> PS У автора как-будто проблема с разными кодировками и семантиками
> не стояла?


Это у меня проблема


> когда принесли базу с семантикой byte и потребовали проимпортировать,
>  изменили FAR'ом BYTE на CHAR прямо в файле экспорта, протестировали,
>  залили
> это, конечно, не рекомендация к использованию


Беда в том, что файл экспорта гигабайт так на 200, да и CHAR там не в одном месте находится.


> про самозамену импортом семантики слышу впервые, честно
> - можно подробности: конкретная кодировка в БД экспорта,
>  NLS_LENGTH_SEMANTICS в БД экспорта?


Можно подробности:
Исходная база данных в CL8MSWIN1251, надо импортировать в AL32UT8, NLS_LENGTH_SEMANTICS в базе данных экспорта - BYTE, в базе данных импорта CHAR. Так сделано для того, чтобы импортируемые таблицы создавались во время иморта, с учетом семантики CHAR, таблиц много, данных тоже.

Я к чему задал вопрос - может, способ имеется какой.

>Игорь Шевченко ©   (26.03.10 12:33) [7]
>Так сделано для того, чтобы импортируемые таблицы создавались во время иморта, с учетом семантики CHAR, таблиц много, данных тоже.
признаться, не понял: база с WIN1251 создана с NLS_LENGTH_SEMANTICS=BYTE специально? если "да", то причина от меня ускользает - можно на примере?

Кщд   (26.03.10 12:56) [8]

База с WIN1251 создана с NLS_LENGTH_SEMANTICS по умолчанию. А это был BYTE на момент создания. Хотелось бы максимально безболезненно перелить ее в юникодную базу.
Таблиц много, данных много, размер файла полного эскпорта я озвучил.

>Игорь Шевченко ©   (26.03.10 13:02) [9]
Задача разовая или периодическая?

1. на базе с NLS_LENGTH_SEMANTICS=BYTE скриптом для всех таблиц с char/varchar2: alter table modify с увеличением размера поля в 4 раза, после чего экспорт и заливка в базу NLS_LENGTH_SEMANTICS=CHAR.

2. в базе с NLS_LENGTH_SEMANTICS=CHAR создать все таблицы(например, из экспорта метаданных базы с BYTE) и увеличить размеры всех полей char/varchar2 в раза, после чего сделать экспорт из базы BYTE и залить в базу CHAR.

Чем не подошли два этих варианта?

>Кщд   (26.03.10 13:33) [10]
>и увеличить размеры всех полей char/varchar2 в раза
в четыре раза))

> 1. на базе с NLS_LENGTH_SEMANTICS=BYTE скриптом для всех
> таблиц с char/varchar2: alter table modify с увеличением
> размера поля в 4 раза, после чего экспорт и заливка в базу
> NLS_LENGTH_SEMANTICS=CHAR.


Невозможно по определению. База readonly


> 2. в базе с NLS_LENGTH_SEMANTICS=CHAR создать все таблицы(например,
>  из экспорта метаданных базы с BYTE) и увеличить размеры
> всех полей char/varchar2 в раза, после чего сделать экспорт
> из базы BYTE и залить в базу CHAR.


Невозможно. Размер поля VARCHAR2(4000) куда увеличивать ?

>Игорь Шевченко ©   (26.03.10 13:42) [12]
вопрос весьма интересен

http://forums.oracle.com/forums/thread.jspa?messageID=2371685
похоже на Ваш(и на наш) случай

что скажете?

Кщд   (27.03.10 09:01) [13]

Спасибо за ссылку.

Как минимум прочитал, что:
"You cannot just export data, and import it into a character semantics database, because export/import preserves original semantics of the exported tables."

Последняя ссылка в дискуссии, увы, не открывается.

В свое время (небольшую базу) пришлось переносить потаблично, PL/SQL Developer-ом, через INSERT-ы. Объем побольше, тоже потаблично, через INSERT INTO SELECT FROM database link.

Еще одна трудность в том, что в желаемой к переносу базе таблиц порядка двух тысяч, писать нужную последовательность, мягко говоря, небыстро.

В предыдущих вариантах слегка поменьше...

> Игорь Шевченко  (27.03.2010 11:19:14)  [14]

Разве Оракл не поддерживает такой формы как INSERT INTO db1... SELECT FROM db2...

--

Anatoly Podgoretsky ©   (27.03.10 11:38) [15]

Целиком все объекты за один раз ? Поддерживает, называется экспорт/импорт :)

Потаблично тоже поддерживает, таблиц много, да и кроме таблиц еще тонна объектов всяческих. Их тоже хочется убить^^^^^импортировать

> Игорь Шевченко  (27.03.2010 11:44:16)  [16]

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

--

>Игорь Шевченко ©   (27.03.10 11:19) [14]
вот это:

To migrate semantics of an original schema you need to create a script that will contain all CREATE statements needed to recreate this schema (at least CREATE {TYPE | TABLE | MATERIALIZED VIEW | PROCEDURE | FUNCTION | PACKAGE [BODY]}). Then, you can just add the ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR after any CONNECT command in this script. You can than run the script in the target database. How you create the script is irrelevant. You can use any reverse-engineering tool available (e.g. SHOW=Y option of import, DBMS_METADATA package, etc.)

After you pre-create the schema with the new semantics, you can import the data from the original (source) database with IGNORE=Y. The original semantics saved in the export file will be ignored for pre-created objects.

чем не решение?

в понедельник проверю на нашей тестовой, но пока всё выглядит более, чем съедобно)

Кщд   (27.03.10 15:26) [18]

Вот это место имеется в виду:

"The original semantics saved in the export file will be ignored for pre-created objects."

?

Надо попробовать.

Страшно не хочется создавать все объекты вручную, много их там :)