Removing Advanced Compression from Large Tables with DBMS_REDEFINITION

Problem:

One of Datavail’s customers had found there were some tables using advanced compression features on tables, but did not have a license. We had previously tried to perform an ‘Alter Table Move…’ operation, but two tables were so large they couldn’t be moved during the outage window provided by the business. We needed to find a way to remove advanced compression to get the customer’s licensing current, but with minimal impact to the business.

Solution:

Oracle has provided a package name dbms_redefinition, that can be used to perform operations on a table while keeping it online.

Here are the steps to follow:

1. Verified that table could be redefined:
   can_redef_table
   (uname=’<table_owner>’
   , orig_table=>’<table_name>’
   , options_flag=>’cons_use_pk or cons_use_rowid’); <= optional if table has PK con_use_rowid if no PK on table.

 

2. Validated space is available prior to beginning compression removal.
   Assumption – that table would grow to double in size as an estimate.

 

3. Created separate undo tablespace for process, to prevent impacting other database transaction undo usage.

 

4. Create interim table that mirrors original, but without compression.

 

5. Next part is to run the compression itself.

    

   ALTER SESSION FORCE PARALLEL DML PARALLEL 2;
ALTER SESSION FORCE PARALLEL QUERY PARALLEL 2;
ALTER SESSION ENABLE RESUMABLE TIMEOUT 86400;
ALTER SYSTEM SET UNDO_TABLESPACE = UNDOTBS3;

    

   begin
dbms_redefinition.start_redef_table
( uname=>'<table_owner>',
orig_table=>'<table>',
int_table=>'<interim_table>', <= uncompressed table
options_flag=>dbms_redefinition.cons_use_rowid  <= table doesn’t have a primary key defined.
);
end;
/

    

   During this run, you can validate the original table doesn’t have a lock on it allowing the application and users to access it as normal.

    

   select b.owner, b.object_name, a.locked_mode
from v$locked_object a, all_objects b
where a.object_id = b.object_id
/

    

   OWNER ------------------------------ SYS <TABLE_OWNER>

   OBJECT_NAME ------------------------------ SNAP$ <INTERIM_TABLE>

   LOCKED_MODE ----------- 3 6

 

6. After table redefinition has completed, now is the time to sync up all the table updates that happened during redefinition process.

    

   EXEC DBMS_REDEFINITION.sync_interim_table('OWNER', 'ORIGINAL', 'INTERIM_TABLE');

 

7. Copy table dependents to new table. This should copy all constraints, indexes and triggers using the default parameters.

    

   BEGIN
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS
(uname=>'<table_owner>',
orig_table=>'<table>',
int_table=>'<interim_table>');
END;
/

 

8. Finally, tables can be switched the interim table will now be the name of the original table and vice versa. To be safe, there should be no applications accessing the table for this last step.  It only takes a few seconds to perform.

    
   
EXEC DBMS_REDEFINITION.finish_redef_table('<table_owner>', '<orig_table>', '<interim_table>');

Conclusion:

Using dbms_redefinition allows the DBA to make structural changes to a table that is completely transparent to the user community. In this example the purpose was to remove advanced compression from a table, but this is appropriate for changing a non-partitioned table to partitioned, changing column order or similar types of operations.