Re: Taking Backup from standby database

From: Gmail <jacques.kostic_at_gmail.com>
Date: Fri, 02 Dec 2016 08:50:30 +0100
Message-ID: <158be835d70.279d.f39e3e69b57dc29d82f1c76ed37cd589_at_gmail.com>



Hi Vadim,

Remember that you must be licensed active data guard for backup from active standby.
Cheers
Jko

On 2 December 2016 7:10:34 a.m. Vadim Keylis <vkeylis2009_at_gmail.com> wrote:

> Good evening oracle experts. I am having issue activating database restored
> using backup taken from standby.
> Our current setup: We have one primary and one standby database. The
> standby database is kept in sync with primary using dataguard. We are
> currently taking backups from primary. We are want to move backups from
> primary to standby database.
>
>
> I used script bellow to take backup from standby database and then restored
> backup on different server. The database was successfully restored and
> physical standby. The problem started when I try activating it. I got the
> following error
> ORA-01194: file 1 needs more recovery to be consistent
> ORA-01110: data file 1:
> '+STAGEDATA/SETLR/DATAFILE/system.5096.929468439'
>
>
>
> I will greatly appreciate suggestions on taking backups from standby in
> order to restore as primary in case of emergency as well as how to solve
> inconsistency error after standby database is activated.
>
> Thanks so much,
> Vadim
>
>
> -------------------------Script to backup from physical standby
> -------------------------------------------------
> run
> {
> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
> '/mnt/db_transfer/SETL/rman_backup/ctl/control_%F';
> CONFIGURE MAXSETSIZE TO 128 G;
> CONFIGURE SNAPSHOT CONTROLFILE NAME TO
> '/mnt/db_transfer/SETL/rman_backup/ctl/snapcf_SETL.f';
> ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT
> '/mnt/db_transfer/SETL/rman_backup/db_%d_df_t%t_s%s_p%p_level0';
> BACKUP INCREMENTAL LEVEL 0 TAG LEVEL_0_20161201_1526 DATABASE ;
> DELETE FORCE NOPROMPT OBSOLETE;
> RELEASE CHANNEL ch1;
> }

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Dec 02 2016 - 08:50:30 CET

Original text of this message