RE: Data Guard to Logical Standby

From: Baumgartel, Paul <paul.baumgartel_at_credit-suisse.com>
Date: Thu, 1 May 2008 16:03:08 -0400
Message-ID: <21469B88E0EA11498818517F2103353101C662ED@EPRI17P32001A.csfb.cs-group.com>


The assertion that "all it does is ship the logs" is incorrect. A logical standby is very different from a physical standby, as I said before.  

Paul Baumgartel
CREDIT SUISSE
Information Technology
Prime Services Databases Americas
One Madison Avenue
New York, NY 10010
USA
Phone 212.538.1143
paul.baumgartel_at_credit-suisse.com
www.credit-suisse.com  


From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of April Wells Sent: Thursday, May 01, 2008 3:25 PM
To: Howard Latham
Cc: oracle-l_at_freelists.org
Subject: RE: Data Guard to Logical Standby

Okay... I'll buy that.  

However...  

On the logical standby, can I create users that are not in the primary database? I'm trying to multi-purpose this database rather than "just" being a transformation database between solaris source and linux destination by keeping historical data and giving us an alternative place to run some batch reporting. But I don't want to rely on the fact that the data and structures are all representative of the up stream primary.  

Or am I stuck with "just" having the ability to structure the whole database as if it were the primary?  

April


From: Howard Latham [mailto:howard.latham_at_gmail.com] Sent: Thursday, May 01, 2008 2:09 PM
To: April Wells
Cc: oracle-l_at_freelists.org
Subject: Re: Data Guard to Logical Standby  

AFAIK
All it does is ship the logs from one db (target) to another (standby) You cant filter anything.

2008/5/1 April Wells <awells_at_netspend.com>:

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.

-- 
Howard A. Latham


==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================


--
http://www.freelists.org/webpage/oracle-l
Received on Thu May 01 2008 - 15:03:08 CDT

Original text of this message