Question

I need to back up tables and their data as part of software testing. The exact tables and the data they contain may vary so I can’t hard code the DDL or the data. The back up tables will have similar names as the original tables but with the prefix “QA_”. Similar, but not identical (except for the prefix), only because in order to work around the 31 character limit for table names I have to abbreviate some of the names.

Which would be the faster way of doing this? Using a cursor object and looping through the tables to get their DDL like this:

select dbms_metadata.get_ddl(''TABLE'',' || '''' || cursor_rec.object_name || '''' || ') from dual

Using that DDL to create the backup tables and then populating those tables with:

INSERT /*+ parallel(' || new_table_name || 'DEFAULT) */ INTO '  || new_table_name  || ' SELECT  * FROM '  || table_name  || ''

Or doing a simple:

CREATE TABLE' || new_table_name 'PARALLEL AS SELECT * from ' || table_name || ''

Which is the faster of the two methods?

Answer 1

Well, both INSERT /*+ PARALLEL */ and CREATE TABLE .... PARALLEL AS SELECT ... are going to do direct load insert. So, they are largely going to use the same code path, for the data loading.

CTAS will need to first do the DDL to create the table, before proceeding with the load. But, that’s a small amount of fixed work. The larger the table being copied, the smaller factor that will be.

Finally, I’ll just mention, that you should look into NOLOGGING to further improve performance.

On the CTAS, you can just add the NOLOGGING keyword after the PARALLEL keyword. For the INSERT /*+ PARALLEL */, you’ll need to first do an ALTER TABLE ... NOLOGGING to enable it.

Note that there are a few things you need to know, if you decide to go with NOLOGGING. First, only direct-load will do nologging. For tables, that means CTAS and INSERT with PARALLEL or APPEND hint.

Secondly, consider the recovery implications of NOLOGGING. When a table is loaded with NOLOGGING option, the data is NOT logged to REDO. So, you won’t be able to recover the data in the table, unless you use a backup taken after the data was sucessfully loaded and committed.

Hope that helps.