Re: logical standby database limitation
From: onedbguru <onedbguru_at_yahoo.com>
Date: Wed, 30 Mar 2011 16:16:49 -0700 (PDT)
Message-ID: <9aaeea2d-80b3-4d76-adf2-c701285e5006_at_h38g2000yqn.googlegroups.com>
On Mar 30, 5:27 pm, Steve Howard <stevedhow..._at_gmail.com> wrote:
> 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.
Date: Wed, 30 Mar 2011 16:16:49 -0700 (PDT)
Message-ID: <9aaeea2d-80b3-4d76-adf2-c701285e5006_at_h38g2000yqn.googlegroups.com>
On Mar 30, 5:27 pm, Steve Howard <stevedhow..._at_gmail.com> wrote:
> 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.
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/database/options/active-data-guard/index.html Received on Wed Mar 30 2011 - 18:16:49 CDT