Our situation is like this, we want a system where we can let end user
to use it as a report server, browse the source code, etc. And
occasionally they will need to create a temp table to facilitate their
reports as well.

It seems to be me that logical standby database is a way to go .
However, from DBA_LOGSTDBY_UNSUPPORTED, we can see there are about 100
columns in our database that are not supported.

What is your opinion or recommendation? Could we use logical_standby
database and use datapump to move those tables manually? or use
steams on top of logical standby database?

Thanks very for your support

On Mar 30, 4:19*pm, charles <dshprope... (AT) gmail (DOT) com> wrote:
Streams is subject to the same limitations, as they each use SQL apply
to transform redo records into SQL updates, deletes, and inserts.

You can use the skip_logstdby_apply procedure (I think that is the
name) to skip those tables. However, you are still stuck with the
problem of not having those tables in your standby database.

We ran into this exact same situation three years ago when we migrated
from AIX to Linux using streams, and ended up using old fashion
replication to handle those tables. The problem is they are not
synchronized with each other, i.e., the tables handled by the logical/
streams processes won't be at the same point in the life of the
database as those handled by replication. This may be an issue for
you, and it may not if you can disable the constraints and live with
slightly "bad" data in the standby.

If the source tables aren't frequently updated, you could also use
triggers on them.

On Mar 30, 5:27*pm, Steve Howard <stevedhow... (AT) gmail (DOT) com> wrote:

Have you looked at ACTIVE DATAGUARD?? basically the second standby
database is open - no changes to the replicated data should be made,
however you can run reports etc as well as using it for DR. The
downside, is that now you pay for the opportunity to "save money"...

http://www.oracle.com/us/products/da...ard/index.html