Hi Carel,
That is good help, can you please send me the pdf that
you implemented there then.
Tell me one thing I agree that we some
times
(rather most of the time ) generate less redo so we
should be smooth. Can you tell me is there any
releation between LSB and Primary keys, I read like
LCR(logical Change Request) is based on Primary keys
as It does not depends on Transaction at that time.
Have you implemnented LSB successfully?
with many thanks,
Vi.
- Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl>
wrote: > Comments inline
>
> At 13:34 8-12-03 -0800, you wrote:
> >Hi Tanel,
> >
> >
> >Much appreciated, The fact is I am interested in
> >Logical standby rather than physical.
> >
> > Our 30-50% of our Production data needs to be
> >replicated to another database and where they will
> >have their processing and batches.
>
> It all depends on the amount of redolog you
> generate. When that's pretty
> much, you waste some resources by transporting
> online/archived redologs you
> actually don't need.
>
>
> > Now We didn't go to Snapshot because It is on
> >multiple tables (where we didnot have PK's and
> many
> >tables) and due to performance issue I didn't want
> to
> >use Snapshots (they did not want any tables to be
> >truncate before being loaded even via snapshots).
>
> So, they don't like nologging operations like
> truncate, not even on the
> standby database?
>
>
> > The best option I think is Logical Standby
> Database.
> >Or Can you please suggest me any other means.
> >
> > Replication should be quicker like once
> in
> >every 20 minutes, Even Transportable tablespacs
> does
> >not work here since they need all tables to 24*7.
>
> LSB might work, but do not consider the option of
> failing over to it. Be
> aware that, altough in maximum protection mode your
> redolog arrives at the
> SB system within the transaction, it doesn't get
> applied there instantly.
> SQL Application takes place _after_ the log-switch
> on the Primary. When you
> take 10 minutes of redolog, and perform a logswitch,
> the SQL Apply process
> might even take longer than 10 minutes to complete
> processing of the
> redologfile. There is a risk that not every
> transaction arrives within 20
> minutes at the LSB. So, your log-switching frequency
> and the amount of redo
> you generate per unit of time both play a major role
> in the refresh rate of
> the LSB.
>
> I'll send you the PDF of a DG Special I did in Kista
> a few months ago.
>
>
> Regards, Carel-Jan
>
> -- There will allwasy be another 10 last bugs --
>
>
> >Any suggestion would be more helpful.
> >
> >with thanks,
> >Vi.
> >
> >
> >
> >--- Tanel Poder <tanel.poder.003_at_mail.ee> wrote: >
> >
> >Hi All,
> > > >
> > > > can any one let me know kindly the following
> info.
> > > >
> > > > 1) Has any one used the Oracle 9i Data Guard?
> > >
> > > Yes, physical standby and successfully.
> > >
> > > > 2) If yes then, is there any performance
> impact
> > > on
> > > > Target/Source server database.
> > >
> > > Your database has to be in archivelog mode, but
> when
> > > you are thinking such
> > > solutions as DG, then you probably are already
> > > running archivelog anyway.
> > >
> > > If you run in maximum protection or maximum
> > > availability, yes there is. The
> > > impact depends mainly on network connection
> between
> > > primary and standby(s)
> > > and the speed of redolog disks. You could tune
> these
> > > by using faster
> > > network, enabling jumbo frames and SDU size if
> using
> > > Gbit ethernet, also
> > > setting lgwr and log apply processes priority
> higher
> > > than others.
> > >
> > > > 3) any drawbacks using Data Guard.
> > >
> > > You should set your database or critical
> tablespaces
> > > to force logging mode
> > > in order to transfer all changes to standby in
> > > physical standby. That means,
> > > performance improvements which take advantage of
> > > nologging operations (such
> > > insert append nologging etc), will not run that
> fast
> > > anymore.
> > > In logical standby, I think there's no such
> > > requirement, but I don't
> > > recommend you to use logical stby yet, it's more
> > > like a prototype currently,
> > > not exactly a working product.
> > >
> > > Tanel.
> > >
> > >
> > > --
> > > Please see the official ORACLE-L FAQ:
> > > http://www.orafaq.net
> > > --
> > > Author: Tanel Poder
> > > INET: tanel.poder.003_at_mail.ee
> > >
> > > Fat City Network Services -- 858-538-5051
> > > http://www.fatcity.com
> > > San Diego, California -- Mailing list and
> web
> > > hosting services
> > >
>
>---------------------------------------------------------------------
> > > To REMOVE yourself from this mailing list, send
> an
> > > E-Mail message
> > > to: ListGuru_at_fatcity.com (note EXACT spelling of
> > > 'ListGuru') and in
> > > the message BODY, include a line containing:
> UNSUB
> > > ORACLE-L
> > > (or the name of mailing list you want to be
> removed
> > > from). You may
> > > also send the HELP command for other information
> > > (like subscribing).
> >
>
>________________________________________________________________________
> >BT Yahoo! Broadband - Save £80 when you order
> online today. Hurry! Offer
> >ends 21st December 2003. The way the internet was
> meant to be.
>
>http://uk.rd.yahoo.com/evt=21064/*http://btyahoo.yahoo.co.uk
> >--
> >Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> >--
> >Author: =?iso-8859-1?q?Nalla=20Ravi?=
> > INET: vvnrk2001_at_yahoo.co.uk
> >
> >Fat City Network Services -- 858-538-5051
> http://www.fatcity.com
> >San Diego, California -- Mailing list and
> web hosting services
>
>---------------------------------------------------------------------
> >To REMOVE yourself from this mailing list, send an
> E-Mail message
> >to: ListGuru_at_fatcity.com (note EXACT spelling of
> 'ListGuru') and in
> >the message BODY, include a line containing: UNSUB
> ORACLE-L
> >(or the name of mailing list you want to be removed
> from). You may
> >also send the HELP command for other information
> (like subscribing).
>
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> --
> Author: Carel-Jan Engel
> INET: cjpengel.dbalert_at_xs4all.nl
>
>
=== message truncated ===
BT Yahoo! Broadband - Save £80 when you order online today. Hurry! Offer ends 21st December 2003. The way the internet was meant to be.
http://uk.rd.yahoo.com/evt=21064/*http://btyahoo.yahoo.co.uk
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: =?iso-8859-1?q?Nalla=20Ravi?=
INET: vvnrk2001_at_yahoo.co.uk
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Mon Dec 08 2003 - 16:54:25 CST
