RE: Data Guard to Logical Standby
Date: Thu, 1 May 2008 21:03:34 -0400
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.
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>Received on Thu May 01 2008 - 20:03:34 CDT