и можно ли это реализовать batником, и чтоб как в expdp сразу для нескольких схем?
просто с sqlplus практичекси не работал...(

вот, если у меня есть такой код



 как мне сделать, чтоб
1) вывести содержимое в какой-нибудь файл? есть что-то типа DBMS_FILE_IO? чего-то не нахожу ничего..
2) указанный код выполнялся через бат-файл?

или это вообще можно сделать как-то гараздо проще?
И еще хочу оточнить в чем конкретно глюк в empdp/impdp? Некорректно формируется сам дамп-файл, или ошибки именно этапа импорта? Т.е. если поставить патч, уже имеющиеся дампы будут импортироваться?

Спасибо!!!

Это сообщение отредактировал(а) setnull - 29.10.2009, 15:34

Вот. Как теперь его через бытник запустить?

Блин!!! Этот скрипт вязывает ту же самую ошибку!!!!

Похоже на баг.
У тебя что вернет:

Это именно баг. Я выше писал об этом. Нужно патч ставить, т.к. dbms_metadata не пашет. Либо ставить патч, либо раскручивать dba_source

Так да. у меня ошибку швыряет именно dbms_metadata.get_ddl. И, собственно, предложенный запрос также.
Причем, только на отдельных триггерах. Сильно не анализировал, но навскидку на тех, которые отличаются большими размерами, но тоже не факт. (Может, это ассоциативное мнение из-за  предложенного


)
И тут вот еще что у меня вчера всплыло  блин. Это тот же баг?

Вот захожу в свои схемы - там все замечательно (с таблицами).
Если же заходить через sys в эти же схемы, то кроме нормальных таблиц там также присутствуют таблицы с именами такого вида 
BIN$/FTzNt4HSwaArTixM/7I7Q==$0 
и со структурами оригинальных таблиц (оригинальные также присутствуют в нормальном виде).
Также и с такими же иероглифическими именами эти таблицы имеют и соответствующие оригиналу триггеры.
Так вот при попытке metadata построить ddl для таких триггеров, говорит, что не может найти такой объект.
Но все равно, если ставишь фильтр
     and (object_name not like 'BIN%')     
в запросе на множество трггеров, и работая только с оригиналами
LPX-00225 вылетает именно на нормальных  объектах.
Также отмечу, что не смотря на отсутствие BIN$таблиц в оригинальных схеммах, поведение же все запросов вокруг all_objects и dbms_metadata не меняется, если вызывать их под этими схемами. Т.е. тоже на может найти BIN$/FTzNt4HSwaArTixM/7I7Q==$0 
и все то же LPX-00225.

Что это вообще за BIN$ы? Уж очень они мне не нравятся?

Ну а возвращаясь к ddl, сейчас буду разбираться с dba_source.

Спасибо!!!.

так, с dba_source, вроде, все понятно.
Единственное уточню:
Там все начинается со строк
"TRIGGER "SCHEME"."TRIGGER_NAME". 
Если же я хочу получиь DDL, то нужно просто добавиь CREATE OR REPLACE? Или есть еще какие-то нюансы?

И, все-таки, как же потом выполнение моего скрипта реализовать через бат-файл?

И все еще переживаю за BIN$-глюки. Насколько это серьезно? Что это? Или это проявление той же дыры?

P.S. Так а в чем собственно этот баг, который патчить нужно, выражается? Какой его характер? Может быть, что сейчас проблема с триггерами, а потом возникнет и с пакетами или еще с чем? Или, обойдя, эту ситуацию с триггерами, в дельнейшем к ней не вернусь?

Спасибо!!!

Это сообщение отредактировал(а) setnull - 30.10.2009, 11:30

setnull,  

BIN$ это оракловая мегамысль (чтоб юзвери чувтствовали себя в базе как в родном вантузе). Это называется Oracle Resicle Bin. В принципе почисти корзину, может быть поможет и не придётся тогда ковырять dba_source.

Странно, но я и сам догадывался, что BIN$ы связаны с корзиной, только искал почему-то более косвенную связь 
Как бы там ни было, но очистка корзины никак не отобразилась на imp'е.

В общем у меня осталось три актуальных вопроса

1) Достаточно ли для формирования DDL отдельного трггеора просто сконкатенировать 'create or replace' с соответствующей последовательностью кода из dba_source
2) Как выполнить опеределенный PL код из командной строки, только невнесением последовательности команд, а типа бат-файл, чтоб прописать все, что необходимо, а оператор только запускал....
3) В полной ли мере решается проблема с этим багом при imp, если осуществить отдельнуюу выгрузку триггеров? Или следом может полететь выгрузка других объектов? В чем именно этот баг заключается?

Спасибо!!!

Добавлено через 4 минуты и 39 секунд
А, и еще, я могу как-то узнать, гуляя по all_objects и т.п., что объект Корзинный по более достоверному признаку, чем object_name like 'BIN$%'?
Приджойнить, может, что-то можно?

1) Вроде да. Но нужно проверить. 
2) Вот здесь уже обсуждали.
3) Насколько я понимаю речь только о триггерах. Там при экспорте проскакивают null символы, на которых всё и падает. (за что купил называется, описалово бага у оракла не очень вразумительное).

Добавлено через 1 минуту и 23 секунды

благодарю!!!

Добавлено через 14 минут и 15 секунд
P.S. а еще в dba_source нет информации касательно состояния триггера.
Как ее узнать?

В смысле валидный/не валидный? dba_objects (ну или all_objects). 

нет. Вот нашел