RE: Standy database on standard edition
Date: Wed, 12 Jun 2013 14:33:46 -0400
Message-ID: <C1117B1AA0340645894671E09A7891F71511DF6A1D_at_EIHQEXVM2.ei.local>
:) Thanks... Remember some of the caveats that went with this... apparently one is that RMAN is not allowed... (Can you believe that)? So this tangent is solely a logical exercise. Duplicating the entire database every time is clearly time consuming... so if RMAN had to restore all the datafiles every time, it is not going to be practical... although legal - not exactly a standby work around.
Joel Patterson
Database Administrator
904 928-2790
From: Ryan January [mailto:rjjanuary_at_multiservice.com]
Sent: Wednesday, June 12, 2013 1:54 PM
To: Patterson, Joel
Cc: Hans Forbrich; oracle-l_at_freelists.org
Subject: Re: Standy database on standard edition
From a legal perspective you'd be 100% in the clear. From a technical standpoint, once the database is opened I think it would require a fresh copy of the datafiles.
From the 10.2 rman docs: http://docs.oracle.com/cd/B19306_01/backup.102/b14191/rcmdupdb.htm (Using DUPLICATE DATABASE to Resynchronize a Duplicate Database)
"You may want to synchronize a duplicate database with the original database that was duplicated. The solution is to run the DUPLICATE DATABASE command again, essentially re-creating the duplicate database.This technique requires making complete copies of the datafiles of the duplicate database."
While I've experienced similar behavior on 11.2, I have not run across comparable docs to corroborate.
On 06/12/2013 12:38 PM, Patterson, Joel wrote:
Hmmm. Well we are just talking logic with respect to licensing, not practicality. In this scenario the 'full' database replacement' I am arguing would be trivial since the data files would be up to date and rman would recognize that and apply the archive logs.
I did not test that however once the database was opened. I know it would in the case of failure during duplication and before opening, if you just start over.
Joel Patterson
Database Administrator
904 928-2790
--
Joel Patterson
Sr. Database Administrator | Enterprise Integration
Phone: 904-928-2790 | Fax: 904-733-4916
http://www.facebook.com/pages/Enterprise-Integration/212351215444231 http://twitter.com/#!/entint http://www.linkedin.com/company/18276?trk=tyah http://www.youtube.com/user/ValueofIT
This message (and any associated files) is intended only for the use
of the addressee and may contain information that is confidential,
subject to copyright or constitutes a trade secret. If you are not the
intended recipient, you are hereby notified that any dissemination,
copying or distribution of this message, or files associated with this
message, is strictly prohibited. If you have received this message in
error, please notify us immediately by replying to the message and
deleting it from your computer. Messages sent to and from us may be
monitored. Any views or opinions presented are solely those of the
author and do not necessarily represent those of the company. [v.1.1]
From: Ryan January [mailto:rjjanuary_at_multiservice.com]
Sent: Wednesday, June 12, 2013 1:31 PM
To: Patterson, Joel
Cc: Hans Forbrich; oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>
Subject: Re: Standy database on standard edition
You could duplicate to the standby, however this will be a full database replacement rather than a refresh. As long as the database is quite small, and you limit how frequently this is completed it may be the simplest option.
If you were wanting to use RMAN, another viable option would be refreshing the standby with an incremental daily backup.
In this situation you would know at what SCN your standby is at, perform an RMAN incremental backup of the primary from that scn, and apply that to the standby instance.
On 06/12/2013 12:06 PM, Patterson, Joel wrote:
To push logic a little more. Could you not just RMAN 'duplicate the primary, and then shutdown, mount and repeat on a schedule. You could even intervene an open read only legally. Rman should pick up where it left off, recognizing that the datafile have been recovered rather quickly, unless I'm mistaken there, and move right to the archive logs. You could call it the automated duplicating application. Essentially doing the same thing as a manual 'standby' without standby parameters or commands.
I suppose the analogy is akin to the one Steven Hawkins used to describe the idea that he loved to argue about things that had no answer. Of course we know there is an answer, we will just not 'commit' to the one we think it is.
Joel Patterson
Database Administrator
904 928-2790
This email is intended solely for the use of the addressee and may contain information that is confidential, proprietary, or both.
If you receive this email in error please immediately notify the sender and delete the email.
This email is intended solely for the use of the addressee and may
contain information that is confidential, proprietary, or both.
If you receive this email in error please immediately notify the
sender and delete the email.
--
Joel Patterson
Sr. Database Administrator | Enterprise Integration
Phone: 904-928-2790 | Fax: 904-733-4916
www.entint.com<http://www.entint.com/>
[http://i1202.photobucket.com/albums/bb367/Entint/signaturev61.jpg]<http://www.entint.com/>
[http://i1202.photobucket.com/albums/bb367/Entint/th_FaceBook1.jpg]<http://www.facebook.com/pages/Enterprise-Integration/212351215444231> [http://i1202.photobucket.com/albums/bb367/Entint/th_Twitter1.jpg] <http://twitter.com/#!/entint> [http://i1202.photobucket.com/albums/bb367/Entint/th_LinkedIn1.jpg] <http://www.linkedin.com/company/18276?trk=tyah> [http://i1202.photobucket.com/albums/bb367/Entint/th_YouTube1.jpg] <http://www.youtube.com/user/ValueofIT>
This message (and any associated files) is intended only for the use of the addressee and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient, you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company. [v.1.1]
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jun 12 2013 - 20:33:46 CEST