11 Replies Latest reply: Feb 26, 2013 7:43 AM by mseberg RSS

    Gap in logs are too far to recover.  Need to start over I think.

    993195
      Hello,

      I have a dataguard setup and due to several circumstances the connection was lost to the standby and the archivelogs are gone for as far back as needed.

      I want to double check that this is the best method to get synched up again. On primary I am running rman backups every night. Here is my config....

      Oracle 10.2.0.5 (64 bit)
      Red Hat 5 enterprise 64 bit.

      PRIMARY

      CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
      CONFIGURE BACKUP OPTIMIZATION ON;
      CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
      CONFIGURE CONTROLFILE AUTOBACKUP ON;
      CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
      CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 3;
      CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
      CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
      CONFIGURE MAXSETSIZE TO UNLIMITED; # default
      CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
      CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
      CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
      CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u04/flash_recovery_area/snapcf_bcso.f';

      Standby

      CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 28 DAYS;
      CONFIGURE BACKUP OPTIMIZATION ON;
      CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
      CONFIGURE CONTROLFILE AUTOBACKUP ON;
      CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
      CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
      CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
      CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
      CONFIGURE MAXSETSIZE TO UNLIMITED; # default
      CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
      CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
      CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
      CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u04/flash_recovery_area/snapcf_bcso.f';

      Backup script that is only run on primary. No backup on standby at the moment.

      run{
      crosscheck archivelog all;
      delete expired archivelog all;
      backup database plus archivelog not backed up delete all input;
      delete noprompt obsolete;
      #Fix for bug 964522.1
      delete force archivelog until time 'trunc(sysdate-1)' backed up 1 times to device type disk;
      }

      So can I just copy over my flash_recovery_area to the standby FRA, restore database, recover database? Then set my log_archive_dest_2 on the primary and ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; on the standby?

      I did not set this up initially and I see a couple issues I need to address on the standby

      db_recovery_file_dest string /u01/app/oracle/flash_recovery_area
      standby_archive_dest string /u04/flash_recovery_area

      Here is primary

      db_recovery_file_dest string /u04/flash_recovery_area

      What I'm not sure of is which one of these I need to switch on the standby or in RMAN on the standby. RMAN is going to look for the backup in the location set by db_recovery_file_dest on the standby for the files to recover. I don't have room on that drive so can I just simply change on standby db_recovery_file_dest = '/u04/flash_recovery_area' for the recovery then set it back when it's finished?


      Thanks
        • 1. Re: Gap in logs are too far to recover.  Need to start over I think.
          mseberg
          Hello;

          What jumps out right away is this on the Primary :
          CONFIGURE ARCHIVELOG DELETION POLICY TO NONE
          This should be APPLIED ON STANDBY to avoid issues with Archive being removed before the Standby applies it.
          RMAN> CONFIGURE ARCHIVELOG RETENTION POLICY TO APPLIED ON STANDBY;
          So can I just copy over my flash_recovery_area to the standby FRA, restore database, recover database? Then set my log_archive_dest_2 on the primary and ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; on the standby?

          The simple answer is No. I would consider using RMAN duplicate to rebuild the Standby.


          Best Regards

          mseberg
          • 2. Re: Gap in logs are too far to recover.  Need to start over I think.
            993195
            Okay I will look into that. I was just thinking since the databases are named different I will have conflicts.
            • 3. Re: Gap in logs are too far to recover.  Need to start over I think.
              mseberg
              Hello;

              The database name? The database name has to be the same in Data Guard.

              Example

              Primary

              db_name='PRIMARY'
              DB_UNIQUE_NAME=PRIMARY

              Standby

              db_name='PRIMARY'
              DB_UNIQUE_NAME=STANDBY

              This short note is Oracle 11, but everything in it should work with Oracle 10.

              http://www.visi.com/~mseberg/data_guard_on_oracle_11_step_by_step.html



              Best Regards

              mseberg

              Edited by: mseberg on Feb 25, 2013 10:56 AM
              • 4. Re: Gap in logs are too far to recover.  Need to start over I think.
                993195
                I did see that in the documentation however it is setup somewhat different.

                db_name string primary
                db_unique_name string primary
                global_names boolean TRUE
                instance_name string STDBY
                • 5. Re: Gap in logs are too far to recover.  Need to start over I think.
                  mseberg
                  Hello again;

                  The Oracle documents use the whole chicago, boston, denver thing. So in B14239-05 the primary is :

                  DB_NAME=chicago
                  DB_UNIQUE_NAME=chicago

                  While the Standby is


                  DB_NAME=chicago
                  DB_UNIQUE_NAME=boston

                  Does this make sense?

                  Both global_names and instance_name are not very important to Data Guard, instance_name you might need if RAC.


                  Here's my simple duplicate if it helps

                  http://www.visi.com/~mseberg/duprman.html

                  Best Regards

                  mseberg
                  • 6. Re: Gap in logs are too far to recover.  Need to start over I think.
                    993195
                    I did see that in the documentation and I never noticed the difference until now because we were working fine until our issue hit. I'm hesitating to make any changes but at the same time I feel I should get this going my way instead of the prior DBA's method. I guess I will just have to completely wipe everything on the standby and start at step one instead of just trying to copy over the backup and recover.

                    I didn't want to have to do that. :(
                    • 7. Re: Gap in logs are too far to recover.  Need to start over I think.
                      mseberg
                      Been there.

                      You want it right, trust me. I sorry about any rework. But you want it right.

                      Try to look at it as a recovery of the Standby.

                      Best Regards

                      mseberg
                      • 8. Re: Gap in logs are too far to recover.  Need to start over I think.
                        993195
                        I already started. Question.....for these parameters I am confused on what to put exactly. The documentation is a little vague.

                        *.db_unique_name='bcso'
                        *.log_archive_config='DG_CONFIG=(bcso,stdby)'
                        *.log_archive_dest_1='location=/u04/flash_recovery_area valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=bcso'
                        *.log_archive_dest_2='SERVICE=BCSTDBY_40 reopen=60 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby'
                        *.FAL_SERVER=bcso
                        *.FAL_CLIENT=stdby

                        I just want to be clear that in *.log_archive_dest_2='SERVICE=BCSTDBY_40 I put the tnsnames.ora entry of the server I want to connect to not the instance name?
                        • 9. Re: Gap in logs are too far to recover.  Need to start over I think.
                          mseberg
                          Hello again;

                          Monday is meeting day here.


                          PRIMARY

                          db_name='bcso'
                          db_unique_name='bcso'
                          log_archive_config='DG_CONFIG=(bcso,stdby)'
                          log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=bcso'
                          log_archive_dest_2='SERVICE=BCSTDBY_40 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby'
                          FAL_SERVER=bcso
                          FAL_CLIENT=stdby


                          STANDBY

                          db_name='bcso'
                          db_unique_name='stdby'
                          log_archive_config='DG_CONFIG=(bcso,stdby)'
                          log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stdby'
                          log_archive_dest_2='SERVICE=bcso LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bcso'
                          FAL_SERVER=stdby
                          FAL_CLIENT=bcso

                          I just want to be clear that in *.log_archive_dest_2='SERVICE=BCSTDBY_40 I put the tnsnames.ora entry of the server I want to connect to not the instance name?
                          Correct. The is the TNSNAMES.ORA entry.

                          Important

                          The way I show it you need to set DB_RECOVERY_FILE_DEST too.


                          Example

                          db_recovery_file_dest='/u04/flash_recovery_area'


                          If the standby site's FRA is different you need to account for that.


                          Once you get it going keep this query ( I would run once a day )

                          http://www.visi.com/~mseberg/data_guard/monitor_data_guard_transport.html


                          Best Regards

                          mseberg
                          • 10. Re: Gap in logs are too far to recover.  Need to start over I think.
                            993195
                            Thanks. I wasn't going to use the async option because I wasn't planning on using standby logs. I am using the default dataguard availability configuration. Can you give me pro's and cons for the logs if I'm not using the other two dataguard options?
                            • 11. Re: Gap in logs are too far to recover.  Need to start over I think.
                              mseberg
                              Hello;

                              Standby logs are a good thing. They can help buffer redo. They are very small. I cannot think of a single con. I would have them available no matter what.

                              Standby redo logs are populated with redo information as fast as the primary redo logs, rather than waiting for the redo log to be archived and shipped to the standby. So the loss of data in the event of a failover is minimized.

                              Best Regards

                              mseberg