Re: logical standby database limitation
Date: Wed, 30 Mar 2011 14:27:02 -0700 (PDT)
Message-ID: <e8abfa68-29f9-47cf-a185-250e53e8da53_at_a11g2000pri.googlegroups.com>
On Mar 30, 4:19 pm, charles <dshprope..._at_gmail.com> wrote:
> 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
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. Received on Wed Mar 30 2011 - 16:27:02 CDT