2 Replies Latest reply: Sep 23, 2013 9:20 PM by Hemant K Chitale RSS

    Data Guard with NONOGGING with COMPRESS tables


      Hello DG experts,




      Oracle Database 10g Enterprise Edition Release - 64bi

      PL/SQL Release - Production

      CORE      Production

      TNS for HPUX: Version - Production

      NLSRTL Version - Production


      I have a question on this and trying to find the solution for this scenario



      Can I put some tables are in NOLOGGING mode with COMPRESS on both  primary and seconday databases

          These NOLOGGING with COMPRESS tables will be loaded weekly on both databases through ETL jobs, no update happens as I load on both databases do not need to require to recover those tables


      Remaining tables will in LOGGING mode and I will not issue FORCE LOGGING


      will this scenario work?


      Any help would be greatly appreciated.

        • 1. Re: Data Guard with NONOGGING with COMPRESS tables



          I'm thinking no. The the primary database needs to be in FORCE LOGGING mode. Database trumps table.


          Ask Tom


          (Ask Tom "dataguard and nologging")


          The Gains and Pains of Nologging Operations in a Data Guard Environment (Doc ID 290161.1)




          Compress is not an issue.


          You might consider a logical standby for ETL work.


          Best Regards



          • 2. Re: Data Guard with NONOGGING with COMPRESS tables
            Hemant K Chitale

            Technically there is nothing preventing you from NOT setting FORCE_LOGGING=TRUE and then using NOLOGGING operations.

            However, the blocks would be marked as "logically corrupt".  Any subsequent non-direct path DML against those blocks may fail to execute on the Standby and would halt replication of redo.

            So you would use NOLOGGING operations only against tables with *only* operations like Direct Path INSERT and TRUNCATE and no other normal DML.

            Of course, when you open the Standby it becomes your job to identify which operations have not been applied to this table and manually apply them (run ETL for example).


            Never tested this.  It might or might not work !



            Hemant K Chitale