RE: Data Guard to Logical Standby

In line

 

________________________________

From: Mark W. Farnham [mailto:mwf_at_rsiz.com] 
Sent: Thursday, May 01, 2008 8:04 PM
To: April Wells; Ben.Wittmeier_at_gov.ab.ca; oracle-l_at_freelists.org
Subject: RE: Data Guard to Logical Standby 

 

Okay, I'll bite. If this is for historical reporting, what periodicity
is required?

 

>> NEVER more than 4 - 6 hours old data, Risk wants it never more than 1
hour old.

 

If you only need to be within a day or within a week, it is much simpler
to simply do some variety of continuous recovery with a periodic pause
during which you shut down cold, copy the whole shooting match
(locally), startup recover rename resetlogs, thereby instantiating a
frozen reporting database (notice that it is a renamed copy, so you can
run it on the same node as the recovery database which has the same
name), and then you merely restart the standby and resume recovery.

 

>> We don't HOT backup our production database let alone have the
available down time to shutdown cold to rsynch copies (this takes like
20 hours)

 

This will work with one variety or another of physical recovery since
6.0.36.x. A variety of software components from Oracle and others may
make it easier to do (depending on your perspective) and with more
modern techniques you can sort of avoid the copy. But the old way with
the copy allows you to create aggregates that remain valid (since the
base data is frozen until the next refresh). I'm not sure whether a
paper "Getting the most from your standby recovery system" is still
around on the net anywhere. It is a little dated, but the principles and
discussion of costs still apply, I believe. That was also known in some
circles as the "Avoid the Toaster/Freezer" paper.

 

... I like the name of the paper... I will have to go try to find it.

 

Regards,

 

mwf

 

<snip>

We are trying to create a logical standby database (solaris) using data
guard so we can use downstream data capture to populate a reporting
database (Linux) for historical reporting.

 

<snip>




-----------------------------------------
Confidentiality Notice!
This electronic transmission and any attached documents or other
writings are confidential and are for the sole use of the intended
recipient(s) identified above. This message may contain information
that is privileged, confidential or otherwise protected from
disclosure under applicable law. If the receiver of this
information is not the intended recipient, or the employee, or
agent responsible for delivering the information to the intended
recipient, you are hereby notified that any use, reading,
dissemination, distribution, copying or storage of this information
is strictly prohibited. If you have received this information in
error, please notify the sender by return email and delete the
electronic transmission, including all attachments from your
system.

--
http://www.freelists.org/webpage/oracle-l