|
|
|
|
|
|
| Author |
Message |
EdStevens
*nix forums Guru Wannabe
Joined: 06 Sep 2005
Posts: 180
|
 Posted: Thu Jul 20, 2006 4:37 pm Post subject:
re-build physical standby in DG setup
|
|
|
Subject: re-build physical standby in DG setup
Platform: Oracle 10.2.0.1.0 on Solaris 10
DataGuard configuration with a physical standby database. Through an
unfortunate set of circumstances, a couple of archivelog files didn't
get shipped, then got deleted from the primary site. (yes, I'm the
guilty party) (And when I asked the server admin guys if they could
restore the archivelog files from a server level backup, they
discovered that *their* backup procedure had been failing!)
As I understand, that leaves the standby unable to complete it's
recovery, so I need to rebuild it almost from scratch. I say
'almost' because, as I read the chapter on creating a physical
standby in the DataGuard Concepts and Admin manual, it appears that
several of the steps that were done on the initial setup are still good
and can be bypassed for this exercise. Here's how I see this shaking
out. Please tell me if I'm getting ready to dig the hole even
deeper, if there's an easier way out, or if I'm on the right track
but need to consider a few more items.
Following the setup steps in the doc, I should be able to bypass
everything dealing with creating the primary database. It was/is up,
and the only thing I've done is stop archive shipping, to prevent
filling up the recovery area target on the standby.
On the standby, comments on each step:
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?)
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)
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)
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)
3.2.5 - Set up the environment to support the standby database
(already there)
3.2.6 - start the physical standby
-- startup mount
-- alter database recover managed standby database disconnect from
session;
(yes)
(extra item: restart log shipping on the primary)
3.2.7 - verify physical standby is performing properly
(run log switches, examine results --- yes)
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?
Anything I'm overlooking or failed to consider? |
|
| Back to top |
|
 |
Joel Garry
*nix forums Guru
Joined: 24 Mar 2005
Posts: 1044
|
| Posted: Thu Jul 20, 2006 7:01 pm Post subject:
Re: re-build physical standby in DG setup
|
|
|
EdStevens wrote:
| Quote: | Subject: re-build physical standby in DG setup
Platform: Oracle 10.2.0.1.0 on Solaris 10
DataGuard configuration with a physical standby database. Through an
unfortunate set of circumstances, a couple of archivelog files didn't
get shipped, then got deleted from the primary site. (yes, I'm the
guilty party) (And when I asked the server admin guys if they could
restore the archivelog files from a server level backup, they
discovered that *their* backup procedure had been failing!)
|
This is why I'm paranoid about backing up archive logs multiple times,
and not deleting them for at least 3 days (ie, log shipping breaks
Friday night of a 3 day weekend, Tuesday morning I can still suck from
several online backups).
| Quote: |
As I understand, that leaves the standby unable to complete it's
recovery, so I need to rebuild it almost from scratch. I say
'almost' because, as I read the chapter on creating a physical
standby in the DataGuard Concepts and Admin manual, it appears that
several of the steps that were done on the initial setup are still good
and can be bypassed for this exercise. Here's how I see this shaking
out. Please tell me if I'm getting ready to dig the hole even
deeper, if there's an easier way out, or if I'm on the right track
but need to consider a few more items.
Following the setup steps in the doc, I should be able to bypass
everything dealing with creating the primary database. It was/is up,
and the only thing I've done is stop archive shipping, to prevent
filling up the recovery area target on the standby.
On the standby, comments on each step:
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?)
|
Yes, everything. I'm jealous that 10 doesn't require everything to be
in the exact same place :-)
| Quote: |
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)
|
Only if you have an unbroken log sequence. You don't. You need a new
controlfile for standby. I think (there may be something in 10g I
don't know about, but I don't see any relevant new features). But it's
easy enough
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14239/rcmbackp.htm#sthref2283
| Quote: |
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)
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)
3.2.5 - Set up the environment to support the standby database
(already there)
|
OK, but for standby controlfile.
| Quote: |
3.2.6 - start the physical standby
-- startup mount
-- alter database recover managed standby database disconnect from
session;
(yes)
(extra item: restart log shipping on the primary)
3.2.7 - verify physical standby is performing properly
(run log switches, examine results --- yes)
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?
|
Once they are applied, no problem. I use the same paranoid deletion on
the standby as the primary, but that is generally overkill that I
rationalize as something I won't have to change if it becomes primary.
Although, I've seen flaky situations where I've needed to redo the
restore and have been glad those arcs hadn't been deleted yet. I can't
imagine a scenario where that would make sense beyond a few days after
the restore, though. (I had one special situation that took a week to
catch up).
| Quote: |
Anything I'm overlooking or failed to consider?
|
jg
--
@home.com is bogus.
http://www.scaryplace.com/ScaryPlace.html |
|
| Back to top |
|
|
EdStevens
*nix forums Guru Wannabe
Joined: 06 Sep 2005
Posts: 180
|
| Posted: Thu Jul 20, 2006 8:14 pm Post subject:
Re: re-build physical standby in DG setup
|
|
|
joel garry wrote:
| Quote: | EdStevens wrote:
Subject: re-build physical standby in DG setup
Platform: Oracle 10.2.0.1.0 on Solaris 10
DataGuard configuration with a physical standby database. Through an
unfortunate set of circumstances, a couple of archivelog files didn't
get shipped, then got deleted from the primary site. (yes, I'm the
guilty party) (And when I asked the server admin guys if they could
restore the archivelog files from a server level backup, they
discovered that *their* backup procedure had been failing!)
This is why I'm paranoid about backing up archive logs multiple times,
and not deleting them for at least 3 days (ie, log shipping breaks
Friday night of a 3 day weekend, Tuesday morning I can still suck from
several online backups).
As I understand, that leaves the standby unable to complete it's
recovery, so I need to rebuild it almost from scratch. I say
'almost' because, as I read the chapter on creating a physical
standby in the DataGuard Concepts and Admin manual, it appears that
several of the steps that were done on the initial setup are still good
and can be bypassed for this exercise. Here's how I see this shaking
out. Please tell me if I'm getting ready to dig the hole even
deeper, if there's an easier way out, or if I'm on the right track
but need to consider a few more items.
Following the setup steps in the doc, I should be able to bypass
everything dealing with creating the primary database. It was/is up,
and the only thing I've done is stop archive shipping, to prevent
filling up the recovery area target on the standby.
On the standby, comments on each step:
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?)
Yes, everything. I'm jealous that 10 doesn't require everything to be
in the exact same place :-)
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)
Only if you have an unbroken log sequence. You don't. You need a new
controlfile for standby. I think (there may be something in 10g I
don't know about, but I don't see any relevant new features). But it's
easy enough
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14239/rcmbackp.htm#sthref2283
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)
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)
3.2.5 - Set up the environment to support the standby database
(already there)
OK, but for standby controlfile.
3.2.6 - start the physical standby
-- startup mount
-- alter database recover managed standby database disconnect from
session;
(yes)
(extra item: restart log shipping on the primary)
3.2.7 - verify physical standby is performing properly
(run log switches, examine results --- yes)
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?
Once they are applied, no problem. I use the same paranoid deletion on
the standby as the primary, but that is generally overkill that I
rationalize as something I won't have to change if it becomes primary.
Although, I've seen flaky situations where I've needed to redo the
restore and have been glad those arcs hadn't been deleted yet. I can't
imagine a scenario where that would make sense beyond a few days after
the restore, though. (I had one special situation that took a week to
catch up).
Anything I'm overlooking or failed to consider?
jg
--
@home.com is bogus.
http://www.scaryplace.com/ScaryPlace.html
|
Joel,
Thanks for the reply. And the good pointers. Sounds like I'm on the
right track.
Good point about the control file. I was concerned that if I depended
on the current one with the standby, it would still try to recover
through the break in the redo stream. And the pointer to the Appendix
in the DG Admin is very helpful. Thanks again. |
|
| Back to top |
|
|
Andreas Piesk
*nix forums beginner
Joined: 21 Nov 2005
Posts: 18
|
| Posted: Thu Jul 20, 2006 9:01 pm Post subject:
Re: re-build physical standby in DG setup
|
|
|
EdStevens wrote:
| Quote: | 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;
| Quote: | 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
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Mon Dec 01, 2008 6:43 pm | All times are GMT
|
|
Credit Check | Refinance | Secured Loans | Loans | Problem Mortgage
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Databases
»
Oracle
»
Server
