RDBMS 11.2.0.2: unrecoverable operations of Compression Advisor running daily

At one of my customers, we wondered about some entries in v$datafile.unrecoverable_change# for the most critical tablespace of the application. Certainly no application components were allowed to perform nologging operations for segments inside this tablespace and yet there was evidence that “something” was done with nologging.

  • The unrecoverable_time was shortly after 10 pm
  • The ASH data covering this time period showed activity by DBMS_SCHEDULER and Autotask Jobs.
  • An internal DDL log table showed the following operations:
CREATE TABLE "MYOWNER".DBMS_TABCOMP_TEMP_UNCMP
tablespace "DAT_MYOWNER" nologging
AS
SELECT /*+ FULL("MYOWNER"."MYTAB") */ *  FROM "MYOWNER"."MYTAB"  sample block( 3.55) mytab ;   
 
CREATE TABLE "MYOWNER".DBMS_TABCOMP_TEMP_CMP ORGANIZATION HEAP
TABLESPACE "DAT_MYOWNER"
COMPRESS FOR ALL OPERATIONS
NOLOGGING
AS
SELECT  * FROM "MYOWNER".DBMS_TABCOMP_TEMP_UNCMP MYTAB;
 
DROP TABLE "MYOWNER".DBMS_TABCOMP_TEMP_UNCMP PURGE;
DROP TABLE "MYOWNER".DBMS_TABCOMP_TEMP_CMP purge;

Summary:

I find it suboptimal that Compression Advisor is executed on a daily basis during the maintenance window and that the Compression Advisor can not be seperately disabled without also disabling the Segment Advisor. (Although there is supposed to be an enhancement request open for this.)

In addition to that, it is more than problematic that the is using the user tablespace, which could lead to tablespace pressure and that the operations are performed as unrecoverable and therefore logged in v$datafile.unrecoverable_time, overwriting potential important information of real “user” operations performing with NOLOGGING.

More information about Compression Advisor can be found in MOS Note: How Does Compression Advisor Work? [ID 1284972.1]

2 comments
Leave a comment »

  1. Do you have anything further proving this occurs. We just upgraded 11gr1 to r2 and overnight about 10:30 p.m. had an unrecoverable transaction in about 40 tablespaces. Oracle Support does not think the compression wizard did this.

  2. Jeff,

    you can easily prove that this was the Compression Advsior by checking Active Session History (ASH) for this time period. Then you will find SQL statement containing the keyword “NOLOGGING”.

    Best regards,
    Martin

Leave Comment

Print This Post Print This Post