Re: Oracle Data Guard

Comments inline

At 14:54 8-12-03 -0800, you wrote:
>Hi Carel,
>
>That is good help, can you please send me the pdf that
> you implemented there then.

Was on its way already

> 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.

Because LSB 'reverse engineers' SQL from the redolog info, it needs to get hold of the right rows. The rows get inserted/updated/deleted, and _a_ unique identification, not being the rowid, is required. So, every row needs to be uniquely identified.

>Have you implemnented LSB successfully?

Yes, using a PSB / LSB combination for standby and reporting purposes respectively.

>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).

Regards, Carel-Jan

• There will allwasy be another 10 last bugs --

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Carel-Jan Engel
  INET: cjpengel.dbalert_at_xs4all.nl

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).