6 Replies Latest reply: Dec 3, 2012 12:08 PM by mseberg RSS

    Rman issues

    BSalesRashid
      Hi all, I am using Oracle Database 11g Enterprise Edition Release 11.2.0.3.0, with ASM.
      I just did a rman backup and i have some issues about it.

      Here is the script that i've used:
      run {
      backup as compressed backupset database plus archivelog delete input tag 'BKP_FULL_GF';
      delete obsolete;
      }
      exit;
      The backup worked succesfully, but i checked the v$session to see if rman was still active and i found these background processes with status ACTIVE:
      PROGRAM
      -----
      oracle@xxxx.com (O001)
      oracle@xxxx.com (O002)

      These background process wasn't there before the rman Backup [i used parallelism 4].
      I read that the background process O00* have something to do with ASM.

      What would be this? It is a normal behavior?




      Here is another question about the backup i just did:
      I just did this Full Backup, and now i did:
      RMAN> report unrecoverable;
      using target database control file instead of recovery catalog
      Report of files that need backup due to unrecoverable operations
      File Type of Backup Required Name
      -----
      31 full or incremental +DATA/gf/datafile/ts_controlfin.302.791985901
      32 full or incremental +DATA/gf/datafile/ts_controlfin.303.791985931
      33 full or incremental +DATA/gf/datafile/ts_controlfin.304.791985963
      34 full or incremental +DATA/gf/datafile/ts_controlfin.305.791985993
      35 full or incremental +DATA/gf/datafile/ts_controlfin.306.791986023
      36 full or incremental +DATA/gf/datafile/ts_controlfin.307.791986055
      37 full or incremental +DATA/gf/datafile/ts_controlfin.308.791986085
      38 full or incremental +DATA/gf/datafile/ts_controlfin.309.791986115
      39 full or incremental +DATA/gf/datafile/ts_controlfin.310.791986145
      40 full or incremental +DATA/gf/datafile/ts_controlfin.311.791986177


      I understand that the the reason for unrecoverable datafiles would be because of the use of 'nologging' when creating a table (i don't know if there is another reason), based on this, how can i find tables that were created with 'nologging' parameter ?

      I hope you guys understand what i'm trying to say here.

      Thanks in advance.

      Edited by: BSalesRashid on 03/12/2012 06:13

      Edited by: BSalesRashid on 03/12/2012 09:13
        • 1. Re: Rman issues
          vlethakula
          Check this thread:

          Re: rman - "report unrecoverable" concept

          and also

          http://www.pythian.com/news/7401/oracle-what-is-an-unrecoverable-data-file/
          • 2. Re: Rman issues
            mseberg
            Hello;

            The background processes appear to include you full server hostname. Are you sure you want that posted on the net? ( You don't ! ) So I would remove asap
            and form here too :

            Re: How to know if Grid Control is installed ?

            How did you detect these?

            A datafile or tablespace are set to unrecoverable if any operation that had been performed (since the last backup taken on these datafiles) on datafile or tablespace that are unrecoverable.
            These can be caused by :

            SQL*loader with nologging
            partition manipulation
            INSERT /*+APPEND*/
            ALTER TABLE commands
            direct-path inserts result from insert or merge statement
            CREATE and ALTER INDEX commands


            What preventions you can take for not making data file to unrecoverable?

            Use force_logging

            Best Regards

            mseberg
            • 3. Re: Rman issues
              Levi Pereira
              BSalesRashid wrote:
              Hi all, I am using Oracle Database 11g Enterprise Edition Release 11.2.0.3.0, with ASM.
              I just did a rman backup and i have some issues about it.

              Here is the script that i've used:
              run {
              backup as compressed backupset database plus archivelog delete input tag 'BKP_FULL_GF';
              delete obsolete;
              }
              exit;
              The backup worked succesfully, but i checked the v$session to see if rman was still active and i found these background processes with status ACTIVE:
              PROGRAM
              -----
              oracle@xxxxxx (O001)
              oracle@xxxxxx (O002)

              These background process wasn't there before the rman Backup [i used parallelism 4].
              I read that the background process O00* have something to do with ASM.

              What would be this? It is a normal behavior?
              Nothing to worry about... It's a normal behavior.

              ora_O00n - This is ASM Connection Pool Process, it maintains a connection to the ASM instance for metadata operations, Onnn slave processes are spawned on demand.
              These processes communicate with the ASM instance.


              Regards,
              Levi Pereira
              • 4. Re: Rman issues
                BSalesRashid
                Hi,
                Thank you for the warning.
                • 5. Re: Rman issues
                  BSalesRashid
                  Hi,
                  Thanks for replying.

                  Question: The force logging solve this problem no matter the cause?

                  Regards,
                  • 6. Re: Rman issues
                    mseberg
                    Hello;

                    Based on what I've seen with Data Guard. Yes.

                    The first step for is to set Forced logging on the primary so you don't have SYNC issues.

                    With FORCE LOGGING Oracle logs all changes in the database except changes in temporary tablespaces and temporary segments. This setting takes precedence over and is independent of any NOLOGGING or FORCE LOGGING settings you specify for individual tablespaces.

                    Best Regards

                    mseberg