RE: Data Guard to Logical Standby

Have you tested the overhead April?

We have been doing some testing and even under very heavy load, Streams
keeps up well and whilst it does have an overhead on the primary server
it is manageable. 

Where we did notice a very large overhead was when we tried streaming to
two different databases.  Capture once but apply remotely twice. That
killed the primary server off. I must admit I was surprised at that as I
would have expected the redo logs to have only been mined once (albeit
more data captured when dual streaming).

 

I did not spend a lot of time tuning and talking to an Oracle consultant
he expressed the opinion that there was not a lot of Streams expertise
around 

 

 

Blog available at www.jhdba.wordpress.com

 

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of April Wells
Sent: 01 May 2008 22:58
To: Ben.Wittmeier@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Data Guard to Logical Standby 

 

We were "going" to go this route, but the overhead on the OLTP would be
"too huge"

 

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Ben Wittmeier
Sent: Thursday, May 01, 2008 4:54 PM
To: April Wells; oracle-l@xxxxxxxxxxxxx
Subject: RE: Data Guard to Logical Standby 

 

You may also want to look into Oracle Streams.  It is more flexible than
dataguard.  For example, you can choose to capture only a specific
table's changes downstream.....

Regards,

Ben

 

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of April Wells
Sent: Thursday, May 01, 2008 9:48 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Data Guard to Logical Standby 

We are trying to create a logical standby database (solaris) using data
guard so we can use downstream data capture to populate a reporting
database (Linux) for historical reporting.

 

Any chance anyone has done this and can give me some pointers on what
I'm probably going to do wrong?

 

Can I set rules up stream on the source database on what tables I don't
want to have included in the data guard log apply or will it just apply
everything?  I'm trying to tough my way through the documentation, and
am stuck at the "uniquely identify rows" part.  It seems that EVERYONE
on the source system has a plan table and that doesn't have a primary
key.  Do I care?  Will it complain?

 

Should I create a primary key rely disabled on ALL of those plan tables?

 

Thanks for any advice

April

________________________________

 


Confidentiality Notice!
This electronic transmission and any attached documents or other
writings are confidential and are for the sole use of the intended
recipient(s) identified above. This message may contain information
that is privileged, confidential or otherwise protected from
disclosure under applicable law. If the receiver of this
information is not the intended recipient, or the employee, or
agent responsible for delivering the information to the intended
recipient, you are hereby notified that any use, reading,
dissemination, distribution, copying or storage of this information
is strictly prohibited. If you have received this information in
error, please notify the sender by return email and delete the
electronic transmission, including all attachments from your
system.

 


This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.



The information included in this email and any files transmitted with it may 
contain information that is confidential and it must not be used by, or its 
contents or attachments copied or disclosed, to persons other than the intended 
addressee. If you have received this email in error, please notify BJSS.
In the absence of written agreement to the contrary BJSS’ relevant standard 
terms of contract for any work to be undertaken will apply.
Please carry out virus or such other checks as you consider appropriate in 
respect of this email. BJSS do not accept responsibility for any adverse effect 
upon your system or data in relation to this email or any files transmitted 
with it.
BJSS Limited, a company registered in England and Wales (Company Number 
2777575), VAT Registration Number 613295452, Registered Office Address, First 
Floor, Coronet House, Queen Street, Leeds, LS1 2TW

Other related posts: