RE: Data Guard to Logical Standby

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

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.  

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.  

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>

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