Re: re-build physical standby in DG setup

From: EdStevens <quetico_man_at_yahoo.com>
Date: 21 Jul 2006 11:59:24 -0700
Message-ID: <1153508364.175690.279980@i3g2000cwc.googlegroups.com>

Andreas Piesk wrote:
> EdStevens wrote:
> > 3.2.1 - Create Backup Copy of the Primary Database datafiles.
> > (yes, use rman to backup datafiles. This will need to be a hot backup.
> > Just the files listed in DBA_DATA_FILES? Include the SYSTEM
> > tablespace?)
>
> everything, including controlfiles. as i regularly rebuild physical
> standby databases i use the following rman script:
>
> backup as compressed backupset
> check logical
> full database
> include current controlfile for standby;
>
> > 3.2.2 - Create Control file for standby
> > (it says "if the backup procedure required a shutdown of the primary
> > ....". I would think I could skip this and go with the existing
> > control file of the standby, but am unsure of its record of archive
> > sequences)
>
> can be skipped if controlfile was already backed up in 3.2.1
>
> > 3.2.3 - Prepare initialization parameter file for the standby
> > (again, I should be able to go with the spfile that is already in
> > place)
>
> yes, the existing spfile should be fine. if using OMF/ASM there could
> be a little problem with the controlfilenames that can easily be solved
> by renaming the controlfiles in the spfile.
>
> > 3.2.4 - copy files from the primary to the standby
> > (yes to the backup data files, but no to the control file and parm
> > file)
>
> copy all backupsets created in 3.2.1 (including the controlfile). i
> personally use rmans 'duplicate' for creating the standby, very
> comfortable.
>
> > 3.2.6 - start the physical standby
> > -- startup mount
> > -- alter database recover managed standby database disconnect from
> > session;
> > (yes)
>
> did you consider to use dgmgrl for managing dataguard? i recommend it.
>
> > If this is essentially correct, I would also think I can simply delete
> > a bunch of now obsolete archivelogs, followed by rman crosscheck and
> > delete obsolete on the primary. What of archivelog cleanup on the
> > standby, where the db is not open?
>
> i would first catalog everything recovery related on the standby, then
> crosscheck and delete all expired stuff. db in mount state is ok, no
> open db needed.
>
> you should consider making multiple backups of archived redologs. i for
> myself back up all archivelogs on a daily basis and delete only logs
> sucessfully backed up 3 times:
>
> delete archivelog all backed up 3 times to device type sbt;
>
>
> regards,
> -ap

Ah,yes. OMF. Another 'opportunity.' Before he left, the consultant who set this up, mentioned to me that he had inadvertently set the standby to use OMF for the archive logs. So as I studied your note and Appendix F, I also took a side trip to read up on OMF a bit. Here's what I have and what I think I understand about it:

On the primary, we have these parms (output of 'show parameter);

db_create_file_dest                  string
db_file_name_convert                 string
db_create_online_log_dest_1          string
db_create_online_log_dest_2          string
db_create_online_log_dest_3          string
db_create_online_log_dest_4          string
db_create_online_log_dest_5          string
db_recovery_file_dest                string      /db01/oraarch



On the standby, we have these parms
db_create_file_dest                  string
db_file_name_convert                 string
db_create_online_log_dest_1          string
db_create_online_log_dest_2          string
db_create_online_log_dest_3          string
db_create_online_log_dest_4          string
db_create_online_log_dest_5          string
db_recovery_file_dest                string

/db01/archive/epspd/arc

As I understand it, the fact that a value is set for db_recovery_file_dest means that we OMF archivelogs. Still I would think that since these databases were working together that everything should still be ok

I want to make very certain I understand what's going on here .. make certain I don't dig myself a deeper hole than I already have. At this point, it looks like my steps are:

1. turn archive shipping back on on the primary -- so that when the standby comes up, the archives it needs to recover will already be in place.
2. take an online backup of the primary (it is a live production system doing credit card authorization processing. Little tolerance for downtime required by a cold backup)
3. in rman, connected to primary: rman> copy current controlfile for standby to ...
4. on primary server - start rman: $> rman target / auxiliary sys/****@<standby db>
5. rman> duplicate target database for standby nofilenamecheck dorecover;

and at this point, I should be home free, with a standby database mounted, recovered, and continuing to recover from new archives as they arrive. No? Received on Fri Jul 21 2006 - 13:59:24 CDT