This discussion is archived
11 Replies Latest reply: Feb 26, 2013 5:43 AM by mseberg RSS

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

993195 Newbie
Currently Being Moderated
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 Guru
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points