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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > > >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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > === 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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
