About DBMS_Metadata.Get_DDL

I am curios to know why Oracle still does not provide a function that would export the table creation script without tablespace name, PCT , double qoutes. It should give the table script, indexes and constraints scripts so that if anyone runs that script on another schema it should directly create the necessary table.

user10566312 wrote:
I am curios to know why Oracle still does not provide a function that would export the table creation script without tablespace name, PCT , double qoutes. It should give the table script, indexes and constraints scripts so that if anyone runs that script on another schema it should directly create the necessary table.
They do provide such a function: GET_DDL.
See the DBMS_METADATA package in the Packages and Types doc.
Table 74-22 SET_TRANSFORM_PARAM: Transform Parameters for the DDL Transform
http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_metada.htm#BGBJBFGE
Works just fine for me:
EXEC DBMS_METADATA.SET_TRANSFORM_PARAM( dbms_metadata.SESSION_TRANSFORM, 'TABLESPACE', FALSE)
SELECT DBMS_METADATA.GET_DDL('TABLE', 'EMP', 'SCOTT') FROM DUAL
CREATE TABLE "SCOTT"."EMP"
   ( "EMPNO" NUMBER(4,0),
"ENAME" VARCHAR2(10),
"JOB" VARCHAR2(9),
"MGR" NUMBER(4,0),
"HIREDATE" DATE,
"SAL" NUMBER(7,2),
"COMM" NUMBER(7,2),
"DEPTNO" NUMBER(2,0),
CONSTRAINT "PK_EMP" PRIMARY KEY ("EMPNO")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS ENABLE,
CONSTRAINT "FK_DEPTNO" FOREIGN KEY ("DEPTNO")
   REFERENCES "SCOTT"."DEPT" ("DEPTNO") ENABLE
   ) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
If you don't want those segment attributes then just disable them too
EXEC DBMS_METADATA.SET_TRANSFORM_PARAM( dbms_metadata.SESSION_TRANSFORM, 'TABLESPACE', FALSE)
SELECT DBMS_METADATA.GET_DDL('TABLE', 'EMP', 'SCOTT') FROM DUAL
EXEC DBMS_METADATA.SET_TRANSFORM_PARAM( dbms_metadata.SESSION_TRANSFORM, 'SEGMENT_ATTRIBUTES', FALSE)
SELECT DBMS_METADATA.GET_DDL('TABLE', 'EMP', 'SCOTT') FROM DUAL
CREATE TABLE "SCOTT"."EMP"
   ( "EMPNO" NUMBER(4,0),
"ENAME" VARCHAR2(10),
"JOB" VARCHAR2(9),
"MGR" NUMBER(4,0),
"HIREDATE" DATE,
"SAL" NUMBER(7,2),
"COMM" NUMBER(7,2),
"DEPTNO" NUMBER(2,0),
CONSTRAINT "PK_EMP" PRIMARY KEY ("EMPNO") ENABLE,
CONSTRAINT "FK_DEPTNO" FOREIGN KEY ("DEPTNO")
   REFERENCES "SCOTT"."DEPT" ("DEPTNO") ENABLE

Similar Messages

DBMS_METADATA.GET_DDL - Required permissions in absense of SELECT_CATALOG_R

Hi,
In our production database SELECT_CATALOG_ROLE cannot be given to any normal user because of Security policy.
I am normal user and I would like to use DBMS_METADATA.GET_DDL to get the DDL's of all the objects for creation of physical data model using tool.
In absense of SELECT_CATALOG_ROLE, are there any alternate roles/grants present which can be given to the normal user so that he/she can use GET_DDL for any object in the database?
Many Thanks in Advance!

Might not be exact match but Note 312883.1 talks about this.
Another way could be by create script/procedure to generate the DDL (like we use to do in 9i) and call it in place of DBMS_METADATA. This would require granting of SELECT privs on few dictionary objects. Check below article.
http://www.dba-oracle.com/oracle_tips_dbms_metadata.htm

DBMS_METADATA.GET_DDL has problem

Hi all,
I ran the following statement to get detail about index
SELECT DBMS_METADATA.GET_DDL('INDEX','u.UX_myIndex)
FROM USER_INDEXES u;
and I got the error message:
RA-06512: at "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: at "SYS.DBMS_METADATA", line 653
ORA-06512: at "SYS.DBMS_METADATA", line 1260
ORA-06512: at line 1
Do you have any idea what is the problem here and
how to fix it.
Thank in advance,
JP

SELECT DBMS_METADATA.GET_DDL('INDEX','u.UX_myIndex)FROM USER_INDEXES u;
in the above qry ending single quote is missing ('u.UX_myIndex)
and object name won't be there like this u._____________
and how many time u want the same data suppose user_indexes have 1000 rows the it will display 1000 times why don't to use dual table
regs,
naresh

Dbms_metadata.get_ddl wonder...

I'm in the middle of testing a export/import of one database -A - to another - B - (the why is a long, complicated and convoluted discussion of business rules). So I want to grab the ddl for A, in order to create the tablespaces for B prior to importing. Okay, I'll just use dbms_metadata.get_ddl in A, do some editing, and run it in B. No problem. Worked fine. But... when I ran the import, I ran into error after error complaining about space. ?? I look at the script some more and see that the tablespace its importing into is only 1 MB. Its currently 1.5 GB in database A. More poking around, and I fine a difference between the script created with dbms_metadata.get_dd and one I've extracted from Enterprise Manager.
dbms_metadata.get_dd:
CREATE TABLESPACE "PTTBL" DATAFILE
'/oradata/DBATST/data1/pttbl01.dbf' SIZE 1114112
LOGGING ONLINE PERMANENT BLOCKSIZE 8192
EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT MANUAL
EM:
CREATE TABLESPACE "PTTBL"
LOGGING
DATAFILE '/oradata/HSCPY/data1/pttbl01.dbf' SIZE 2000M REUSE
AUTOEXTEND
ON NEXT 51200K MAXSIZE 3000M EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT MANUAL
Why the difference? I'm sure I'm missing something obvious, but I've been searching for an answer for this for quite a while.
Thanks,
Hal...

here you go...
13:00:46 hscpy.system> select * from DBA_TABLESPACES where tablespace_name = 'PTTBL';
TABLESPACE_NAME BLOCK_SIZE INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE MIN_EXTLEN STATUS CONTENTS LOGGING FOR EXTENT_MAN ALLOCATIO PLU SEGMEN DEF_TAB_
RETENTION BIG
PTTBL 8192 65536 1 2147483645 65536 ONLINE PERMANENT LOGGING NO LOCAL SYSTEM NO MANUAL DISABLED
NOT APPLY NO
1 row selected.
13:00:48 hscpy.system> select * from DBA_DATA_FILES where tablespace_name = 'PTTBL';
FILE_NAME
FILE_ID TABLESPACE_NAME BYTES BLOCKS STATUS RELATIVE_FNO AUT MAXBYTES MAXBLOCKS INCREMENT_BY USER_BYTES USER_BLOCKS
/oradata/HSCPY/data1/pttbl01.dbf
102 PTTBL 2097152000 256000 AVAILABLE 102 YES 3145728000 384000 6400 2097086464 255992
1 row selected.
Yes, its a PeopleSoft database, and its not 1 MB in our "running" version. ;-) I've also looked more closely at the script I created with my incredibly complex script (select 'select dbms_metadata.get_ddl(''TABLESPACE'',''' || tablespace_name || ''') from dual;' from dba_tablespaces;) and am seeing more than a few with SIZE 1114112.
I am running it in the same version of sqlplus. I've set my Oracle environment (with oraenv) to this HSCPY environment and use sqlplus from the same Oracle Home.
Thanks,
Hal...

Dbms_metadata.get_ddl returns text of table script but not the view

Hi all
I am using a DDL trigger like
CREATE OR REPLACE TRIGGER SYS.log_ddl AFTER DDL
ON DATABASE
declare
n_text varchar2(2000);
begin
if ora_sysevent='CREATE' and ora_dict_obj_type='VIEW' then
select dbms_metadata.get_ddl
(ora_dict_obj_type ,ora_dict_obj_name,ora_dict_obj_owner)
into n_text from dual;
elsif ora_sysevent='CREATE' and ora_dict_obj_type='TABLE' then
select dbms_metadata.get_ddl
(ora_dict_obj_type ,ora_dict_obj_name,ora_dict_obj_owner) into n_text from dual
end if;
end;
on execution
the first condition produces an error if the view does not already exists
ORA-31603: object "TEST" of type VIEW not found in schema "SHAI"
but the second condition of table creation executs successfuly and return the script of the table
what can be the main theory behind this.

I think some of the bug fixes were targeted for 9.2.0.5, but I can't tell you for certain.
One of the things I really don't like about DBMS_METADATA is that it returns an error if a specified object does not exist. For example, I created a sql script that would accept a schema name as the input parameter and would generate all the ddl for the schema. If the schema did not have a particular object, for example a sequence, the call to DBMS_METADATA to generate the sequence ddl would return an error instead of returning nothing. I had error checking in the script, so this caused problems. (Oracle's response is that this is expected behaviour).
This might be what is happening with your call.
Dan

Dbms_metadata.get_ddl output format is not runable.

Hi,
I am using dbms_metadata.get_ddl to extract the objects. But the output returned is not runable.
In output lines are broken so it makes unable to run that code.
Ex. If I run this for all the synonyms like this.
set pagesize 0
set long 90000
set feedback off
set echo off
spool /tmp/FixSyn.out
select
DBMS_METADATA.GET_DDL('SYNONYM',u.object_name,'ADMINSRV_D1')
from
dba_objects u
where
object_type = 'SYNONYM' and owner= 'ADMINSRV_D1';
spool off;
Output from this is coming like this.
CREATE OR REPLACE SYNONYM "ADMINSRV_D1"."ASSTATEAPPORVALTYPE222" FOR "ADMINSRV
_D1"."ASSTATEAPPORVALTYPE";
CREATE OR REPLACE SYNONYM "ABC"."ASSTATEAPPORVALTYPE3" FOR "ADMINSRV_D
1"."ASSTATEAPPORVALTYPE";
This is broken in multiple lines so not possible to run this.
Please provide any solution to fix this output.
Thanks a lot,
Amit.

How about using word_wrapped
set pagesize 0
set long 90000
set lines 131
column txt format a121 word_wrapped
set feedback off
set echo off
spool /tmp/FixSyn.out
select
DBMS_METADATA.GET_DDL('SYNONYM',u.object_name,'ADMINSRV_D1') txt
from
dba_objects u
where
object_type = 'SYNONYM' and owner= 'ADMINSRV_D1';
spool off;
For help on Column and default attributes.
SQL> help column
You can also check asktom replies.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:30802454515375
Regards,
Sabdar Syed.

Setting DBMS_METADATA.GET_DDL Output for Materialized Views

Hi all.
My Oracle version is 10g.
I'm extracting the DDL of all the objects from database using the DBMS_METADATA package. I'm using SET_TRANSFORM_PARAM to configure the output because I need a simple sql code, without information about tablespaces, storage and segment attributes. Everything works fine except when I'm working with mviews object types. I can't remove the information about tablespace, storage or segment attributes for materialized views.
I would like to know if there's a related issue about it. Or there's something missing in my code?
I tried to specify the object type as another parameter on DBMS_METADATA.SET_TRANSFORM_PARAM but don't work too.
The only transform parameter that works fine with Materialized Views is the SQLTERMINATOR.
See how I have done:
declare
vDDL clob;
begin
dbms_metadata.set_transform_param (DBMS_METADATA.SESSION_TRANSFORM, 'STORAGE', FALSE);
dbms_metadata.set_transform_param (DBMS_METADATA.SESSION_TRANSFORM, 'TABLESPACE', FALSE);
dbms_metadata.set_transform_param (DBMS_METADATA.SESSION_TRANSFORM, 'SEGMENT_ATTRIBUTES', FALSE);
dbms_metadata.set_transform_param (DBMS_METADATA.SESSION_TRANSFORM, 'SQLTERMINATOR',TRUE);
select dbms_metadata.get_ddl ('MATERIALIZED_VIEW', 'MV_STO020', 'HIS117_CHECK') into vDDL FROM DUAL;
dbms_output.put_line (vDDL);
end;
and how the output is:
CREATE MATERIALIZED VIEW "HIS117_CHECK"."MV_STO020"
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "TS_HIS117"
BUILD IMMEDIATE
USING INDEX
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY USING DEFAULT LOCAL ROLLBACK SEGMENT
DISABLE QUERY REWRITE
AS SELECT
STO020_MOVEMENT_LOG_ID STO020_MOVEMENT_LOG_ID
, STO020_QUANTITY STO020_QUANTITY
, STO020_DATE STO020_DATE
, STO020_BEFORE_BALANCE STO020_BEFORE_BALANCE
, STO011_PRODUCT_MOVEMENT_ID STO011_PRODUCT_MOVEMENT_ID
, ADM082_PRODUCT_ID ADM082_PRODUCT_ID
, ADM089_PRODUCT_PRESENTATION_ID ADM089_PRODUCT_PRESENTATION_ID
, STO010_MOVEMENT_TYPE_ID STO010_MOVEMENT_TYPE_ID
, STO001_STOCK_ID STO001_STOCK_ID
, STO001_TARGET_STOCK_ID STO001_TARGET_STOCK_ID
, STO003_PRODUCT_LOT_ID STO003_PRODUCT_LOT_ID
, SYS010_USER_ID SYS010_USER_ID
, EIR001_MPI EIR001_MPI
, ADM056_MEDICAL_ATTENTION_ID ADM056_MEDICAL_ATTENTION_ID
, ADM094_USE_UNIT_ID ADM094_USE_UNIT_ID
FROM
STO020_MOVEMENT_LOG;
Thank you in advanced!
Edited by: lucporto on 28/08/2012 07:26

Right. I found this way but I consider this just a quick fix, because I think there should be a better way to do this.
create table t_clob (c_long);
declare
p clob;
begin
delete from t_clob;
execute immediate 'insert into t_clob (select to_lob(query) from dba_mviews where owner = :1 and mview_name = :2)'
USING 'HIS117', 'MV_STO020';
select 'CREATE MATERIALIZED VIEW MV_STO020' || chr(10) ||
'REFRESH ON DEMAND' || chr(10) || 'AS' || CHR(10) || mv.c_long
into p
from t_clob mv;
dbms_output.put_line(p);
end;
Thanks all.

Use of DBMS_METADATA.GET_DDL with respect to triggers

We are very pleased with DMBS_METADATA for punching DDLs in general, We use the following to create executable scripts for recreating any object in our databases.
SELECT DBMS_METADATA.GET_DDL('OBJECT_TYPE', 'OBJECT_NAME', 'SAINADM' ) from dual;
In most types of object, the DDL produced can be executed without errors, providing that the original target object was well founded. However, we have found that in the case of a triggers, the DDL produced does not function for the following reason:
EXAMPLE
-- This set of instructions is produced by a metascript too complicated to show here
SPOOL TRIGGER_NAME.trg
SELECT DBMS_METADATA.GET_DDL('TRIGGER', 'TRIGGER_NAME', 'SCHEMA_NAME' ) txt
FROM DUAL;
SPOOL OFF
END OF EXAMPLE
This will produce the following output, spooled to the file TRIGGER_NAME.trg
OUTPUT
-- we have anonymised our object names
-- the syntax is what I would like you to focus on
CREATE OR REPLACE TRIGGER "SCHEMA_NAME"."TRIGGER_NAME"
BEFORE INSERT on SCHEMA_NAME.TABLE_NAME FOR EACH ROW
BEGIN
select SCHEMA_NAME.SEQUENCE_NAME.nextval
into :new.colname
from dual;
END;
ALTER TRIGGER SCHEMA_NAME"."TRIGGER_NAME" ENABLE
_END OF OUTPUT_
Note what has happened.
1. The trigger DDL has been produced
2. So has a the ALTER TRIGGER ... ENABLE
3. BUT => between the trigger DDL and the alter trigger statement the is no slash (of course, because naturally DBMS_METADATA does not produce such characters). BUT this is problematic, because the combination of the Create trigger statement and the alter trigger statement, without a slash in between means that the spool file is atomically illegal. Because in real life we need a slash between the two staements.
Why is this a problem for us?
- Because we are about to introduce the automation of object changes between our "Development" "Integration" "Quality Assurance" and "Production" databases based on the execution of files produced by DBMS_METADATA.GET_DDL. For every other type of object, the file produced is well founded and executable DDL that will create the object. But in the case of triggers, the existence of the alter trigger statement renders the foregoing create trigger statement unexecutable.
The use of DMBS_METADATA is more or less vanilla. That is to say, there appears to be no scope for instructing DBMS_METADATA to abstain form including the alter trigger statement
SELECT DBMS_METADATA.GET_DDL('TRIGGER', 'TRIGGER_NAME', 'SCHEMA_NAME' ) txt
Here are my questions
1. How can we punch the DDL for triggers without bringing the alter trigger statement
2. Alternatively, how can we automate the insertion of the slash character in between the CREATE TRIGGER and the ALTER TRIGGER in the original metascript that creates the example spool file.
Thanks for your attention. Every response will be welcomed.
Edited by: user10248070 on Mar 2, 2010 3:54 AM

You can use
dbms_metadata.set_transform_param( DBMS_METADATA.SESSION_TRANSFORM, 'SQLTERMINATOR', TRUE );See http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10577/d_metada.htm#BGBJBFGE.
Example:
SQL> set long 1000
SQL> set heading off
SQL> select * from v$version;
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL> exec dbms_metadata.set_transform_param( DBMS_METADATA.SESSION_TRANSFORM, 'SQLTERMINATOR', TRUE );
PL/SQL procedure successfully completed.
SQL> SELECT DBMS_METADATA.GET_DDL('TRIGGER', 'UPDATE_JOB_HISTORY', 'HR' ) txt
2 FROM DUAL;
CREATE OR REPLACE TRIGGER "HR"."UPDATE_JOB_HISTORY"
AFTER UPDATE OF job_id, department_id ON employees
FOR EACH ROW
BEGIN
add_job_history(:old.employee_id, :old.hire_date, sysdate,
:old.job_id, :old.department_id);
END;
ALTER TRIGGER "HR"."UPDATE_JOB_HISTORY" ENABLE;Edited by: P. Forstmann on 2 mars 2010 13:48

Performance issue when trying to execute DBMS_METADATA.GET_DDL of a table

Hello.
I have a database with lots of partitioned tables and indexes and when I try to get the DDL of a partitioned table the query runs for hours and does not end.
I tried do gather data dictionary statistics but it had no impact on performance.
Can anybody help me find what's causing this performance problem?
Information about the enviorment:
Oracle version:
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
DDL query:
select dbms_metadata.get_ddl('TABLE', 'TABLE1') from dual;
On the "Top Activity" of the Database Control console, this is the query that's running:
SELECT /*+all_rows*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2('TABLE_T', '7')), KU$.OBJ_NUM
FROM SYS.KU$_PHTABLE_VIEW KU$
WHERE NOT (BITAND (KU$.PROPERTY,8192)=8192) AND NOT BITAND(KU$.SCHEMA_OBJ.FLAGS,128)!=0 AND KU$.SCHEMA_OBJ.NAME=:NAME1 AND KU$.SCHEMA_OBJ.OWNER_NAME=:SCHEMA2;
Edited by: Krulikowski on Jan 11, 2013 10:44 AM

|*563 | INDEX RANGE SCAN | I_OBJ1 | 1 | | | 3 (0)| 00:00:01 |
| 564 | TABLE ACCESS CLUSTER | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*565 | INDEX UNIQUE SCAN | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 566 | VIEW | | 1 | 86 | | 4 (25)| 00:00:01 |
| 567 | SORT ORDER BY | | 1 | 64 | | 4 (25)| 00:00:01 |
| 568 | NESTED LOOPS | | 1 | 64 | | 3 (0)| 00:00:01 |
| 569 | ID TABLE ACCESS BY INDEX ROW | SUBPARTCOL$ | 1 | 15 | | 2 (0)| 00:00:01 |
|*570 | INDEX RANGE SCAN | I_SUBPARTCOL$ | 1 | | | 1 (0)| 00:00:01 |
|*571 | TABLE ACCESS CLUSTER | COL$ | 1 | 49 | | 1 (0)| 00:00:01 |
|*572 | INDEX UNIQUE SCAN | I_OBJ# | 1 | | | 0 (0)| 00:00:01 |
| 573 | TABLE ACCESS CLUSTER | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*574 | INDEX UNIQUE SCAN | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 575 | TABLE ACCESS CLUSTER | SEG$ | 1 | 70 | | 3 (0)| 00:00:01 |
|*576 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | | 2 (0)| 00:00:01 |
| 577 | ROWID TABLE ACCESS BY INDEX | DEFERRED_STG$ | 1 | 28 | | 2 (0)| 00:00:01 |
|*578 | INDEX UNIQUE SCAN | I_DEFERRED_STG1 | 1 | | | 1 (0)| 00:00:01 |
| 579 | TABLE ACCESS CLUSTER | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*580 | INDEX UNIQUE SCAN | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 581 | NESTED LOOPS | | 1 | 120 | | 5 (0)| 00:00:01 |
| 582 | X ROWID TABLE ACCESS BY INDE | OBJ$ | 1 | 101 | | 4 (0)| 00:00:01 |
|*583 | INDEX RANGE SCAN | I_OBJ1 | 1 | | | 3 (0)| 00:00:01 |
| 584 | TABLE ACCESS CLUSTER | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*585 | INDEX UNIQUE SCAN | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 586 | R TABLE ACCESS CLUSTE | SEG$ | 1 | 70 | | 3 (0)| 00:00:01 |
|*587 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | | 2 (0)| 00:00:01 |
| 588 | DEX ROWID TABLE ACCESS BY IN | DEFERRED_STG$ | 1 | 28 | | 2 (0)| 00:00:01 |
|*589 | INDEX UNIQUE SCAN | I_DEFERRED_STG1 | 1 | | | 1 (0)| 00:00:01 |
| 590 | TER TABLE ACCESS CLUS | TS$ | 1 | 18 | | 1 (0)| 00:00:01 |
|*591 | N INDEX UNIQUE SCA | I_TS# | 1 | | | 0 (0)| 00:00:01 |
| 592 | STER TABLE ACCESS CLU | TS$ | 1 | 8 | | 1 (0)| 00:00:01 |
|*593 | AN INDEX UNIQUE SC | I_TS# | 1 | | | 0 (0)| 00:00:01 |
| 594 | USTER TABLE ACCESS CL | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*595 | CAN INDEX UNIQUE S | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 596 | LUSTER TABLE ACCESS C | SEG$ | 1 | 70 | | 3 (0)| 00:00:01 |
|*597 | SCAN INDEX UNIQUE | I_FILE#_BLOCK# | 1 | | | 2 (0)| 00:00:01 |
| 598 | BY INDEX ROWID TABLE ACCESS | DEFERRED_STG$ | 1 | 28 | | 2 (0)| 00:00:01 |
|*599 | SCAN INDEX UNIQUE | I_DEFERRED_STG1 | 1 | | | 1 (0)| 00:00:01 |
| 600 | NESTED LOOPS | | 1 | 447 | | 900 (1)| 00:00:04 |
|*601 | HASH JOIN | | 1 | 425 | | 899 (1)| 00:00:04 |
| 602 | NESTED LOOPS | | 1 | 120 | | 5 (0)| 00:00:01 |
| 603 | BY INDEX ROWID TABLE ACCESS | OBJ$ | 1 | 101 | | 4 (0)| 00:00:01 |
|*604 | SCAN INDEX RANGE | I_OBJ1 | 1 | | | 3 (0)| 00:00:01 |
| 605 | CLUSTER TABLE ACCESS | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*606 | E SCAN INDEX UNIQU | I_USER# | 1 | | | 0 (0)| 00:00:01 |
|*607 | VIEW | INDPARTV$ | 33387 | 9944K| | 893 (1)| 00:00:04 |
| 608 | R WINDOW BUFFE | | 33387 | 4336K| | 893 (1)| 00:00:04 |
| 609 | S BY INDEX ROWID TABLE ACCES | INDPART$ | 33387 | 4336K| | 893 (1)| 00:00:04 |
| 610 | SCAN INDEX FULL | I_INDPART_BOPART$ | 33387 | | | 103 (1)| 00:00:01 |
| 611 | LUSTER TABLE ACCESS C | TS$ | 1 | 22 | | 1 (0)| 00:00:01 |
|*612 | SCAN INDEX UNIQUE | I_TS# | 1 | | | 0 (0)| 00:00:01 |
| 613 | VIEW | | 19858 | 40M| | 1471 (1)| 00:00:07 |
| 614 | SORT ORDER BY | | 19858 | 3956K| 4688K| 1471 (1)| 00:00:07 |
|*615 | HASH JOIN | | 19858 | 3956K| | 698 (1)| 00:00:03 |
| 616 | TABLE ACCESS FULL | LOB$ | 1547 | 24752 | | 461 (1)| 00:00:02 |
|*617 | VIEW | LOBFRAGV$ | 19858 | 3645K| | 236 (1)| 00:00:01 |
| 618 | WINDOW BUFFER | | 19858 | 1066K| | 236 (1)| 00:00:01 |
| 619 | INDEX ROWID TABLE ACCESS BY | LOBFRAG$ | 19858 | 1066K| | 236 (1)| 00:00:01 |
| 620 | INDEX FULL SCAN | I_LOBFRAG_PARENTOBJFRAG$ | 19858 | | | 61 (0)| 00:00:01 |
| 621 | ER TABLE ACCESS CLUST | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*622 | INDEX UNIQUE SCAN | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 623 | NESTED LOOPS | | 1 | 120 | | 5 (0)| 00:00:01 |
| 624 | NDEX ROWID TABLE ACCESS BY I | OBJ$ | 1 | 101 | | 4 (0)| 00:00:01 |
|*625 | INDEX RANGE SCAN | I_OBJ1 | 1 | | | 3 (0)| 00:00:01 |
| 626 | TER TABLE ACCESS CLUS | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*627 | N INDEX UNIQUE SCA | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 628 | NESTED LOOPS | | 1 | 53 | | 5 (0)| 00:00:01 |
| 629 | INDEX ROWID TABLE ACCESS BY | OBJ$ | 1 | 34 | | 4 (0)| 00:00:01 |
|*630 | AN INDEX RANGE SC | I_OBJ1 | 1 | | | 3 (0)| 00:00:01 |
| 631 | USTER TABLE ACCESS CL | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*632 | CAN INDEX UNIQUE S | I_USER# | 1 | | | 0 (0)| 00:00:01 |
|*633 | STER TABLE ACCESS CLU | COL$ | 1 | 49 | | 2 (0)| 00:00:01 |
|*634 | AN INDEX UNIQUE SC | I_OBJ# | 1 | | | 1 (0)| 00:00:01 |
| 635 | USTER TABLE ACCESS CL | TAB$ | 1 | 13 | | 2 (0)| 00:00:01 |
|*636 | CAN INDEX UNIQUE S | I_OBJ# | 1 | | | 1 (0)| 00:00:01 |
| 637 | Y INDEX ROWID TABLE ACCESS B | COLTYPE$ | 1 | 13 | | 2 (0)| 00:00:01 |
|*638 | SCAN INDEX UNIQUE | I_COLTYPE2 | 1 | | | 1 (0)| 00:00:01 |
| 639 | CLUSTER TABLE ACCESS | SEG$ | 1 | 70 | | 3 (0)| 00:00:01 |
|*640 | SCAN INDEX UNIQUE | I_FILE#_BLOCK# | 1 | | | 2 (0)| 00:00:01 |
| 641 | BY INDEX ROWID TABLE ACCESS | DEFERRED_STG$ | 1 | 28 | | 2 (0)| 00:00:01 |
|*642 | E SCAN INDEX UNIQU | I_DEFERRED_STG1 | 1 | | | 1 (0)| 00:00:01 |
| 643 | S CLUSTER TABLE ACCES | TS$ | 1 | 18 | | 1 (0)| 00:00:01 |
|*644 | UE SCAN INDEX UNIQ | I_TS# | 1 | | | 0 (0)| 00:00:01 |
| 645 | SS CLUSTER TABLE ACCE | TS$ | 1 | 8 | | 1 (0)| 00:00:01 |
|*646 | QUE SCAN INDEX UNI | I_TS# | 1 | | | 0 (0)| 00:00:01 |
| 647 | NESTED LOOPS | | 1 | 55 | | 3 (0)| 00:00:01 |
| 648 | BY INDEX ROWID TABLE ACCESS | TABPART$ | 1 | 42 | | 2 (0)| 00:00:01 |
|*649 | E SCAN INDEX UNIQU | I_TABPART_OBJ$ | 1 | | | 1 (0)| 00:00:01 |
|*650 | CLUSTER TABLE ACCESS | TAB$ | 1 | 13 | | 1 (0)| 00:00:01 |
|*651 | E SCAN INDEX UNIQU | I_OBJ# | 1 | | | 0 (0)| 00:00:01 |
|*652 | FILTER | | | | | | |
| 653 | MERGE JOIN | | 53239 | 2287K| | 1334 (2)| 00:00:06 |
|*654 | VIEW | TABPARTV$ | 96857 | 3026K| | 872 (2)| 00:00:04 |
| 655 | WINDOW SORT | | 96857 | 1513K| 2672K| 872 (2)| 00:00:04 |
| 656 | ULL TABLE ACCESS F | TABPART$ | 96857 | 1513K| | 414 (2)| 00:00:02 |
|*657 | SORT JOIN | | 273 | 3276 | | 462 (1)| 00:00:02 |
| 658 | LL TABLE ACCESS FU | NTAB$ | 273 | 3276 | | 461 (1)| 00:00:02 |
|*659 | FILTER | | | | | | |
|*660 | FILTERING (UNIQUE) CONNECT BY WITH | | | | | | |
| 661 | INDEX ROWID TABLE ACCESS BY | NTAB$ | 2 | 16 | | 2 (0)| 00:00:01 |
|*662 | AN INDEX RANGE SC | I_NTAB1 | 2 | | | 1 (0)| 00:00:01 |
| 663 | NESTED LOOPS | | 4 | 84 | | 4 (0)| 00:00:01 |
| 664 | P CONNECT BY PUM | | | | | | |
| 665 | LUSTER TABLE ACCESS C | NTAB$ | 2 | 16 | | 1 (0)| 00:00:01 |
|*666 | SCAN INDEX UNIQUE | I_OBJ# | 1 | | | 0 (0)| 00:00:01 |
|*667 | HASH JOIN | | 1 | 32 | | 5 (20)| 00:00:01 |
|*668 | TER TABLE ACCESS CLUS | TAB$ | 1 | 13 | | 2 (0)| 00:00:01 |
|*669 | N INDEX UNIQUE SCA | I_OBJ# | 1 | | | 1 (0)| 00:00:01 |
|*670 | VIEW | TABPARTV$ | 214 | 4066 | | 2 (0)| 00:00:01 |
| 671 | WINDOW BUFFER | | 214 | 2140 | | 2 (0)| 00:00:01 |
|*672 | N INDEX RANGE SCA | I_TABPART_BOPART$ | 214 | 2140 | | 2 (0)| 00:00:01 |
| 673 | VIEW | | 214 | 1304K| | 1555 (2)| 00:00:07 |
| 674 | SORT ORDER BY | | 214 | 72546 | | 1555 (2)| 00:00:07 |
|*675 | HASH JOIN | | 214 | 72546 | | 1554 (2)| 00:00:07 |
| 676 | TABLE ACCESS FULL | USER$ | 184 | 3496 | | 4 (0)| 00:00:01 |
| 677 | NESTED LOOPS | | | | | | |
| 678 | NESTED LOOPS | | 214 | 68480 | | 1549 (2)| 00:00:07 |
|*679 | HASH JOIN | | 214 | 46866 | | 907 (2)| 00:00:04 |
|*680 | HASH JOIN | | 214 | 42800 | | 34 (3)| 00:00:01 |
| 681 | TABLE ACCESS FULL | TS$ | 138 | 3036 | | 26 (0)| 00:00:01 |
| 682 | NDEX ROWID TABLE ACCESS BY I | TABPART$ | 214 | 38092 | | 7 (0)| 00:00:01 |
|*683 | INDEX RANGE SCAN | I_TABPART_BOPART$ | 214 | | | 2 (0)| 00:00:01 |
| 684 | VIEW | TABPARTV$ | 96857 | 1797K| | 872 (2)| 00:00:04 |
| 685 | WINDOW SORT | | 96857 | 1513K| 2672K| 872 (2)| 00:00:04 |
| 686 | L TABLE ACCESS FUL | TABPART$ | 96857 | 1513K| | 414 (2)| 00:00:02 |
|*687 | INDEX RANGE SCAN | I_OBJ1 | 1 | | | 2 (0)| 00:00:01 |
| 688 | X ROWID TABLE ACCESS BY INDE | OBJ$ | 1 | 101 | | 3 (0)| 00:00:01 |
| 689 | TABLE ACCESS CLUSTER | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*690 | INDEX UNIQUE SCAN | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 691 | TABLE ACCESS CLUSTER | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*692 | INDEX UNIQUE SCAN | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 693 | R TABLE ACCESS CLUSTE | SEG$ | 1 | 70 | | 3 (0)| 00:00:01 |
|*694 | INDEX UNIQUE SCAN | I_FILE#_BLOCK# | 1 | | | 2 (0)| 00:00:01 |
| 695 | DEX ROWID TABLE ACCESS BY IN | DEFERRED_STG$ | 1 | 28 | | 2 (0)| 00:00:01 |
|*696 | INDEX UNIQUE SCAN | I_DEFERRED_STG1 | 1 | | | 1 (0)| 00:00:01 |
| 697 | TER TABLE ACCESS CLUS | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*698 | N INDEX UNIQUE SCA | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 699 | NESTED LOOPS | | 1 | 120 | | 5 (0)| 00:00:01 |
| 700 | INDEX ROWID TABLE ACCESS BY | OBJ$ | 1 | 101 | | 4 (0)| 00:00:01 |
|*701 | N INDEX RANGE SCA | I_OBJ1 | 1 | | | 3 (0)| 00:00:01 |
| 702 | STER TABLE ACCESS CLU | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*703 | AN INDEX UNIQUE SC | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 704 | USTER TABLE ACCESS CL | SEG$ | 1 | 70 | | 3 (0)| 00:00:01 |
|*705 | CAN INDEX UNIQUE S | I_FILE#_BLOCK# | 1 | | | 2 (0)| 00:00:01 |
| 706 | Y INDEX ROWID TABLE ACCESS B | DEFERRED_STG$ | 1 | 28 | | 2 (0)| 00:00:01 |
|*707 | SCAN INDEX UNIQUE | I_DEFERRED_STG1 | 1 | | | 1 (0)| 00:00:01 |
| 708 | CLUSTER TABLE ACCESS | TS$ | 1 | 18 | | 1 (0)| 00:00:01 |
|*709 | SCAN INDEX UNIQUE | I_TS# | 1 | | | 0 (0)| 00:00:01 |
| 710 | CLUSTER TABLE ACCESS | TS$ | 1 | 8 | | 1 (0)| 00:00:01 |
|*711 | E SCAN INDEX UNIQU | I_TS# | 1 | | | 0 (0)| 00:00:01 |
| 712 | S CLUSTER TABLE ACCES | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*713 | UE SCAN INDEX UNIQ | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 714 | SS CLUSTER TABLE ACCE | SEG$ | 1 | 70 | | 3 (0)| 00:00:01 |
|*715 | QUE SCAN INDEX UNI | I_FILE#_BLOCK# | 1 | | | 2 (0)| 00:00:01 |
| 716 | ESS BY INDEX ROWID TABLE ACC | DEFERRED_STG$ | 1 | 28 | | 2 (0)| 00:00:01 |
|*717 | IQUE SCAN INDEX UN | I_DEFERRED_STG1 | 1 | | | 1 (0)| 00:00:01 |
| 718 | S NESTED LOOP | | 1 | 421 | | 2864 (1)| 00:00:13 |
| 719 | PS NESTED LOO | | 1 | 402 | | 2863 (1)| 00:00:13 |
| 720 | N MERGE JOI | | 1 | 380 | | 2862 (1)| 00:00:13 |
|*721 | VIEW | INDSUBPARTV$ | 203K| 54M| | 2857 (1)| 00:00:13 |
| 722 | BUFFER WINDOW | | 203K| 13M| | 2857 (1)| 00:00:13 |
| 723 | ACCESS BY INDEX ROWID TABLE | INDSUBPART$ | 203K| 13M| | 2857 (1)| 00:00:13 |
| 724 | FULL SCAN INDEX | I_INDSUBPART_POBJSUBPART$ | 203K| | | 517 (1)| 00:00:03 |
|*725 | N SORT JOI | | 1 | 101 | | 5 (20)| 00:00:01 |
| 726 | CCESS BY INDEX ROWID TABLE A | OBJ$ | 1 | 101 | | 4 (0)| 00:00:01 |
|*727 | RANGE SCAN INDEX | I_OBJ1 | 1 | | | 3 (0)| 00:00:01 |
| 728 | ESS CLUSTER TABLE ACC | TS$ | 1 | 22 | | 1 (0)| 00:00:01 |
|*729 | IQUE SCAN INDEX UN | I_TS# | 1 | | | 0 (0)| 00:00:01 |
| 730 | SS CLUSTER TABLE ACCE | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*731 | QUE SCAN INDEX UNI | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 732 | VIEW | | 3220 | 6653K| | 252 (2)| 00:00:02 |
| 733 | SORT ORDER BY | | 3220 | 679K| | 252 (2)| 00:00:02 |
|*734 | HASH JOIN | | 3220 | 679K| | 251 (1)| 00:00:02 |
| 735 | NESTED LOOPS | | | | | | |
| 736 | NESTED LOOPS | | 12 | 336 | | 14 (0)| 00:00:01 |
| 737 | FULL TABLE ACCESS | LOBCOMPPART$ | 12 | 144 | | 2 (0)| 00:00:01 |
|*738 | SCAN INDEX UNIQUE | I_LOB2 | 1 | | | 0 (0)| 00:00:01 |
| 739 | BY INDEX ROWID TABLE ACCESS | LOB$ | 1 | 16 | | 1 (0)| 00:00:01 |
|*740 | VIEW | LOBFRAGV$ | 19858 | 3645K| | 236 (1)| 00:00:01 |
| 741 | WINDOW BUFFER | | 19858 | 1066K| | 236 (1)| 00:00:01 |
| 742 | BY INDEX ROWID TABLE ACCESS | LOBFRAG$ | 19858 | 1066K| | 236 (1)| 00:00:01 |
| 743 | SCAN INDEX FULL | I_LOBFRAG_PARENTOBJFRAG$ | 19858 | | | 61 (0)| 00:00:01 |
| 744 | Y INDEX ROWID TABLE ACCESS B | TABSUBPART$ | 1 | 111 | | 3 (0)| 00:00:01 |
|*745 | SCAN INDEX UNIQUE | I_TABSUBPART$_OBJ$ | 1 | | | 2 (0)| 00:00:01 |
| 746 | VIEW | | 418K| 2477M| | 38130 (1)| 00:02:41 |
| 747 | SORT ORDER BY | | 418K| 177M| 192M| 38130 (1)| 00:02:41 |
|*748 | HASH JOIN | | 418K| 177M| | 3590 (3)| 00:00:16 |
| 749 | TABLE ACCESS FULL | USER$ | 184 | 3496 | | 4 (0)| 00:00:01 |
|*750 | HASH JOIN | | 418K| 170M| | 3582 (2)| 00:00:16 |
| 751 | L TABLE ACCESS FUL | TS$ | 138 | 3036 | | 26 (0)| 00:00:01 |
|*752 | HASH JOIN | | 418K| 161M| | 3552 (2)| 00:00:15 |
| 753 | VIEW | TABSUBPARTV$ | 30 | 9120 | | 4 (0)| 00:00:01 |
| 754 | WINDOW BUFFER | | 30 | 3750 | | 4 (0)| 00:00:01 |
| 755 | BY INDEX ROWID TABLE ACCESS | TABSUBPART$ | 30 | 3750 | | 4 (0)| 00:00:01 |
|*756 | SCAN INDEX RANGE | I_TABSUBPART_POBJSUBPART$ | 30 | | | 3 (0)| 00:00:01 |
| 757 | LL TABLE ACCESS FU | OBJ$ | 825K| 79M| | 3539 (2)| 00:00:15 |
| 758 | NDEX ROWID TABLE ACCESS BY I | LOB$ | 1 | 10 | | 2 (0)| 00:00:01 |
|*759 | N INDEX UNIQUE SCA | I_LOB2 | 1 | | | 1 (0)| 00:00:01 |
| 760 | STER TABLE ACCESS CLU | USER$ | 1 | 19 | | 1 (0)| 00:00:01 |
|*761 | AN INDEX UNIQUE SC | I_USER# | 1 | | | 0 (0)| 00:00:01 |
| 762 | NESTED LOOPS | | 1 | 120 | | 5 (0)| 00:00:01 |
| 763 | INDEX ROWID TABLE ACCESS BY | OBJ$ | 1 | 101 | | 4 (0)| 00:00:01 |
|*764 | AN INDEX RANGE SC | I_OBJ1 | 1 | | | 3 (0)| 00:00:01 |

How to get script of all tables through DBMS_METADATA.GET_DDL

Hi friends
Is there any way thr which i can generate script off all tables at one time...
select dbms_metadata.get_ddl('TABLE','CONSUMER','UPCLMAIN')FROM DUAL;
I ve 78 tables and its too tedious to to one by one and i am working in 10 g...
thanks
sonal....

How about
select dbms_metadata.get_ddl('TABLE',table_name,owner)FROM dba_tables where owner='yourschema';
Regards,
PP

Error while using DBMS_METADATA.GET_DDL package.

Hi all,
I want script of DDL of all tables in Database not in particular schema,
As I am using below query
SELECT DBMS_METADATA.GET_DDL('TABLE',u.table_name)
FROM ALL_TABLES u
WHERE u.nested='NO'
AND (u.iot_type is null or u.iot_type='IOT')
but it gives error as below.
ORA-31603: object "ICOL$" of type TABLE not found in schema "SCOTT"
It should give DDL of all tables, also I am not having DBA Privs.
Please help me.
Thanks & Regards
Rajiv.

It could be helpful if you have a look into [url http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_metada.htm#i1016867]documentation.
Security Model
The object views of the Oracle metadata model implement security as follows:
Nonprivileged users can see the metadata of only their own objects.
SYS and users with SELECT_CATALOG_ROLE can see all objects.
Nonprivileged users can also retrieve public synonyms, system privileges granted to them, and object privileges granted to them or by them to others. This also includes privileges granted to PUBLIC.
If callers request objects they are not privileged to retrieve, no exception is raised; the object is simply not retrieved.
If nonprivileged users are granted some form of access to an object in someone else's schema, they will be able to retrieve the grant specification through the Metadata API, but not the object's actual metadata.
In stored procedures, functions, and definers-rights packages, roles (such as SELECT_CATALOG_ROLE) are disabled. Therefore, such a PL/SQL program can only fetch metadata for objects in its own schema. If you want to write a PL/SQL program that fetches metadata for objects in a different schema (based on the invoker's possession of SELECT_CATALOG_ROLE), you must make the program invokers-rights.
Best regards
Maxim

Stange error when using dbms_metadata.get_ddl in PL/SQL procedure

Basic info:
Oracle 10.2.0.4.0 on linux.
I'm trying to extract ddl of indexes that I drop and recreate frequently during monthly loads and store it in a table.
This statement works on the command line:
insert into saved_indexes
select index_name,dbms_metadata.get_ddl('INDEX',index_name,owner_name)
from sys.all_indexes
where owner = owner_name
and table_name = table_name;
commit;
The table 'saved_indexes' is a two column table with a varchar2(40) and a CLOB.
When I use the following procedure, I get 'ORA-04044 procedure, function, package, or type is not allowed here -4044' every time.
PROCEDURE SAVE_INDEXES (v_table IN VARCHAR2, v_owner IN VARCHAR2) IS
v_errorcode number(8);
v_errortext varchar2(1000);
v_start_time date;
BEGIN
insert into saved_indexes
select index_name,dbms_metadata.get_ddl('INDEX',index_name,v_owner)
from sys.all_indexes
where owner = v_owner
and table_name = v_table;
commit;
EXCEPTION
WHEN others THEN
v_errorcode := sqlcode;
v_errortext := substr(sqlerrm, 1, 1000);
dbms_output.put_line(v_errortext || ' ' || v_errorcode);
END;
Alternatively I have tried it this way:
PROCEDURE SAVE_INDEXES (v_table IN VARCHAR2, v_owner IN VARCHAR2 ) IS
v_errorcode number(8);
v_errortext varchar2(1000);
v_index_ddl CLOB;
BEGIN
for x in (select index_name
from sys.all_indexes
where owner = v_owner
and table_name = v_table)
loop
select dbms_metadata.get_ddl('INDEX',x.index_name,v_owner) into v_index_ddl from dual;
insert into saved_indexes
values(v_table,v_index_ddl);
end loop;
commit;
EXCEPTION
WHEN others THEN
v_errorcode := sqlcode;
v_errortext := substr(sqlerrm, 1, 1000);
dbms_output.put_line(v_errortext || ' ' || v_errorcode);
END;
Always with the same result. I have poured over the documentation on this and have not found anything. All objects are in the same schema, so there is not an issues with invokers rights, or privileges.
Any suggestions would be helpful...

qwe11126 wrote:
When I use the following procedure, I get 'ORA-04044 procedure, function, package, or type is not allowed here -4044' every time.There is nothing wrong with SP. Post a snippet of SQL*Plus code showing how you call SP along with errors.
SY.

Calling DBMS_METADATA.GET_DDL on scheduler jobs owned by SYS

Hi!
While I can generally retrieve the DDL for scheduler jobs using the PROCOBJ type, this doesn't seem to work for scheduler jobs owned by SYS.
Does anybody happen to have a workaround for this?
SELECT user FROM dual
USER
SYS
1 row selected
select * from v$version
BANNER
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
PL/SQL Release 10.2.0.4.0 - Production
CORE     10.2.0.4.0     Production
TNS for 64-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
5 rows selected
SELECT DBMS_METADATA.GET_DDL('PROCOBJ' ,'MGMT_CONFIG_JOB', 'ORACLE_OCM') DDL FROM dual
DDL
BEGIN dbms_scheduler.create_job( ...
1 row selected
SELECT DBMS_METADATA.GET_DDL('PROCOBJ' ,'AUTO_SPACE_ADVISOR_JOB', 'SYS') DDL FROM dual
ORA-31603: object "AUTO_SPACE_ADVISOR_JOB" of type PROCOBJ not found in schema "SYS"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: at "SYS.DBMS_METADATA", line 2806
ORA-06512: at "SYS.DBMS_METADATA", line 4333
ORA-06512: at line 1Cheers,
Marcus

I guess I need SELECT_CATALOG_ROLE role
http://www.orafaq.com/node/807
SYS and users with SELECT_CATALOG_ROLE can see all objects.

[RESOLVED] dbms_metadata.get_ddl() issues

Hi all,
I'm having a bit of an issue using the dbms_metadata package. I've never used it so possibly I'm unaware of something basic.
I'm getting diferent results in my production and dev servers, both of which have this configuration:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
I am trying to replicate the DDL for one particular schema and so tried the following:
SQL> select dbms_metadata.get_ddl('TABLE',u.table_name)
2 from user_tables u
3 where rownum = 1;
ERROR:
ORA-06502: PL/SQL: numeric or value error
LPX-00210: expected '<' instead of 'n'
ORA-06512: at "SYS.UTL_XML", line 0
ORA-06512: at "SYS.DBMS_METADATA_INT", line 3698
ORA-06512: at "SYS.DBMS_METADATA_INT", line 4553
ORA-06512: at "SYS.DBMS_METADATA", line 458
ORA-06512: at "SYS.DBMS_METADATA", line 615
ORA-06512: at "SYS.DBMS_METADATA", line 1221
ORA-06512: at line 1I tried again with hard-coding a table name and got these very scary results:
SQL> select dbms_metadata.get_ddl('TABLE','CAMPAIGN_LOOKUP','XMLUSER') FROM DUAL;
ERROR:
ORA-06502: PL/SQL: numeric or value error
ORA-31605: the following was returned from LpxXSLResetAllVars in routine
kuxslResetParams:
LPX-1: NULL pointer
ORA-06512: at "SYS.UTL_XML", line 0
ORA-06512: at "SYS.DBMS_METADATA_INT", line 3722
ORA-06512: at "SYS.DBMS_METADATA_INT", line 4553
ORA-06512: at "SYS.DBMS_METADATA", line 458
ORA-06512: at "SYS.DBMS_METADATA", line 615
ORA-06512: at "SYS.DBMS_METADATA", line 1221
ORA-06512: at line 1in the above, I am logging in as the XMLUSER user and so owns the table campaign_lookup.
Next I tried getting the DDL for another schema that while still logged in as xmluser.
I'm certain that I have access read/write from the tclient table but got these results:
possibly the dbms_metadata package requires you to be loged in as the schema owner though
the oracle documentation link gives me a 404 error at the moment so I can't check.
SQL> select dbms_metadata.get_ddl('TABLE','TCLIENT','TRAVEL') from dual;
ERROR:
ORA-31603: object "TCLIENT" of type TABLE not found in schema "TRAVEL"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: at "SYS.DBMS_METADATA", line 628
ORA-06512: at "SYS.DBMS_METADATA", line 1221
ORA-06512: at line 1So now I log into production:
SQL> select dbms_metadata.get_ddl('TABLE',u.table_name)
2      from user_tables u
3      where rownum = 1;
DBMS_METADATA.GET_DDL('TABLE',
CREATE TABLE "XMLUSER"."CAMPAIGN_LOOKUP"
   (    "SCHEME_ID" VARCHAR2(30),
        "S
etc...but still can't extract DDL for another schema.
my main issue is, I can't log into production (or our implementation environment) as the schema
I want to extract due to big nasty DBAs locking it all down. however I can in dev, but get the above errors.
thoughts anyone?

Hi,
For your table not existing error it could be
1) Table not existing
or
2) Nonprivileged users can see the metadata of only their own objects.
SYS and users with SELECT_CATALOG_ROLE can see all objects
For other problem, there is a bug reported for your version, can search in metalink for workaround
Regards

Execute immediate on DBMS_METADATA.GET_DDL with error of ORA-01031: insufficient privileges

I want to mirror a schema to a existing schema by creating DDL and recreate on the other schema with same name.
I wrote the code below:
create or replace
PROCEDURE                                    SCHEMA_A."MAI__DWHMIRROR"
AS
v_sqlstatement CLOB:='bos';
str varchar2(3999);
BEGIN
select
    replace(
      replace(replace(
      replace(DBMS_METADATA.GET_DDL('TABLE','XXXX','SCHEMA_A'),'(CLOB)',''),';','')
    ,'SCHEMA_A'
    ,'SCHEMA_B'
into v_sqlstatement
from dual;
select CAST(v_sqlstatement AS VARCHAR2(3999)) into str from dual;
execute immediate ''||str;
END;
And Executing this block with below code:
set serveroutput on
begin
SCHEMA_A.MAI__DWHMIRROR;
end;
But still getting the following error code:
Error report:
ORA-01031: insufficient privileges
ORA-06512: at "SCHEMA_A.MAI__DWHMIRROR", line 47
ORA-06512: at line 2
01031. 00000 - "insufficient privileges"
*Cause:    An attempt was made to change the current username or password
           without the appropriate privilege. This error also occurs if
           attempting to install a database without the necessary operating
           system privileges.
           When Trusted Oracle is configure in DBMS MAC, this error may occur
           if the user was granted the necessary privilege at a higher label
           than the current login.
*Action:   Ask the database administrator to perform the operation or grant
           the required privileges.
           For Trusted Oracle users getting this error although granted the
           the appropriate privilege at a higher label, ask the database
           administrator to regrant the privilege at the appropriate label.

user5199319 wrote:
USER has DBA Role
when all else fails Read The Fine Manual
DBMS_METADATA

About DBMS_Metadata.Get_DDL

Similar Messages

Maybe you are looking for